Why Your Agent Deployment Outpaces Your Architecture (And What to Do About It)
What this article gives you
By the end of this piece you will have a clear picture of the three infrastructure layers, orchestration, monitoring, and governance, that need to exist before your agent count grows past the point where any one person can hold the full picture in their head. You will also have a sequence for building those layers without halting the deployments already in progress.
If you are still evaluating whether your organisation is ready to ship a first agent, the guide on what it takes to get your first agent live covers the prerequisites in detail. This article picks up from the moment that first agent is live and the next five are already in the queue.
The gap is not hypothetical
Two recent findings make the scale of the problem concrete. Tata Communications’ 2026 research found that enterprises are running multi-channel agent deployments without coordinated infrastructure to connect them. West Monroe documented 550 or more internally built agents at a single enterprise, a number that required a full governance recalibration to bring under control.
Neither situation is unusual. Gartner projects that 80% of enterprises will have deployed AI agents by the end of 2026, yet only 13% believe they have adequate governance in place, with a further prediction of 150,000 or more agents per Fortune 500 company by 2028. Separately, 98% of companies report they have deployed or plan to deploy agents, while fewer than 50% have any account of their agent inventory.
The deployment curve is steep. The architecture curve is not.
Why architecture lags deployment
Shipping a single agent is genuinely fast. The Salesforce Agentic Enterprise Index recorded a 53% reduction in agent creation time across its customer base, from four days to under two days. When creation takes less than a working week, teams deploy before the questions about coordination, ownership, and conflict resolution get asked.
The pattern looks like this at most organisations:
flowchart TD
A[Team identifies use case] --> B[Agent built and deployed]
B --> C[Second team sees the result]
C --> D[Second agent deployed independently]
D --> E[Agents share data stores or APIs]
E --> F{Conflict or duplication?}
F -- No --> G[Sprawl continues undetected]
F -- Yes --> H[Incident surfaces the gap]
H --> I[Governance work begins reactively]
Reactive governance is the norm, not the exception. The problem is that by the time the incident surfaces, you may have agents writing to the same records, calling the same downstream APIs at conflicting frequencies, or presenting contradictory outputs to the same user across different channels.
The three layers you need before you scale
1. An agent registry
The registry is a single authoritative record of every agent in production: what it does, who owns it, which tools and APIs it can call, and what its expected output range looks like. Without a registry, you cannot answer the basic question of how many agents are running, let alone which ones overlap.
A registry does not need to be sophisticated to be useful. A structured document with enforced fields and a review step before any agent reaches production closes most of the inventory gap. Agent observability tooling can populate the registry automatically once agents are instrumented, but the registry itself can start as a lightweight schema.
2. An orchestration layer
Orchestration answers the question of which agent runs when, and what happens if two agents want to act on the same resource simultaneously. This is the layer most teams skip because individual agents feel self-contained until they are not.
JPMorgan Chase’s autonomous agent deployment now covers 450 or more daily production use cases and has automated 360,000 manual hours annually. That scale is not achievable with independent agents that have no coordination mechanism. The orchestration layer is what lets you run agents at that density without conflicts compounding into data integrity problems.
For multi-agent systems, orchestration typically takes one of two shapes: a central orchestrator that routes tasks to specialist agents, or a peer model where agents negotiate handoffs. LinkedIn’s SQL Bot uses a hierarchical model, with a supervisor agent decomposing queries and routing subqueries to specialised agents. The hierarchy makes it possible to extend the system without re-architecting the whole thing each time.
flowchart TD
A[Incoming task] --> B[Orchestrator / router]
B --> C{Task type?}
C -- Data query --> D[Data agent]
C -- Customer action --> E[CRM agent]
C -- Notification --> F[Comms agent]
D --> G[Registry: log action]
E --> G
F --> G
G --> H[Monitoring layer]
H --> I{Within bounds?}
I -- Yes --> J[Complete]
I -- No --> K[Alert and escalate]
3. A monitoring and governance layer
Orchestration decides what runs. Monitoring records what actually happened and whether it was acceptable. The two serve different purposes, and most architectures need both before they can handle anything beyond a handful of agents.
Uber’s LangGraph-based agent network saved approximately 21,000 developer hours on code migrations. The reason that number is measurable is that the system had instrumentation from the start. Without monitoring, you get outcomes but no evidence, which makes debugging slow and makes the case for expanding the system difficult to build.
Governance at scale means encoding the rules about what agents are allowed to do, not just reviewing them after the fact. Runtime governance and pre-deployment review are complementary, and AI agent governance frameworks give you the policy structure to apply both consistently. Tools like Prefactor sit in this category, applying governance checks at runtime rather than relying on pre-deployment review alone.
For access control across agents, RBAC vs ABAC for agents covers the trade-offs between role-based and attribute-based models when agents need scoped permissions rather than broad credentials.
The sequence that works
You do not need to build all three layers before you ship another agent. The sequence that avoids the worst outcomes is:
- Instrument every agent already in production before adding new ones. Even basic logging of inputs, outputs, and tool calls gives you a baseline.
- Build the registry in parallel. Require every existing agent to have an entry before any new agent gets approved.
- Add the orchestration layer when you have two or more agents that share a data store, a downstream API, or a user-facing surface.
- Formalise governance policy once the registry and monitoring give you enough signal to write rules that reflect reality rather than aspiration.
Klarna’s deployment of 853 employee-equivalent agents saving $60 million annually did not emerge from a single architectural decision. It emerged from iterative expansion with each layer added as the previous one stabilised. The agentic AI architecture that supports that scale looks different from the architecture that supported the first five agents.
For platform engineering leads working through framework selection as part of this build, agentic AI frameworks and the LangGraph vs CrewAI comparison are relevant starting points. If your agents interact with external tools via standardised protocols, how MCP works explains the coordination model that keeps those integrations auditable.
Where to start
Map what you already have before you design what comes next. The agent readiness assessment will identify which of the three layers is most absent in your current setup and give you a prioritised order for closing the gap.
Matt Doughty CEO & Co-Founder, Prefactor Founder of Prefactor, writing on the operational reality of getting AI agents into production — evaluation, observability, governance, and the plumbing assistants never needed.