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.