The automated research intern: what changed inside the lab

How agent work was measured

OpenAI defines an “automated research intern” as a supervised system that completes well-defined tasks that would take a skilled researcher several days. Its analysis covers internal agent use and divides research into stages including problem selection, experimental design, code construction, execution, analysis and communication. By mid-August, the company recorded 3.1 aggregate agent-days for each human working day. These are vendor-reported observations from OpenAI’s own laboratory, not an independent measurement of research work across the wider industry.

An “agent-day” measures aggregated execution time, not one day of equivalent expert human contribution. Multiple agents may run simultaneously, repeat experiments or pursue branches that are later discarded. The metric demonstrates increasing delegation but does not by itself measure scientific value, correctness or time saved for researchers. A productivity assessment also needs successful-task rates, human interventions, duplicated work, total cost and evidence that the additional experiments changed a research decision or produced a result worth retaining.

What the data says about autonomy

OpenAI reports that experiments per active experimenter reached their highest level since tracking began in January 2025, alongside increasing Codex use. At the same time, more than half of successful tasks estimated at four to eight hours required at least one human intervention. Agents contributed very little high-level planning. The evidence therefore supports longer and broader delegation of execution more strongly than it supports the idea that agents independently manage a complete research programme.

The evidence is limited by its setting: one laboratory using its own models, infrastructure and working practices. Available compute increased during the same period, so the rise in experiments cannot be attributed solely to agents. The report also does not provide a complete counterfactual comparison with an otherwise identical team working without them. The findings are useful operational evidence, but they should remain labelled as preliminary internal measurements reported by OpenAI rather than a general productivity law.

Compute cost and hidden human work

OpenAI reports median daily inference spending of roughly $600 and a ninetieth percentile around $7,000. That wide spread indicates that cost depends heavily on the experiment, parallelism, context length and number of retries. It is not a universal price for an automated researcher. The figures describe use at scale inside OpenAI; a smaller organization may face a very different balance of model charges, infrastructure, quality assurance and integration work.

A full accounting must include labour that token totals do not reveal: preparing environments, specifying tasks, judging outputs, repairing failed directions and maintaining tools. Agents may increase experiment throughput while moving the bottleneck to human review. The report does not establish that the cost of one valuable discovery fell or that every laboratory would obtain a positive return. It shows instead that research economics increasingly includes deliberate management of a portfolio of parallel machine-run attempts.

Mateusz’s proposed delegation model

Mateusz’s framework separates responsibility into four gates. A person defines the question and success criteria, an agent runs a constrained experiment, an independent mechanism checks the artifacts, and a researcher decides how to interpret the result and what happens next. For expensive or irreversible actions, the system should stop before using new data, allocating resources or publishing. This is Mateusz’s organizational proposal derived from the reported limitations; OpenAI does not present it as its formal operating standard.

The next useful evidence should compare teams on similar tasks, measure the share of results surviving independent replication and report the cost of one retained outcome. Intervention counts, review time and the agent contribution to high-level planning also matter. Genuine research autonomy will require more than running for longer without contacting a person. It will require reliable selection of subsequent steps, calibrated recognition of uncertainty and an auditable record showing why each consequential action was taken.

“Intern” is an operational milestone, not a job description

OpenAI uses “automated research intern” in a deliberately narrow operational sense: under human direction, the system completes well-defined tasks that would take a skilled researcher several days. The definition does not say that an agent possesses the full range of abilities expected from a junior scientist, understands a laboratory’s culture or bears professional responsibility. Nor does it include independently selecting a worthwhile research problem. The label is informative only when its boundary remains attached: longer technical execution under supervision, with an explicit starting point and a testable finish condition.

The company presents this level as a step towards a more autonomous AI researcher, with March 2028 stated as an organizational target. That is a goal, not a forecast or a promise that a safe system will be delivered on schedule. OpenAI acknowledges that it does not yet know how to reach fully aligned recursive self-improvement safely, and that people continue to set priorities, judge ideas and results, and decide whether to scale, pause or deploy systems. The important information is therefore not the employment metaphor but the responsibility boundary that remains in place.

The telemetry covers a broader organization than scientists alone

The report uses a broad “researcher” category. It includes not only people designing model experiments but also infrastructure staff and project managers. Most, but not all, agent use in the organization appears in the telemetry. An organization-wide average therefore does not describe a uniform day for a representative scientist. It combines roles, task classes and levels of experience, and an infrastructure specialist with unusually heavy usage can shape the distribution differently from a researcher formulating a hypothesis.

Daily concurrency peaks also require care because they include agents launched directly by a user and subagents created during a run. They measure simultaneous computation, not the number of independent research problems solved that day. Two sessions may investigate the same defect, repeat an approach or wait for a resource. Before transferring the result to another institution, an analyst needs the user population, log coverage and the rule for counting descendant processes. Without those definitions, a scaling effect can be mistaken for an accounting effect.

Support channels are an indirect signal, not a quality measure

The authors report declining attendance at tool-support office hours and fewer new top-level posts in the support channel. That is an interesting trace of changing practice: problems may have become rarer, recurring answers may have moved into documentation, or users may have learned to resolve common failures themselves. The report does not establish which explanation dominated, nor whether questions moved into private conversations or another channel. A falling visible count is compatible with several distinct mechanisms.

Fewer requests for help do not automatically mean that outputs are more correct. A user may fail to notice an error or abandon a run without posting. Conversely, one difficult case can attract many replies while the top-level-post metric records only one issue. Support activity should be paired with time to resolution, recurrence, abandoned-session rates and independent artifact checks. On its own, the decline describes community behaviour, not scientific quality or causal productivity. It is supporting context rather than a substitute for outcome validation.

The success classifier works only where a reference outcome exists

The success analysis does not cover an arbitrary research conversation. The authors searched for tasks where a ground-truth outcome could be identified and then excluded cases classified as uncertain. Data points associated with a user or time bucket containing fewer than fifty sessions were also omitted from the reported aggregates. Those filters protect against unstable inference from very small samples, but they also define the population to which the chart can speak. Work without a recoverable reference answer remains outside that particular estimate.

A task described as taking four to eight hours means an estimate of how long a human would need, not the agent’s measured runtime. This distinction matters: difficulty estimates can be wrong, and work that admits automatic outcome classification does not represent every scientific activity. Reading the curve responsibly requires asking who estimated human time, how the reference outcome was recovered and how many ambiguous cases were removed. Without that provenance, the graph appears more universal than its sampling procedure permits.

Output-token share is not responsibility share

The report assigns activity to six phases — Decide, Design, Build, Run, Analyze and Communicate — using output tokens. This is useful for locating where the system emits text or code, but it does not directly measure the leverage of a decision. One short instruction in Decide can set the question, cost ceiling and success criterion for thousands of later tokens. A minimal planning share therefore does not imply minimal human influence on the research programme or transfer of responsibility to the model.

Growth in Build or Run needs the same caution. A long diagnostic log and a concise, correct experiment consume tokens differently even if the latter has greater value. The metric does not automatically capture human time spent preparing data, waiting for compute, consulting colleagues or rejecting an output away from the interface. Token share describes the shape of interaction with the tool. Authorship, accountability and value each require a separate decision record and downstream validation; none can be inferred by adding generated words.

Safety constraints are part of research speed

OpenAI describes temporarily shutting down a container service used for training after a research-infrastructure compromise, then hardening the environment and pausing some work on its newest models. Later restrictions on Astra-class systems reduced their GPU allocation, while some compute shifted to other model classes. This part of the report demonstrates that throughput is not independent of safety controls. A system that can solve more difficult problems may also increase the consequences of a misconfigured environment, excessive permission or unsafe goal. Capability and containment must therefore be measured in the same operational account.

An experiment-count dashboard should sit beside incident data, forced pauses, monitoring coverage and time spent hardening the environment. Redirecting compute to other model classes may preserve aggregate activity, but it does not by itself establish that risk fell. Responsible agent work needs separation of data and credentials, least privilege, cost limits, action logs and a dependable stop mechanism. These safeguards are not an external overhead to subtract from productivity; they are part of the cost of producing a result that an organization can safely keep and use.

A changing system needs stable measurement definitions

Models, tools, available compute and user experience all changed between January and August. Task selection changed too: as capability grew, people could move longer or more complex work into the agent queue. A raw comparison between two months therefore combines model progress, organizational learning and a different basket of tasks. A rise or fall in success rate may partly reflect a denominator whose questions no longer mean the same thing, even when the chart’s labels remain unchanged.

Tracking the milestone needs a versioned measurement card: model and tool identifiers, a stable control set, budget, intervention definition, method for estimating human time and rule for assigning success. A live stream of production tasks can sit beside it, but the two series should not be merged. The fixed set measures capability change; the production stream measures practice change. Reading them together helps separate a better agent from an easier benchmark, a more experienced user or a revised counting rule.

A research task portfolio should maximise the value of information

An automated researcher may produce hypotheses quickly, but throughput does not determine which task deserves to run. A portfolio should combine work with different purposes: replications that test reliability, experiments that distinguish competing explanations, searches with high uncertainty and infrastructure tasks that improve the quality of later studies. Selecting only easy benchmarks optimises a visible activity measure. Selecting only speculative ideas can consume the budget without creating a foundation for the next decision. The programme needs an explicit balance between exploiting methods that already work and exploring areas where new knowledge could change its direction.

The value of information depends on the decision a result could unlock. Before resources are assigned, the team describes possible outcomes, how each would affect subsequent steps, the cost of waiting and whether similar knowledge could be obtained more cheaply or safely. An experiment with a modest chance of a positive result can still be valuable when a negative result would eliminate an expensive path. A striking demonstration has little value when no plausible outcome would alter the plan. Assessment should remain qualitative where defensible numbers are unavailable; a precise score must not conceal assumptions that cannot honestly be compared.

The portfolio also needs decision gates. After a pilot, a task may be expanded, redesigned, paused or stopped, while the record preserves the original hypothesis, evidence obtained and reason for the choice. Work-in-progress limits protect the team’s capacity to interpret results, because unread outputs do not become knowledge. A regular review should also examine correlated failure: several projects built on the same model, dataset or assumption do not provide diversification. Managed this way, the portfolio measures progress through consequential uncertainties resolved in a form that improves decisions, rather than through the number of reports generated.