How it works

How an agent run works

Five states on the main path (triggered, context built, model decides, tool runs, done), two exceptions (stopped by a step or cost cap, paused because it needs a human), and one fact that shapes the product: every lap re-sends the growing context, so each lap costs more than the last.

One run: a support agent issues a refund (pillar in brackets)

1. Triggered (orchestration): a chat message, API call, webhook, schedule or another agent's handoff. The platform stamps a run ID, the thread, the end user, the agent's version and the tenant. What can go wrong: a rate or spend limit returns HTTP 429; a duplicate webhook without an idempotency key (a unique ID that lets the receiver spot a repeat) starts a second run.
2. Context built (context and memory): system prompt, tool definitions, recalled memory, documents retrieved as the end user and filtered by their permissions, and the conversation so far, compacted if it's long. What can go wrong: the index holds last week's permissions; a long context buries the fact the model needs, since accuracy falls as input grows even inside the advertised window; compaction drops a detail; a reordered tool list breaks the prompt cache and the step costs several times more.
3. Model decides (orchestration): a final answer, tool calls or a handoff to another agent. What can go wrong: an error triggers a fallback to another model that behaves differently; malformed arguments; parallel calls emitted before any check.
4. Tool runs (secure execution): the executor, not the model, checks the call against an allow-list and a policy outside the model, fetches a credential, runs the tool and appends the result. What can go wrong: the ERP times out after committing, and a retry without an idempotency key refunds twice; the result carries instructions from an injected email; a valid call does the wrong thing.
5. Paused (orchestration, secure execution): the refund is above the approval threshold, so the run saves its state, releases compute and waits for a person. What can go wrong: nobody approves; the approver clicks yes without reading.
6. Back to model decides for another lap until the model answers, or Stopped when a guard fires: maximum turns, a token or cost budget, a timeout. What can go wrong: the agent repeats a step, the most common single failure (about one in six) in a study of 1,600 multi-agent traces.
7. Memory written (context and memory): a model decides what to remember, for whom and for how long. What can go wrong: it saves an instruction planted in a ticket, or personal data you'll later have to erase.
8. Done (evals and governance): the result goes back, the trace closes, and usage (input, cached, output and reasoning tokens, tool fees, runtime) is metered and charged to a tenant. What can go wrong: the trace says "refund issued" and the payments system disagrees; the trace was sampled, or holds no content.

A long-running task: onboarding a vendor

1. Triggered by an API call; the engine saves a checkpoint after every step.
2. Paused three minutes in, when the agent proposes changing the vendor's bank details. State is saved and compute released: an idle managed session isn't billed on Anthropic's platform, and AWS tears down an idle microVM after 15 minutes.
3. Resumed two hours later, when an approver says yes in another tool. Resume means replay: the step restarts from its beginning, so anything it did before the pause must be safe to repeat.
4. Retried when the ERP call times out after the ERP committed; the retry carries the same idempotency key, so the ERP returns the original result instead of writing twice.
5. Recovered after a worker crash, from the last checkpoint, not from scratch; a code deploy in between mustn't change how this run behaves.

What can go wrong: the provider's stored state expires (30 days on OpenAI's Responses API, 55 days on Google's paid Interactions API, until deleted on Anthropic's managed sessions); the model retires mid-run; the session hits its maximum lifetime (8 hours by default on AWS); compaction drops the detail the approver asked about.

Cost grows roughly quadratically with turns, because the whole history is re-sent each turn. Capping coding agents at the turn count three in four runs stay under cut cost by a quarter to two-thirds without hurting results. Caps are what stop runaway loops; risky actions pause for a human, and "resume" means replaying from the last checkpoint.

Cheat sheet: ways to build and run agents

Why pay for an independent platform when every lab and cloud ships one? Because the labs' stateful APIs, caching rules and usage formats all differ (even cached tokens sit in differently named fields at OpenAI, Anthropic and Google), and a company running several models needs one place for state, approvals, traces and evals. Labs and clouds keep absorbing features; the independents sell neutrality. I'd choose based on where state, credentials and eval history will live the day you change models, which a demo won't show you.