Most enterprise agentic stacks are built bottom-up — orchestration framework, agents per use case, tools, retrofitted governance — and become brittle, incoherent, and expensive to refactor long before they reach production scale. We design them the other way around: architecture first, from Stafford Beer's Viable System Model, so that coordination, recursion, identity, and adaptation are commitments of the structure before the first agent is wired in.
A familiar trajectory: the team picks an orchestration framework, builds an agent for the first use case, adds a second, wires in tools, layers approval gates over the parts that touch customers, retrofits observability when the first incident review demands it. Each individual agent works. Each individual workflow ships. But somewhere between the third and the tenth production deployment, the system as a whole begins to drift — coordination is improvised, ownership is unclear, identity is enforced by string concatenation, and the cost of each new use case rises rather than falls.
The architecture was never decided. It accreted. What looks like a platform from the inside reads, to anyone arriving from outside, as a set of agents that happen to share infrastructure.
Per-agent metrics stay healthy. End-to-end behavior — across agents, tools, and human approvals — disagrees with what the team would say the system does. The discrepancy is not in any one component.
Two agents share a resource. Conflict surfaces in production. A patch is added. A third agent joins. Another patch. Coordination logic is whatever the last incident required — never designed, never auditable as a whole.
The system's values, refusal criteria, and non-negotiables live inside system prompts that drift across agents, versions, and teams. There is no structural guarantee that the system as a whole behaves like one organization.
We start from the opposite end. The architecture is decided first: what kinds of viable units exist in the system, how they coordinate, how they are audited, how strategy and identity propagate through them, and how the whole pattern recurses as the organization scales. Only then do we choose agents, tools, and orchestration. Agents become inhabitants of an architecture — not the architecture itself.
This is not a methodology preference. It is a constraint on what kinds of failures the resulting system can have. A system designed for viability before implementation cannot drift into the failure modes above by accident, because the structural commitments that prevent them were made before the first line of orchestration code.
An enterprise agentic system is not a collection of agents. It is a viable system that happens to be implemented with agents.
The Viable System Model is one of the strongest architectural accounts we have of how complex systems remain coherent at scale. Developed by the cybernetician Stafford Beer across four decades of practice in industry and government, the VSM specifies five interrelated functions that every viable system must carry — operations, coordination, control, intelligence, and identity — and the recursive principle that every viable subsystem is itself a viable system.
The model was built for organizations made of people. It transfers, with very little adaptation, to enterprise systems made of agents. The functions that hold a firm together — and the reasons firms fall apart when one of them is missing — are precisely the functions that hold an agentic stack together, and the reasons agentic stacks fall apart when one is missing.
Beer's model emerged from large-scale industrial work — most famously the Cybersyn project in Chile in the early 1970s — and was refined across two later books that remain the canonical statements. The VSM is not a metaphor borrowed from biology. It is a structural account of the necessary and sufficient conditions for a system to remain itself while adapting to a changing environment, derived from first principles of information and control.
The five systems are not layers in a software sense, nor agents in an implementation sense. They are functions every viable system must carry, whatever the substrate. Read in order, they describe how value is produced, how production is held together, how the holding-together is held together, how the system reads its environment, and how it remains itself across change.
Fig. 01 The five systems of a viable agentic enterprise. S1 produces value; S2 keeps S1 units from interfering with one another; S3 manages here-and-now; S4 scans environment and plans adaptation; S5 closes the system and sets its ethos. The S3* audit channel lets management see operational reality without going through the operational hierarchy. The agentic alert channel routes critical signals from any level directly to S5, bypassing the chain when something is structurally wrong. This corresponds to what Beer called the algedonic channel, translated here into agentic-systems language.
The agents and workflows that actually do the work the system exists to do — handle customer cases, process claims, execute trades, review documents, draft code. Task-level agents, tool-using executors, retrievers. Everything else in the architecture exists in service of S1.
Keeps S1 units from interfering with each other when they share resources, contexts, downstream effects, or human attention. Locking, queueing, conflict resolution between concurrent agents, shared-memory protocols, dispatch policy. Designed, not improvised.
Allocates resources across S1 units, enforces SLAs, audits behavior. Includes S3* — the privileged audit channel that lets management see operational reality without going through the operational hierarchy. Orchestrator-level supervisors, evaluation pipelines, the trace audit path.
Scans the environment, models how it might change, plans adaptation. Where the strategic question lives. Environment models, planning agents, evaluation harnesses that feed back into agent design, the layer that decides "we need a new capability" before the gap shows up in production.
Ethos, norms, non-negotiables, and the criteria by which the system recognizes itself. Resolves the standing tension between S3 — today's operational reality — and S4 — tomorrow's possibility. Not a prompt, but a structural constraint that holds regardless of which agent is on call, which model is behind it, or which use case is being served.
The model is recursive. The five-system structure holds at every level of the organization, and is what makes agentic systems composable rather than ad hoc. A single planning-and-acting agent — one that takes a goal, executes against it, audits its own work, adapts to feedback — is itself a viable system with its own internal S1 through S5. A squad of such agents serving one business capability is a viable system. The capability inside a division is a viable system. The division inside the enterprise is a viable system.
The same architectural pattern repeats at each scale. Scaling, on this account, is not adding more agents. It is adding another level of recursion — and doing so without breaking the patterns at the levels above and below.
A planning agent with internal S1 (act), S2 (manage tool conflicts), S3 (self-monitor), S4 (replan on environment change), S5 (refuse out-of-policy actions). The same five functions, at the smallest useful scale.
A team of specialist agents serving one business capability. S1 units are the individual agents; S2 coordinates them; S3 supervises; S4 monitors how the capability's environment is shifting; S5 governs what the capability will refuse to do.
An entire business function — claims, support, research, compliance — implemented as a single viable system whose S1 units are themselves viable systems of the kind below. The pattern repeats, deliberately.
The translation of organizational cybernetics into software architecture began long before contemporary LLM-based agents appeared. In The Viable System Architecture, presented at HICSS in 2001, Charles Herring and Simon Kaplan translated Stafford Beer's principles into a pattern language for software, defining software viability as the capacity of a system to remain itself while being adapted over time.
The author worked on intelligent adaptive systems grounded in the same cybernetic principles in the mid-2000s, in direct dialogue with Herring on the transition from organizational to software viability.
Enterprise agentic systems are a special case of this longer line of work — and one of the hardest ones. The system is no longer only software that must adapt; it is an organization of software agents that reason, act, delegate, coordinate, escalate, and reorganize. The viability problem moves up a level.
Beer gives the cybernetic model of viability. Herring and Kaplan show how that model can be translated into software architecture. Complexity Lab extends this line into contemporary enterprise agentic systems.
The Viable System Model is not an abstraction floating above engineering. It maps naturally onto a contemporary enterprise agentic substrate: workflow pods or agent teams, supervisor agents, framework adapters, MCP integrations, structured summaries, and auditable reporting channels.
Microservices, supervisors, adapters, and MCP integrations are an implementation language. They become an enterprise agentic system only when organized by viable-system functions from the start — operations, coordination, control, intelligence, and identity — rather than assembled bottom-up and governed afterward.
Bounded operational units carry business capabilities: task agents, tool access, local execution logic, and operational responsibility.
Adapters, shared-resource governance, message translation, and communication gateways prevent oscillation, resource conflict, and incoherent handoffs between locally valid agent teams.
Supervisor agents, SLA monitoring, evaluation, error recovery, escalation, resource allocation, and S3* audit channels give management a direct view into operational reality.
The system monitors changing models, frameworks, regulation, user behavior, and capability gaps — deciding when it needs a new capability, not merely a new tool call.
The enterprise identity layer defines what the system is allowed to do, what it must refuse, and what must remain true across model substitutions, new pods, and new business use cases.
MCP servers, structured JSON summaries, schema validation, durable messaging, and traceable integration calls connect agentic pods with legacy AI modules, functional enterprise systems, and higher-level management loops.
The engagement can begin as design, architecture, prototype planning, or development support. The deliverable is scoped to the client's stage, but the core output is always the same: an enterprise agentic system whose cybernetic structure and technical implementation belong to one design.
A clear S1–S5 model of the enterprise agentic system: operational units, coordination layer, supervisory control, intelligence loop, and identity layer.
A translation from VSM functions into workflow pods, supervisors, adapters, MCP integrations, schemas, reporting channels, and infrastructure constraints.
Protocols for inter-agent coordination, shared-resource governance, escalation paths, S3* audit channels, and agentic alert routes.
The non-negotiables the system must preserve across models, frameworks, workflows, business use cases, and future adaptation.
A practical path for testing the most load-bearing structural claims before the architecture hardens into production complexity.
Support for the first implementation phase: specifications, boundaries, supervisor patterns, schema design, and integration points for the engineering team.
The choice between bottom-up and architecture-first does not show up in the first quarter. It shows up in the second year, when the platform is asked to do something it was never structurally designed for. At that point the two paths diverge sharply, and the difference is read directly in engineering hours, incident counts, and the speed at which new capabilities reach production.
The same team, the same models, the same talent — and substantially different operational outcomes, because the structural commitments that absorb scale were made at different points in the project.
Some clients will already have agents, workflows, orchestration tools, and infrastructure choices in place. Others will only have the business capabilities they want to automate and the organizational constraints the system must respect. In both cases, the work is the same at the structural level: define the viable agentic architecture before the system hardens into accidental complexity.
We participate where the engagement requires it: designing the viable-system structure, mapping S1–S5 functions onto the enterprise and its technical substrate, specifying coordination and audit channels, defining identity and policy constraints, and translating the architecture into an implementation path.
The goal is not merely to advise from outside. The goal is to help the client build an enterprise agentic system whose cybernetic architecture and technical implementation belong to the same design.
The Enterprise Agentic Systems offer is one of four sibling offers in Complexity Lab's Production practice. Full descriptions live on the Production page; this section is only for orientation and direct navigation between the offers.
Send a brief description of the agentic system you are building or planning — its intended capabilities, agent topology, orchestration choices, infrastructure constraints, and the governance and identity commitments it must honor. We assess the right point of entry: design, architecture, prototype, or development support for the first build phase.
NDA-friendly. Anonymized descriptions are enough to begin.