When you let everyone build agents, you get a lot of agents. Stripe published the number: over 4,000 from a no-code builder. KPMG and Gartner call the pattern agent sprawl. Shopify hit a second version of it: one merchant agent that stopped making sense once it had 50+ tools.
This post is not “4,000 is wrong” or “one agent is right.” It is what these teams wanted, what broke, what they changed, and what is worth stealing for your own stack.
Stripe: 4,000 little programs
Stripe wanted company-wide knowledge AI — sales, finance, GTM — with the agent available in web, Slack, and embeds, not stuck in one chat tab.
They tried two paths:
- A no-code agent builder — anyone could ship an agent with tools.
- Coding agents — strong for engineers; risky and support-heavy when non-engineers used them.
The no-code path worked at shipping. Over 4,000 agents. That is not 4,000 copies of one service. It is thousands of little programs: similar prompts, uneven quality, no clear owner, no single place to fix things when a tool or policy changed.
They rebuilt as Kai:
- One agent behind APIs — web, Slack, and embeds are just front ends
- AgentStudio — domain teams own skills, tools, and quality
- A shared runtime — same sandbox and execution path as their product agents (Deep Agents; LangChain’s write-up)
After launch they reported 83% weekly active users, 1,000+ skills and tools, and sessions long enough that one hit 932 turns.
Takeaway: Shipping is easy. Owning is the job. They scaled builders by putting owned skills on one shared agent, not by keeping thousands of orphans.
The industry names it
KPMG describes the same movie elsewhere: agents shipped as one-off features, nobody can list them all, hard to see what they did, spend goes up, shared model capacity gets noisy when unbound agents run wild.
Gartner: by 2028, an average Fortune 500 may run 150,000+ agents (from under 15 in 2025). Only 13% of orgs think they have the right governance.
KPMG’s response language is fewer big orchestrators with reusable skills under clear rules — close to what Kai became. Gartner’s list starts with policies, a catalog, owners, permissions, and a way to retire agents. Rules around building — not a ban on building.
Takeaway: The number matters less than whether you can name an owner, kill a dead agent, and change a skill without a scavenger hunt. Low-code studios often show up where sprawl appears. That does not mean studios are the villain. Unowned creation is.
Shopify: too many tools in one agent
Sidekick had to stay trustworthy as merchants asked for more — segments, product forms, admin work, SEO.
Tool count grew. Their bands:
- 0–20 — clear
- 20–50 — fuzzy
- 50+ — many ways to do the same thing; hard to reason about
They called the prompt mess “Death by a Thousand Instructions.” Jumping to multi-agent setups early looks tempting. A vague “rate this 0–10” model judge is not real eval.
What they did instead:
- Send instructions with the tool when it is needed — keep the base prompt thin
- Build eval sets from real production chats, not only hand-picked examples
- Train judges against human labels (they report agreement moving from near-random toward near-human), and watch for the model gaming the judge
Anthropic’s Agent Skills describe the same idea: show a short description first, load the full skill when it is used, pull heavier files only if needed. Shopify, Stripe’s skill routing, and Anthropic are solving one problem: do not dump the whole catalog into every turn.
Takeaway: Sprawl is not only “too many agents.” You can break the one agent you kept by stuffing it. Load tools when needed. Check quality for real — “it returned 200” is not “it was right.”
What is worth taking
| What broke | What they did |
|---|---|
| Thousands of unowned agents | One shared agent + owned skills (Stripe); catalog, owners, retire path (Gartner/KPMG) |
| One agent with too many tools | Load guidance with the tool; eval from production; judges checked against people (Shopify) |
No single vendor shortlist falls out of this. Studios, managed agents, cloud runtimes, frameworks, and eval tools do different jobs. Teams that published rebuilds usually wired several of those jobs together. That is an observation, not a mandate to copy Kai’s bill of materials. Anthropic and Shopify both say the same quieter thing: start simple; add complexity when the metrics say you must.
Practical questions:
- What does your “4,000” mean? Same owned service × N, or N little programs?
- Who owns each agent — or each skill — after it ships?
- Can you update or kill a capability without hunting?
- As you add tools, do you load them all at once or only when needed?
- Do you know it still works because someone checked — or only because the request succeeded?
Agent sprawl, in these write-ups, is what happens when building outruns ownership. Stripe wrote down the micro-agent chapter and the Kai rebuild. Analysts named the pattern. Shopify wrote down the same pressure inside one agent. Steal the questions. Skip the dogma.