The early footprint of automations, measured rather than predicted

Most accounts of agent adoption are written either by someone selling agents or someone worried about them. Both produce clean stories. The observed version is messier and more useful.

This is what the first three months tend to look like.

Weeks one to three: the easy win

Something works almost immediately. It is usually narrow, well-specified and boring: a triage step, a summary, a draft. The team is pleased, and reasonably so, because the thing genuinely works.

This period generates most of the enthusiasm and almost none of the durable value. The work that is easy to automate is easy because it was already well-defined, which usually means it was not the expensive part of anyone's week.

Weeks four to seven: the sprawl

Having seen it work once, people build more. This is the point at which the count goes from three agents to thirty, and the first structural problem appears: nobody knows what is running.

Not in a dramatic way. No incident, no outage. Simply that if you ask which agents exist, who owns them and what they cost, the answer takes a week to assemble and is incomplete when it arrives.

Teams that had attribution and ownership in place before this point pass through it without noticing. Teams that did not spend the next month building it retroactively, which is considerably more work than building it in advance.

Weeks eight to eleven: the quality question

Somewhere in here, an agent produces something confidently wrong and a person does not catch it.

This is the moment that determines how the rest of the year goes. One response is to add human review to everything, which returns the time saved and makes the programme pointless. The other is to define what good output looks like precisely enough to score automatically, which is harder up front and is the only version that scales.

Evals are not a sophistication to add later. They are what allows review to become triage rather than uniform suspicion.

Week twelve: the orphans

By the end of a quarter, a measurable share of the agents built in weeks four to seven are still running and no longer serving any purpose. The project ended, the person moved team, the workflow changed.

Without a named owner per agent, nothing in the organisation notices. The spend continues, the audit trail fills with actions nobody reads, and the count of running agents becomes a number people have stopped trusting.

What separates the teams that do well

It is not model choice, and it is not the sophistication of the first automation. It is whether four things were in place before the sprawl arrived: attribution per agent, a named owner per agent, a budget that blocks rather than warns, and at least a crude evaluation set for the highest-volume work.

Teams with those four handle the ninety days as a normal engineering progression. Teams without them experience it as a series of surprises, each of which is solvable and none of which was anticipated.

The honest summary

Agents do remove work. They also add a category of work that did not exist before: operating them. Any account of adoption that reports the first without the second is describing a demo, not a quarter.

Next

The Future of Work pages cover the four areas we study, and the Agent Orchestration System pages cover the attribution, ownership, budget and evaluation layers that this pattern keeps pointing at.