Cycle time for agent work: the four phases

Cycle time for agent work should be reported in four parts: spec (the task was created until the first run started), build (the run itself), verify (evidence attached until the gate returned a verdict) and settle (passed until closed). A single nine-day number gives you nothing to act on. The split shows you which of the nine days to fix.

Why does one number stop working once agents are involved?

Because agents move the bottleneck but leave the total where it was.

With a human team, execution was the expensive phase, and everyone knew it. Most tracker metrics were designed around that assumption: time in progress, work in progress limits, burndown against days of effort. All of them assume that building is the slow part.

Agents break that assumption. Execution shrinks toward minutes, and the time that used to hide behind it becomes most of the cycle. Teams then see a cycle time that has barely improved and conclude the agents are not working. What has happened is that the constraint moved into a phase nobody was measuring.

DORA found the same pattern at the release end. The 2025 report recorded AI improving throughput while delivery stability declined. More work arrived faster, and more of it needed attention afterwards. The time is moved more than it is saved, and a single undivided metric cannot show that move.

What are the four phases?

Spec runs from creation to the first run. It holds everything that has to exist before an agent can start: the description, the definition of done, the scope, and the revisions to all three. Most teams do not know they have this phase.

Build is the execution itself, whoever does it. For an agent task this is often the shortest phase on the chart, and that is the main finding.

Verify runs from evidence attached to verdict returned. It covers the automated checks, any model-graded checks, and the wait for a human when the task was sampled. It is the phase most likely to be nothing but queueing.

Settle runs from a passing verdict to a closed task: the merge, the release, the sign-off, whatever your process still requires after the work is correct.

Which phase is usually the problem?

Spec and verify, and they fail in opposite ways.

Long spec time is not automatically bad. Writing a precise done-test is real work, and it is the work that makes the run succeed first time. Long spec with a high first-pass rate is a team investing correctly. Long spec with a low first-pass rate is a team rewriting the same task again and again. That is a different problem, even though the timestamps look the same.

Verify time is more often waste, because most of it is spent waiting, not verifying. It is the gap between the evidence being ready and a person picking it up. That gap should be tracked as its own measure, human wait share, and it is usually the biggest single thing you can change. It improves with better scheduling, not more engineering, so it is the cheapest thing on this list to fix.

How do you instrument the split honestly?

From status transitions, and only from transitions the system recorded itself.

Each phase boundary has to be an event the tracker wrote when it happened. A field somebody set afterwards does not count. Once a phase boundary can be edited, the split stops describing what happened and starts describing how the work was supposed to go. Three rules keep it honest:

• Take the median, not the mean. One task that sat over a holiday will dominate an average and tell you nothing about the normal case.
• Count reopens as new cycles, not extensions. Otherwise a reopened task inflates settle time without anyone seeing it, and the reopen itself disappears.
• Report the unestimated and the unverified as counts beside the chart, and never fold them in. If a number quietly leaves out the awkward cases, people stop trusting it.

What do you do with the answer?

Each phase has its own fix, and the fix for one will not help another:

Split the time before you act, because three of those five rows look the same on an undivided chart. A team that adds agents to fix a spec problem will produce unspecified work faster than before.

Is this just lead time with extra steps?

No. The difference is the verify phase.

Lead time and cycle time, as normally defined, stop at delivered. They have no concept of a verdict. When people did the work, claiming a task was complete and completing it were the same event. Once an agent is the worker, those two things separate. The claim always arrives, and it arrives at once. The verdict arrives later and sometimes says no. A metric with no verify phase cannot show the gap between a task saying it is done and a task being done. On an agent programme, that is the gap that matters most.

In Cognibl this split is the headline chart on a project, drawn as one stacked bar with a segment for each phase. We draw it that way because the comparison people need is between the four parts, not against last quarter.