What is an agent run?

Agent run, explained#

Talking about an agent's work in messages or tokens is awkward for the people paying for it. A run is a more useful unit: it starts when the agent is given a task, it ends with something produced or with a failure, and it can be queued, watched, cancelled and audited as one thing.

A typical run moves through states. It is queued, then running while the agent reads context, calls tools and streams its progress, then ends as succeeded, failed or cancelled. What it leaves behind matters most: a document, a set of proposed tasks, a report. A run that ends with nothing useful should, ideally, not count against a quota.

Products that sell runs usually include a monthly allowance per plan, and the important questions are what counts as a run and what does not. Does asking the agent a question use one? Does a retry after an error use another? Is a failed run refunded? The answers decide whether an allowance is generous or a trap.

Runs also give a natural checkpoint for people. Because each run ends with an output, a reviewer can read it, accept it, edit it or throw it away before anything moves on, rather than discovering what an always-on agent did after the fact.

For example, a product manager starts a run in planning mode on a new project. A few minutes later the run has succeeded: there is a requirements document on the project and four proposed issues in the backlog. She edits two requirements, accepts three issues and deletes one. The run counted once.