An AI agent can stay busy all day without making a team more productive. The useful question is what happens to the work after the agent says it is finished.
That is the distinction I would keep in front of me when reading OpenAI’s September 6 research-acceleration report. The company says that, as of mid-August 2026, its research organization used 3.1 agent-workdays of effort for every workday of human labor, expressed in standard eight-hour workdays.
That is a meaningful change in how work is organized. It is not a finding that every researcher became 3.1 times more productive.
What an agent-workday measures
An AI agent is software that uses a model to carry out tasks through tools, rather than only answering a question. Several agents can run at once. Adding their runtime describes the amount of automated activity, not an equivalent amount of human judgment or useful output.
OpenAI reports more code contributions and experiments alongside increased agent adoption. It also explicitly cautions that overall research progress probably will not keep pace with those individual metrics. Available computing capacity grew too, so the changes do not isolate the effect of agents.
Simon Willison’s independent commentary highlights the sharp growth in internal coding-agent use. His post is useful context, not an independent audit of OpenAI’s underlying data. The numerical findings here remain OpenAI’s own measurements.
Measure activity and outcomes separately
I would keep runtime on the dashboard, but not at the top of the success report. This is the scorecard I would use for a pilot:
| Measure | What to record | What it tells you |
|---|---|---|
| Activity | Runs, runtime, and tasks attempted | How much capacity the workflow consumes |
| Accepted outcomes | Completed tasks that meet a written acceptance standard | Whether the activity produces usable work |
| Review and rework | Human minutes spent checking, correcting, and rescuing tasks | Whether effort was reduced or merely moved |
| Cycle time | Elapsed time from request to accepted result | Whether work finishes sooner, including queue delays |
| Failures and incidents | Rejected outputs, escaped errors, and unauthorized actions | Whether speed comes with unacceptable consequences |
| Resources per accepted task | Human minutes and service usage tracked separately, including failed attempts | Whether useful work requires fewer resources; do not add unlike units |
Define “accepted” before running the pilot. For a document, that might mean every required section is present and factual claims are checked. For a code change, it might mean the relevant checks pass and a reviewer approves it. Those are proposed evaluation rules, not results from my own trial.
Count the work that did not succeed
A success rate needs a denominator. Record every attempted task, including abandoned runs, unresolved outcomes, and retries. Otherwise, removing the difficult cases can make a weak workflow look strong.
OpenAI notes that some task-success charts exclude sessions whose outcome could not be determined. That qualification matters when interpreting the chart. The report also says more than half of successful tasks estimated to take a human four to eight hours involved at least one intervention during the period it analyzed.
The report uses an AI-based classifier to assess task success and estimated human task duration; these are preliminary internal measurements, not a controlled comparison with a human doing each task.
Human steering is not automatically a failure. It is part of the operating cost and should be visible. An agent that finishes good work with a short review can still be useful; a nominally autonomous run that needs extensive cleanup is a different proposition.
A small pilot that answers a real question
- Choose one repeatable workflow and define the acceptance standard.
- Record a baseline using comparable tasks, including review time and errors.
- Run the agent-assisted version with the same definition of done.
- Separate results by task difficulty so easy tasks do not hide difficult failures.
- Expand only when accepted outcomes improve without unacceptable rework or incidents.
This connects to the implementation question in my AI agent hub guide: where the agent runs matters, but so does the evidence that its work is worth keeping.
FAQ
Does 3.1 agent-workdays mean 3.1 times the productivity?
No. It is OpenAI’s aggregate runtime comparison for its research organization, not a measured productivity multiplier or a promise for other teams.
What should I measure first?
Accepted tasks and the human effort required to get them accepted. Add cycle time and incident tracking so speed does not hide quality problems.
Is more human intervention always bad?
No. Necessary review can be valuable. Measure its effort and effect rather than assuming that zero intervention is the goal.
Bottom line: A busy agent is a capacity signal. Accepted work, with visible review effort and manageable errors, is the outcome that matters.
Sources checked September 8, 2026. The scorecard and pilot steps are an editorial framework, not an OpenAI benchmark.