Runs
A run records one execution: its input, status, events, output, and errors. The run ID connects requests made at different stages of that execution. Runs can start child runs. Parent and child IDs preserve that relationship so a client can inspect delegated work and its results. Access checks still apply to each run. Look up event types and groups in the run event reference.Conversations
A conversation stores messages and related agent runs across an interaction. Branches preserve alternative message paths. Participants and read state control collaboration within the conversation. An input request asks a person for structured information while execution waits. Responding to an input request and resuming a run follow the requirements of the selected operation. The resume operation depends on the run kind, waiting reason, and submitted signal.Definitions and triggers
Task and workflow definitions describe the work to execute. They are stored in project source; their source lifecycle is separate from run history. Agent definitions belong to the Agents API. A job runtime executes implemented tasks and workflows. The definition describes the work; each execution records its own outcome. Schedules start work at configured times. Webhooks start work in response to deliveries. Each resulting run has its own identity and progress, regardless of how it was triggered.A support interaction
A new question can start an agent run associated with a conversation. The runtime reports progress through events, and the conversation stores the resulting messages. The same project can also run a scheduled summary task without a chat thread. A run’s existence means work was accepted, not that it completed successfully. Read its status and output, and inspect child runs when work was delegated.Runtime integration
A registered agent service exposes an invocation endpoint; a worker connects to accept work. They can execute on infrastructure you manage while Cloud records run state and history. Both report progress and completion against the assigned run identity. Registration, event publication, leases, and completion use the credentials required by their integration contract. Those credentials can be scoped to a service, project, or run. Read access to a run does not imply permission to publish its events or mark it complete. Runtime availability and execution outcome are separate signals. A disconnected worker or closed client stream does not establish that a run succeeded. The reference identifies runtime-facing operations, internal interfaces, and the credentials they accept.Explore the execution model
- Runs and conversations: How an interaction becomes tracked execution.
- Run lifecycle: Status, waiting, cancellation, and results.
- Conversations and messages: Messages, branches, and human input.
- Events and streaming: Live progress, replay, and notifications.
- Child runs: Delegation and execution relationships.
- Agent runtime contract: Responsibilities of connected services and workers.