OptionalactionThe MJ: Action Execution Logs row this step produced, when it was an Action step.
The action equivalent of promptRunID, and it exists for the same reason: the Task row
records that an action ran, and nothing recorded WHICH execution. So a workflow's action step
had no way to offer "view the execution log" — the one thing a person wants when an action
misbehaves — while an ordinary agent run step has offered exactly that all along through its
TargetLogID.
Set on the step's LAST execution, matching promptRunID: the logs themselves are the durable history, and this points at the one whose output the payload actually carries.
OptionaliterationsOne entry per pass of a loop step, in iteration order.
Without this a loop's work does not exist anywhere the platform can see it. The run tree
reaches nested work through exactly six links — a run's steps, a task-graph step's graph, a
graph's tasks, a Sub-Agent step's run, and a task's own AgentRunID — and a loop iteration is
none of them. AIAgentRun.ParentRunID does not help either: it records parentage but is not a
link the tree traverses. So a While that spent real money across three passes reported one
childless node with no cost, the settlement rollup under-counted every loop-bearing workflow,
and the timeline offered nothing to expand — the work had happened and was unreachable.
Recorded by the dispatcher as each pass completes, so a loop that is still running already has its finished iterations here.
OptionalpayloadThe payload as it stood when this step BEGAN — its dependencies' outputs merged with whatever authored input it carried.
Why this is not Task.InputPayload. That column holds the authored input from the spec
and round-trips back out through TaskGraphSpecToAgentSpec; overwriting it at completion would
make a run's resolved values indistinguishable from what its author declared. So the resolved
value lives here, and the authored one stays where it was written.
Why it is stored at all, when OutputPayload already holds the payload as it stood after.
Without a before, the run view has nothing to diff against and reports every step as having
created the entire payload from nothing — a step that added one key showed as root Added Object{5 keys}. It is the same before/after pair an AIAgentRunStep has always recorded, for
the same reason. It duplicates the upstream task's output by design: recomputing it would mean
re-implementing the dependency merge in every consumer.
OptionalpromptThe MJ: AI Prompt Runs row this step produced, when it was a Prompt step.
Set on the step's LAST execution. A retried step overwrites it rather than accumulating: the prompt runs themselves are the durable history, and this is the pointer to the one whose output the payload actually carries.
The runtime artefacts a completed step points at.
This exists because cost was unreachable for prompt steps. A workflow's spend is aggregated by walking the run tree: an Agent step reaches its cost through
Task.AgentRunID→ the run's own totals. A Prompt step has no agent run — the dispatcher executes the prompt directly — so itsAIPromptRun, and with it every token and dollar it spent, had no path back from the Task at all. The runner returned the id and the dispatcher dropped it on the floor.