Durable execution stores the work associated with a conversation or project. It tracks run identity, lifecycle, replayable output, waiting checkpoints, resume signals, cancellation, and finalization.Documentation Index
Fetch the complete documentation index at: https://veryfront.com/docs/llms.txt
Use this file to discover all available pages before exploring further.
Durable execution
Durable execution covers run lifecycle and replayable output.| Data | Meaning |
|---|---|
| Canonical run | Shared execution record with runId, kind, owner, parent run, root run, status, and waiting reason |
| Agent run | Conversation-owned execution for chat and project-agent work |
| Workflow run | Project-owned execution for a workflow target and its step graph |
| Job run | Project-owned execution for a background target, including a task target |
| Run event | Ordered event payload for text, tool, reasoning, custom data, and terminal updates |
| Waiting checkpoint | Stored state for a paused tool, approval, event, or human-input step |
| Resume signal | Tool result, approval, event, or input response that moves a waiting run forward |
| Finalization | Terminal status plus usage, model, provider, result, and error metadata |
Key concepts
- Run: A canonical durable execution record with a public run ID, kind, owner, status, parent run, and root run.
- Agent run: A conversation-owned run with
kind: "agent". It represents chat or project-agent execution attached to a conversation. - Workflow run: A project-owned run with
kind: "workflow". It represents a workflow target and its step graph. - Job run: A project-owned run with
kind: "job". It represents background execution of a target, including task targets. - Task: A developer-defined unit of background work. Jobs execute tasks when the job target points at a task.
- Cron job: A schedule definition. Each scheduled or manual trigger creates a job run.
- Run event: An ordered event attached to a run. Events power snapshots, replay, and public SSE streams.
- SSE stream: The response transport that updates Studio while a run is active.
- WebSocket notification: A lightweight event that tells Studio to invalidate and refetch state. It does not carry the token stream.
Run types
Use the run kind to know which detail record and runtime path apply.| Run type | Owner | What starts it | What it represents | Related record |
|---|---|---|---|---|
| Agent run | Conversation | AG-UI chat request, detached AG-UI run, or project-agent trigger | Agent execution attached to a conversation | Conversation agent run and run events |
| Workflow run | Project | Workflow start request | Workflow target plus step graph state | Workflow run detail and backing job |
| Job run | Project | Job start request or cron trigger | Background execution of a target | Job detail, job events, and optional result |
Workflows, tasks, jobs, and cron jobs
Workflows, tasks, jobs, and cron jobs share the canonical run layer, but they are different concepts.- Workflow definition: Describes a workflow and its steps.
- Workflow run: Creates a canonical run with
kind: "workflow"and stores workflow-specific detail. - Workflow backing job: Runs the workflow target in the job runtime. This gives workflow execution the same status and runtime infrastructure used by jobs.
- Task definition: Describes a callable background task and its input or output contract.
- Job run: Creates a canonical run with
kind: "job"and stores job-specific detail. A job target can point at a task, workflow target, deploy target, or another supported runtime target. - Cron job: Stores schedule, timezone, target, config, timeout, retry limit, and concurrency policy. A cron job is not itself a run. Each trigger creates a job run linked back to the cron job.