Workflows overview

A workflow organizes ordered work around inputs, actions, outputs, evidence, and approval boundaries. In the supplied implementation, those ideas appear through agent-run actions and functional contracts rather than a fully verified universal workflow builder.

General workflow authoring controls, every trigger type, and broad control-flow behavior remain partially grounded.

The current evidence supports a workflow model built from ordered actions inside an agent run. It does not establish that every workflow has a separate definition object, visual canvas, or generally available trigger service. Documentation should therefore explain inputs, actions, approvals, evidence, outputs, and run state without inventing a product-wide builder. This narrower model is still useful because it makes each step traceable to the tool, risk, proposal, decision, and persistence records that govern it.

What a workflow is

The verified model is deliberately narrower than a visual automation canvas. Work is represented as ordered actions attached to a governed execution, with proposals and approvals inserted where policy requires human review. Evidence supports decisions, and output records what the execution produced. Trigger type declarations indicate intended shapes, not proof that every scheduled, webhook, or event-driven path currently runs.

In the supplied runtime, workflow behavior is represented through ordered actions, functional-agent step definitions, proposals, approvals, evidence, artifacts, and run state. A universal workflow-builder object or editing interface was not verified. Use workflow as the coordinated sequence expressed by those contracts, not as proof of a generally available no-code product.

A workflow can be understood only through an actual run. The definition describes intended steps and boundaries; the run records what executed, waited, failed, or completed.

A workflow is a defined sequence of work represented by ordered steps or actions and the data that moves between them.

The current sources ground the execution record more strongly than a general definition UI.

Keep a workflow definition separate from each run that instantiates it.

A workflow is the ordered work represented by actions within an agent run or functional contract. The sources support workflow concepts and fixtures but do not prove one universal workflow builder or separate generally available workflow engine.

Evidence and outputs should remain traceable to the action and run that produced them. Functional-agent contracts can define workflow steps, evidence, artifacts, proposed actions, and approval boundaries. Control flow documentation should name the exact state or action boundary that allows, pauses, rejects, or stops progress.

Scheduled, webhook, and event-driven trigger types in the contract do not prove live orchestration in every environment. Actions carry ordered step numbers, tool identifiers, risk, status, input, output, proposal IDs, and timestamps. Timeout behavior remains local to the verified implementation unless a workflow-wide policy is explicitly defined.

Steps

An action includes an ordered step number, tool ID, risk level, status, input, output, optional proposal ID, and timestamps. The order field supports sequential interpretation. It does not establish arbitrary branching, loops, parallel execution, or compensation.

Tool execution state and approval requirements apply at each step. A planned tool or blocked action cannot become executable merely because it appears in a workflow definition.

Actions have an order, tool ID, risk level, status, input, output, proposal ID, and timestamps.

Functional contracts can describe workflow steps and approval boundaries.

A contract-only step does not become executable until its tool and agent implementation are available.

Steps are represented by ordered action numbers and tool identifiers. Each action carries its own risk, status, input, output, proposal relationship, and timestamps so a multi-step result can be reviewed at the correct boundary.

A workflow execution is represented through an agent run rather than a separate verified universal workflow runtime. Ordered action numbers and declared state transitions are verified; a universal branching language, loops, concurrency, and compensation are not.

Inputs and outputs

Workflow input enters through the run and may be supplemented by action-specific input. Keep credentials out of general input unless a verified integration path resolves them. Outputs can appear at the action or run level and may be accompanied by evidence and artifacts.

Do not treat an output value as proof of durable storage or export readiness. Persistence mode and artifact metadata must be inspected separately.

Workflow input belongs to the run or step contract and should be scoped to the intended task.

Outputs can exist at action and run levels, with evidence and artifacts referenced separately.

Do not assume a universal schema or automatic downstream delivery.

Inputs enter through the run and actions; outputs remain attached to the records that produced them. Evidence and artifacts should retain provenance rather than being detached into an unexplained final result.

A structured output may still be transient, while an artifact reference may point to storage whose access and retention are environment-dependent.

Approvals

Tool proposals are routed through the approval service. Policy can allow an action, require confirmation, or block it. A signed agent-run decision can approve or reject the proposed action; rejection may move the run to rejected.

Workflow guidance must account for the Private Alpha approvals surface, whose card actions remain scaffolded placeholders. It can illustrate the intended record shape but cannot be described as a persistable reviewer workflow.

Risk and approval requirements determine whether an action can proceed, must ask, or is blocked.

Signed decisions from agent-run approval services are distinct from scaffolded general Approvals cards.

Approval context should bind the request, run, step, tool, and parameters.

Approvals create explicit pauses before material actions. A proposal, supporting evidence, and signed decision are different records, and scaffolded controls on the general Approvals page are not equivalent to that decision path.

Functional-agent contracts can also define workflow steps, evidence, artifacts, proposed actions, and approval boundaries. Persistent reviewer escalation remains unverified.

Runs

One run records one execution of the workflow behavior. Trigger type, idempotency, parent-child relationships, transitions, actions, evidence, output, audit events, and persistence describe that execution. Different runs can produce different outcomes because tools, credentials, approvals, policy, and environment state change.

The verified /agent-runs route provides an index of platform runs. No universal workflow-run launcher is established.

Each execution creates or references a run with state, trigger, actions, evidence, timestamps, and persistence mode.

The same workflow concept can produce multiple runs with different inputs or outcomes.

A completed run is the execution result, not proof that every future run will follow the same route.

Runs provide state, transition, persistence, audit, and parent-child context for the workflow. Trigger-type definitions alone do not establish that every schedule, webhook, or event integration is live.

Tool availability and approval behavior are evaluated for each action.

Where to begin

Begin with a narrow manual run for an active agent using available tools and nonsecret input. Inspect each ordered action, confirm that approval requirements are honored, and verify the persistence mode. Add more steps only after the simple sequence produces understandable transitions and evidence.

Keep planned triggers, branching, loops, concurrency, and compensation outside the documentation until their execution behavior is verified.

Start with capabilities and tools to verify executable building blocks.

Read workflow steps and control flow before describing branching or retry behavior.

Use human approval gates and troubleshooting for governed and failed executions.

Begin by modeling the smallest ordered path, assigning tool and approval boundaries, and testing it as a run. Add complexity only when the action and state records remain understandable.

Provider retry behavior should not be promoted into a general workflow retry policy.

A visual builder or generally available trigger service should not be implied when the source only verifies runtime contracts.

The source bundle verifies workflow-related contracts and runtime primitives, not a universal visual workflow builder or live support for every trigger type.

Model a workflow as ordered agent actions governed by the run state machine. Each action can name a tool, risk, status, input, output, and proposal relationship; the run supplies trigger, inputs, initiator, parent relationship, timestamps, and final output. Evidence and approvals attach to specific work rather than existing as generic workflow decoration.

The supplied contracts do not establish a universal no-code builder, arbitrary branching language, loops, compensation engine, or live support for every declared trigger type. Start with a short ordered path that can be represented by the verified action and transition records. Add approval only where the tool contract or policy requires it, and evaluate the result through the run, actions, decisions, evidence, output, and persistence mode.