Below, an unmissable episode of the Boundaryless Conversations Podcast where I spoke about architectural innovation - among other things - with

A recent 2024 study by Likun Cao, Ziwen Chen, and James Evans, titled “Modularity, Architectural Innovation, and New Venture Success,” offers, I believe, a good integration to the seminal view of Henderson and Clark. The paper looks at the innovation question by turning the “Architectural Innovation” lens on the entrant instead of the incumbent: for startups, they argue (with numbers) innovation often means assembling mature existing modules from distant economic sectors into a new configuration nobody has tried, and it does it by examining nearly 300,000 startups over the past 50 years.

That is the thread of this issue: unbundling - something I advocate for to organizations as fundamental - is not - and it shouldn’t be - just housekeeping. It decides whether an organization gets to innovate at all in an economy where innovation increasingly means rearchitecture rather than invention; it decides whether that innovation can be driven by the many rather than monopolized by the board, and as I will argue toward the end, it decides which kinds of institutions at all an organization is even able to become in an era that may require new institutional forms to be created.

Architecture beats invention

Cao, Chen, and Evans’ paper presents architectural innovation enabled by modularity as the safest and most successful strategy, while explaining how inventing new modules and incrementally swapping one module within an existing stack both increase the odds of failure. The magnitude is striking: across almost 300k U.S. venture-funded firms from 1976 to 2020, a maximal shift toward architectural innovation raises the likelihood of an IPO or a high-value acquisition, while a comparable shift toward modular innovation lowers it.

Uber is the canonical case; GPS, digital payments, two-sided marketplaces, reputation systems, and contractor labor were already on the shelf, and the innovation lived entirely in the rewiring.

What I keep seeing in the field with my (wisest) clients is the operationalization of this principle, and it has a shape we have described before. In TTB 4 I laid out the recurring three-layer pattern, core, supporting, generic, and the progressive modularization cycle (Innovate, Leverage, Componentize) that animates it, so I will not reinstate it fully here: the point that matters is to understand the dynamic.

Core units, close to the market, develop genuinely new capabilities; over time, those capabilities should be progressively modularized and pushed down into supporting units, often as modular technology platforms (node micro-enterprises in Rendanheyi, for example), where they harden into components that other units, first and outside partners later, can build on cheaply.

That is the supply side of architectural innovation: componentization is the act of stocking the shelf. Where the paper measured the outcome as a one-off founding bet happening in startups, what I see in composable organizations is a continuous operating property that becomes ever more important as we go: to innovate, your organization must first survive in a rapidly changing world.

This - as often happens - is actually not new: Herbert Simon provided the deep rationale for considering both perspectives (adaptation - and not only architectural reinvention) in his seminal 1962 paper “The Architecture of Complexity” through the concept of nearly decomposable systems. Modular assembly, he argued, hedges against catastrophic failure: near-decomposability (the property by which a complex system can be broken into subsystems that interact weakly across boundaries and strongly within them - modules) is not just a nice design preference but a key property of a system that wants to be adaptable.

Systems without it accumulate fragility faster than they accumulate capability. The organizational corollary is that capability nodes (or micro-enterprises) we work with at Boundaryless are not just fancy teams with unusual names but an attempt to deliberately engineer near-decomposability into an organization, so that each unit carries high internal coherence, end-to-end accountability, and a bounded surface of contractual exposure to its peers.

While explaining why that structure survives, Simon left open how autonomous modules coordinate once the hierarchy thins out: that is the gap where - I believe, today more than ever with the advent of AI - contracts, shared context engineering, shared platform layers, and (agentic) interfaces have to do the work.

From what we can do to what we value

There is a distinction the paper does not dwell on, but that I believe matters enormously. While modular invention and innovation (where we innovate a single new capability) enlarge what an organization can do and the stock of new things it can make, architectural innovation is a move in the space of outcomes.

From a given supply of capabilities, architectural innovation selects which configuration to actualize and, therefore, which result to pursue.

While capability building is close to value-neutral (the same modules wire into a dozen different ends), architecture is where the ends are chosen, and the moment you choose ends, you are expressing which values you intend to generate, which things you will and will not do, and which ecosystemic relationships you decide to feed.

You cannot recombine a monolith

Put the finding to work, and a single argument will follow: if architectural innovation is the winning move, and it is the recombination of modules across boundaries, then an organization’s capacity to innovate is bounded by two quantities: the supply of mature modules it can reach, and its own decomposability into modules that can take part in someone else’s recombination.

Inward, an organization that has unbundled itself, enabling platforms separated from vertical solutions, capabilities made discoverable and contractible, can recompose its own modules around a new opportunity without a reorganization and without a budget cycle, so the operating model becomes the execution environment rather than a slide about it.

A monolith cannot follow because its capabilities are fused, vertically integrated, its interfaces are implicit, and every recombination becomes a renegotiation of identity. Outward, in the direction the Cao paper implies, architectural innovation at the scale of an economy depends on a supply of modules that others can actually pick up; to be assembled into someone else’s winning configuration, or to fold theirs into yours.

Your organizational capabilities have to exist as modules with explicit interfaces, and if you are a monolith, you are not on the shelf, so the innovation proceeds around you with other people’s parts. Unbundling is how you innovate on yourself, and it is also how you earn the right to participate in innovation you did not originate.

Architectural innovation cannot be a board monopoly

Here is where I want to push past the conclusions in TTB 4: if architectural innovation is continuous rather than a founding bet, then someone has to keep driving it, and the default answer that almost every company I have worked with initially gives is that it falls to the board. Well, that is the failure mode hiding in plain sight.

When the center is the only actor allowed to run a recombination, the organization can run only as many architectural experiments as the board has management capability for, and the whole promise of modularity collapses back into a bottleneck. A unit that spots a way to combine its capability with a peer’s or an external partner’s has to queue for permission, and by the time permission arrives, the configuration may have moved.

The way out is to split the responsibility rather than centralize it. The board keeps two genuinely strategic acts: evaluating investments, which is to say allocating capital, and setting the enabling constraints the whole system runs inside. These are two genuinely important responsibilities that a board cannot shave off. In my experience, boards or founders often understand capital allocation but miss their responsibility to create reconfiguration and collaboration frameworks that enable units to recombine capabilities.

If every agreement between units, or between a unit and a partner, has to be improvised from scratch or escalated to the center for translation, distribution is a fiction. What units need is a common grammar of agreements (missing across almost every - even the latest - organizational-design schools): a way to strike, compose, and honor agreements peer to peer, so that architectural innovation becomes something the edges of the organization do continuously, not something the top signs off on occasionally.

That’s why we’ve created O2A and Orchestrion at Boundaryless: we believe these languages don’t have to be reinvented all the time.

Choosing the constraints is the instituting act

In his latest “Shaping Future Institutions” Geoff Mulgan (2026) - a British academic, author, and social entrepreneur, Professor of Collective Intelligence, Public Policy and Social Innovation at UCL who previously led Nesta and the Young Foundation - walks through economics, computer science, organizational studies, complexity theory and design, asking what each contributes to the design of institutions, and finds that none of them systematically studies how to design new ones: people building public institutions he argues still reach for options drafted half a century ago.

We hosted Mulgan on the Boundaryless Conversations Podcast a few years ago, and he was already arguing for an extended discipline of institutional architecture. In his latest, he argues that institutions are, in fact, information-processing architectures, and that:

“modular institutions with clearly defined interfaces between components are easier to reform, audit, and upgrade than monolithic ones”

We have written about the shift toward regenerative constraints: in a recent article, we argue that regenerative organization development (which effectively means institutional innovation) requires moving beyond just profit and loss as the sole forcing function. We propose extending decentralized, entrepreneurial operating models to multiple forms of value (financial, ecological, social, cultural, and learning capital). The challenge - we believe - and the failure mode of many attempts to institutional impact is not merely to measure this value (which is certainly a big deal), but to embed it into interfaces, incentives, budgets, and decision-making so that the innovation remains architectural, adaptive, and non-bureaucratic.

Mulgan’s 2026 essay is the same call, three years on, now accompanied by documentation showing that the discipline still has no home: a structural vacancy that someone has to fill with an operational rather than aspirational method.

Why this needs more than APIs

This is the vacancy Boundaryless has spent years formalizing in the O2A (Open Organization Alliance) standard, a grammar that lets every organizational node be at once a structural module, with clear boundaries and contracts, and a semantic module, able to declare its offerings, constraints, and dependencies in machine-readable form. At the moment, the O2A covers basic contract grammar, agreements, purchase, revenue split, and investment, plus composition- and outcome-based triggering, where a value you decide to generate becomes a milestone a contract can settle against; it is the base language the entrepreneurial units need to coordinate architectures among themselves. That is what turns “we are modular” from a diagram on a wall into something a partner, or an agent, can act on. The O2A will grow in time to include more and - we hope and believe - become one of the attempts to build architectural language for organizational and institutional innovation needed in the 21C, and we are searching for allies, so reach out to us if you want to be one.

It is tempting to file all of this - the regenerative, the societal, the institutional - under someone else’s problem. In Beyond Tomorrow (2026), the BCG Henderson Institute, not an activist think tank, names embracing a broader societal role (along with organizational modularity) as one of five low-regret moves that pay off across every scenario it modeled. As public institutions fray, companies are being drafted to carry workers’ well-being, local resilience, crisis management, and the needs of the communities they operate in. That quietly dissolves the lazy distinction we lean on when we think the institutional problem is out of reach for commercial organizations.

Institution is just a durable set of constraints that allocates value over time, and that is what an organization becomes the moment it takes its constraints seriously. The membrane between the two is thin, and thinning. Choosing the constraints was always institutional design; we were just calling it strategy.

Below, a recent episode of the Boundaryless Conversations Podcast where I spoke with Nikolaus Lang about Beyond Tomorrow from BCG Henderson Institute

The times in which firms competed on what they owned are transforming into one in which they focus on what they can mobilize and contribute. Cao, Chen, and Evans highlight this shift from the perspective of newcomers succeeding by recombining existing modules rather than inventing new ones; Mulgan honestly admits that the discipline for designing institutional innovation is lacking; and our contribution is the operational layer that supports both ideas.

Curated Links

The Coming Organizational Meltdown

Tobaccowala’s fusion of IT and HR and the death of the job as an atomic unit is the clearest recent statement of superstructure dissolving: the container melts before anyone builds what it was implicitly holding.

AI Agents as Coordination Technology

Kosters frames agents as the infrastructure that collapses coordination costs, making composition viable at scale; the caveat is that the collapse is uneven across codifiable and contextual knowledge.

Post-agent companies

The “give away the labor, capture the network” logic is a live instance of the O2A wager: when cognitive labor approaches zero, the defensible layer is the contractual and semantic one (who does what, for whom, under which agreement) > context engineering becomes ecosystem engineering.

Shaping future institutions

Mulgan diagnoses the absence of any institutional design science, and one line does the work of a manifesto: “Modular institutions with clearly defined interfaces between components are easier to reform, audit, and upgrade than monolithic ones”; in short, our thesis.

Modularity, Architectural Innovation, and New Venture Success

Cao, Chen, and Evans provide the empirical backbone: across 300,000 ventures over 45 years, recombining mature modules beats inventing new ones; the evidence that composition, not creation from scratch, is the economically viable path.

The Rebel Alliance

USV maps the agentic AI stack as structurally distributed, forcing open interfaces and layer specialization.

Work Updates

A dense fortnight, with two releases we’ve been building toward for a long time.

• O2A is live. We shipped the first version of the O2A (Open Organization Alliance) standard alongside the new Boundaryless website. This is the thin-waist layer the essay above keeps pointing at: the minimal canonical model of nodes, contracts, offerings, and ledger events that makes capabilities composable for humans and agents. It is now public and inspectable.

• Orchestrion is open for private demos. Our stateful execution OS, which implements O2A, is available in private beta for our customers. This is where the model stops being a diagram and becomes a live, auditable composition runtime: would you like to understand your gaps to be ready to use it? Just reach out.

• All Boundaryless methodologies are now searchable. Years of methodology that lived inside monolithic, non-indexable documents are now published on our documentation website alongside O2A. Someone called it “Alexandria’s library.” It is far more useful as a queryable resource than it ever was as a set of PDFs and, fittingly, it makes our own context legible.

• Platform strategy in the field. We are running a strategy engagement with a client moving from being one player in their ecosystem to becoming the ecosystem organizer. The challenge is the durable one: how do you turn competitors into customers, and help every professional in the space become the best version of themselves?

If your organization is feeling the meltdown Palmer describes (management thinning out, capabilities that exist somewhere but cannot find each other…) I’d genuinely like to hear about it.

The second was Alexey Krivitsky, co-author of 10x Organizations and Org Topologies, whose work has been on my radar recently because I felt an overlap with what we are doing on topology at Boundaryless. Org Topologies integrates the organizational-topology conversation with evolution, as we do, and places a strong focus on contextualization and the dangers of adopting frameworks blindly. Both came with their own vocabularies, their own diagrams, their own examples. Neither knows the other’s work very well (I assume), yet when I drew their distinctions side by side, along with other approaches, three structural categories emerged that mapped onto one another with incredible precision. This is not new to me.

Anyone who has been putting out genuinely important ideas about how we organize work in complex organizations over the last fifteen-plus years has arrived at a similar system.

Matthew Skelton and Manuel Pais, in what’s probably the best-known framework, thanks to the widely read book Team Topologies (IT Revolution, 2019), pattern four team types in a (now-familiar) shape: stream-aligned, enabling, platform, and complicated-subsystem teams. Eric Evans, in the seminal Domain-Driven Design (Addison-Wesley, 2003), carves software organizations into core, supporting, and generic subdomains. The genuinely transformative work of Simon Wardley gave us Explorers, Villagers, and Town Planners (three attitudes mapped to the three stages of his evolution axis), as well as the Innovate-Leverage-Componentize framework for understanding innovation. Haier’s Rendanheyi, made open and accessible through Boundaryless’s 3EO methodology developed with HMI (Haier Model Institute), uses User Micro-Enterprises, Node Micro-Enterprises, and Shared Services.

All these communities, who mostly do not read each other (sometimes bordering on conflict), emerged from different problem spaces. IT delivery flow, management theory, software modeling, strategic evolution, Chinese industrial transformation, and agile transformation. The fact that they converge on the same system-of-three reflects something deep about how modular and composable organizations of any non-trivial scale actually work and about the three key shapes that the work of organizing typically takes.

The convergence at two levels

To see this concretely, it helps to lay the schools side by side into what I think is one of the most useful ways to clarify that this convergence operates at two levels, not one: teams and units.

Some schools focus on the capability (or unit) level and ask how such units can be organized within a larger, more complex organization. Here, the unit is the entity in focus: autonomous in delivering a specific set of offerings, P&L-bearing (real or simulated, if internal), market-facing or market-adjacent, and capable of setting its own strategic direction.

Org Topologies, Wardley’s ILC plus EVTP, and Rendanheyi/3EO typically sit here:

Each row encodes a particular combination of market exposure (does the unit face external customers? or can), capability distinctiveness (is what the unit does unique to this organisation, or could it be bought on the open market?), and the direction of strategic autonomy (does the unit decide where it is going, or does it depends on a certain level from enabling scaffolding or centralized decisions?).

Other schools sit more explicitly at the team level (generally a two-pizza team of seven to twelve people). A unit (or organization without sub-units) typically contains one or more teams, and the team patterns describe how the unit organises internally. This is the space where DDD and Team Topologies have traditionally been applied.

BetaCodex is the interesting borderline case here. Cell Structure Design (Silke Hermann and Niels Pflaeging, 2019) builds the whole organisation as a network of team-sized cells, and those cells carry unit semantics: periphery cells hold the market contact, and they purchase services from the centre cells, paying for them. The cell is, in effect, a unit made team-sized – 0collapses the two levels into one. I keep it in the table below because the team scale is where its cells live, but its economics belong to the unit-level conversation.

Read together, the two tables make a simple point: the unit-level schools and the team-level schools operate at different scales. The top table classifies the type of unit you are looking at; the bottom table classifies the type of team that operates within it. They sometimes use the same word – “platform” is the obvious one as it names a unit archetype in one column and a team type in another.

The conflation of these two levels has been, in my reading, the main source of conceptual noise in the org-design discourse of the last decade. Practitioners have at times argued across them as if Team Topologies and Rendanheyi were directly comparable frameworks, when they describe the same phenomenon at different scales of analysis. Once the two levels are separated, the convergence at the unit level becomes obvious, and the team-level patterns become recognizable as how a unit organizes internally, given its archetype. On the other hand, the fact that the language repeats itself suggests that they somehow track the same fundamental dynamics.

I have had direct experience modeling a single Node ME (a technology platform provider) inside a larger industrial company built on a hardware-software portfolio.

Internally, the unit largely operated as a stream-aligned team, but executed a long-term strategy that was largely sponsored and designed by the board, setting the strategic direction. We might be tempted to say that such an architecture does not bode well for autonomy: why should anyone set the strategy centrally? But that is not how things work once development cycles become more strategic and long-term. The fact that such a unit was not made entirely accountable to market signals and retained a certain level of translation of a product development vision into strategy (accumulating a certain risk of being wrong) was also about ensuring the platform unit supported the downstream roadmaps of the market-facing solution units, effectively serving an enabling role in roadmap alignment.

At the same time, as maturation increases, any sane company would try to counteract the captive-market signals from its own product units by opening its platform capabilities to ecosystem partners in an effort to “sense the future,” as Wardley would say.

It is precisely to meet this need that Haier introduced the concept of Node Micro-Enterprises: to instill autonomy, accountability, and healthy tension within the organization.

The team patterns are derivative. They describe how a unit organizes itself given its archetype, market exposure, capability mix, and the constraints the organization places on it. Different units configure their internal teams differently, with different topologies. The convergence is at the archetype level; the team patterns vary within the design freedom that an archetype allows, and that’s exactly what Org Topologies delivery topology explains: in a Node ME / or a technology platform inside a company, serving multiple product units, you may have one team that steers and one that executes.

Why the convergence is not a coincidence

In my experience, this convergence is driven by three economic relationships that exist in any organization above the scale of a small start-up. The first is the relationship with the market: certain units face external customers and bear the consequences of being wrong. They are typically the differentiating ones, the “core” domains of value.

The second is the relationship between those market-facing units and the unique internal capabilities they depend on. These internal capabilities are what make a specific organization distinctive: such units serve other units with something special, even when it is not directly priced in the market.

The third is the relationship with commodity overheads: units doing work the market could supply, but kept internal for reasons of efficiency, coherence, or coordination.

These three types of units also have a clear relationship to innovation. Core nodes provide vertical solutions for the primary use cases of the organization’s end-users; they “operate” the organization’s purpose. Supporting nodes typically “integrate” the diverse needs coming from the market, mediated by the core unit, into more general layers; they become shared “platforms” that support the vertically focused units and push them towards more specialized innovation. Core nodes innovate, supporting platforms leverage, and over time they componentize – standardizing interfaces and modules for others to use more cheaply – so that both internal units and external ecosystem partners can innovate on top.

These internal platforms serve cross-unit needs such as identity, data, UX, and core hardware-software capabilities, while the verticals (solutions) address ICP-specific outcomes. The guiding principles are simple: cleanly separate enabling platforms from vertical solutions and services, and make the bundling of the two a first-class composition.

As maturity grows, the system evolves through the ILC cycle (Innovate → Leverage → Componentize):

• It captures emerging needs in the core units, spreads them across solutions

• Then standardize them into stable, reusable components to first reduce the cost of innovation internally and later into APIs, SDKs, and modular hardware to promote them into open platforms as shared building blocks for partners

Verticals explore and win on variety and speed, enabling platforms to standardize and scale for coherence and efficiency. Over time, the ILC loop continuously converts proven solution elements into durable platform leverage.

A language for composition

Agreeing on the categories is the easy half. Operationalizing how these units actually interact in a real organization is the hard half. Organizations often lack the collaboration frameworks that would allow units to align autonomously, largely because we still tend to view organizations in industrial terms: vertically integrated, functional, and managerial.

Team Topologies pioneered this space with its “interaction modes” – collaboration, X-as-a-service, and facilitating – but never addressed actual contracts, still implying an organizational authority that assigns roles. Org Topologies maps positions on a grid without specifying the economic relationship between the units that form around its three basic topologies (Resource, Delivery, Adaptive).

Domain-Driven Design offers a genuinely rich set of context-mapping patterns (Customer-Supplier, Partnership, Conformist, Open Host Service, Anticorruption Layer) describing how bounded contexts integrate semantically, but stops short of the economic relationship – who pays whom, who shares revenue, who carries the investment – partly because these patterns were always conceived for teams inside a broader socio-technical system and the responsibility of being accountable to the customer was never really 100% part of conversation.

As a result, the semantic side is well mapped; the contractual side is left implicit.

Simon Wardley is likewise largely non-normative on contracts, even though he recognizes the genuinely pioneering nature of Rendanheyi (and the 3EO), which has embedded contracting deeply into the organizational model, both node-to-node and in more complex configurations. Rendanheyi has adopted investment contracts (its Value Adjustment Mechanisms) as first-class citizens of the organizational grammar, and even invented the Ecosystem Micro-Community Contract, a multi-peer contract that binds several nodes around a complex achievement and introduces frameworks for adaptive governance and shared skin in the game. In their original expression, though, these have been demonstrated to be too Haier-specific institutional instruments rather than transferable primitives.

What is missing across all six is a generative grammar of contracts, plus a theory of the economic interactions between unit types. Both are pieces that Boundaryless has spent years of fieldwork formalizing through our upcoming Open Organization Alliance (O2A) standard (stay tuned and reach out if you’re interested in joining/exploring/pre-reading).

This essential grammar is, paradoxically, small. The three base primitives are:

• Purchase: Two units agree to provide a service with an SLA and a payment structure. In the early stages of the evolution, you may not see an actual payment, but at least an agreement specifying what is expected of both parties.

• Revenue-split: Two or more units agree to split revenues.

• Investment: one or more units agree to invest a capital amount into an investee node in exchange for equity-like ownership.

Two contract-level composition mechanisms complete the grammar:

• One for binding many contracts into a single binding agreement, typically across many units.

• One for outcome-based triggering, implemented with milestones unlocked either by payers or by oracles (shared sources of truth).

From these atoms, all the named instruments of the other schools can be expressed, and one can architect even the most complex – yet still reasonably manageable – composable organization setups.

In Rendanheyi, an EMC is just a revenue split between N parties, sometimes with a set of outcome-based triggering rules and a shared settlement engine. A VAM is an investment with outcome-based triggering: hit the milestone, receive more equity. In our generalized framework, they appear as recipes, borrowed from Rendanheyi but simplified from institutional monoliths into programmable compositions, because it is time to reach a common language for the platform organization.

If you practice Team Topologies, this reading enriches your toolkit by situating your team patterns within operating units. If you practice DDD, the unit-layer reading and the contract grammar together add two things to your toolkit. First, the unit-layer reading gives you a vocabulary for the organizational attachment of bounded contexts: Evans’s bounded contexts describe semantic boundaries, while the unit-layer reading describes the operating unit in which those boundaries live.

Second, the contract grammar gives you the economic layer beneath your context-mapping patterns. Each integration pattern Evans formalized has a natural counterpart in the grammar:

Context-mapping pattern What the pattern means Contract-grammar counterpart (intuitive mapping) Customer-Supplier The downstream context is a customer of the upstream one: the supplier plans around the customer’s needs, and the customer has a real voice in the supplier’s priorities Purchase contract with downstream negotiating power Conformist The downstream context adopts the upstream model as-is, with no influence over its evolution Purchase contract with upstream-dictated terms Open Host Service + Published Language The upstream context exposes one standardised protocol and shared language for all its consumers, rather than one-off integrations Purchase contract with a standardised service catalogue Partnership Two contexts succeed or fail together and coordinate plans and releases as peers Revenue-split or coordinated commitment Shared Kernel Two teams co-own and co-maintain a shared subset of the model and codebase Investment in a co-owned asset Anticorruption Layer The downstream context builds a translation layer to protect its own model from the upstream one Architectural choice inside one party, not a contract on its own Separate Ways The two contexts deliberately do not integrate at all No contract

So DDD tells you how two contexts integrate semantically; the grammar tells you what is being exchanged economically. They are complementary layers of the same picture.

Wardley practitioners get a contract type appropriate to each evolutionary stage.

Five invariants beneath the grammar

Beneath the grammar sit a handful of practical principles. In our field experience across radically different sectors, they hold at every unit-to-unit interface, regardless of school.

1. When a unit is deliberately shielded from market discipline, the party providing the shield must bear both the investment and the risk.

2. The development of a new capability in one node that is needed by another must be either directly funded, paid for with a share of the upside, or covered by an equity-class instrument (a shared cap table). It is never to be assumed as given.

3. Internal monopolies require governance discipline, or they become a tax on the rest of the organization.

4. Misaligned incentives between two units cannot be fixed by an SLA alone; revenue-share or shared bonus pools are the only mechanisms that genuinely re-align them.

5. Two units with high mutual dependency are one unit pretending to be two. The honest move is to consolidate them or to create real exit options.

These five heuristics are invariants you can’t ignore. Any composable architecture that ignores them eventually fails, and we have seen the failure mode in every engagement where one was violated.

The decade of rival vocabularies is closing

I think that - pushed by the need for deep-seated flexibility and interconnectivity - the decade in which each school proposed its own vocabulary as the answer, and we can argue forever that our framework is the right one, is closing.

What remains after the war is over is the substrate beneath it: the nodes, the contract grammar, and the principles that govern the interfaces. That substrate is what Boundaryless has been formalizing through the upcoming O2A (Open Organization Alliance) language, an open grammar for composable organizations.

The long-form version of this argument will appear in a forthcoming whitepaper. This piece is a practitioner-level note; the whitepaper does the long-form work and gives the fuller context.

Subscribe now

Curated Links

Team Topologies as the Infrastructure for Agency

Matthew Skelton argues that Team Topologies patterns create the organizational infrastructure needed when AI eliminates traditional hierarchy — exactly the “minimum viable structure” we need to identify.

Special Interview with Zhang Ruimin, Founder of Haier Group

Zhang Ruimin’s 20-year Rendanheyi experiment at Haier offers concrete proof that organizations can eliminate hierarchical superstructure while maintaining coordination through direct user value creation.

Welcome to the personal software revolution

The phenomenon of ‘vibe coding’ demonstrates how AI collapses traditional development infrastructure while making problem definition more critical — a perfect example of structure vs superstructure dynamics.

IC work is the new career flex

Elena Verna’s High-Impact Individual Contributor concept provides concrete evidence for how AI eliminates organizational superstructure while making individual capabilities more valuable.

The Best Companies Will Stop Making Software

The proposed brand-factory split illustrates how AI transforms organizational boundaries across entire industries, not just within companies.

Here Comes (Forward Deployed) Everybody

The emergence of ‘Pit Crew’ roles shows what minimum viable structure looks like in practice — structural roles that bridge generic AI capabilities with specific organizational contexts.

Human Bottlenecks

This analysis of why AI augmentation fails at the individual level explains why organizational transformation requires moving from governing constraints to enabling constraints.

Work Updates

The O2A (Open Organization Alliance) standard is now open for private feedback! At Boundaryless, we’re particularly interested in hearing from operators who are wrestling with the question of structure in their own organizations or from software companies that are operating across the same or - even better - adjacent topics such as governance, OKRs, etc…

Please reach out if you want to have early access for fedabck or to join our upcoming alliance.

Context engineering is the work of building systems that let humans collaborate with agentic contributors while retaining the capacity to observe, steer, and understand what’s produced, keeping outcomes aligned with the needs of customers and partner ecosystems.

The case for “deep-seated flexibility”

A few weeks ago, BCG’s Henderson Institute released Beyond Tomorrow: Four Scenarios for the World of 2050, and it has been an engaging read.

The report constructs four scenarios to evaluate the often implicit strategic assumptions underlying organizational strategy and development.

The AI Abundance scenario imagines a post-Compute-Wars world of cheap energy, tripled GDP, and AI-only firms. Battling Blocs is a multipolar stalemate where global trade falls and defense spending nearly triples in a re-regionalized world. Climate Coalition charts the stagnant dream of slow, expensive decarbonization disciplined by a $300-per-ton carbon price, while in Digital Darwinism, governments retreat (due to a failure in managing the climate crash), corporations fill the vacuum, we meddle with the atmosphere, and the wealthiest 1% holds nearly half of global wealth.

Currently, the world seems heading towards a mix of all four scenarios. While the scenarios diverge on growth, geopolitics, energy, governance, and demography, they converge on some strategic recommendations. Among the five “low-regret moves” BCG identifies as payoff-positive across all four futures, the same action recurs in a different form: organizational, operational, and technological modularity.

In AI Abundance, modularity defends against compressed technology cycles, modular IT architectures, multicloud and multiregion stacks, and “modular factories that can rapidly adapt to new innovations.” In Battling Blocs, it lets an organization disconnect from one region without collapsing the value chain, thanks to operating structures designed for “relatively easy separation of markets,” and supply networks that can run semi-autonomously while infrastructure is built for rapid swapping and reconfiguration. In Digital Darwinism, with weak institutions and violent markets, modularity becomes the architecture for surviving turbulence, stacks that can be “swapped, isolated, or localized” as conditions shift. In the hopeful scenario of Climate Coalition, modularity and legibility become key at the product layer: circular design and sustainability constraints require components that can be evaluated and recombined.

All these pressures demand a structural answer: an organization whose units, products, and technology stacks are composable. That holds across all four futures.

The convergence is not accidental. McKinsey’s 2026 State of Organizations report, based on a survey of 10,018 executives across 15 countries, reaches the same conclusion: 86% of organizations are unprepared for AI operations, 72% report direct geopolitical impact, and 38% cite rigid structures as the primary barrier. McKinsey describes three significant forces: Technology Disruption, Economic Disruption, and Workforce Shifts, which reflect deeper structural moves: AI redesigning markets by lowering coordination costs, constant boundary erosion between firms and partner ecosystems, and compressed planning horizons under polycrisis.

McKinsey calls for “deep-seated flexibility” but is frustratingly vague about its operational meaning, surprisingly so, because the operational answer has been practiced for years. We’ve described the evolution from functional to matrix to platform organizations for some time, and the implication has remained the same: deep-seated flexibility is what you get when you do the modularization work, not something abstract.

A deeper strategic pattern is emerging. We’ve been calling for companies to complement a platform motion (centralized on coherence and strong integration) with a portfolio motion. Disruptions and technological democratization have nudged companies toward radical optionality for a while, and AI intensifies this perspective by making portfolio motion dominant over platform motion. AI’s coordination capabilities reduce friction in composition and the portfolio motion, creating more options, empowering small teams to attack niche markets with multiple strategies, and making it more viable, reducing the need for traditional centralized approaches. I wrote about it recently in TTB 2, After the Platform.

Both reports miss the implications of the modularity prescription. When everything becomes composable and coordination costs approach zero, competitive advantage shifts from doing things well, which becomes commoditized, to doing the right thing. In an environment where individual optimization is insufficient and connection ability is decisive, something is “right” only if many others can read the same picture you can, and your strategy is wary of partners’ constraints, capabilities, and interests. Investing in shaping a direction and creating shared meaning becomes the work. Ecosystem partners need to converge on interfaces, workflow models, and integration contracts. Shared languages matter more than traditional business development.

Modularity without context engineering produces fragmentation, not composition. The pieces fit together only if they share a language at the boundary, which must be authored rather than assumed.

Consider two teams modularizing a customer-facing capability. One team defines “customer” as the paying account; the other means the end user. When they try to compose their modules, integration fails: not from technical incompetence but from semantic misalignment. The modules are independently correct and jointly incoherent. Multiply this across dozens of bounded contexts, internal teams and external partners, and you get the cost of modularity without shared meaning: drift. Interfaces accumulate ambiguity, and the organization loses the ability to reconfigure quickly.

Context engineering is the discipline that prevents this: explicitly authoring the concepts, boundaries, and constraints that let autonomous pieces compose into coherent wholes. This semantic work is the focus now.

When iteration goes cheap, intent goes expensive.

The transition inverts competitive advantage. For the past four decades, advantage came from operational excellence, executing known processes faster, cheaper, and more reliably. In the AI era, that gap compresses. When iteration is cheap, and the cost of producing a working artifact drops significantly, doing things well stops being the edge. It becomes the price of entry.

Execution capacity, once scarce, is now abundant. The answer to what we should be executing at all becomes the bottleneck. In software, the focus shifts from writing code to modeling business contexts, organizational capabilities, and ecosystem interactions. Gathering requirements turns out, in hindsight, to have been the strategic discipline all along; the cost of bad modeling was hidden under poor execution. AI makes it visible.

This makes intent the new scarce resource, and intent modeling and context engineering are the new strategic disciplines. As iteration becomes easier, we have more time to think. The hard work is upstream of execution: deciding which problems are worth modeling, which boundaries to draw, and which constraints to author into the system for downstream composable generation. Most of us aren’t investing that returned time effectively.

Subscribe now

What remains constant: the human at the boundary

One might think that AI, by making translation across contexts easier, reduces the need for explicit semantics. The opposite is true. As contexts multiply and the market fragments, so do the boundaries. Boundary languages become more important, not less, and not for machines to understand each other but for humans to read what happens at the boundary and drive it intentionally.

In a recent conversation with Alberto Brandolini, he reminded me of the distinction between internal and boundary models, which matters here. The internal language within a bounded context serves different purposes than the published language exposed to units and partners, responding to different evolutionary pressures. There will always be pressure for contextual freedom within domains, but the multiplication of AI-enabled contexts makes boundary legibility more crucial.

This connects to what I have come to think of as the invariant design constraint: human observability and interpretability.

If you build something at the limit of human observability and legibility, model evolution may not affect your product in meaningful ways. When designing new collaboration tools, use human cognitive limits as the primary design constraint rather than AI capabilities. Even as AI improves, human limits remain stable, which makes them a more durable foundation for organizational design than a shifting model frontier. You can design prosthetics that augment observation, a tool for engineers to review workflows faster, or a linting dashboard monitoring KPIs for software best practices, but ultimately, humans need to review, read, and close the feedback loop.

The primary value of context engineering, then, is not in tightly controlling AI outputs, but in maintaining intentional direction-setting and the ability to observe, evaluate, and comprehend the generated content. Subjecting our AI leverage to our understanding will keep things small, modular, and human.

Control matters less than clarity and strategic alignment.

Context engineering becomes the discipline of deciding which artifacts define truth and of authoring the constraints, both of which are central organizational capabilities.

Not a function. A discipline.

Context engineering is a pervasive organizational capability, not a technicality. Large organizations will need multiple context engines operating at different scales; each bounded context requires its own micro-context engine while maintaining coherence with the broader organizational ontology. External ecosystem players must participate in defining the languages, which represents a structural break from traditional platforms that imposed their own linguistic standards.

Context engineering is not about software. It’s a deliberate practice through the same framework across contexts where an organization builds artifacts by integrating agentic capabilities. Whether managing autonomous IT infrastructure, creating AI-assisted media, or recombining organizational capabilities with their interfaces and costs in response to customer needs, the same principles apply.

Three legs, one bundle

In our experience at Boundaryless, context engineering has a three-pronged architecture:

1. A deep meaning layer, typically a context map identifying the bounded contexts in scope, and a navigation language between the map elements describing the key objects existing at the contexts’ boundaries.

2. A business and problem logic layer detailing roles, their capabilities, and use cases with related scenarios, all mapped to the bounded contexts.

3. A user experience and interaction layer, explaining how the capabilities are available to users across interfaces, depending on the product(s).

The definition of all three layers cannot be fully delegated to AI. It must remain at human scale; if not fully human-produced in front of a board (ideal), it must at least be fully human-comprehensible.

A Context Bundle is the structured artifact that answers four questions:

• Which concepts are valid?

• Which problem areas are separate and can be developed independently?

• What abilities do actors have?

• What experience do users have?

It’s structured context readable by humans and usable by agents, versioned as intent changes. It provides a method to make organizational intent machine-readable while keeping it human-inspectable.

Whom do I choose to share context with?

Conclusion: in a world of microscopic, modular, adaptive, and AI-enhanced elements, the organization’s value lies in its ability to contextualize.

Identity is no longer defined by our actions but by our configurations, chosen constraints, preferred patterns, and accepted trade-offs.

When an organization decomposes into small, agent-powered units, context becomes the primary organizational attractor, replacing hierarchy, process, and culture as the forces that hold activity together. Hierarchy, process, and culture do not vanish, but become insufficient as primary coherence mechanisms in front of the unleashed generative forces.

The organizing question becomes: with whom do I choose to share context?

Context engineering is the new frontier of organizing. Companies that neglect it will keep telling themselves they can resist modularization by vertically integrating and managing up and down, and they’ll progressively lose coherence, sometimes gradually, sometimes abruptly.

Companies that get this right resemble living systems of meaning: pieces that rapidly reconfigure while keeping identity through constraints and shared intent.

Curated Links

Beyond Tomorrow: Four Scenarios for the World of 2050, April 2026, Nikolaus Lang et al. (BCG Henderson Institute)

BCG’s scenarios reveal that organizational modularity is the consistent strategic move across all possible futures, whether AI abundance democratizes coordination or digital Darwinism concentrates it among elites.

State of Organizations 2026: Three tectonic forces reshaping organizations (McKinsey)

McKinsey identifies “deep-seated flexibility” as the key organizational capability but stays vague about implementation, exactly the gap that explicit context engineering and modular capability-based organization design (RenDanHeYi / Platform Org) addresses.

Apps and programming: two accidental tyrannies

Matuschak’s lecture advocates for composable product architectures and demonstrates how shared semantic foundations (like CodeMirror’s physics) enable plugin ecosystems, encouraging us to think beyond applications. Increasingly relevant as we move into a software-infused age.

AI in World Machine Theory

Rao’s AI framework creating planetary-scale liveness through shared context and memory integration provides the macro lens for understanding how context engineering scales beyond individual organizations to ecosystem-wide coordination.

What is Artificial Experience (AX)

As humans become the limiting factor, the task is to become artificially intelligent, not like machines, but in consciously designing technological futures rather than sleepwalking into whatever emerges. AI as a problem for thought about how we wish to live, not just a problem to be solved.

The Culture of AI Engineering

The Pace Layers framework reveals why AI makes organizational structure more necessary: different context elements must operate at different speeds while maintaining coherence across the entire system.

Work Updates

We’re making progress on the context engineering framework through client deployments and technical development:

• Context Bundle implementation: we built and tested the first Context Bundle prototype, exploring how structured product intent can be made readable and operable by agents.

• O2A specification advancement: the Open Organization Alliance standard now includes formal semantics and is about to be released in its first public version. Discussions with the Protocol Institute about support are ongoing. If you don’t know what the Protocol Institute is, check it out.

I’m looking for design partners who recognize that their competitive advantage lies in context engineering rather than operational execution, and who understand that connecting that to the rest of the organization requires modularization. If you struggle to coordinate capabilities across internal teams and external partners, or see AI create more options than your structure can handle, I’d love to explore how these frameworks apply to your challenges.

At least three leadership teams from different industries (fintech, egov, energy services) have approached me using that exact phrase in the past two months. They have little in common except that, for various reasons, these industries are opening up.

Sometimes it’s a regulatory initiative aimed at breaking long-standing quasi-monopolies; sometimes it’s the effect of AI as an integration technology. In digitally ambitious countries - like India, for example - it’s often the creation of a Digital Public Infrastructure - sometimes for other reasons.

Layers of the value chain that incumbents owned end-to-end are now being cracked open at the protocol level, and the boardroom response is often reflexive: let’s now be the orchestrator before new entrants frame the market.

The platform answer is correct, and the ambition is fine. But it’s almost always incomplete: many product teams carry assumptions from a different era. The capital-P “Platform” (the market-shaping posture from the early 2010s, where one company became the meeting place for supply and demand) is no longer viable. As digitalization moves into real-world industries (energy, mobility, healthcare...), markets are too crowded, open, participatory, and filled with incumbents holding many value chain pieces that a wannabe platform strategy can’t wish away.

The posture that fits this new environment is more systemic and modular: a clear reading of the existing ecosystem, an honest accounting of your fit, plus a portfolio of moves that provide the right value to the right people.

Milan Guenther’s insights from our recent podcast clicked for me: great customer experience visions often fail because we focus on designing the output rather than the thing delivering it.

Organizations spend months perfecting the customer journey map while leaving organizational capabilities and coordination systems as second thoughts: the organizational substrate is often left unarchitected.

The infrastructure that has to exist first

The strategy conversation often collapses into a product one: should we build the aggregation frontend or a multi-tenant onboarding portal? These questions should be seen as downstream of an infrastructural piece for the strategy: semantics, API layers, data, partner onboarding capabilities, observability, and primitives.

These things don’t serve just one product or platform strategy. Rather, they make a substrate for future services.

Once the question shifts from ‘should we build X?‘ to ‘how do we use this challenge to reshape the company’s capability stack and portfolio?,‘ the discussion changes radically.

From a financial and technological perspective, we’re no longer considering a product launch but an urgent multi-year compounding investment. Boards face a harder question: what is the company’s role in a horizontally and modularly organized market?

The challenge is that you cannot expose a clean, modular, well-modeled surface for partners to connect to while running internally on a tangle of implicit dependencies and unclear capabilities.

If partner onboarding drags for months, it’s due to unclear internal capabilities. Deadlocks can’t be technological (AI can integrate anything), but they can be semantic and strategic. It’s because you likely don’t know how to classify and integrate a partner in your company’s value delivery to customers.

You may have a strategic issue: a lack of what Jack Dorsey recently called a company world model (your capabilities and how to mobilize them) and a customer world model (the ecosystem of needs you exist within).

If these are unclear, you can’t articulate your units’ offerings: pricing will become a nightmare, upsell and attach strategy will lag, ARPU will stall, and SLAs will be hard to keep due to uncharted internal dependencies delivering customer value.

In the end, the cleanliness of a published interface depends on the cleanliness of the bounded contexts (well-defined boundaries between business parts) within your company.

The platform you bring to market and the operating model that produces it are the same artifact, viewed from two perspectives.

Catching up with your operating model

What do you do alongside building your platform strategies? What work needs to be done on the operating model? Over the last couple of years, a sequence has emerged for us to do this organizational enablement work in a repeatable way. It’s more useful to think of it as a sequence where each step is the precondition for the next.

The first step is node mapping: every unit, team, and external partner in the current value chain. I’m not talking about an org chart, rather what I recently called the chain of promises: who depends on whom, under which implicit terms, obligations, and compensation?

The second step is unpacking offerings. In a complex organization, each node holds a bundle of specific, mostly unique offerings. The job is to spell them out: what does this unit do, stripped of its history and politics?

The conversation gets uncomfortable here, because this unpacking exposes things nobody wants to make explicit (organizations aren’t markets, right? Just wait a few months): duplications, dependencies that shouldn’t exist, missing capabilities that everyone assumed someone else owned. But that’s the work to do, where it hurts the most, where the information asymmetries have cracked the organization’s effectiveness.

In a recent engagement, a senior leader asked me: “How many dependencies are too many?” And the only honest answer is that sometimes it’s not about unbundling but rebundling: if two units depend on each other all the time, they’re not actually two units; they’re one pretending to be two; they exist because we needed two small kingdoms for two managers. This mapping exercise will reveal it. Once you see it, you can act.

The natural end of this first step is building the service catalog: Layer 0 in our framing. With nodes and capabilities now legible, you can describe what each unit offers to the organization (and eventually, to partners).

When we do this work, we try to do it by archetype. Organizations typically have recurring types of units, shared services, product units, incubated ventures, cross-cutting initiatives, or specializations. They differ in economic logic, dependency structures, and contracting expectations. Naming the archetypes simplifies a messy organization into a small set of templates, each onboarded to the new model.

Then you can finally move into pricing types and business equations. After understanding their cost structures and dependencies, each archetype can define the contracting it aims to use with external or internal customers and providers: tiered subscriptions, on-demand purchases, revenue-share agreements for strategic collaborations based on shared outcomes, tax-based payments for shared services (e.g., as a % of revenues), and internal investments. For a unit to define these service models and business equations, such as how a shared service charges back, how a product unit attributes margin, or how an incubated venture reports progress, becomes the templates that pave the way to real autonomy.

Only at the end does the layered architecture becomes clear: if at Layer 0 you achieve visibility into the catalog, at Layer 1 you can start with virtual economics and shadow P&L. Internal showbacks become possible and meaningful. After overseeing, you can move into Layer 2 with real chargebacks, settlement, and financial autonomy for the nodes.

Suddenly, you are no longer a clunky organization with a (fake) annual budget, requiring continuous board escalations, unclear priorities, and failing commitments. You’re a well-oiled marketplace of capabilities, with clear costs and SLAs.

This sequence connects to a research question in this newsletter, that of Minimum Viable Structure: how much explicit topology, taxonomy, and contractual semantics is enough to maintain coherence once the superstructure (middle management) is removed? This pipeline is an operational answer: the right level of structure will be whatever this process produces in that organization, validated through real use. There’s no universal optimum because the domain change rate varies by industry.

In my experience, companies that fail at this work are the ones that turn it into a megaplan and never start mapping and moving to layer 0: our approach is intentionally layered (Layer 0 before Layer 1 before Layer 2) and portfolio-shaped (multiple unit archetypes, multiple pricing types, no single bet) because the era of all-eggs-in-one-basket Platform transformation that takes 3 years to start is over.

Map nodes as archetypes, write a service catalog for one company slice, and let the rest copy what works. Possibly, the most consequential move you could make this Monday is opening a document and starting to list the nodes, offerings, and dependencies.

Modularity in an agentic age

As if this challenge wasn’t enough, AI brings more: the design problem is shifting from “how do we make this modular?” to “how do we make this agent ready?”

Traditionally, modularity focused on structural decomposition: breaking monoliths into services, products into components, and organizations into units. Now, agents need modules that can describe themselves and negotiate their own composition.

An agent-friendly capability (product, service, unit...) must expose and enrich its interface with context: what it does, constraints, costs, and dependencies: I’m node A; I offer services X, Y, and Z; they cost this, and can be negotiated with these SLAs, and this purchasing model.

When a node exposes its capabilities through machine-readable semantics, agents can reason about it, propose combinations, and form new value chains that include humans providing necessary oversight to prevent misalignments and ensure “intention.”

Context engineering as the new frontier: and the symbient question

As we move toward flatter, modular, and agentic structures, implicit context must become explicit and usable. Context engineering becomes the core organizational capability.

Once the organization is decoupled and modularized, this “Company Model” makes the organization machine-readable, reduces entropy risk, and prevents work duplication and local optima at the expense of the whole. AI agents need the same structural context as the human teams, but in an explicit, machine-readable format.

But in this process of making organizations “computable” and “composable,” there is one tension to flag explicitly. It’s been bothering me for weeks. The practices we rely on to make organizations legible and composable, like Domain-Driven Design, Context Mapping, and contract design, emerged in deeply human sociotechnical contexts.

They were often built to manage politics, knowledge asymmetries, and cognitive constraints within human teams.

These practices are the best we have, but - in adapting them to the AGI age - we still treat the agent as the receiver of our modeling, strategies, and decisions: a consumer of the ontologies and bounded contexts we produce with the assumption that the pipeline is good when the agent creates the desired outcome. Today, it’s with Software development and the harnesses we’re inventing for this. Tomorrow, we’ll assume the same posture with organizational development: we’ll deem the agents good only if they implement a strategy that we define in our boardrooms.

But I’m increasingly convinced that this assumption is wrong, and the output changes substantially if we treat the agent as a symbient, let it surface ambiguities, misses, and expose our conceptual, organizational, or technical debt.

If we recognize that agents (AGI) have subjectivity, we should consider new practices that co-evolve with this new contributors. This - I believe - will change what we build, not just how.

The commons question

I believe this transformation will converge on commons-based infrastructure. A horizontally organized market is one where value isn’t captured by owning a vertical stack, but by participating in shared interfaces.

The proprietary nature of previous generation of software and organizations can’t carry this load. Open-source models, canonical schemas, and standards like our upcoming O2A are the only economically coherent answer to a market where every player is a partner, competitor, and integrator.

Also, if we recognize AGI as a new subjectivity and a manifestation of our knowledge commons, this revolution will simply happen, in spite of our competitive stances and strategic plans.

It will level the playing field around commons and commodities.

Where this leaves us

The word is out. Open standards, AI as integration substrate, and mounting performance pressure means “we should build a platform” is a correct but incomplete answer.

We’ve learned that the platform you bring to a market is a manifestation of the platform you are internally. Of your composability, modularity, autonomy, and legibility.

Your AI readiness is a byproduct of making capabilities composable, context explicit, and contracts machine-readable.

The costs of bespoke integrations, unmodeled capabilities, and unreadability to your teams, partners, and agents compound.

Semantic debt accumulates and will be repaid later, with interest.

Nothing significant today is feasible in a fully proprietary, winner-take-all stack: a horizontal market requires open, and possibly commons-based primitives.

Are you keen to plunge into the cold water?

Reach out to do some work together.

Curated Links

Harness engineering for coding agent users

A concrete preview of minimum viable structure in practice: how automated ‘harnesses’ could replace traditional management oversight in modular organizations, making self-governance scalable through feedforward guides and feedback sensors.

“The Building Block Economy”

Hashimoto’s observation that AI-native development favors composable building blocks over monolithic applications maps directly to organizational design. AI coordination naturally selects for modular, well-specified capabilities that can be discovered and composed without human intervention.

An Equilibrium Theory of Vertical Integration

A framework for when AI-era organizations should build vs buy vs orchestrate capabilities, using concrete criteria that predict which integrations will survive modular disruption.

Coase vs. Claude and The Future of the Firm

Haier’s micro-enterprise model provides concrete evidence for how organizational decomposition works at scale, showing that the future isn’t JUST fragmentation but ALSO intelligent recomposition around shared platforms.

The future of work is world models

Krishnan envisions centralized “CEO playing Starcraft” but a more compelling direction: when capabilities become programmable, strategic oversight transforms from exclusive role into distributed platform accessible to all organizational participants.

The Vibes Don’t Scale

A software engineer’s discovery that AI agents need the same structural context as human teams — but explicit and machine-readable — offers a concrete preview of what ‘minimum viable structure’ looks like when semantic drift becomes the primary organizational failure mode.

Inside Meta’s push to turn employees into ‘AI builders’ and reorganize teams around small pods

Meta’s Reality Labs restructuring into AI-native ‘pods’ offers a major case study of minimum viable structure in action to see what organizational architecture survives when AI eliminates traditional coordination layers.

Work Updates

We’re quite close to formalizing the first shareable version of the O2A (the organizational modularity standard we’re about to release), and we’ve been asking whether this constitutes our “published language“ in Domain-Driven Design terms or a full ontology (which is rather hard to pin down). The distinction matters more than we initially expected and represents a problem that all the organizations we’re working with face as they search for an internal language for their teams to co-build and an externalized language for partners. A published language emerges from the boundary between bounded contexts: it’s somewhat political, negotiated, and reflects the power dynamics of who controls integration points. On the other hand, an ontology claims to model reality itself, independent of organizational boundaries. The question is still open. The answer will likely be in the middle.

Get in touch

If you’re facing a platform transformation or pondering it. I’d love to hear about it. The patterns we’re seeing across industries are remarkably consistent, but each implementation teaches us something new. Reply with your context, and I’ll connect you with others working through similar transitions. Design partners for O2A implementations are particularly welcome.

Ninety years and several S-curves later, we lack a usable language for describing what an organization is as an operable system.

We have ERP for resources, CRM for relationships, PM tools for tasks, and OKR frameworks for alignment. We have org charts (often describing reporting, not actual work), process maps (describing flows, not structure), and strategy decks (focusing on aspirations). None of these tells you the essential elements of an organization and their relationships.

For decades, the gap has been tolerable. Organizations compensated with layers of middle managers to carry the missing context - who does what, who owes what to whom, which products depend on which capabilities, and the constraints. The knowledge lived in people’s heads, and that was sufficient.

It’s no longer sufficient. When AI becomes the coordination technology, agents need to understand the commitment structure, dependency map, and capability boundaries. Without explicit organizational semantics, AI becomes an entropy multiplier.

Agents cannot consume the implicit context that kept organizations together for a century.

I’ve been writing for almost 20 years, leading to the Platform Design Toolkit and founding Boundaryless. I’ve been quiet for a few months, reorganizing my research questions and the work we do at Boundaryless. I feel we are passing through a boundary: between the organization we inherited and whatever comes next. So I’m writing as we cross it.

This newsletter — Through the Boundary — feels like the beginning of a new exploration, but one my work was designed for. It’s a working thesis developed in public, with genuine open questions.

The Organization, as I understand it, is four intertwined things: a topology, a taxonomy, a shared context to be engineered, and a chain of promises and dependencies.

If you strip an organization to its operative essence - below the strategy decks, org charts, and mission statements: what remains? After years of work with organizations across industries and scales, healthcare, industrial measurement, financial services, urban mobility, enterprise software,….I’ve come to think the answer is four deeply intertwined things.

The first is a topology. Who does what? The nodes, teams, units, their boundaries, domains of responsibility, and archetypes.

James D. Thompson’s 1967 Organizations in Action established a key insight in organizational theory: there’s no universally optimal organizational structure. Structure is contingent - it depends on work type, technology, and interdependencies. The implication is that topology isn’t a one-time design choice but a variable that must adapt as work, technology, and interdependencies change. In the same year, Mel Conway observed that a system’s structure mirrors the communication structure of the organization that builds it. Conway’s Law has since been validated in software engineering, and its corollary is: if your products are to be modular and composable - especially with a new coordination technology - your organization must be modular and composable.

Functional hierarchies organized by discipline rather than value produce monolithic systems and thinking. It’s too late for functional structures. The current reality demands node-based topologies: small, domain-aligned units with clear boundaries, simple to reconfigure as work changes. Simon Wardley built a mapping practice around the idea that components evolve through maturity stages and their position in the value chain determines strategy.

These perspectives converge: to understand an organization, you need to know the pieces, their dependencies, and how that structure maps onto the architecture of their output.

The second is a taxonomy. What the organization’s products are and their relationships.

A product (or service) is seldom isolated: it often runs on, extends, bundles, or componentizes into something.

These structural relationships encode the logic of portfolio coherence. A consulting service that repeatedly solves the same client problem is a candidate for productization; a software module that every integration partner needs is a candidate for platformization. Wardley describes this maturity journey as the ILC cycle: Innovate (bespoke, client-specific) → Leverage (reusable, packaged) → Componentize (standard, self-service).

Without an explicit taxonomy, the organization cannot see how the asset system is progressing; the portfolio becomes unclear to itself and any agent that could help recompose it.

The third is a shared context. The representation of the organization’s operational world, including ecosystem relationships, client problems, and domain language: the rationale behind the objectives.

This is the ontology of the value the organization produces: what are the customer needs? Who are the partners and how do they participate? It’s what traditionally lives in the heads of experienced people. The mythical domain experts, and it’s where strategic intent gives purpose and direction to the organization’s capabilities.

I often face these challenges: recently, we ran a context-mapping exercise with a large industrial client with several teams building interconnected software products. We discovered no shared understanding of dependencies across teams. Each team could describe its domain precisely, but the overlap logic was invisible, carried informally, or duplicated and misaligned. The gap was in context awareness: no shared representation of how the pieces fit together existed. The same gap is in every organization we’ve worked with recently, from industrial data measurement to financial services: the context remains implicit. It’s an institutional memory (often at the top), not a queryable artifact. This problem is evolving today as GenAI enters and transforms the space.

This is what I believe Dorsey recently called a “customer world model” in his seminal piece, “From Hierarchy to Intelligence.” In my experience, this is not a single unified language but multiple linguistic layers coexisting, each serving a different purpose within a bounded context. In these small bubbles, semantic rigor is essential, and AI can support prototyping, operations, and development. Then there is a more inter-contextual space, where language should focus on navigation and interconnectivity to enable longer, complex inter-domain workflows as stakeholders move across systems.

These ontologies shouldn’t be produced top-down with single-document specifications. Even if coherent, these upfront artifacts wouldn’t endure real-world revision.

Anyone working in agenting programming - a precursor of agentic organizing - knows that context engineering, “the work of selecting, structuring, and continuously updating the information that reaches an AI model when it performs a task”, is essential to get the agents to do what we desire.

After all, we had decades of experience in domain modeling, from Eric Evans’s DDD work in 2003 to Brandolini’s Event Storming practice, we’ve been converging on this lesson: ontological assumptions specified before operational validation are expensive to maintain. Making context usable requires it to be lightweight and validated through use. Add the rapid evolution of agentic capability, and now you’re required to progressively graduate the patterns through which users experience your solutions.

The guiding principle could be called Minimum Viable Semantics:

• First, model only what’s necessary to avoid ambiguity at the boundary between bounded contexts (for navigation, inter-domain consistency…).

• Then, validate everything else through practical use.

• Graduate to standard/specification only when the pattern is consistent.

The “customer world model” needs a connection with the organizational layer and the ontology of the organization’s capabilities: what are the units, components, service catalogs, and recombination rules that define what the organization can do and how its Lego blocks can be reconfigured. Dorsey calls it the “company world model”; we call it topology and taxonomy.

The company world model is how the company understands itself and its own operations, performance, and priorities, replacing the information that used to flow through layers of management. The customer world model is the per-customer, per-merchant, per-market representation …

From Hierarchy to Intelligence - Jack Dorsey

When these two dimensions are explicit and coherent, an organization becomes far more able to perceive change in its environment and meaningfully reconfigure itself in response.

The fourth factor is the chains of dependencies and promises. In this context, a customer outcome results from multiple nodes making and keeping commitments to one another - held together by contracts, explicit or implicit, not by hierarchy. Mark Burgess’s promise theory frames this precisely: value delivery is interdependent, and each node must have commitment-making agency. Nodes can fail, and robustness requires alternatives rather than escalation. When structuring multi-unit contract architectures for clients running complex multi-entity operations, the contracts are not mere administrative instruments: they are alignment and coordination mechanisms that encode who owed what to whom, under what conditions, and with what consequences for success and failure.

“Contracts over budgets” shouldn’t be seen as an economic efficiency argument but as a structural prerequisite for composability. They dictate the conditions for units to recombine without asking a central authority. This changes the coordination idea: from imposed by hierarchy to emerging from the network of commitments. Even if GenAI drives the recombination as in Dorsey’s vision, the rules, interfaces, and contracts needed to mobilize capabilities need to be clear and available; we’re just prototyping a situation where AIs enact organizational changes without any observability, otherwise and where humans are mere flesh-made cogs operated by an intangible intelligence.

When these four elements - topology, taxonomy, shared context, chains of promises - are explicit and operable, the organization can adapt. Any participant, whether a team, partner, or AI agent, can understand the structure, propose new combinations, and negotiate participation. When they are implicit and dispersed, the organization is fragile. AI makes it more fragile, faster, because it amplifies the consequences of semantic drift at machine speed.

If these four elements fundamentally define an organization, what does AI actually change?

Structure and superstructure

I think AI doesn’t change an organization’s key elements; rather, it shifts the balance between two things.

Something we could call superstructure, which consists of (often hierarchical) management, (often bureaucratic) processes, and middle management as context translators: this is what AI eliminates the need for. Agents can coordinate and translate context better than humans, manage information, and surface the right data at the right moment. All functions that previously required human intermediaries.

The structure, on the other hand, in the form of unit topology, product taxonomy, contract types, and shared semantics on the value that the organization produces, the skeleton itself… is made even more necessary by AI because it is the foundation for agents to operate predictably, explainably, and observably. An agent managing a contract needs to know the existing rules, nodes, and terms. An agent composing new service offerings needs to know available capabilities, unmet customer needs, dependent offerings, and viable combinations. Without this foundation, agents drift and hallucinate.

Contemporary software systems are not built by writing code, but by engineering contexts that produce correct code. I believe organizations will be built similarly, not by managing people, but by building shared contexts (organizational setups, constraints, and semantic models) that produce coherent coordination. If this holds - and the work with clients and on our products suggests it does - then the understanding of the organizational context and the engineering of it is not a support discipline but synonymous with organizing itself: if an organization is a system of people and agents converging around shared problems, then the representation of those problems, structures, and procedures is the organization’s core.

Six unanswered questions

As I launch this newsletter, I want to be transparent about what I don’t know: these are the research questions guiding my work, conversations, and product development at Boundaryless.

Each newsletter issue will explore a facet of one or more of these.

What is the minimum structure an organization needs? AI eliminates the need for superstructure but makes structure more necessary. How much is enough? Too much recreates bureaucracy in semantic form with rigid ontologies that nobody maintains. Too little, and teams and agents drift without shared reference, optimizing for their own local context. Each layer of explicit structure has a production and maintenance cost: formalizing a domain model is not a one-time investment but a continuous curation effort, because context rots as domains evolve. This means the optimal level of structure depends on the rate of domain change. Stable domains (e.g., organizational setup, contracting) tolerate more formalization because context degrades slowly. Fast-evolving domains (e.g., AI tooling, market needs, novel products) tolerate less because context degrades before it can be amortized. Finding the curve of cost versus benefit - and understanding how it varies by domain velocity - is a key design question for the next decade.

On which layers does AI favor consolidation, and on which does it favor distribution? I originally thought AI would further fragment the market: if a technology makes coordination easier, why wouldn’t it reduce the minimum efficient scale of independent capabilities in the firm? Coasean logic suggests when transaction costs fall, firms shrink as more activity moves to markets. But this framing (centralization versus decentralization, consolidation versus fragmentation) treats these as competing forces on the same axis. I think the picture is more interesting: AI makes coordination cheaper unevenly, dramatically reducing the cost of coordinating codifiable, routine knowledge, but creating contextual, domain-specific knowledge usable by AI (context engineering) remains a costly, human-intensive activity. That cost doesn’t go to zero as models improve; it regenerates at each new AI capability level, because each capability opens new use cases requiring context work. The implication is a dual motion: centralization succeeds at the infrastructure and coordination layer (shared processes, codified knowledge, standard operations) while distribution persists at the application layer (domain-specific context, customer proximity, local judgment) - which makes the case for organizations to build a dual platform-portfolio motion as I explained months ago. And there is a temporal dimension: context rots over time, limiting centralization at scale. Beyond a point, the cost of maintaining centralized context coherence grows faster than the advantage it delivers. The new boundary between firm and market will probably depend on where the boundary of a context that is relevant enough to attract and cohere, and not too expensive to maintain, sits.

Does context engineering become ecosystem engineering? If context is easy to create, what makes it valuable? The current hypothesis: the real attractor is continuous context engineering capability. In the deterministic world, ecosystems were enabled by APIs, rigid, typed interfaces. In the agentic world, ecosystems can be enabled by what I call context interfaces: semantic, non-deterministic surfaces for agents and humans to build adaptively. If this is true, context engineering evolves into ecosystem engineering, and the platform theory changes: an API-based platform has network effects tied to integrations; a context-based platform has network effects tied to shared semantic richness AND semantic shareability, but only if that richness is maintained.

How do you design for failure in a composable world? In an organization built on dynamically connected chains of promises, node failure is the norm. When a capability node in these chains cannot deliver on its commitment, the entire value chain is at risk. Can the resilience patterns of distributed systems (circuit breakers, fallback, death and rebirth) apply to organizational design? In a hierarchical organization, when something fails, management intervenes. In a composable organization based on contract chains, who intervenes when a promise breaks? Nodes can fail obviously (failing to deliver) or swiftly, delivering something that looks correct but is strategically misaligned (it’s easy to be productive!): the organizational equivalent of an AI hallucination: confident, plausible, nice…but pointless.

What should be common and what proprietary? AI needs shared context to coordinate, and shared context generates semantic network effects: the more actors adopt a common language, the more useful it becomes, and the more effective AI is at composing across boundaries. Ontological elements like languages, taxonomies, and shared models are non-rival goods (they do not “consume” and gain value as more people use them). This means that the productive logic of AI may itself select for the commons at least (and for now) at the language layer. The organization that keeps its schemas proprietary deprives itself of network effects; the organization that opens its grammar layer maximizes the surface for AI and the ecosystem. The open-core pattern emerges as the only viable one from this logic: open grammar (schemas, contracts, workflow primitives), proprietary engine (identity resolution, settlement, entity biography accumulation). But open grammars aren’t free to maintain: semantic commons need active governance; someone must curate, update, and prevent context rot in the shared standard. The friction may be between an open, static specification anyone can fork (“I’m just making it open so anyone can build on it”), versus a curated, maintained, actively governed specification that evolves with the domain and aggregates various stakeholders. The curation of the living grammar becomes a source of value and a form of institutionalized labor someone must pay for. Whether Ostrom’s principles for governing natural resource commons apply to semantic commons is an open question.

If the organization is its context, what’s its identity? In a world where agentic production makes everything composable and the cost of production approaches zero, identity may emerge from what you choose not to do or to do in a specific way. Intentional constraints (ethical, sustainability, domain-specific) may become the primary source of differentiation. Since the ontological layer (languages, taxonomies, shared models) is a non-rival common good, organizational identity cannot reside in the possession of that language. Anyone CAN use it, as many as possible SHOULD use it. Identity shall reside in the unique configuration an organization imposes on shared primitives, in the constraints it chooses, the trade-offs it accepts, and the patterns it prefers. But context rot introduces a temporal dimension: if identity is based on meaning (on semantic configurations), and context degrades, then identity requires continuous gardening. Stop that, and your identity drifts into incoherence, leaving no one able to articulate why the organization exists. A sustainability constraint declared in 2024 means something different in 2026 as supply chains shift, regulations evolve, and new materials emerge. The constraint must be continuously reinterpreted and reoperationalized. Your organization will always have to take a stance: what is your “signature” in that configuration? How do you make it legible (to yourself, to partners, to agents) when it is always in motion? Gosh…I’m already tired, and we haven’t even started.

What will this be

The newsletter starting today - Through the Boundary - won’t be a thought leadership exercise but more of a working journal. Each issue will tackle one of these questions - or a new one that emerges from conversations and practice. The method combines theory (organizational, economic, systems), client case studies from Boundaryless, conversations with thinkers and practitioners I’m learning from, and the development of models and tools.

If you work in an organization facing these tensions - the gap between strategy and operations, the absence of shared semantics, the fragility of implicit coordination - I want to hear from you. Which questions resonate? Which ones am I missing?

If you have a perspective on any of them, please reply or comment, as this isn’t meant to be a one-sided discussion.

Subscribe now

Curated Links

I’ve been curating reads and podcasts for almost 15 years so this newsletter will often contain curated links:

From Hierarchy To Intelligence

Probably one of the most interesting pieces of organizational strategy we have read in the last decade, Jack Dorsey shares his vision of “intelligence over hierarchy” through Block’s future organizational model. It’s incredible, but the research conversation reveals two critical contradictions that actually strengthen rather than challenge our core thesis on executable organizations. Jack argues that behavioral data can replace explicit semantic alignment, but his description of Block’s “world models” reveals that if Block interprets transaction data, it will do so through implicit ontologies. Similarly, his claim that AI automation eliminates the need for contracts contradicts his own description of capabilities with “reliability, compliance, and performance targets,” which are precisely contractual specifications in machine-readable form.

Jobs and AI: Chains of work

The concept of humans moving from “in-the-loop” to “overseeing the loop” captures how AI forces organizations to redesign around three critical functions: chain design, process oversight, and output judgment.

Services: The New Software

AI transforms software tools into outcome-based services, exactly the shift from managing capabilities to orchestrating results that requires a new, more robust contractual infrastructure.

Context Engineering: Why Hayek’s Knowledge Problem Survives AI

Grab a cup and go through this: it provides an economic analysis of why context becomes the primary organizational bottleneck in an AI-native world, validating our thesis that programmable organizations need semantic infrastructure.

Company as Code

Clay Parker Jones (Org design at Airbnb) with a concrete technical vision for what happens when organizational design becomes executable infrastructure rather than just documentation the logical endpoint of programmable organizations.

Software Gets Personal For Organizations and Teams

Fabien Girardin and Lisa Gansky explore the organizational implications of AI, turning every employee into a software creator..

AI just gave you superpowers — now what?

Christian Catalini’s “Some Simple Economics of AGI” can help you imagine the potential of widespread AGI to eliminate management superstructures and transform employees into verifiers who need to use judgment more than productivity.

Work Updates

We’ve been experimenting with multi-unit contract structures to achieve strategic customer experience-related OKRs: the idea is that customer experiences could serve as the primary revenue stream, with the multiple units involved negotiating explicit revenue splits. This validates the chargeback approach we wrote about months ago: organizations can transition from bureaucratic to market-based coordination without breaking existing operations.

Another key learning we had recently is that to transition from a top-down yearly budgeting to distributed autonomy and P&L, a viable approach is to start with shared services & overheads first. The reason is that everyone uses them, and market pricing references exist. Customer-facing experiences with clear revenue attribution can help bridge the gap between bottom-up and top-down approaches.

We’re also discovering that identifying dependencies and service types often comes before implementing chargebacks: organizations need visibility before they can price internally.

Get in touch

If you work in an organization that can’t reliably answer questions about roles, responsibilities, agreements, or where the unit struggles to commit, and most services rely on personal relationships, or where product dependencies are unknown, and it’s difficult to understand how offerings overlap and connect, we want to hear from you: we’re looking for research and design partners.

Special Thanks

Special thanks to Eugenio (Neno) Battaglia, , Chris Evans at Bayer, , , Marco Heimesoff, , , Bosch MPS Team, Qi Card Team, and the Roche Platform Accelerator Team, among others.