Interface AgentStep

Maps a step's inputs and outputs, as JSON text or as the object it parses to.

Both shapes, because both are already in use and pretending otherwise made the type a lie: AgentSpecSync parses these into objects when reading a step back out and stringifies them when writing, the Architect's validator explicitly accepts either, and the prompt documents them as string | object. Declaring only string meant the one honest place — the read path — had to be typed any to compile.

Step-specific settings, as a JSON string — the shape AIAgentStep.Configuration stores.

For a loop step: { type, collectionPath?, itemVariable?, indexVariable?, maxIterations?, continueOnError?, condition? }. Typed as a string rather than an object because that is what the column holds and what the runner parses; giving the spec a richer shape than the storage would put a translation step between authoring and execution, which is where the two would start to disagree.

What runs on each pass of a ForEach or While step.

A loop step is a wrapper: LoopBodyType says which of ActionID / PromptID / SubAgentID is the body, and the loop's own bounds live in AgentStep.Configuration. Ignored for the non-loop step types.

Canvas geometry. Presentation only — nothing about execution reads it.

Carried so reopening a saved workflow puts the boxes back where its author left them instead of re-running auto-layout, which discards the arrangement they made.

If this is the first step of the flow agent or not

Derived from the entity rather than restated. The hand-copied union here read 'Prompt' | 'Action' | 'Sub-Agent' and had already drifted: AIAgentStep.StepType also accepts ForEach and While, so anything authoring an agent through this spec — the Agent Manager above all — could not express a loop at all, even though the runner has executed them for releases. Deriving the type is what makes the next value CodeGen adds flow through for free.

Per-step execution policy, mirroring the entity's TimeoutSeconds / RetryCount / OnErrorBehavior columns.

Optional and additive: added so a compiled workflow can round-trip back to a flow without silently losing these settings. Behaviour for a compiled flow comes from the graph's failureSemantics, not from OnErrorBehavior — a flow's real error handling is its recovery paths — but the values still have to survive the trip.