The Last Mile Notebook, Issue 2
Last quarter I sat in two conversations about a week apart, with two companies in roughly the same industry, at roughly the same size. The first one walked me through their AI agent with real pride. One agent, live, doing something genuinely useful in their support workflow. They had fought hard to get it there, and they had earned the pride. I told them so, and I meant it.
The second company, same week, mentioned almost in passing that they were running twelve. Not pilots. Twelve agents in production, across different functions, and they were mid-conversation about the next handful. They did not say it to impress me. They said it the way you mention how many laptops your team has. It was just infrastructure to them now.
I have not been able to stop thinking about those two conversations, because the first company does not yet understand that they are not one agent behind the second. They are a year behind, and the distance is growing while they sleep. That is what this issue is about, and if you read issue 1 about why most pilots die, this is the uncomfortable thing that happens to the ones that live.
The number that should worry boards
The analysts have now put a shape on what I was seeing in those two rooms. HFS Research studied this and found that the enterprises leading on AI agents, the ones they call Orchestrators, already run an average of about twelve agents in production, with some pushing twenty. The rest of the market is sitting at zero or one, mostly still in pilot.
Read that again, because the framing matters. The leaders are not slightly ahead. They have crossed into a different mode of operating. While most companies are still debating which model to standardize on, the leaders settled that question a year ago and moved on to the part that actually decides the outcome.
The wall at the sixth agent
Here is the part the proud-of-one company is about to discover, and it is the most counterintuitive thing I have learned in this space.
Going from one agent to two is easy. Two to five, harder but manageable. Then somewhere around the sixth agent, something breaks that has nothing to do with any individual agent’s quality. They start stepping on each other. One agent takes an action that quietly invalidates an assumption another agent is relying on. Behavior emerges that nobody designed and nobody can trace. A small failure in one workflow cascades into three others. And the audit gaps multiply faster than any human can keep up with.
I have watched teams hit this wall and misdiagnose it completely. They think agent number six is buggy. They debug it for weeks. But the agent is fine. What broke is that they were running six independent agents with no shared system underneath them, no common view of the data, no enforced boundaries between what each one is allowed to do, no single trail recording all of it. Five disconnected agents is a manageable mess. Twelve is chaos, unless there is an operating layer holding them together.
The companies running twelve did not get lucky or hire better prompt engineers. They built, or adopted, the layer that lets a fleet run without colliding. That is the whole difference. The analysts even have a name for it now, the same name we use: the agent operating system.
Why it is a clock and not just a gap
A gap you can close at your own pace. A clock you cannot.
The reason this is a clock is that the lead compounds. Every agent the second company puts into production teaches their operating layer something. A constraint gets tightened. An audit gap gets closed. A pattern gets reused on the next agent so it ships faster than the last. Their twelfth agent took a fraction of the effort their first one did, because the hard infrastructure work was already done.
So when the first company finally decides to get serious and go from one agent to twelve, they are not starting twelve steps behind. They are starting behind a system that has been compounding for a year, getting faster and safer with every deployment. The analyst read on the window is blunt: somewhere around twelve months for most enterprises, after which catching up stops being a budget decision and starts being a structural disadvantage. I think that read is right, and I think most boards have not priced it in at all.
What I would tell the company with one agent
I did not say all of this in the room, because nobody wants to hear “your proudest achievement is actually a warning sign” in a first conversation. But here is what I would say now, to them and to anyone sitting at one agent feeling good about it.
Be proud of the one. Getting even one agent into real production is harder than the demos make it look, and you did it. But do not mistake it for a finish line. The question that matters is not “do we have an agent in production.” It is “what happens when we try to run the sixth one next to the first five, and who owns the trail when all of them are acting across our systems at once.” If you cannot answer that, you are not behind on agents. You are behind on the system that lets agents become a fleet. And that is the thing with the clock on it.
One ask, same as last time
If you are inside a company doing this right now, hit reply and tell me the real number. Not how many agents you have built or demoed. How many are actually in production, governed, today. I am collecting these, honestly, because the gap between the number people say and the number that is real is its own story, and it might be the next issue.
Next issue is the one I have been building toward since issue 1: the last mile itself. How a single agent actually gets across the line from “works in the demo” to “live and governed,” told through the rescues I have watched up close. It is the most hopeful issue of the three, because it is the part you can actually do something about starting Monday.
If this was useful, subscribe so the last issue lands in your inbox. See you there.
Naman
Source:
HFS Research, HFS Horizons: Agentic Technology, 2026.
Product-voice version on the blog: createos.sh/blogs/enterprise-velocity-gap