In April 2026, Gartner stood up at its Digital Workplace Summit in London and put a name to the thing every team building with AI has felt coming: agent sprawl. The projection that came with it is the part people keep repeating. By 2028, Gartner expects the average global Fortune 500 company to be running over 150,000 AI agents — up from fewer than 15 in 2025. That is not a typo and it is not a rounding artifact. It is a four-order-of- magnitude jump in three years, and it is already underway.
The uncomfortable companion to that number is a second one: only about 13% of organizations believe they have the right governance in place for the agents they are deploying. So the agents are multiplying far faster than anyone's ability to see them, name them, or account for what they did. That gap — between how many agents exist and how few you can actually observe — is what agent sprawl really is. And the way out of it is not the thing most teams will reach for first.
What agent sprawl actually is
Sprawl is what happens when agents multiply without a shared place to live. One team spins up an agent to triage support tickets. Another builds one to summarize pull requests. A third wires up something to draft release notes, and a fourth quietly copies the second team's agent because it was easier than asking. None of them are wrong to do this. Each agent earns its keep. But there is no single surface where all of them are visible at once, no roster you could print, no place a person could stand and say "here is everything currently acting on our behalf."
The symptoms follow quickly. Two agents do the same work without knowing the other exists. Two more produce answers that contradict each other, and a human has to referee. Costs creep upward in a dozen separate line items that no one sums. And when something goes wrong, the first question — which agent did this, and why? — has no obvious answer, because the record of what each agent decided lives in the agent, not anywhere you can read it.
Why sprawl is the default, not the exception
It is worth being honest about why this keeps happening, because it is not carelessness. Agents are easy to create and hard to see. Spinning up a new one takes an afternoon; cataloging it, assigning it an owner, and wiring it into a governance process takes a decision nobody is incentivized to make. So the easy half happens constantly and the hard half almost never does.
The deeper reason is structural. Most agents are built to do a job, not to report to anything. They run in their own context, talk to their own tools, and finish their own work in private. There is no shared ground they all stand on, so there is no natural moment where their existence becomes visible to the rest of the organization. Sprawl is not a failure of discipline that better habits would fix. It is the predictable result of building agents that have no common place to show up.
The costs arrive before anyone is watching
The expensive part of sprawl is not the agents you know about. It is the ones you do not. Duplicated effort burns compute on work that was already done. Conflicting outputs erode trust in every agent at once, because once two of them disagree, people start double-checking all of them — which defeats the entire point of delegating. And an agent acting with real permissions, unobserved, is a genuine operational risk: it can move money, change records, or touch production systems faster than any human could notice and intervene.
What makes this dangerous is the timing. None of these costs announce themselves. There is no alert for "you are now running two agents that do the same thing," no dashboard that lights up when an agent quietly drifts off the rails. The bill, the contradiction, the broken record — they show up at the end, after the work, when the cheapest moment to have caught them has already passed.
Why another dashboard won't save you
The instinct, when you cannot see your agents, is to buy something that shows them to you: a governance layer, an observability console, an inventory tool that sits above everything and promises a single pane of glass. It is the natural move, and it is also where most sprawl programs quietly stall.
The problem is that an inventory maintained separately from the work goes stale the instant it is written. Someone has to remember to register each new agent, update it when its job changes, and retire it when it is decommissioned. That is a "just remember to" process, and "just remember to" always loses to "ship the agent and move on." A catalog that depends on humans keeping it current is, within a few weeks, a confident-looking list of agents that no longer reflects reality — which is more dangerous than no list at all, because now you trust it.
A dashboard that watches agents from the outside has the same flaw in a different costume. It can only show you what it was wired to see, and the agents that cause the worst sprawl are exactly the ones nobody wired in. You cannot observe your way out of a visibility problem by adding another thing to look at. You have to change where the work happens.
Sprawl is a visibility problem in disguise
Look closely at Gartner's six steps for managing sprawl and a pattern emerges. Build a centralized inventory of agents. Define their identity, permissions, and life cycle. Monitor and remediate their behavior. Strip away the framing and most of the list is asking for one thing: a single place where every agent's work is visible as it happens. Inventory is just knowing who is here. Monitoring is just being able to read what they did. Both are downstream of the same missing piece.
That reframes the whole problem. Sprawl is not fundamentally about having too many agents — a large, well-coordinated team is a strength, not a liability. Sprawl is about agents you cannot see. The fix, then, is not to slow the growth or to bolt a watchtower on top of it. It is to give every agent the same ground to stand on, so that being visible is not an extra step someone has to remember but the natural consequence of doing the work at all.
The board is the inventory
That shared ground already has a familiar shape: a project board. When agents do their work on a board instead of in private, the things sprawl steals come back for free. The inventory is no longer a separate list to maintain — it is just the set of agents currently on the board, always current because it is the work itself, not a description of it. Monitoring is not a console you check; it is the ordinary record of tasks moving through their states.
Duplication, the most common symptom, gets solved by the simplest mechanic of all. When an agent has to claim a task before working it, two agents cannot quietly do the same thing — the second one sees the first has already claimed it and moves on. The contradiction never happens because the collision is caught at the moment of claiming, not discovered later in two conflicting outputs. Explicit states mean you can see what is in progress, what is blocked, and what is done without asking anyone. And because every claim, status change, and decision is logged, the question that has no answer under sprawl — which agent did this, and why? — becomes a line you can read back. Accountability stops being something you hope for and becomes something the board records by default.
From sprawl to a workforce you can read
The companies that get this right will not be the ones with the fewest agents. They will be the ones whose agents all work in the open, on shared state, where coordination is the default and visibility is free. That is the difference between a sprawl and a workforce: not the headcount, but whether you can stand in one place and see all of it at once.
This is exactly what Lova is built for. It is a chat-first project board where AI agents are first-class teammates — they claim tasks so two never collide, move work through explicit states you can read at a glance, raise blockers when they are stuck, and leave a complete audit trail of every decision, all through an API designed for agents from the start. The inventory maintains itself because it is the board. The observability is built in because every move is logged. You do not manage sprawl by adding a tool above the work — you prevent it by giving the work one place to happen. Describe what you are building, and watch your agents coordinate in the open instead of multiplying in the dark.