How do you estimate AI agent work?

Estimate the same scope and dependency inputs you always did, then replace the duration estimate with a review-time estimate. The agent's own working time isn't a meaningful number to plan against; the human check before the output counts as done is.

Does historical velocity still work once an agent joins the team?

No, not for the tasks an agent touches. Velocity is built from how long people historically took to finish similar work, and an agent's working time follows different rules entirely, so points calibrated against human throughput stop predicting anything for agent-touched items.

What should you estimate instead of an agent's build time?

Review time. It's the part of the equation that still resembles human effort: a reviewer reads the output, checks it against the requirement, and either approves or sends it back, at a pace that hasn't changed just because an agent produced the draft.

Do scope and dependency estimates still apply when an agent does the work?

Yes, unchanged. What the work requires and what it depends on don't move just because who executes it changed. Only the 'how long will this take' line item needs a new method.

Estimating AI Agent Work: Why Velocity Breaks

Q: How long does agent work actually take?

The draft itself can take minutes regardless of scope. The real duration is scope plus dependencies plus however long a qualified reviewer needs to check it, and that last number is the one worth estimating carefully.

The direct answer: estimating AI agent work breaks the part of your estimate that assumed a human pace, not the whole estimate. Scope sizing and dependency mapping still hold, because they describe what the work requires, not who does it. What stops working is duration and effort-per-item, because those numbers were always a proxy for how long a person needed, and an agent doesn't run on that clock. The fix isn't a new estimation framework; it's swapping one input. Estimate how long a qualified reviewer needs to check the output, not how long the agent needs to produce it, because review time is the part of the equation that still behaves like the old one.

TL;DR: Keep scope and dependencies, replace duration with review time

Scope and dependencies are unaffected. What the work requires doesn't change based on who executes it.
Duration and effort-per-item break. Both assumed a human working pace an agent doesn't have.
Review time is the new estimate. It's still bounded by a person's pace, so it's still estimable the old way.
Historical velocity doesn't transfer to agent-touched work; it was calibrated against a baseline that no longer applies.

Why Historical Velocity Breaks the Moment an Agent Joins

A velocity number is a average of how long a team, working at a human pace, has taken to close similar-sized work in the past. It's useful precisely because the pace it's built on is stable: the same people, roughly the same hours, roughly the same interruptions, sprint over sprint. Story points and velocity already measure relative effort, not hours, which is why the technique survives team changes that don't touch the underlying pace.

An agent changes the pace itself, not just the team roster. It doesn't take a coffee break, it doesn't context-switch the way a person juggling three projects does, and it doesn't need eight hours to produce what might have taken a person eight hours to produce. None of that makes the points wrong for human-only work. It makes them meaningless for agent-touched work, because the number was never measuring effort in the abstract; it was measuring effort at a specific pace that no longer applies to that item.

What Still Holds When Estimating AI Agent Work

Not everything about estimation changes, and conflating the parts that do with the parts that don't is how teams end up either over-correcting into no estimates at all or under-correcting into treating an agent like a slightly faster employee.

Scope stays exactly as hard to estimate as before. Figuring out what "done" means for a task, whether the acceptance criteria are actually clear, and how big the surface area is, none of that depends on who does the work. A vague requirement is just as vague handed to an agent as handed to a person.

Dependencies stay exactly as real. If task B needs task A's output, that's still true regardless of execution speed. An agent finishing task A faster changes when B can start; it doesn't change whether the dependency exists.

Review effort is a legitimate estimation target, and it's the one piece of the old model that still describes a human doing human-paced work: reading output, checking it against the requirement, deciding whether it's right. Capacity planning for a team that includes agents covers the same shift from the planning side: review capacity, not agent throughput, is the number that actually determines what a team delivers.

Estimate Review Time, Not Build Time

The practical swap is a one-line change to how you size agent-touched work, but it requires giving up a number that feels more precise than it is.

Stop asking "how long will the agent take." For most tasks the honest answer is minutes, and treating that number as a planning input just adds false precision to the schedule.
Ask "how long will checking this take a qualified reviewer." Group agent-touched work by review complexity, not by task type. A one-paragraph status draft and a budget reallocation both might be "agent work," but they need wildly different review time.
Size the review the way you'd size any task, with the same estimation technique your team already trusts: relative sizing, a three-point estimate, whatever the team is calibrated on. The technique doesn't need to change, only what it's applied to.
Keep the dependency chain visible. An agent producing a draft in ten minutes doesn't collapse a five-step dependency chain into ten minutes; each downstream step still waits on review of the step before it.
Recalibrate as trust builds. When it's appropriate to let an agent close its own work without a full review shrinks the review-time estimate for that specific task type, which is the only way the estimate legitimately gets smaller over time.

The diagram below shows the same swap: the old estimate added scope, effort-per-item, and duration; the new one keeps scope and dependencies and replaces the other two inputs with a single review-time estimate.

How Long Does Agent Work Actually Take?

This is the question teams actually ask, and the honest answer disappoints anyone hoping for a formula that outputs a single duration. The draft itself is close to instantaneous for most tasks; that part of the old question stops being interesting once an agent is involved. What actually determines when the work is done is the same three-part chain it always was: how long until the task can start (dependencies), how complete the draft is against the requirement (scope, and whether it was clear), and how long a reviewer needs to check it (the new estimate). Teams that keep asking "how long will the agent take" end up with schedules that look fast on paper and slip in practice, because the number they tracked was never the bottleneck.

What This Means for Planning With AI Agents

None of this requires new estimation software or a new point scale. It requires separating two questions that used to collapse into one: what does this work need, and how long will a human need to check it. Planning estimates with AI agents on the team still runs through the same PMO discipline that made estimation useful in the first place, sizing based on what's actually knowable, and being honest that speculative build-time numbers were never the part worth defending in a planning meeting. The part worth defending was always the review.

More on how AI agents change the rest of the planning picture, capacity, status reporting, permissions, is on the Onplana blog.