Temporal's 2026 State of Development Report landed last week. 554 engineers and engineering leaders across the US and UK, surveyed between late April and late May. Everyone quoted the adoption number: 80.8% now use AI agents daily or more, up from 47.3% twelve months earlier.
That number is not very useful. Daily use of anything climbs past 80% eventually if it works. The figure worth staring at sits further down the report. The median respondent runs five AI agents. The average is 10.7. A slice of the sample runs more than a hundred.
Five is a fleet. Most teams are not running it like one.
Agents arrived one person at a time
Nobody approved this. That is the point.
Your microservices went through a design review. Somebody argued about the name. There is a repo, an owner, a dashboard, and a line in the on-call rota. When it breaks at 2am, a specific human's phone lights up.
Your agents went through none of that. An engineer wired up a PR triage agent on a Thursday afternoon. Someone else built a thing that turns support tickets into Linear issues. A third person has a script that runs nightly against production data and has mentioned it in standup exactly once. All of it is useful. None of it is written down anywhere.
The same report says 41.1% of respondents hit agent-related issues daily or more, and 9% hit them continuously. Those two findings belong together. You do not get a 41% daily failure rate from weak models. You get it from a dozen unowned processes holding production credentials with no agreed definition of what working looks like.
The question that exposes it
Ask your team to name every agent running against your systems right now, who owns each one, what credentials it holds, and what happens if it stops.
Most teams cannot finish that sentence. Every time we run this exercise the list comes back longer than anyone expected, and there are always two or three entries nobody can attribute. That is a service catalog problem wearing a new hat. You have solved it before.
What to actually do
Treat the fleet like services, because that is what they are.
- Give every agent one named owner. A person, not a team. If nobody will put their name on it, switch it off and see who complains.
- Write down its blast radius. What it can read, what it can write, whose credentials it runs on. Most agents inherit a human's token, which means their blast radius is that human's entire access.
- Define failure in business terms. Not "the API returned 500". An agent that cheerfully produces wrong output for three weeks does more damage than one that crashes on day one, and only the second kind shows up in your error rate.
- Add a kill switch someone other than the author can pull. At 2am the author is asleep.
None of this is exotic. It is the operational hygiene you already apply to everything else you run in production. The reason it has not reached agents yet is that agents did not feel like infrastructure while you were building them. They felt like scripts. Then there were five of them, then ten, and the credentials never got scoped down.
The teams doing well here noticed early that they had quietly acquired a fleet and started running it on purpose. Which model they picked barely enters into it.
We're here to help founders and teams design and build digital products that are built to scale with you, not slow you down. If you're looking to build something, get in contact with us today!