If I Had to Build It Again: Re-architecting an Enterprise AI Platform

What the evolution of an enterprise AI platform has taught me, and how I intend to apply those lessons going forward.

I lead an enterprise AI platform. It started as a project-management assistant, grew into a platform with agents, skills, Workspaces, and integrations, and is now heading into its third architecture.

A third architecture is the closest a product leader gets to the question every builder asks: if I had to build it again, what would I do differently? The difference is that I have to answer it with a budget attached and a team waiting on the answer.

The answer is best expressed in the language of systems thinking. Donella Meadows wrote in 2008 that a hierarchy works when there is enough central control to coordinate the whole and enough autonomy for every subsystem to run itself. Here is what that rule looks like applied to a real platform twice: once in hindsight, and once in the plan we have committed to.

We built the hierarchy from the bottom up, which is how hierarchies grow

Version one was a chat assistant with retrieval over a curated knowledge base. It answered project-management questions well, and that was the whole product.

Version two grew on top of it, one capability at a time. Agents, on a framework that has since been deprecated. Reusable skills. Document upload and generation. Short-term and long-term memory, and personalized prompts. Folders with role-based access. Localization into ten languages. A sandboxed code interpreter for spreadsheet analysis.

Meadows would have predicted this shape. Hierarchies grow from the bottom up: the subsystems come first, and the center emerges to coordinate them. That is what happened, and it was the right way to find out what the platform was for.

The cost of growing that way is that the center was never designed. It evolved through a series of trade-offs with the subsystems it governed, each reasonable on its own terms, so what it owned was settled by negotiation rather than by rule.

Setting the center's scope by trade-off cost us three ways

Meadows names the two ways a hierarchy fails: suboptimization, when a subsystem's goals win at the expense of the whole, and over-control, when the center holds so much that the subsystems stop functioning. We managed both.

We owned implementations, not contracts. The agent framework we started on wove itself through everything: the conversation service, the shape of chat history in the database, the way retrieval was called. It became a center nobody chose, which is over-control by accident.

When the vendor deprecated it, the swap took two sprints. It was cheap because the team planned it thoroughly and executed it well, not because the platform was built to absorb it; what the swap exposed was a conversation service, a chat-history model, and a retrieval path shaped around the framework rather than around contracts we owned.

We let agents multiply without a rule for what an agent is. Many of the agents we have today are better understood as skills: a template plus instructions, a procedure with no need for its own multi-step loop. Register enough of these behind a single router and the router loses the ability to tell which one to call; we avoided that failure by requiring team approval before any agent reaches the main chat. The gate worked, and it is still a control doing the job a rule should do, because the rule about what an agent is came only this year.

We built the commons last. Tenancy boundaries, role-based access, observability, and evaluation each arrived as its own foundation project after the features that needed them. They were built as shared services, so the cost was sequence rather than duplication: every feature that shipped first ran for a time without the rules the commons later set, which is suboptimization in its quietest form. The platform team, meanwhile, spent that interval at the bottom of Meadows' leverage-points ranking, tuning parameters instead of setting rules.

None of these were failures of talent or effort. They were the predictable result of setting the center's scope by trade-off rather than by rule. So here is the rule.

The rule I'd start with: own the contracts, free everything else

Meadows' sentence is worth quoting in full:

"To be a highly functional system, hierarchy must balance the welfare, freedoms, and responsibilities of the subsystems and total system—there must be enough central control to achieve coordination toward the large-system goal, and enough autonomy to keep all subsystems flourishing, functioning, and self-organizing."

Translated into platform terms, the center should own four things and nothing else.

The goal, stated precisely enough that a product team can test its backlog against it.
The contracts: the interfaces between agents, tools, servers, and data, and never the implementations behind them.
The commons: identity and permissions, tenancy, storage, sandboxes, model access and spend, guardrails, and observability. The things everyone needs and nobody should rebuild.
The feedback loops: evals and outcome metrics at every level, routed to whoever can act on them.

These are categories, not four line items. The test for anything the center wants to hold is which of the four it belongs to, and if the answer is none of them, it belongs to a subsystem. Subsystem boundaries go where relationships are densest; call it the density rule. Meadows' phrase is that relationships inside a subsystem are "denser and stronger" than relationships between them.

Herbert Simon's watchmaker parable explains why this is a necessity rather than a preference. Hora built from stable subassemblies and Tempus built each watch in one continuous sequence, so every interruption cost Hora a subassembly and cost Tempus the whole watch. Simon's conclusion was that the complex systems which survive are hierarchical for exactly this reason: stable intermediate forms are the only ones that outlast interruption.

A contract is what makes a subassembly stable, because it is the boundary that lets the piece behind it be replaced. And an AI platform lives under an unusual rate of interruption: model generations turn over in months, frameworks get deprecated, protocols appear and become expected within a year, and teams reorganize around all of it. A platform built as one continuous sequence pays for each of those with the whole watch; excellent execution made our framework swap cheap, but the shape the swap exposed is still there, and the next interruption will test the shape, not the team.

Version three makes the center explicit and the subsystems freer

Version three is a re-architecture of the core: how the platform stores conversations, documents, and knowledge, how it models conversation and agent state, how agents search, and how they run tools. Those change together, and that is what makes it a parallel build rather than a series of patches. Here is what changes.

Storage. Everything the platform works with, from conversations to documents to knowledge, moves into a single navigable structure: a virtual file system that replaces the NoSQL store holding user chats today. An agent can then work with the platform's material the way a person works with a well-organized folder.
Search. Agents search the way people do: find, open, read, and refine, rather than receiving a fixed set of passages from a single retrieval call. This is the same agentic search loop that coding agents rely on.
Data model. A deliberate, standard schema derived from AG-UI, the contract between agents and the interface, replaces a model that is fragile and nonstandard today. Conversation and agent state will persist in a form that outlasts any single framework or model.
Tool calls. Tools become a typed code interface. The model writes a short program that calls the tools a task needs, and that program runs in a sandbox. Models are more reliable writing code than emitting tool-call syntax, and one program completes what previously took many round trips, so multi-step work finishes faster with fewer failures.
Sandboxes. Execution is tiered to match risk and cost. A lightweight Python interpreter (Monty) runs the short programs, and a heavier isolated sandbox is reserved for work that needs real libraries, such as data analysis or document processing.
Knowledge base retrieval. Contextual embeddings improve grounding, so answers rest on the right passage for the right reason. Graph-based retrieval is under evaluation.

You cannot swap storage, schema, search, and tool execution one piece at a time under a live conversation service, because the old data model leaks into every piece not yet replaced. So the new platform goes up beside the old one, is tested against it, and takes over only once testing is complete.

Every one of those decisions maps to one of the four things.

Contracts. Version three adds AG-UI as the contract between agents and the interface and derives the schema from it, so the data model follows a contract instead of a framework. The typed code API is a contract too: adding a tool means adding a typed function, not inventing a new call format.

A parallel build only works if the external contract is the fixed point. We standardized the core API earlier around a common messages format with backward compatibility, and the new build is tested against that same contract before the switch. That is what lets us compare the two side by side and cut over on evidence rather than on hope.

Commons. Much of the commons is in place. The Workspace, the layer a user works in, is released, with Projects and folders, role-based access, and safeguards against cross-tenant leakage inside it. Persistent memory runs as a shared service, and observability is a platform capability spanning agents, retrieval, model calls, tools, and MCP, built on OpenTelemetry and fed into an evaluation platform, with prompt versioning that lets us compare model generations before we switch.

Version three adds storage, sandboxes, and retrieval as shared services that every agent uses and none rebuilds. Beneath the Workspace, storage moves to the virtual file system without changing the Workspace's boundaries.

Feedback loops. Retrieval quality has its own evaluation suite, and agents and skills have task-level evals. Production monitoring, dashboards, alerts, and regression checks in the delivery pipeline close the loop. Above the code, the roadmap runs as a portfolio of options we review formally every quarter, with one to three research spikes each sprint tracking whether an option's trigger has been met.

The goal. Version one answered questions about project management. Version two did work on the user's own material, with agents and skills acting on their documents and spreadsheets. Version three is built to know the project.

Projects, the layer above folders, chats, and documents, is where that goal is most visible today: it reads a project's context against a standard model of the domains a project has to manage, surfaces insights, and reveals conflicts in the project's state. Version three enhances the skills, tool sets, and architecture behind it, so that the platform knows the project better and puts what it knows to more use.

That gives the goal a test a product team can apply to its backlog: does this capability help the platform know the project better, or act on what it already knows? Multi-tenant Projects come after version three.

And the subsystems get freer as the center gets clearer.

Agents versus skills. The rule we adopted in an authoring workshop this year: a dense, self-contained procedure is a skill, made of encapsulated knowledge plus instructions, and it should be available to other agents. A separate agent is justified only for a multi-step, multi-tool process with a human in the loop. We expect the authoring experience to become a skill generator over time, with skills invoked by name.

Meadows' density rule is also the tie-breaker in the wider argument over agent architecture. Anthropic's 2025 write-up of its research system found that multi-agent designs pay off for work that parallelizes cleanly, and Cognition's "Don't Build Multi-Agents" warned that parallel agents that cannot see each other's work make conflicting decisions. Both are right: split only where the relationships between the parts are sparse.

Agents manage their own context. The agentic search loop is Meadows' autonomy made literal. An agent that can list, open, and read what it needs regulates its own context instead of depending on the center to assemble it.

Workspaces run themselves. The platform sets a Workspace's boundaries: who can access it, which roles exist inside it, and which policies apply. Within those boundaries, the people in the Workspace create their own agents, curate their own knowledge base, upload their own documents, and manage their own Projects. None of that requires the platform team.

Product teams own their backlogs. They own their discovery as well, and the platform team treats the platform as a product whose customers are those teams, in the sense Team Topologies uses. The center allocates budget and attention through the portfolio review and never designs on a team's behalf.

Here is the ledger as it stands for version three.

Subsystem	The subsystem owns	The center owns
Agents	Instructions, tool selection, skill composition, task-level evals	Identity and permission boundary, tool-use contract, spend budget, guardrails, main-chat exposure
Skills	Procedure content and versioning	Packaging format, discovery, approval tier
Tools and MCP servers	Implementation, data-access logic, their own SLAs	Typed code API, protocol, registry, auth model, observability hooks
Storage and sandboxes	What each agent reads, writes, and runs inside them	File system contract, sandbox tiers, isolation, quotas
Knowledge bases	Curation, scope, freshness	Retrieval contract, tenancy isolation, provenance standard
Workspaces, Projects, and folders	Their agents, knowledge, documents, instructions, decisions, and policies inside the boundaries the platform sets	Tenancy boundaries, role model, data residency, audit, project analysis model
Product teams	Backlog, discovery, implementation within the contracts	Platform goal, portfolio allocation, review cadence
Evals and observability	Domain-specific evals	Shared tracing, eval harness, system-level outcome metrics
Model access	Prompts and task-level evals for its own use case	Model selection, provider abstraction, routing, spend limits, fallbacks

It pauses feature work for months, and it is still the cheapest option

The business case for version three asks for months of paused major feature work and a small dedicated team, with a start date already set. That is a real price, and it is worth naming what it was weighed against.

The alternatives were to keep patching the current core one feature at a time, or to rewrite the core in place. Patching means every new capability inherits the fragile data model. Rewriting in place means changing storage and schema under live users with no baseline to compare against; the parallel build pauses the same feature work but leaves today's platform untouched until the new one has proven itself against it.

Three things will be true after the switch that are not true today:

An agent will find what it needs and manage its own context, instead of being handed everything at once.
Adding a tool will mean adding a typed function, not designing a new call format.
A model or framework change will touch an adapter, not the data, because the data model will follow a contract.

The balance is tuned, not set, and version three gives us the gauges to tune it. Lead time from idea to shipped agent and the share of requests that route through the platform team are the over-control gauges: when they rise, the center is holding too much. The ratio of bespoke integrations to contract-conformant ones and cost per completed task are the suboptimization gauges: when they rise, the center owns too little.

The balance runs in reverse as well. When a more capable model makes a decomposition unnecessary, we will let the hierarchy flatten rather than defend a layer that no longer serves the one below it.

If you are at version one

You will not get to skip the bottom-up phase, and you should not try; the goal only becomes clear once real capabilities exist and real people use them. But the goal is the only part of the center that should be allowed to emerge. Settle the other three by rule before the trade-offs settle them for you.

Write the contracts before the second agent. The message format, the tool contract, and the retrieval interface. Own those and you can replace everything behind them.
Stand up the commons before the third feature. Identity, tenancy, storage, and observability. Every feature built before them will have to be retrofitted onto them later.
Write the agent-versus-skill rule before the tenth capability. Most of what people will want to build is a skill. Say so early and routing stays reliable.
Keep a one-page ledger of what each subsystem owns and what the center owns, and review it every quarter with one question: where are we over-controlling, and where are we suboptimizing?

We are answering that question with version three. If I had to build it again, I would build it in this order.

Own the contracts. Free everything else. Then watch the gauges.

Sources and further reading

Donella H. Meadows, Thinking in Systems: A Primer (Chelsea Green, 2008), chapter 3.
Donella H. Meadows, "Leverage Points: Places to Intervene in a System" (The Sustainability Institute, 1999).
Herbert A. Simon, "The Architecture of Complexity," Proceedings of the American Philosophical Society (1962).
Matthew Skelton and Manuel Pais, Team Topologies (IT Revolution Press, 2019).
Anthropic, "How we built our multi-agent research system" (June 2025).
Walden Yan, "Don't Build Multi-Agents," Cognition (June 2025).
Cloudflare, "Code Mode: the better way to use MCP" (September 2025).
Anthropic, "Code execution with MCP: Building more efficient agents" (November 2025).
Pydantic, Monty: a minimal, secure Python interpreter for AI agents (open source).