Long-running agents

Long-running agents work across hours, days, or recurring schedules.

They do not need to hold one process open forever.

They need durable responsibility, recoverable execution, persistent state, and a clear next action.

Available now Models through integrations

The durable responsibility loop

stateDiagram-v2
  [*] --> Ready
  Ready --> Running: schedule, event, or user
  Running --> Waiting: approval or external dependency
  Waiting --> Running: decision or callback
  Running --> Checkpointed: durable progress
  Checkpointed --> Running: continue
  Running --> Completed: outcome and evidence
  Running --> Recovering: timeout, restart, or failure
  Recovering --> Checkpointed: restore
  Completed --> Ready: next recurrence

The agent’s durable record should contain its objective, current step, checkpoint, artifacts, tool results, approval state, retry history, and next eligible execution time.

Do not treat an in-memory conversation as the source of truth.

Product patterns

Research operator

Watches sources, maintains a living thesis, and sends evidence-backed changes instead of repeating the same research.

Customer operations agent

Owns a queue, investigates each case, updates systems, and escalates only bounded decisions.

Engineering agent

Reproduces bugs in isolated sandboxes, modifies code, verifies the result, and returns a reviewable patch.

Revenue agent

Researches accounts, prepares outreach, updates records, and follows up when events occur.

Compliance agent

Collects evidence, checks requirements, records exceptions, and prepares an approval packet.

Operations agent

Runs recurring procedures across internal systems and preserves a receipt for every action.

Reference architecture

flowchart TB
  Triggers["Schedules, webhooks, inboxes"] --> Coordinator["Coordinator service"]
  Coordinator --> Run["Durable run record"]
  Run --> Sandbox["Isolated sandbox"]
  Run --> Computer["Persistent computer"]
  Sandbox --> Artifacts["Files and artifacts"]
  Computer --> Sessions["Authenticated sessions"]
  Artifacts --> Database["Managed database"]
  Sessions --> Database
  Run --> Approval{"Approval needed?"}
  Approval -->|Yes| Human["Human decision"]
  Human --> Run
  Approval -->|No| Evidence["Evidence and result"]
  Evidence --> Coordinator

Use a sandbox for code, shell commands, document transformations, and disposable execution.

Use a computer when work depends on browser identity, desktop software, or a persistent graphical session.

Use managed data for the responsibility ledger and snapshots for recoverable environment state.

Reliability contract

A production agent should make these states visible:

State	Meaning	Required evidence
Queued	Work is durably accepted	Run identifier and trigger
Running	One worker owns the current attempt	Attempt identifier and heartbeat
Waiting	Work cannot continue yet	Dependency or approval record
Recovering	Execution stopped unexpectedly	Last checkpoint and retry policy
Completed	The requested outcome finished	Artifacts, actions, and verification
Failed	The workflow cannot safely continue	Cause, evidence, and next action

Long-running does not mean unbounded

Set budgets, deadlines, tool permissions, retry limits, approval rules, and cancellation behavior before an agent begins work.

Design for restarts

Persist state before external actions.

Give every mutation an idempotency key.

Record enough evidence to determine whether a timed-out action actually completed.

Resume from a checkpoint instead of replaying the entire conversation.

Keep the previous deployed release live while a candidate is being built and verified.

Build next

Long-running agent recipe See the complete sandbox, computer, database, trigger, and deployment map.