Scale Capabilities Before You Scale Agents
Enterprise AI reference architectures have converged on two pictures. One is agents everywhere: a planning agent, a finance agent, an ERP agent, a supervisor to coordinate them, shared memory, handoffs, routing, state. The other is a company brain, one chat that knows everything. Every box in the first is another boundary where context can diverge, state can go stale and meaning can get lost. The second has no boundaries at all, which is its own problem: one application ends up answerable for the whole company.
The estate at Warmtebouw went the other way. Twelve MCP servers and 97 tools by the end of August, reaching eleven external APIs and our own internal ones, and no network of agents anywhere in it. Around twenty colleagues use it on a given day, and more than a hundred have used it at least once over the past few months. Most of them are not developers.
The bias is one sentence: before you add autonomy, give the model reliable and well-explained access to the business. By capability I mean a permission-bounded tool exposing one live operation or query, with enough semantics travelling alongside it that a model can use it correctly. Not an endpoint, and not a document about one.
The three architectures differ in one thing
Almost every "AI for the company" proposal is one of three shapes. The useful way to compare them is to ask where the meaning of the company ends up living.
| Approach | Where meaning lives | Source of truth | Architectural cost |
|---|---|---|---|
| Agents everywhere | Spread across the agents, and it has to survive being passed between them | The systems, reached through a chain | Task ownership, per-agent identity, state, cross-agent evaluation, failure propagation |
| The company chatbot | Centralised in the chatbot, which has to know about every source | Whatever each integration was wired to | One application holding every integration, permission model and interpretation, and having to be right about all of them at once |
| Capabilities | In the interface to each system, next to the data it describes | The system of record, unchanged | Writing the meaning down once per capability, and fitting every description into one context window |
Agents distribute interpretation across boundaries. A chatbot centralises it in one application that has to be right about every source at once, which is a layer you keep alive on top of systems that already work. Capabilities keep interpretation next to the system that owns the data. For operational questions, that was the trade-off we preferred.
Why capabilities won here
The questions are operational. They change during the day, and a copy is only ever as current as the last sync, which is a job you own rather than an answer you get.
There is one place to fix a misreading. A raw API is not automatically a useful capability. Hand the model { "energielabel": null } and it still has to work out whether that means no label, not registered, not applicable, or not loaded yet. Four valid answers share one JSON representation, so this is a contract problem and not a model-quality problem. No model reliably recovers a distinction the interface does not encode; a strong one guesses right more often, which is the trap. That interpretation belongs with the capability, in one place read by every client, rather than with whichever agent happens to consume it.
Users do not ask questions that respect the org chart. A project manager working out why a job is losing money wants the ERP margin, the installed BIM elements, the service history and the meter readings in one conversation, in about ninety seconds. Route that through four departmental agents and a supervisor and you have built a switchboard for a question nobody would phrase that way. Permissions come along with the capability: access is allowlisted per role against the identity provider that already governs those systems, rather than reinvented per agent.
If a capability is semantically thin, an agent on top of it does not fix that. It guesses, a supervisor interprets the guess, and the user gets a well-written answer with the uncertainty two hops from anyone who could have caught it.
If the interface is empty, an agent on top of it is a guess with a job title.
Capabilities, procedures, agents
Three levels, and most architecture diagrams collapse them into one.
- A capability gives the model access, meaning and bounded authority.
- A procedure prescribes how capabilities are combined. A skill is one.
- An agent decides at runtime what to do next.
The dividing line is control flow, not intelligence. A procedure has a path you can read before it runs; an agent chooses part of that path while running, and that choice is where the machinery starts. Stopping conditions, state, evaluation and observability all get harder once the path is not known in advance. Control flow is also what keeps this consistent with my complaint about skills: the skill is the procedure, the capability holds the domain knowledge and the data. A skill that explains what a field means has taken over the capability's job.
"Agent" increasingly describes how a system looks from outside rather than how it is built. A workflow calling five tools can look agentic while containing no autonomous component at all. What matters is where meaning lives, who may act, and which decisions genuinely require autonomy.
Do not ask how to operate an agent until you have established that you need one.
So is there a place for an agent?
Yes, but less often than those reference architectures suggest. A service message comes in, and Gemini 3.7 Flash writes a usable subject line for it: clear input, bounded output, one responsibility, easy to evaluate. It chooses no next action and carries no state. Much of what gets drawn as an agent turns out to be a function with a model in it, that example included.
A "finance agent" is the opposite shape: no clear input, no bounded output, nowhere natural to measure it, and one reason to exist, which is that finance is a department. Use an agent when you need autonomy, a capability when you need access.
What does earn autonomy is work whose next step genuinely cannot be known in advance, and the levels stack cheaply once the bottom one is good. A scheduled task runs a procedure, the procedure calls the capabilities in the order it prescribes, and the model handles whatever the procedure could not anticipate. Ours is a scheduled task in Claude running a skill. That is autonomy doing real work, with no agent per domain. The capability was the investment; the schedule and the skill are configuration on top of it.
Where this breaks down
Tool selection scales badly, though less than it did. Ninety-seven tools in one context is a selection problem before it is an achievement, and descriptions rich enough to carry domain meaning consume the most room. Clients have started fixing that, with tools connected deferred and their schemas fetched on demand, and the protocol is moving the same way. That moves the ceiling rather than removing it. Selection now runs against the description, so a thin description stops being misunderstood and starts being skipped over, and getting the right meaning to the model at the right moment becomes the work. When routing does arrive, I want it choosing which capabilities to load, not choosing which departmental agent to ask.
And this is one company. Around 350 people, one primary user-facing model, and about an hour a week keeping twelve servers' descriptions true. Whether the same defaults hold across a multinational with hundreds of systems and complex tenancy, I have no idea.
The measure is not how many agents are running
Agent count is not a maturity metric. The better question is whether the model can reach the right part of the company and understand what it finds there.
Build that layer first. Add procedures when the sequence is known, routing when scale requires it, and autonomy only when it earns its place.
This post is one piece of a longer argument. Production MCP: A Practitioner's Guide puts all of them in order, from understanding your data through to identity-bound deployment.
Go deeper: read the full practitioner report, The Missing Layer, or explore the mcp-metadata-demo server, an open-source extract of these patterns, since the production servers run on private business data.