Run Inputs

When you queue a run you may supply initial context: a dictionary of string key/value pairs seeded onto the run before the first step executes. Inputs appear in the run's context channel with kind Input and are visible to every step.

{
  "workflowId": "…",
  "agentId": "…",
  "initialContext": {
    "task_id": "task-7f3a",
    "purpose": "instance-fulfilment",
    "fspNumber": "12345",
    "advisorName": "Jane Q. Advisor"
  }
}

Ordinary keys (like fspNumber above) are plain data for your step instructions to reference. A few keys are reserved: the run pipeline reads them instead of treating them as opaque data.

Schedules seed inputs from their input template, and event and webhook triggers from their input mappings. Runs started through the MCP server take the declared inputs of the exposed workflow.

Reserved keys

task_id

The task this session is being composed for, typically an identifier opened in a downstream system before the run. When present, it is threaded into every step's token exchange, and the issued delegated token carries a matching task_id claim. Downstream resources can bind their fulfilment scope to it (e.g. "this session may only stage proposals attributed to task X").

A schedule opens one fulfilment task per firing and stamps its id as task_id. That id replaces any task_id in the schedule's input template.

purpose

The declared purpose of the session (e.g. instance-fulfilment). When present, it is sent in every step's token exchange, where the identity provider validates it against the client's allowed purposes, and the issued token carries a matching purpose claim. The value is trimmed, stored on the run, and may be at most 500 characters.

A workflow can require a purpose (PUT /api/workflows/purpose-requirement). A run of such a workflow launched without one is refused before it is created.

No purpose, no problem — fail-closed

If you omit purpose (and the workflow does not require one), no purpose claim is requested. Resources that require a purpose reject the session at the door, and resources that don't require one run unchanged. Forgetting a purpose can never grant broader access. It can only reduce where the session is accepted.

Both values are constant for the whole run and identical across all its steps. Child runs inherit them: a sub-workflow step, or a workflow an Orchestrator agent calls as a tool, carries the parent run's task_id and purpose into the child's inputs.

thread_id

Set by Agentfleet, not by callers, when an assistant in a conversation thread starts a workflow run. The run records the thread's id under thread_id, its task_id is the turn's id, and its purpose is the thread's purpose. The model cannot set any of the three.

Context keys produced by steps

As steps execute, outputs are promoted under predictable keys (<n> is the 1-based step number):

Key	Kind	Content
toolResult_<n>	ToolOutput	Step n's last tool result: authoritative data.
modelResponse_<n>	ModelText	Step n's final model text.
structuredOutput_<n>	StructuredOutput	Step n's schema-validated JSON, written instead of modelResponse_<n> when the step declares an output schema. For a for-each step, the aggregate of every item's result.
iterationSummary_<n>	StructuredOutput	A for-each step's summary: item counts and the items that failed.

Inside a for-each step, per-item keys carry an _item<i> suffix (e.g. toolResult_2_item3), so items never overwrite each other.

Reference these in later step instructions, e.g. "using the match verdict in toolResult_1, call CreateAdvisor …".

Limits

• Keys prefixed binary: are excluded from the context visible to steps.
• A large tool result (over 4,000 characters by default) is promoted as a reference with a bounded preview. A large context value (over 1,000 characters) appears in the step prompt as a preview line. The model reads the rest on demand with the read_context built-in, so the full value stays stored on the run.
• A step's prompt includes every input but only the most recent 40 step-produced entries (VisibleContextWindow). Older entries stay readable by handle.
• Model steps enforce caps on the visible context: at most 100 entries (MaxContextEntries) and 50,000 characters of keys plus values (MaxContextCharacters). Breaching a cap fails the step explicitly, with the limit named in the failure reason. Nothing is silently dropped or truncated.

The defaults come from the Execution configuration section and may differ per environment.

Related

• REST API
• Runs
• Identity & Security
• Automation