Deep Dive: Composability
The Condition That Makes Technology Serve Evolution, Not Just Use Cases
The Installation Problem
Most technology deployments are installations, not architectures. They are built to solve a specific problem in a specific context for a specific moment. They solve it. And then the organization tries to use them for something adjacent, something slightly different, something that emerged after the deployment was complete. The system resists. Workarounds accumulate. The deployment that was supposed to extend organizational capability becomes a constraint on it.
This is not a technology failure. It is a composability failure. The system was assembled for a use case. It was never designed to be reassembled for an evolving need.
Composability is the principle that separates technology that serves a use case from technology that serves evolution. It is the condition that determines whether a deployment can be reconfigured as the organization changes, or whether it must be replaced when the organization outgrows the problem it was originally built to solve.
What Composability Actually Is
Composability is the capacity to assemble and reassemble a system from interoperable units to serve different needs without rebuilding from scratch.
Three elements of that definition carry distinct weight.
Interoperable units means the units can work together because they share a common interface language. They were not built to fit each other specifically. They were built to fit a standard that allows them to fit anything that speaks the same language. Interoperability is what makes reassembly possible. Units that were designed only to fit their current neighbors cannot be composed into new configurations. They can only be reinstalled in the arrangement they were built for.
Assemble and reassemble means the act of combination is repeatable and reversible. A composable system is not assembled once and fixed. It can be taken apart and put back together differently when the need changes. The cost of reassembly is low because the units were designed for it. If reassembly requires significant engineering work, the system is not composable regardless of how it was described at design time.
Without rebuilding from scratch means the existing units retain their value across configurations. An organization does not discard what it has built when it needs something different. It reconfigures it. This is the economic argument for composability: the investment in each unit compounds across configurations rather than being written off when a use case ends.
How Composability Differs From Modularity
Modularity and composability are related but distinct. Confusing them produces systems that have one without the other, which in both cases is insufficient.
Modularity is the structural condition: bounded, independently evolvable units. It governs how a system is built. A modular system can evolve its parts without cascading failure. But modular units do not automatically compose. They can be independently evolvable and still speak incompatible interface languages that prevent them from being assembled into new configurations.
Composability is the operational condition: interoperable units that can be assembled and reassembled. It governs how a system is used and reused. A composable system can be reconfigured to serve new needs. But composable units without modularity underneath them become brittle over time. The configurations can be changed, but the units themselves cannot evolve, and eventually the units fall behind the needs the configurations are trying to serve.
Modularity without composability gives you a system whose parts can evolve but cannot be rearranged. Composability without modularity gives you a system that can be rearranged but whose parts cannot evolve. Both are partial. The full condition requires both: units that can evolve independently and that can be assembled into any configuration the need requires.
Why Organizations Build Without It
The same pressure that produces tight coupling produces non-composable systems. Building for a specific use case is faster than building for composability. The units are shaped to the problem at hand. The interfaces are specific to the current context. The assembly is efficient for right now.
The cost appears when the organization needs something different. If the units were shaped to their current problem, reshaping them for a new problem requires significant work. If the interfaces were specific to the current context, connecting them in a new configuration requires translation work that should not exist. If the assembly was efficient for right now, it is inefficient for anything else.
The organization finds itself doing one of two things. It builds a parallel system for the new need, which means two systems to maintain, two sets of assumptions to keep coherent, and eventually a decision about which one to retire. Or it extends the existing system beyond what its design supports, accumulating technical and strategic debt until the weight of the extensions makes the system harder to work with than starting over.
Both paths were created at the design stage, when composability was not treated as a requirement.
The Three Failure Modes of False Composability
Organizations frequently describe their systems as composable when they are not. The appearance of composability without the substance produces three specific failure modes.
Configuration masquerading as composition. The system has settings, toggles, and parameters that can be adjusted. It feels flexible. But the underlying units are still shaped to a fixed purpose. Changing the configuration changes the behavior within a fixed design space. It does not compose new capabilities from existing units. Configurability is not composability. A configurable system can be adjusted. A composable system can be reconstituted.
Integration masquerading as interoperability. Two units have been connected. An integration layer translates between them. It works. But the translation layer is specific to these two units in this configuration. Connecting either unit to anything else requires a new integration layer. The units are not interoperable. They are integrated. Integration is point-to-point. Interoperability is universal. A system built on integrations is composable only to the extent that integrations have been built. A system built on interoperable units is composable into any configuration that requires them.
Assembly masquerading as composition. The system was assembled from multiple units. That assembly is treated as evidence of composability. But the units were assembled once and the assembly has never been changed. Composability is not a property of having been assembled. It is a property of being reassemblable. The test of composability is not whether a system was built from parts. It is whether those parts can be taken apart and rebuilt into something different without significant cost.
What Genuine Composability Enables
When composability is real, three things become possible that are not possible without it.
Capability reuse across contexts. A unit built for one purpose can contribute to a different purpose without being rebuilt. An organization that has built strong data processing capability can apply it to a new analytical need by composing it with new units rather than rebuilding the data processing from scratch. The investment compounds rather than being written off when the original use case ends.
Incremental capability expansion. New capabilities can be added by introducing new units and composing them with existing ones. The organization does not need to anticipate every future need at design time. It needs to ensure that what it builds can be composed with what it will build later. This is the architectural equivalent of leaving the right doors open.
Graceful retirement. Units that are no longer needed can be removed from the configuration without taking the system down with them. A deprecated technology, a superseded model, an outdated process can be replaced by composing a new unit into the configuration in its place. Retirement becomes a composition operation, not a surgery.
These three capabilities are what separate organizations that can adopt new technology incrementally from organizations that must undergo periodic large-scale transformations to stay current. Incremental adoption is only possible when the existing system is composable enough to accept new units without resisting them.
Composability in AI and Agentic Deployments
AI deployments expose the cost of non-composability faster than any previous generation of technology, because AI capabilities evolve faster than the organizational contexts they are deployed into.
Consider what happens in practice. An organization deploys a language model into a customer-facing process. The model is integrated directly into the workflow: its output format, its response patterns, and its decision thresholds are all assumed by the downstream system. Eighteen months later a substantially better model is available. The organization evaluates the upgrade and discovers that adopting it requires rebuilding significant portions of the downstream system because those portions were built around assumptions specific to the current model. The upgrade cost is prohibitive. The organization stays on the inferior model. The gap between what it is using and what is available widens with every subsequent release. That is the treadmill. It was built at the integration stage, when composability was not treated as a requirement.
A composable AI deployment separates the model from the system that uses it, the data from the processing that acts on it, and the orchestration from the intelligence it coordinates. Each of these can then evolve independently and be composed with whatever is current in each domain. The organization does not need to be ahead of AI development. It needs to be composable enough to integrate what AI development produces as it produces it.
For agentic deployments specifically, composability determines whether agents can be assembled into configurations that serve evolving organizational needs. An agent built for a specific narrow task that cannot be composed with other agents is an installation. An agent built with a clear interface that can be composed into multi-agent configurations, handed off between systems, and integrated with future capabilities is an architectural investment. The difference is a design decision made at the beginning. It does not cost more to make the right decision there. It costs considerably more not to.
The Principle Applied
Composability is a design commitment, not a property that emerges from good intentions. It requires deciding at the beginning that the units being built will speak a common interface language, that the assembly will be designed to be reassembled, and that the value of each unit will be measured across its reuse in multiple configurations rather than its performance in the one it was originally built for.
That commitment changes how organizations think about technology investments. A composable unit is not an expense tied to a use case. It is a capability that compounds across every future configuration it participates in. The organization is not buying a solution. It is building a vocabulary of capabilities that can be composed into any solution the future requires.
The organizations that understand this build differently from the organizations that do not. They invest carefully in interface design. They resist the shortcut of building units that are optimized for their current context at the cost of their future reuse. They treat composability as a strategic property rather than an engineering detail.
The result is not a more complex system. It is a more durable one. A system that serves the organization it was built for today and can be reconfigured to serve the organization it becomes tomorrow.
Human in Meaning provides the orientation for what that reconfiguration is in service of. Composability provides the structural condition that makes reconfiguration possible at all.
Without composability, you are not building for evolution. You are building for installation. And installations, however well built, eventually become the thing that needs replacing.
This Substack is from Sebastian Thielke. You know him as Schwarzpfad. You can find all about him here: sebastianthielke.com