The Agentic Day.
A “horsepower” for AI.

How much work did the AI actually do?

Tokens, API requests and agent runs describe machine activity. They do not directly tell a delivery lead how much work was produced, help a client interpret an estimate, or show a team what additional capacity it has gained.

I created the Agentic Day (AD) to bridge that gap. It translates agent output into the productive effort a skilled person would need to deliver equivalent work. The analogy is horsepower: a familiar reference point for understanding a new capability.

This is my proposed measurement framework, not an established industry standard or a vendor billing unit. It is intended for practical planning, reporting and discussion, with calibration made explicit.

One unit. A fixed human anchor.

The unit measures output equivalence, irrespective of the model used or the calendar time taken. Its reference is focused productive effort, rather than a person’s full working day or the time an agent remains switched on.

• Raw output. AD measures work before human acceptance. Quality is recorded separately through Effective Agentic Days.
• Model-agnostic. Different models use the same output benchmark. Their cost and speed can differ.
• Fixed. Better models can deliver more ADs in the same time; the meaning of one AD does not expand with model capability.
• Agent output only. Human prompting, orchestration, review and integration effort are tracked alongside it, not hidden inside it.

Why six hours rather than eight?

The v1.0 paper chooses six hours as a practical reference for a productive human day. It distinguishes focused work from the meetings, administration, breaks and context-switching within an eight-hour schedule.

This is a framework assumption to validate in your domain, not a claim that every person produces the same amount each day. Measure representative work with skilled practitioners. If the local calibration differs, document the conversion method while keeping the base unit fixed.

Measure the work, not the runtime.

First establish the human-productive effort associated with a comparable piece of work. Then assess the agent’s output against that baseline in scope, complexity, completeness and utility.

AD = human-equivalent productive hours of output ÷ 6

If an agent produces work equivalent to a task benchmarked at 12 productive human hours, that represents 2 AD. If it takes the agent one hour or four hours, the output still represents 2 AD; the elapsed-time efficiency changes instead.

Next, review the result and record the proportion accepted without significant rework. Define the acceptance method consistently, so that raw output and useful delivery remain distinguishable. Recalibrate when the task mix, models or tooling materially change.

From a unit to a measurement system.

The base unit becomes more useful when quantity, acceptance, cost and elapsed time are reported together. Use the same reporting boundary and calibration method throughout.

Use acceptance rates as fractions: 85% becomes 0.85. Cost and ratio measures need a non-zero denominator. CPAD excludes human orchestration costs, so it is not a complete return-on-investment calculation; report those costs separately.

A worked delivery example.

These figures are illustrative, not measured project results. Suppose a reporting week produces 40 AD, with 85% acceptance, £600 of compute and tooling cost, and 10 human-days of human contribution on the same productive-day basis.

Accepted output

34 EAD40 × 0.85

Technology cost per raw AD

£15£600 ÷ 40

Weekly output

40 AD/week40 AD ÷ 1 week

Raw augmentation ratio

5×(40 + 10) ÷ 10

The difference between 40 AD and 34 EAD makes acceptance visible. The 5× ratio describes combined raw output in this example; it is not a claim of fivefold cost savings or an equivalent reduction in headcount.

Keep orchestration explicit in the delivery estimate: for example, 40 AD of agent output plus 5 human-days of orchestration and review. These are different kinds of effort and should remain distinguishable.

What changes when agents work in parallel?

Independent output contributions can be added. Three agents that each deliver 4 AD produce 12 AD in total, even if their runs overlap. Avoid counting the same deliverable more than once when agents collaborate.

The paper’s 24-hour illustrations assume an operating rate equivalent to one human-productive hour of output per agent-clock-hour. Under that assumption, one agent produces 4 AD over 24 hours and three agents produce 12 AD.

Single agent: 4 AD ÷ 24 hours ≈ 0.167 AD/hour

Three-agent system: 12 AD ÷ 24 hours = 0.5 AD/hour

The second calculation uses the shared elapsed window, not the sum of all agent-hours. Actual throughput must come from calibrated output: continuous runtime alone does not guarantee those figures.

The v1.0 reference specification.

The paper describes a baseline operating environment. These settings help document a calibration; they do not define the Agentic Day.

Maximum turns per run

300; tasks can finish earlier.

Timeout per run

2,700 seconds, or 45 minutes.

Concurrency

One active run per agent at a time.

Runs per AD

Variable; multiple sequential runs may contribute.

Reference models

Frontier-class models from 2025–26; the unit itself remains model-agnostic.

A run ending after 45 minutes does not automatically earn a fixed fraction of an AD. Its contribution depends on the equivalent productive work delivered.

How to put it into practice.

1. Establish a human baseline. Choose representative tasks and record the productive time skilled practitioners need. Cover the task types you actually intend to automate.
2. Calibrate agent output. Run equivalent tasks and compare the scope, completeness and usefulness of the output. Record the operating parameters and any domain-specific conversion factor.
3. Instrument delivery. Track ADs, acceptance rate, compute and tooling costs, and human orchestration effort. Record the reporting period and elapsed operating window for time-based measures.
4. Review and refine. Revisit calibration at least annually, or after significant changes in models, tooling or domain scope. Update the operational assumptions without quietly changing the six-hour anchor.

For comparisons between teams or organisations, disclose the task mix, baseline, operating parameters and acceptance methodology. A shared unit name is not enough if the underlying measurements differ.

Useful, with explicit boundaries.

Version 1.0 is an early planning framework based on empirical observation and collaborative research, not a precision instrument backed by controlled calibration studies and confidence intervals.

• Task types differ. V1 uses a common unit across code, tests, documentation and analysis. It does not yet supply validated task-specific weightings.
• Raw output is not accepted delivery. Report EAD alongside AD to avoid overstating practical value.
• Human effort still matters. Prompting, review, rework and integration require separate visibility.
• Comparability depends on method. Different baselines or acceptance rules can make apparently similar figures misleading.
• Capability changes. Historical costs and throughput are not guarantees of future performance.

The paper identifies future work in controlled calibration studies, task-type weighting, acceptance benchmarks, cross-organisational reporting protocols and applications beyond software engineering.