Agent sprawl: how to run a company on one AI agent instead of 3,000

Recently I was on a call with an account executive from a company that sells an AI agent platform. At one point he told me how they run their own operations: 3,000 agents working in parallel, about 500 of them active at that moment.

I've never understood this way of running a company on AI, and the call made me sit down and write out why. Below is what those 3,000 agents actually are, what goes wrong as they pile up, what Vercel did instead, and how we build the same thing at SegmentStream.

What "3,000 agents" means

In most agent platforms, an agent is one automated job: match yesterday's payments, triage new leads, write the weekly report, file a form in a government portal. Each one gets its own instructions, its own tools, its own connections to company systems with their own credentials, and an owner, usually the person who built it.

So 3,000 agents means 3,000 copies of all of that. 3,000 sets of instructions, each restating some part of how the company works. 3,000 sets of access to company systems, granted one at a time by whoever built the agent. And with 500 active, 2,500 agents doing nothing right now, many of them still holding their keys.

This is quickly becoming normal. In May, the Wall Street Journal reported that staff at DaVita had built more than 10,000 agents and that FICO's 3,500 employees create dozens of new agents every day (summary). Gartner expects the average Fortune 500 company to use more than 150,000 agents by 2028, up from fewer than 15 in 2025. The problem already has a name: agent sprawl.

What goes wrong

Each agent on its own is usually fine. It was built for one job, tested on that job and does it. The trouble is the sum.

Nobody can say what the agents may do. Ask "which of our agents can issue a refund or read salaries?" and the answer is spread across thousands of configurations in several platforms.

Every rule is copied. The refund limit, what counts as an active customer, which deals need a manager's approval: every agent that needs a rule carries its own copy in its instructions. Change the rule and you have to find every agent that copied it. Miss one and two agents give the same customer different answers.

Keys outlive their purpose. An agent built for a one-off project keeps its connection to the CRM after the project ends. The person who built it moves to another team. The agent sits idle, and its key still works.

Each agent sees only its slice. The lead triage agent doesn't know the customer has an open support escalation, because that lives in another agent's context. Every answer is right within its slice and can still be wrong for the company.

There is no single history. Each agent logs what it did in its own platform, if it logs at all. When a number changes in the CRM, finding which of 3,000 agents changed it is an investigation.

Arvind Jain, the CEO of Glean, hears the same thing from the people he talks to:

Vercel went the other way

Vercel went through this earlier than most companies. "Last year was about prototyping," Guillermo Rauch, Vercel's CEO, told TechCrunch in July. "We did that, and we learned a lot because we had hundreds of agents organically developed and deployed within the company." In the same interview he named the agent that helps you run the company as one of the two big uses for agents, and named its hard parts: "How do you securely access data? How do you audit what the agent is doing?"

Today Vercel's people work with one internal agent, V.

In the same post he writes that V is "seeded by the skills we gave it and we update," and keeps "memories and personalized workflows and schedules on a per-user basis." He also answers the obvious objection, that a company could get the same thing from an AI vendor's Slack integration: "that's not your agent, that's their agent."

V doesn't do every job itself. Vercel describes it as an orchestrator that hands work to specialists, such as d0, its data agent, and v0, which builds charts and apps. For the people at Vercel, though, there is one agent to ask, and new capabilities are added behind it. The job listing for the team that builds V describes the goal as letting teams add capabilities without creating fragmented agents.

The data agent got better the same way. Vercel's team replaced most of d0's specialized tools with a single tool that runs shell commands over the files describing their data. Its success rate went from 80% to 100%, it ran 3.5 times faster and it used 37% fewer tokens.

We share this view

We came to the same conclusion, and SegmentStream is built on it. A company needs one agent of its own, with the business described once behind it: what the company deals with, what may happen to it, who may do what, and what has already happened.

Vercel built V and everything under it on its own infrastructure, with its own team. Most companies can't do that. SegmentStream Cloud gives them that layer: the ontology, the gateway every agent connects through and one history, defined in code in a repository the company owns. That last part matters for the reason Rauch gives. When the description of your business lives in your own repository and workspace, the agent working on it is yours, whichever model runs it.

One company agent, one company context

Here is how it fits together.

It starts with the context, so that comes first.

The company context is an ontology. An ontology is a description of the business that software can work with. It names the things the company deals with, how they relate to each other and what may happen to them:

• Objects: customers, deals, payments, vendors, with the same fields and the same IDs for everyone. A deal belongs to a company; a payment settles an invoice.
• Actions: what the company allows to happen, with its rules inside. refund.issue knows the support limit; deal.moveStage knows that a won deal is final.
• Roles: who may run which action.
• Skills: how the company does things, from onboarding a customer to closing the month, written once.
• Connections: every system connected once, with its credentials kept in the workspace.
• History: every change, who asked for it, through which agent, and the value it replaced.

In SegmentStream the ontology is written in code, and every action in it becomes a tool that agents call through MCP, the standard way agents connect to software. I compared it with a semantic layer in another post.

Everyone keeps their own agent. For personal work, people use whatever they like: Claude, ChatGPT, Grok, a bot on their phone. Each one connects to the same ontology through the same gateway and signs in as its person. It sees the same tools and follows the same rules, so it can do everything the company agent can do for that person, and nothing their role doesn't allow.

The company agent is for multiplayer work. Some work belongs to no single person's chat: a request in a team channel, a handoff from support to finance, a job that runs at night with nobody watching. That is what the one company agent is for. It works in shared spaces, knows who asked each time and acts with that person's role.

A workflow is the company agent with a fixed setup. A workflow starts the same agent on a schedule or when something happens, with exactly the tools and skills that job needs and a role that allows nothing more. The weekly report is the company agent every Monday at 8:00, with the weekly-report skill and read-only metric tools. Lead routing is the company agent started by a new lead, with the lead-routing skill and one tool, lead.assign.

Because everything that matters lives in the ontology, any of these agents can be replaced. Change the model, move from one chat app to another, add whatever interface appears next year: the objects, rules, roles and history stay where they are. I wrote about that side of it in MCP gateway vs raw MCP servers.

Where the 3,000 jobs go

The work those 3,000 agents do still has to be done. Each job moves into the ontology as what it really is.

Almost everything that gets built as a separate agent is one of three things:

1. An action with its rules: issue a refund, assign a lead, pause a campaign. Defined once and checked on every call, whichever agent makes it.
2. A skill: how a job is done. Any agent reads it when a task calls for it.
3. A workflow: the company agent, started on a schedule or by an event, with a fixed set of tools and skills and a role that allows only what the job needs.

Workflows cover the usual reason for building a separate agent: a job that runs in the background with narrow permissions. It still gets its own trigger, its own tools and its own role. It no longer gets its own copy of the company.

So the company runs one agent. What grows is the number of actions, skills, workflows and roles. Each is defined once, reviewed like code and visible in one place, and every run, from every agent, lands in the same history.

When a separate agent makes sense

Some separation is justified. Three cases come up.

Someone outside the company is talking to it. A support assistant on your website acts for customers, who should see a far narrower slice of the company than any employee. Give it its own role and its own front door. It still reads the same objects and calls the same actions.

Helpers inside one task. A research question might run several searches in parallel and combine the results. Cognition, the company behind Devin, argued in 2025 that most teams shouldn't build multi-agent systems. This year it wrote that it now uses them in a narrower form, where several agents contribute to a task "while writes stay single-threaded."

Specialists behind the front door. V hands data questions to d0. That works because d0 answers from the same data definitions and under the same permissions as everything else.

In all three cases the agents share one context. That is the part a company should never copy.

The other view: 100 times more agents than people

Aaron Levie, the CEO of Box, often says companies will have 100 times more agents than people. Count every run of one agent across a company and he may well be right. His conclusion is the same as this article's:

Whether you count one agent or a hundred thousand runs, they need the same thing underneath: one description of the business, one set of rules, one place where access is granted and one history.

Before you build agent number 3,001

Ask these about the next agent someone wants to build:

1. Whose key is it? Will the agent hold its own credentials, or act through connections the company controls?
2. Where do its rules live? In its instructions, or in actions every agent shares?
3. What happens when a rule changes? Do you edit one action, or look for every agent that copied it?
4. Can you list what it may do? Next to what every other agent may do, in one place?
5. Where does its history go? Into the same history as every other change, with the value before?
6. What happens when its builder leaves? Who owns it, and who switches it off?
7. Could it be an action, a skill or a workflow instead? Usually it can.

How we build this

On SegmentStream Cloud, the layer this article describes is your company's software: an ontology of entities, actions with their rules, roles and measures, plus connections and history, defined in code in a repository you own. Every app's ontology is served as MCP tools and an API, so whichever agent your people use signs in as the person using it and sees only the actions that person's role allows.

See how every workspace serves its ontology to agents over MCP, how we run our own CRM on it, or start a pilot: our engineers model your business, connect the systems you already use and hand you the repository. Or read MCP gateway vs raw MCP servers and why AI agents need a semantic layer.