Long-running AI agents change the unit of knowledge work from a conversation to a delegated outcome. That changes planning, review, management, and the metrics that matter.
Chat-based AI fits comfortably into the shape of an ordinary workday. A person asks a question, receives an answer, and continues. The machine is fast and the human remains the centre of the interaction.
Long-running agents break that rhythm.
A person can now delegate a task that takes the agent twenty minutes, two hours, or most of a day. They can start several tasks at once, leave them running, return to partial results, redirect one, approve another, and reject a third. The work is no longer organised as a conversation. It is organised as a queue.
That sounds like a small interface change. It is an operating-model change.
In June 2026, OpenAI published internal and customer usage research describing a shift toward longer agent tasks. In its sample, more than 70% of individual Codex users had asked the system to perform at least one task estimated to exceed an hour of human work, and the heaviest internal users were running many agent-hours in parallel. The figures come from one provider’s environment and should not be projected onto every workplace. The directional signal is still useful: concurrency is becoming a normal part of AI-assisted knowledge work.
The management problem is no longer “How do we help employees write better prompts?” It is “How do we design, assign, review, and learn from delegated work?”
A prompt is an instruction. An agent task is a small contract.
It needs an outcome, relevant context, boundaries, tools, an evidence standard, and a stopping condition. “Research this market” is not a sufficient contract. Neither is “fix the repository.” Both invite the agent to choose a scope the organisation has not chosen for itself.
A well-formed task looks more like this:
That contract improves the agent’s work, but its larger value is organisational. It forces the person delegating to decide what good means before output starts arriving.
When ten tasks can run at once, execution stops being scarce. Judgment becomes scarce.
Teams experience this first as a pleasant surprise: work comes back faster. Then the queue fills with pull requests, reports, analyses, and proposed actions waiting for someone qualified to inspect them. If review capacity does not change, agent speed simply moves waiting time downstream.
The result can be worse than the old process. People skim because the volume is high. Weak work receives superficial approval. Several agents solve overlapping tasks because no one can see what is already in flight. The organisation produces more artifacts while making the same number of sound decisions.
Capacity planning therefore needs two numbers:
The second number is usually smaller.
Teams should set limits on work in progress, define review service levels, and reserve expert attention for tasks where errors are expensive. Parallelism is valuable only when review, integration, and decision-making can keep pace.
One of the most useful studies published this summer came from Anthropic. Its analysis of roughly 400,000 Claude Code sessions found that people tended to make most of the planning decisions—what to do—while the agent made most of the execution decisions—how to do it. People with stronger domain expertise generally achieved better outcomes and could recover more effectively when the system misunderstood the task.
The implication is not that everyone must become a software engineer. The study found that users across occupations could complete coding tasks at similar average rates when success was verifiable. The advantage came from understanding the problem well enough to direct and judge the work.
This changes the shape of expertise. A finance leader may no longer need to write the analysis code personally, but still needs to recognise an invalid assumption, an inappropriate time window, or a reconciliation that has silently excluded a class of transactions. An engineer may type less code while spending more time defining interfaces, invariants, tests, and rollout constraints.
Agents can compress execution. They do not remove the need to know what should be executed.
In a queue-based environment, good management means designing the flow of work.
Every delegated task should state the outcome, owner, risk level, evidence requirement, allowed tools, and definition of done. Templates help, but the standard matters more than the form.
The agent can declare that it has finished. Only the organisation can accept the result. Acceptance should depend on tests, evidence, review, or observed performance—not the fluency of the final message.
Not every artifact needs the same ceremony. A draft internal summary may receive automated checks and a quick human read. A production migration, public filing, or customer decision requires a named expert and explicit approval.
Keep the task brief, relevant context, agent version, tool activity, result, review notes, and final disposition. This enables incident analysis, but it also allows the team to learn which task designs produce reliable outcomes.
Rejected work is valuable data. Record why it failed: missing context, poor task framing, weak model capability, tool error, insufficient evidence, or reviewer disagreement. Then change the system that caused the failure.
Without that loop, teams repeat the same correction manually forever.
Agent dashboards naturally surface tokens, runs, tool calls, and runtime. These are useful operating metrics. They are not business outcomes.
A better scorecard includes:
These measures resist a common mistake: celebrating more output even when review and rework have consumed the gain.
For coding work, lines of code were already a weak productivity measure. With agents, they become nearly meaningless. A thousand generated lines may represent useful delivery, unnecessary abstraction, or future maintenance cost. The accepted change and its effect in production matter.
Delegation also creates a capability risk. If junior employees always hand implementation to an agent, they may produce more today while failing to develop the judgment needed to supervise difficult work tomorrow.
The answer is not to ban the tool or require people to perform every task manually. It is to design learning into the workflow:
An organisation needs both production throughput and a pipeline of people capable of exercising independent judgment. Optimising only the first eventually weakens the second.
The best pilot is not “give every employee an agent.” Choose one workflow with observable inputs and outputs: research briefs, support escalations, test generation, data reconciliation, or release documentation.
Define the task contract. Instrument the queue. Set a review policy. Measure accepted work for four weeks. Hold a weekly review of failures and bottlenecks. Then decide whether to expand.
The shift from chat to agents will be described as a leap in model capability. Inside organisations, its success will depend on something less glamorous: whether people can turn abundant execution into a controlled flow of good decisions.
The agent is fast. The system around it determines whether the work is useful.
Co‑Transform helps organisations connect AI learning to real workflows, operating controls, and measurable behaviour change. Explore the programme.