This is a research-led field note from the work behind part four of Agentic Operating System For Your Business. It is not part five. It is the question that part four left sitting on my desk.

How long will this take?

It is a completely fair question.

I ask it myself. I have been building the Chief Agentic Officer briefing and the operating system around it, watching agentic workers move through tasks, files, tools, tests, decisions, and unexpected problems. I want to know how far they have got. I want to know what remains. I want to know when the work will be useful.

Then I had a rather uncomfortable flashback.

There I was, nearly forty years ago, being asked the same question while trying to understand a system I had not worked on before.

How long will it take, Tony?

Well, I am reading the manual.

My first large business computer was an IBM AS/400. Strictly speaking, it was a midrange system rather than a mainframe. IBM launched it in 1988, and the documentation felt as if it arrived in its own geological layer. You learned by reading, trying, failing, finding the right book, and trying again.

I could estimate familiar work. I could not honestly give the same confidence for work where part of the job was discovering what the job really was.

Now my agents are facing the same problem.

We keep asking one question about four different kinds of work

When somebody asks how long a house will take, there is uncertainty, but the shape of the work is familiar. Foundations, walls, services, roof, inspection. We have reference projects. We have trades. We have sequences and known failure modes.

Agentic work is often described as if it were all one thing. It is not.

Work type What we know What an honest estimate looks like Sensible commercial shape
Routine The task, path, tools, and quality standard are well understood. Historical cycle time and a service level expectation. Fixed price, unit price, or service fee.
Configured The pattern is known, but it must be adapted to a particular business or system. A range with named assumptions, dependencies, and checkpoints. Fixed sprint, capped time and materials, or phased delivery.
Discovery We know the problem area, but not yet the right solution or route. A timebox for learning and a decision, not a promise that the whole product will be finished. Fixed discovery with explicit learning outcomes.
Research We do not yet know whether the proposed capability is feasible, valuable, or safe. A budget envelope, hypotheses, evidence gates, and go, change, or stop decisions. Funded stages with review gates rather than one fixed completion price.

This classification matters because a discovery cannot honestly be priced as if it were a repeated production task.

The UK Government Service Manual makes this distinction rather nicely. A discovery phase is not simply the first chunk of delivery. Its purpose is to understand the problem and decide whether to proceed to an alpha. Discoveries do not have one compulsory length, and stopping can be a valid result.

That is a much healthier way to think about novel agentic work.

You cannot step into the same technology river twice

The line usually attributed to Heraclitus says that you cannot step into the same river twice.

The history is a little more nuanced. The familiar wording reaches us through later writers, and scholars debate how the surviving river fragments should be interpreted. But the image remains useful.

You cannot step into the same technology river twice.

The operating system has changed. A browser has been updated. A security patch has tightened a permission. The model has changed. The harness has added a capability. An API has altered a limit. The data is different. The people understand the problem differently because of what the previous attempt taught them.

Experience still matters enormously. It gives you patterns, warning signs, reference classes, and better questions. It does not make the river stand still.

The estimate is often less certain than it sounds

Projects have always had a problem with optimism.

HM Treasury's Green Book asks appraisers to make explicit adjustments for optimism bias, ideally using historical forecast errors from comparable work. The GAO cost-estimating guidance similarly stresses scope, assumptions, historical data, sensitivity, risk, and continuing updates as actual evidence arrives.

Large IT projects have another awkward feature: their overruns are not always nicely distributed around an average. Research led by Bent Flyvbjerg and Alexander Budzier on thousands of IT projects found a heavy-tailed pattern in which a minority of projects account for extremely large overruns. Averages can therefore create false comfort.

I have lived the smaller version of that.

One piece of work looked like roughly three weeks. It took about three months.

That does not prove that AI makes every project expand by the same amount. It proves that my first estimate did not include enough of the discovery, integration, assurance, and changing scope that the work uncovered.

AI can make this stranger. When a new possibility becomes cheap to try, the sensible response is often, “While we are here, could we also do this?” The work gets better and more ambitious, but the scope quietly grows.

That is not necessarily failure. It is only failure if we pretend the original promise has not changed.

What do we mean by done?

Before estimating the work, we need to agree which finish line we are discussing.

Five levels of done for agentic work: learning, artifact, operational, governance, and outcome.
Agentic work can be done at five different levels. An estimate is meaningless until the finish line is named.
  1. Learning done. We have answered the important uncertainty and know whether to continue, change direction, or stop.
  2. Artifact done. The document, code, model, workflow, or prototype exists and meets its stated quality checks.
  3. Operational done. It works in the real environment, with monitoring, backup, recovery, ownership, and support.
  4. Governance done. The authority, privacy, security, audit, approval, and accountability requirements have been satisfied.
  5. Outcome done. The business or human result has actually changed, not merely the system.

These finish lines can be separated by weeks or months.

A prototype can be impressive on Tuesday and still be nowhere near safe enough to run a company process on Wednesday.

The Scrum Guide's Definition of Done is useful because it creates a shared understanding of the quality state of an increment. But agentic work often needs a broader operating definition. A technically complete increment may still lack the evidence, authority, resilience, or business result that makes it genuinely complete.

The better first question

I do not think we should stop asking when the work will be finished.

I think we should ask a better question first:

When will the first meaningful outcome arrive?

That outcome might be a tested hypothesis, a working slice, a risk retired, a customer journey demonstrated, a reliable data path, or evidence that the proposed route should be stopped.

“Meaningful” matters. A pile of generated code is activity. A verified slice that changes a decision is progress.

The Open Guide to Kanban offers a practical model for repeatable work: a service level expectation combines elapsed time with a probability, based on historical cycle time. For example, “we expect 85 percent of these items to complete within eight days” is more useful than pretending every item takes exactly five.

For new work, I would use a similar spirit but different evidence:

  • What is our next useful evidence?
  • What is the likely range?
  • How confident are we?
  • Which assumptions could break the range?
  • When will we reforecast?

The pause is part of the work

There is another cost I had not given enough weight to: the pause.

Agentic systems can move quickly. They can inspect, generate, test, correct, and continue. OpenAI describes agents as running in loops until an exit condition is reached. Anthropic describes evaluator-optimizer patterns where one model produces a response and another evaluates it in a loop.

Those are useful mechanisms. They are not automatically independent peer review.

A self-check is the same system looking again. A separate agent can offer a different critique. But if both agents share the same model, context, assumptions, or incentives, they may share the same blind spot.

Human peer review adds something different: lived context, accountability, scepticism, professional judgement, and the ability to ask whether the whole direction is wrong. Independent assurance adds further distance when the consequence demands it.

Review level What it can add What it cannot honestly claim
Agent self-check Fast consistency, missing steps, test failures, formatting, and obvious contradictions. Independent challenge.
Separate agent critique A second pass, alternative reasoning, adversarial questions, and repeatable evaluation. Human independence when the underlying model and context are shared.
Human peer review Domain judgement, organisational context, consequence, dissent, and accountable challenge. Perfect knowledge or complete freedom from bias.
Independent assurance Deliberate separation for high-risk security, legal, financial, safety, or regulatory decisions. A replacement for management ownership.

NIST's AI Risk Management Framework explicitly values independent review as one way to reduce internal bias. Anthropic's guidance on agent evaluations recommends combining deterministic checks, model-based graders, and human judgement because multi-turn agents are harder to evaluate than single answers.

This review time belongs in the plan and the price.

It is not friction to be eliminated. It is part of producing trustworthy work.

You can be the fastest runner in a hundred-metre race, but if you are running in the wrong direction, speed will not help you win.

Stop, Look, Challenge, Continue

I want a simple human ritual inside long agentic loops.

  1. Stop. What is the agent doing, and has it reached the promised checkpoint?
  2. Look. What changed? What evidence exists? What did we learn about the estimate?
  3. Challenge. Are we solving the right problem? Which assumption is weakest? What would a sceptical peer say? What evidence would make us change direction?
  4. Continue. Do we continue, modify, pause, or stop? Who owns the decision, and when is the next review?

That pause protects against something agentic systems are extremely good at: continuing.

A coastal route showing an agentic estimate moving from a goal through work and evidence to a deliberate pause, peer challenge, and a decision to continue, change, or stop.
A useful estimate includes the evidence point, the human pause, the challenge, and the decision route.

A practical method for estimating agentic work

This is the method I intend to use.

  1. Classify the work. Routine, configured, discovery, or research.
  2. Name the finish line. Learning, artifact, operational, governance, or outcome done.
  3. Find a reference class. Use comparable completed work where it exists. Do not rely only on the inside view of the current team.
  4. Give a range and a probability. Use a likely range and a prudent range, such as a central estimate and an 85-percent planning boundary.
  5. Write down assumptions and exclusions. The estimate should change when these change.
  6. Timebox discovery. Buy evidence before buying the whole imagined solution.
  7. Set the first meaningful outcome. Say when useful evidence or a working slice should arrive.
  8. Name the review ritual. Decide who challenges the work, what independence is needed, and what the review costs.
  9. Keep a scope ledger. Record new possibilities as explicit choices, not invisible additions.
  10. Reforecast from actuals. Update cost, time, risk, and direction at each checkpoint.

This is not an argument for vague delivery.

It is an argument for more precise honesty.

Price the uncertainty, not just the hours

The commercial model should follow the nature of the work.

Routine work can be priced by item or service level. Configured work can use fixed sprints or capped time and materials. Discovery can be a fixed timebox that purchases evidence and a decision. Research needs a budget envelope with go, change, and stop gates. Operational services need a service price that includes support, monitoring, recovery, usage, and change.

UK Government guidance on contracting for agile work warns that a single rigid fixed price can be unsuitable where uncertainty is high. Phased work and fixed-price sprints can preserve control without pretending that every later requirement is already known.

Whatever the model, include:

  • human peer review and decision time;
  • independent assurance where the risk warrants it;
  • agent critique and evaluation runs;
  • verification and likely rework;
  • security, privacy, legal, and regulatory review;
  • the cost of changing direction;
  • the cost of operating and maintaining what survives.

The code may become cheaper. Responsibility does not.

The Agentic Estimate Card

This is a starter card for the next piece of work. It is deliberately visible and copyable. It should be updated as evidence arrives.

AGENTIC ESTIMATE CARD

Work and outcome
- Work name:
- Goal:
- First meaningful outcome:
- Work type: Routine / Configured / Discovery / Research
- Definition of done: Learning / Artifact / Operational / Governance / Outcome

Estimate
- Reference class or comparable work:
- Likely range:
- Prudent planning range and probability:
- Assumptions:
- Exclusions:
- Known dependencies:
- Unknowns being tested:
- Budget envelope:

Review and direction
- Named reviewer:
- Review type: Self-check / Separate agent critique / Human peer review / Independent assurance
- Next direction checkpoint:
- Alternative considered:
- Current dissent or concern:
- Evidence that would change direction:
- Pause trigger:
- Human approval required:
- Review time and cost:

Control
- Allowed tools and actions:
- Stop-lines:
- Scope changes since last estimate:
- Decision at this checkpoint: Continue / Modify / Pause / Stop
- Owner:
- Next review date:

When will it be useful?

I will still ask my agents how long the work will take.

But I am going to ask more of the estimate.

What kind of work is this?

Which version of done are we promising?

When will the first meaningful outcome arrive?

What evidence supports the range?

Who will challenge the direction?

When will a human pause long enough to make sure we are still running towards the right finish line?

Sometimes the most useful answer will be a completion date.

Sometimes it will be: give us two weeks, and we will know whether this is worth building.

That is not a weaker answer.

For genuinely new work, it may be the most professional answer available.

Sources and notes

This is an operating field note supported by project-estimation, agile-delivery, AI-governance, and agent-evaluation research. The categories and the five meanings of done are my practical synthesis, not a claim that one framework has adopted those exact labels.