Runs and conversations

Follow progress, respond to requests, continue a conversation, and inspect outcomes and usage.

An agent or workflow is a reusable definition. A run is one execution of a published version with particular input, identity, context, and limits. Inspect runs to understand what actually happened.

Start and follow a run

Choose Run… on a published target and fill in the form generated from its input schema. For custom JSON input, provide the expected object. Check the selected environment and version before starting.

The run workspace presents output, progress, activity, files, and operational details. Streaming text is provisional; a partial answer appearing on screen does not mean the run has succeeded or passed its result checks.

Read the state

State or display label	What it means	What to do
Queued	The run has not started executing.	Check queue position, pause state, and capacity.
Running	Work is in progress.	Follow activity and progress.
Sleeping	The run has a pending self-wakeup.	Inspect the expected wakeup rather than starting a duplicate.
Needs your input	The run has asked a question.	Answer the outstanding request.
Awaiting approval	A proposal needs an authorized decision.	Review it and approve, reject, or request changes where offered.
Waiting for external event	A step is waiting for a matching signal.	Check the event's correlation and trigger records.
Waiting for budget	Execution is blocked on budget availability.	Review limits and available capacity.
Needs recovery / Needs review	An outcome cannot be safely assumed.	Inspect the unresolved action and settle it through recovery.
Succeeded	The run finished with an accepted result.	Inspect the final output and files.
Failed	Work ended without a successful result.	Inspect the failure and last relevant attempt.
Canceled	The run was canceled.	Inspect completed actions; cancellation does not undo them.

Respond to the existing run

Use the run's pending request or the corresponding Inbox item to answer a question or review a proposal. Respond to the current request; a stale approval or response from an earlier attempt is not interchangeable.

For interactive work, instruct an agent to perform each action and wait for the next message until told done. Its discoverable Wait for the next message capability needs no binding. The run shows its current response and a message field; Send message continues that same run, and Finish run asks for the final result. It can wait repeatedly, retaining its files and progress. No worker is held and the run timeout pauses while waiting for the next message. Each accepted reply renews the timeout, step, model-turn and tool-call allowances for the next response. History, total usage and costs remain cumulative. Sleep, worker restarts and duplicate replies do not renew these allowances. Declared input waits remain available for questions with a specific responder or response schema and retain their configured deadlines.

Long runs compact older messages and results automatically as the model context fills. The original instructions, task, current plan, explicit notes and latest input stay exact. All originals remain saved and the agent can read earlier messages or results back when a summary lacks a detail. Summaries are lossy, so keep lasting constraints in instructions or notes and large work products in files. If required context cannot fit, the run reports a context-limit failure.

An approval records a decision about a particular proposal. Check the content and proposed action before approving. If revisions are supported, request changes and follow the resulting path.

For an uncertain external action, check whether that action happened before retrying. A new start or a blind retry could repeat a write. The recovery developer guide describes integration-level controls.

Inspect output, activity, and usage

Output contains accepted results and committed files. Inspect or download files you are authorized to access.
Activity records the sequence of work and waiting states.
Usage separates known usage from unsettled estimates and shows budget and provider details.
Technical exposes attempts and identifiers. An attempt has its own outcome, counters, and failure details; a retried call is not erased from usage.

If an answer stops early, inspect whether its attempt reached the output-token limit. If a run failed despite plausible text, check its schema and acceptance criteria. See Troubleshooting.

Conversations and follow-ups

A conversation session groups related turns and context. Each turn can start its own run; the conversation is not one permanently running agent. In an embedded experience, client-session authorization and conversation history are separate concerns.

A follow-up to finished work is a new linked run using prior context. Use it to ask another question or extend the result. Schedule follow-up creates that new work later. Answering a pending question, approval, or signal instead resumes the run already waiting.

When comparing outcomes, record the version, input, relevant context, and identity. A changed model, collection, or permission can explain differences even when the question looks the same.