The unit of work moves from the ticket to the pipeline because a named workflow with one owner, one benchmark, one model choice, and one gate puts cost and quality somewhere a team can test a change to them.
TL;DR
Per-seat cost controls and prompt discipline do not compose across thousands of seats. Agents now open a growing share of coding sessions with no human in the turn, and in Uber's environment cost per session and per 1,000 model requests both fell while total spend merely held level. That is efficiency per unit of work, not a smaller bill.
Thousands of engineers each open a terminal agent, set their own model, and decide how much context to paste in and when to stop. The bill arrives as one line per seat. The engineering manager reading it cannot say which sessions produced a merged change, or what a passing result looked like, or why the same task cost far more on Tuesday than on Monday. Per-seat governance can raise or lower a budget cap; it cannot make quality measurable.
Choosing between interactive sessions and agent-run pipelines is an operating-model question for a CTO or VP of Engineering: whether the unit of work the organization funds and measures stays the ticket or becomes the pipeline. Inside a software factory, that funded unit is where cost and quality ownership sits. This guide covers the shape of each unit, which workflows move first, and what stays interactive. Spend mechanics and headcount are budgeting questions, model selection belongs to routing, and coordination belongs to multi-agent design.
The Interactive Session Is a Ticket-Shaped Unit of Work
An interactive session is one engineer holding one conversation with an agent, and every control attaches to the seat. The engineer supplies the context, chooses the model where the execution layer allows it, decides when the output is good enough, and closes the conversation. The ticket defines the scope and the session inherits it. Cost lands on the seat's subscription, quality on the engineer's judgment, and neither is visible outside the conversation until a pull request appears.
Uber optimized this unit before it moved past it, in an August 27, 2026, engineering account by Uday Kiran Medisetty. One wrapper around the interactive tools carries installation, configuration, authentication, and cost visibility, and the prompt cache moved from the default five-minute window to a one-hour one, because engineers leave sessions idle longer than five minutes. The cache change lowers the cost of a conversation and the wrapper makes that cost visible. Ownership of the conversation, and the measurement of quality, are untouched. An autonomous coding session launched from a terminal changes none of that. The unit is still the ticket, held by the caller, whether the caller types every turn or lets the agent run.
Why the Unit Is Moving Now
A growing share of sessions at Uber are opened by what its engineering account calls automated managed agents, with no human in the turn. Those agents review code, repair failing CI runs, and complete end-to-end pull requests with visual validation. They also triage on-call alerts, debug incoming bugs, and handle code maintenance tasks, with humans reviewing the work and taking escalations. Uber attributes more than 70% of pull requests to local or cloud agents, a figure that spans the agents engineers drive from a terminal as well as the ones that run with no caller.
Once a session has no caller, the choice between a seat-shaped unit and a pipeline-shaped one becomes an operating-model decision. No engineer holds the context, judges the output, or closes the conversation, so all three have to be defined elsewhere. That shift marks movement in the factory maturity model from seat-owned conversations toward team-owned workflows.
Uber benchmarks against thousands of its own real-world pull requests, and states that the cost reductions it measures are unique to its environment and may vary with codebase, team size, and agent workflows. The mechanism transfers; the magnitudes belong to one company's environment.
The Pipeline-Shaped Unit: Owner, Benchmark, Model, Gate, Trigger
An agent-run pipeline is a named workflow that no person opens, that runs when an event fires, and that belongs to a team rather than a seat. Its output passes through a gate before it counts for anything. An interactive session has none of these parts.
- Owner: The workflow's outcome metric belongs to a named team, and which team is a software factory org design decision.
- Benchmark: A fixed set of real tasks with known-good answers scores a prompt, execution layer, or model change before it ships.
- Model choice: Model routing fixes the model once for the workflow, at the point on the cost-accuracy curve the benchmark justifies.
- Gate: The check determines whether the team merges the output, escalates it, or discards it.
- Trigger: The event that starts a run belongs to the workflow definition. What fires it can change without touching the prompt or the model.
Uber sorts agent usage into four layers running from the most specialized to the most general, and concludes that moving workloads into managed environments grants complete control over model routing, execution harnesses, and operational spend. A terminal session leaves those controls with the caller, and the platform team holds none of them.
Cosmos, Augment Code's unified cloud agents platform available on all paid plans, makes two of those five parts into objects. An Expert is a reusable template carrying its own instructions, model, capabilities, and the events it reacts to, which fixes the model choice for every run that Expert handles. A Trigger turns an outside event into an Expert action: Cosmos opens a session and drops the raw event payload in as the first message. Triggers arrive from first-party integrations with GitHub, Linear, Slack, GitLab, and PagerDuty, from a five-field cron expression with a timezone, or from a webhook URL.
The other three have no object to configure. Ownership, the benchmark, and the gate stay an operating model question that no platform answers on a team's behalf.
Why the Pipeline Costs Less Per Unit of Work
A pipeline hands the settings that drive cost to the owner, where an interactive session leaves them with each caller. Model routing and execution limits such as the turn budget move with them, which is the point of running a fleet of specialized agents each scored against its own benchmark. The published numbers are averages, and none of them compares the two units on cost per completed task.
A benchmark scores each run against known-good results. The owning team ships a routing change only when the pass rate on real pull requests holds, and the same set catches a regression at the next model upgrade. Because the execution layer, the model, and the turn budget are fixed for every run, a cost change is something the owner ships and tests, not something that emerges from how two engineers happened to work the same ticket.
The turn budget is the lever with published numbers behind it, in two peer-reviewed papers from 2026, one at ICSE and one in Findings of the Association for Computational Linguistics. Frontier models held to a turn limit at the 75th percentile of their own baseline solved their tasks for 24% to 68% less, with little effect on how many they solved. Stopping an agent as soon as prior runs suggest it is finished cut total cost 19.3% to 55.1% across every agent and model pairing it tested, for at most 0.2 percentage points of resolution rate.
The two disagree on what a hard cap costs. The second paper puts a plain turn limit at 10.7 percentage points of resolution rate, where the first found little effect on its own sample. What neither disputes is who sets the number. In both, the budget is decided once, in advance, by whoever owns the workflow.
Holding one model constant, because agent behavior shifts with every upgrade and model family, Uber saw cost per session fall 52% from its June peak. Cost per 1,000 model requests fell almost 34% from its peak over the February to July 2026 window, with the cost-per-session series starting at the end of May.
Volume moved hard in the other direction over a slightly longer window. From February to mid-August 2026, Uber reports that weekly active users across its agent offerings grew 7x and weekly agent requests grew 9.4x, counting engineers and non-engineers alike and deduplicating users across tools. Uber says total AI spend has held relatively stable since April. The three figures sit on overlapping but different windows and Uber publishes no arithmetic reconciling them, so what the account supports is per-unit efficiency, not a cut in agent token spend. Building the cost equation out into a budget is a separate exercise.
Seven dimensions separate the two units.
| Dimension | Interactive session | Agent-run pipeline |
|---|---|---|
| Execution trigger | Engineer opens a conversation | Event, schedule, or webhook starts a run |
| State ownership | Engineer holds context in their head and terminal | Workflow records hold the conversation and the tool calls |
| Owner | The seat holder | A named team accountable for the outcome metric |
| Benchmark | None shared; the engineer judges each output | Dedicated evaluation set of real tasks with known results |
| Model choice | Per conversation, by the engineer where allowed | Per workflow, fixed at the benchmark-justified point |
| Gate | Engineer decides when to stop and open a pull request | Defined check that accepts, escalates, or discards the output |
| Billing unit | Seat subscription plus overage | Usage attributed to the workflow when accounting supports it |
Workflow-level attribution makes software factory metrics useful for comparing repeated runs of the same workflow. Every message, agent turn, and tool call from one run belongs to its Cosmos Session, and archived sessions can be reopened, which is how the run behind a cost figure gets checked. Billing on a Cosmos cloud environment runs per minute of uptime, giving the compute term a meter the workflow owner can read. Sessions, requests, pull requests, and accepted outputs stay separate denominators; collapsing them into one unit-of-work figure hides whether the cost moved on routing, on volume, or on acceptance rate.
Which Workflows Move First
In every workflow that moved first at Uber, something other than a person starts the run, and whatever starts it also bounds the work before the agent begins. A started-and-bounded task is one a check can score without a human steering each turn. Code review fires when a pull request opens, works on one diff, and produces comments that a benchmark can score against known findings. A failing CI run works the same way. The red build triggers the run, the breaking change bounds it, and a green rerun verifies the result.
Alert triage starts from a page and scores against the incident's eventual root cause. The remaining three classes on Uber's list carry human review the same way. The Experts Cosmos ships line up with all of them: Deep Reviewer and Risk Analyzer on review, PR Author on end-to-end changes, Verifier on verification, and Incident Investigator on alert triage. Review and CI repair move first because their trigger and verification already exist in the tooling. Alert triage follows once incident records provide a stable check, and the maintenance and end-to-end classes need a benchmark built before anyone can score them.
None of them should move before four pieces of infrastructure exist.
- Intake: An event source fires reliably and carries the run's context with it.
- Gates: A defined check accepts or rejects the output. The quality gates already running on human changes provide the starting set.
- Telemetry: Enough run history survives to show what the agent saw and did when a gate rejects its output.
- Halt path: The run ends somewhere, and the workflow decides what survives. A Cosmos cloud environment starts every session from the same image and keeps nothing between sessions, so the pipeline commits or gates useful output before the run finishes. A self-hosted daemon persists disk state, a different failure to plan around.
Those four turn an automated task into an owned workflow. Once pipelines open pull requests faster than people read them, review hours become the binding constraint, and capacity planning covers what to do about that.
What Stays Interactive, and Why
Work with no stable target stays an interactive conversation. A pipeline needs a repeatable outcome metric and past cases to score against, and exploring an unfamiliar subsystem, scoping an ambiguous request, and designing something the codebase has never held have neither. The engineer discovers the target during the conversation, the state an interactive session is built for. A trigger-started run cannot begin there, and Cosmos does not change that. An Expert is a template written in advance, and a template needs a task defined before the event fires.
The same test separates steering from approval. Human-in-the-loop steering, where an engineer redirects an agent mid-task as understanding forms, belongs in a session the engineer owns. Autonomous approval, where a gate accepts or rejects a finished output against a known standard, belongs in a pipeline. Uber attaches human review and escalation to its agent-initiated tasks even while attributing most pull requests to agents. The gate can still ask for a person, and the exploratory step stays with one.
Where the Per-Unit Saving Gets Re-Spent
A cheaper run does not mean a cheaper quarter, because the work a pipeline creates lands on people the pipeline does not pay for. Faros AI measures where it lands, in delivery telemetry from 22,000 developers on its own platform, published as the AI Engineering Report 2026 with analysis through March. Faros is the instrument as well as the publisher. Its comparison follows teams past a 50% weekly-active threshold on assistants such as Claude Code, Cursor, GitHub Copilot, and Windsurf, plus autonomous agents wired into the delivery lifecycle.
Median time in pull request review, measured from the moment a reviewer starts, rose 441.5%. Pull requests merged with no review at all rose 31.3%. The incidents-to-pull-request ratio rose 242.7%, and Faros reads that as the probability of an incident more than tripling for every pull request merged. Each figure sets a team's own two lowest-adoption quarters against its own two highest, across more than 4,000 teams, so none of them measures one company against another.
Uber counts pull requests agents create. Faros, at other companies, counts how long a pull request sits in review once it exists. Uber's figure does not bear on Faros's, and together they describe a capacity problem. A factory can lower its cost per session while the review load it just created grows faster than the saving. A 52% session-cost decline is not a 52% budget decline. Unit efficiency and review-and-incident load belong in the same ledger, the accounting at the center of the productivity paradox in AI-assisted delivery.
What to Do Next
The tradeoff is tighter per-run cost control against review and incident load that may absorb the saving. Test it on one workflow first. Pick one with a stable outcome and enough past cases to build a benchmark, then record cost per session, cost per accepted output, review time, and gate failures as separate metrics.
Start with code review, where known-good findings already sit in review history. Have the owning team define the outcome metric, build a benchmark from real past cases, and select the model against it. On Cosmos that is one Expert, one Environment, and one Trigger, configured before anything routes to them. Run the current process and the proposed pipeline over the same cases, and move the workflow only if its pass rate holds and the combined run, review, and incident cost improves.
Frequently Asked Questions About Agent-Run Pipelines
Related Reading
Written by
Molisha Shah
Molisha is an early GTM and Customer Champion at Augment Code, where she focuses on helping developers understand and adopt modern AI coding practices. She writes about clean code principles, agentic development environments, and how teams are restructuring their workflows around AI agents. She holds a degree in Business and Cognitive Science from UC Berkeley.