Agent sprawl: why ten clever agents add up to less than one good workflow

The easiest way to waste money on agentic AI is to automate tasks one at a time. You get a dozen agents and nothing changes. Here is the alternative.

What we keep seeing

A company gets Copilot Studio. Within a month there is an agent that summarises tickets, an agent that drafts quotes, an agent that answers HR questions, and an agent somebody in finance built to chase invoices. Each one works. Each one has a happy owner. And six months later the finance director asks what all of this has changed, and the honest answer is: not much.

IBM's guide to return on agentic AI calls this prioritising task automation over workflow transformation, and names it as one of the three main reasons agents fail to pay back. Their phrase for the result is agent sprawl: many disconnected agents across applications, functions and workflows, none of them contributing to the same goal. We would add that it is the same shape as the Power BI estate with four hundred reports nobody can find, or the Fabric tenant with sixty workspaces. New tool, old habit.

This is the second of three posts drawing on IBM's guide. The first was about deciding what you are measuring before you build. The third is about the people who decide whether it pays back.

Why task-by-task feels right and is not

Automating one task is easy to scope, easy to demo and easy to approve. That is exactly why it happens. The problem is that a task sits inside a process, and the process is where the cost and the delay live.

Take a quote. The agent drafts it in thirty seconds instead of twenty minutes. Good. But the quote still waits two days for a credit check that happens in a different system, then another day for a manager to approve it in email, then it is keyed into Business Central by hand. The customer sees a four-day turnaround become a three-and-a-half-day turnaround. Nobody notices. The agent is technically a success and commercially irrelevant.

IBM's point is that the return comes from redesigning the whole flow, with agents, automations and people each doing the part they are best at, under one set of rules. That is not a bigger agent. It is a different question: what does this process need to look like end to end, and where does automation actually move the number?

What a workflow-first design looks like

We approach it the way we approach any analytics programme. Start with the outcome, work backwards.

Map the flow once, honestly. Enquiry to cash, ticket to resolution, purchase request to goods received. Every hand-off, every wait, every system. Most organisations have never drawn this, and the drawing alone changes the conversation. The waits are usually longer than the work.

Find the one number the flow is judged on. Days from enquiry to quote. First-time fix rate. Supplier onboarding time. This is the measure from the first post, applied to the whole process rather than one step in it.

Decide where agents help and where they do not. Agents are good at reading, drafting, classifying and routing. They are bad at being the system of record. The data an agent produces should land in the system that owns it, which for most of our clients is Dataverse, Business Central or a Fabric lakehouse, never a spreadsheet or the agent's own memory. We wrote about the same rule for apps in When a Power App is the right fix, and when it is not.

Give the agents one place to get their facts. IBM calls this the orchestration layer and, for an enterprise, it is a product category. For a mid-market Microsoft estate it is mostly a data question. If every agent reads from the same governed model of customers, products and orders, they agree with each other and with the reports. If each one has its own connection to its own copy, you have built four opinions. OneLake in plain English explains why one copy of the data matters so much more once agents are involved.

Put a human where the decision is. Not everywhere. At the point in the flow where money, risk or a customer relationship is committed. Our post on in the loop or on the loop is the longer version of that argument.

The governance you need, and the governance you do not

IBM's guide is clear that governance is what separates the organisations getting a return from the rest: 68% of the top performers in their research had mature governance frameworks, against 32% of everyone else. We agree, and we would add a warning. Governance for agents in a mid-market business is not a committee and a forty-page policy. It is an inventory of what exists and who owns it, a rule about where data lands, a rule about which connectors an agent may use, and a review every quarter of what is still earning its keep. Microsoft has started putting the tooling for this into the admin centres, as our post on managed apps describes. Use it.

What to do with the agents you already have

Do not switch them off. List them. For each one, write down which process it sits in, what number it is supposed to move, and whether anyone can show that number moving. Most will fall into one of three groups: genuinely useful and worth folding into a proper workflow design, harmless and cheap enough to leave alone, or quietly expensive and unowned. The third group is where the sprawl is. That list is the start of a real AI roadmap, and it is a conversation we are happy to have as part of our AI and analytics work.

Ten clever agents are a collection. One well-designed workflow with three agents inside it is a result.

Related reading

Only one AI agent in four pays back. Decide what you are measuring before you build one

AI does not remove workflow debt, it compounds it

The Fabric rollout that quietly goes wrong: workspace sprawl, shadow BI and the readiness checks

From prototype to production: the Azure architecture behind enterprise AI agents