Executes a Workflow with streaming output.

A dictionary of input parameters for the agent execution. Keys correspond to parameter names defined in the agent's entry point flow step.

A list of file attachments included with the execution request. These are files sent by the user (e.g., via a connector) that the agent can access during execution.

Inbound media references recorded when the message arrived, without downloading the files yet. They are resolved into attachments, with their links added to the user query, just before execution. Empty when attachments were downloaded on arrival, and for non-chat runs.

The raw message text that the rendered user query ends with when this request carries deferredAttachments whose links have not been added yet. Resolved attachment links are inserted there. Null unless attachments were deferred.

The chat user initiating the execution, if applicable. Populated when the request originates from a connector (e.g., Slack, Teams).

An optional session ID for maintaining execution context across requests. When provided, the agent can resume a previous conversation session.

The participant associated with this run's inbound venue: the group for a group conversation, or the person for a direct message. Null for synchronous API/test runs, scheduled runs and senders with no matching participant.

The individual sender's participant id, distinct from participantId (the conversation venue) in a group. Null when the sender is not a known participant. Tells the agent who it is talking to and whose memory applies; never used for routing.

True when the sender has proven they own the identity the inbound message matched on.

True when the provider vouched that the inbound message came from the sender's identity.

The addressed person's messaging identity for a participant-directed run. Allows the person's integration credentials to be selected on consult and topic turns. Null on runs without a participant identity.

Required Application operating boundary selected for this run. Producers stamp the owning Agent/Application before execution or queue persistence, and queued/resumed requests carry it unchanged.

The runnable binding that scheduled this execution; for a collection pipeline it is the pipeline id. Null for conversational and ad-hoc runs, which resolve through an agent membership instead.

Identifies the environment this execution targets. Enables per-environment cost tracking, quota enforcement, and analytics. For system agents, this is automatically set to the calling tenant's slug.

Integration-config variant this execution resolves against. Defaults to ExecutionMode.Production.

Provider-reported time of the inbound message in Unix milliseconds. Null for non-chat runs or when the provider supplied no timestamp. Preserved through queueing so the recorded message retains its event time.

When Fruxon received the inbound message that started this run, in Unix ms: the start of the run's inbound-to-reply latency. Null for runs with no inbound message (API, scheduler and sub-task runs) and for older runs.

The customer's text from inbound messages, in send order, excluding sender headers, quoted replies, mention lines and attachment links. Reactions and bare attachments add no text. Aggregated turns concatenate these entries. Empty for non-inbound runs and older queued payloads. Available to prefetch rules and {{turn.message_text}}.

Inbound reaction emoji in send order. A reaction contributes no entry to inboundTexts, allowing a reaction-only turn to be distinguished from a written reply. Aggregated turns concatenate reactions. Empty for non-inbound runs and older queued payloads.

Origin marker for the user turns this run persists, threaded onto AgentContext.MessageOrigin and stamped onto AgentMessage.Origin. Set to AgentMessage.OrchestrationOrigin by enqueue sites whose user_query is a platform-synthesized orchestration prompt (topic kickoff/resume/relay/interject, background async-op updates) so the conversations transcript can tell it apart from a participant's actual message. Null everywhere else — including synthetic-but-conversational prompts that ARE the exchanged content (an AI-peer consult question is what the peer asked, so it stays visible). Survives the queued-payload round-trip.

How the agent appears on the channel this run came from: the provider bot handle (for example "@your_bot"). Set from the integration config's connection identity, and given to the model in its identity preamble. Null for non-channel runs (API, test chat, triggers).

When this run was spawned as a sub-task (e.g. spawn_subtask), the spawning run's execution-record id. Carried on the queued request so the child's execution record can be stamped with it when the worker eventually runs it, connecting the two traces. Null for top-level runs. See AgentExecutionRecord.ParentExecutionRecordId.

True when this run is a headless copy of the agent — it carries the flow's full system prompt but none of the conversation context (no TopicSession, no live participant dialogue, no inbox). Set only by SubtaskSpawnHelper.EnqueueChildAsync, the single choke point for spawn_subtask(s) fan-out and cross-agent delegation via AgentTaskToolExecutor. Drives ExecutionRequest.IsSpawnedChildRun, which the step executor uses to withhold the conversation-context and fan-out tools in ChildRunToolPolicy.

Declared explicitly rather than inferred from AgentExecutionRequest.ParentExecutionRecordId != null. That inference conflated two orthogonal questions — "whose run tree do I belong to?" (lineage, observability) and "do I have a conversation?" (capability) — and they only ever agreed while sub-tasks were the sole thing with a parent record. Once TopicSessionRunner began stamping lineage on consult-opening, interject-notice, relay and resume runs so an investigator could walk from a parked consulter to the run that answered it, those genuinely conversation-bearing dialogue runs were misread as headless and stripped of resolve_topic / accept_interject / defer_interject — the very tools their prompts instruct them to call (prod, 2026-07-22 → 07-25: an interject notice asked the agent to accept or defer with neither tool present, so it could only emit prose). CreateAgentTaskQueue.IsChildRun keeps the lineage-derived meaning — it gates run-credit admission, where "the parent's charge covers its tree" is exactly right.

The parent run's async-operation id this sub-task satisfies (pins the exact spawning call). Null for top-level runs.

Top-level ancestor of this run's spawn tree (the parent's root, or the parent's own id for a first-level child). Null for top-level runs (the record then roots itself).

The automation this run is part of, stamped on its record as AgentExecutionRecord.AutomationId. Set by whoever knows it: the queue worker from the task, the ledger for the runs it makes in-process. Null leaves the record to inherit its parent's, or to belong to no automation.

True for a turn of a conversation someone has already been asked in — a person's reply, and every orchestrated turn after the opening. The automation's spend limits let these through (they still count toward them): an automation that has run out of money stops asking, it does not stop answering. Set by the queue worker from the task's topic.

What role this run plays in its spawn tree — set alongside the lineage ids above by whoever spawns the run (SubtaskSpawnHelper for delegated children, the consult dispatch paths for advisor runs). Carried on the queued request so the child's execution record can be stamped when the worker eventually runs it. Defaults to ExecutionRunType.Root — an ordinary top-level run.

Short label for what this run is being asked to do, set by whoever spawns it when they know a better name than the raw prompt — the consult's goal, the sub-task's assignment. Left null on ordinary runs, where the record derives it from the run's own user_query input. See AgentExecutionRecord.Subject.

Optional per-run cap on the side-effect class of tools the agent may use. Set by collection-pipeline fan-out from the pipeline's actionTypeCeiling run policy; null for ordinary runs.

Optional agent revision to run. When set, the queued execution runs exactly this revision instead of the agent's current one. Collection-pipeline fan-out sets it so every item in a run executes the same revision, pinned when the run starts; null for ordinary runs, which use the current revision. A suspended item resumes on the same revision.

Forces this run's answer into a declared shape, overriding whatever contract the agent's own terminal step carries. Set by a caller driving an agent it does not own — a ledger stage needs its transition verdict parseable, while the agent may promise something else to every other caller. Null leaves the agent's own contract alone.

A test run's reply style instead of the agent's active one: a particular version (a draft under review) or none, so the same message can be tried with and without it. Honoured only for test-origin runs — the draft-test endpoints and evaluation rehearsals — and ignored everywhere else.