Member Junction
    Preparing search index...

    For flow agents, this defines a single step

    interface AgentStep {
        ActionID?: string;
        ActionInputMapping?: string | Record<string, unknown>;
        ActionOutputMapping?: string | Record<string, unknown>;
        Configuration?: string | Record<string, unknown>;
        Description?: string;
        Height?: number;
        ID: string;
        LoopBodyType?: "Prompt" | "Sub-Agent" | "Action";
        Name: string;
        OnErrorBehavior?: "fail" | "continue" | "retry";
        Paths?: AgentStepPath[];
        PositionX?: number;
        PositionY?: number;
        PromptDescription?: string;
        PromptID?: string;
        PromptName?: string;
        PromptText?: string;
        RetryCount?: number;
        StartingStep: boolean;
        StepType:
            | "Decision"
            | "ForEach"
            | "Prompt"
            | "Sub-Agent"
            | "While"
            | "Action"
            | "Human";
        SubAgentID?: string;
        TimeoutSeconds?: number;
        Width?: number;
    }
    Index

    Properties

    ActionID?: string
    ActionInputMapping?: string | Record<string, unknown>
    ActionOutputMapping?: string | Record<string, unknown>

    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.

    Configuration?: string | Record<string, unknown>

    Step-specific settings, as JSON text or as the object it parses to.

    For a loop step: { type, collectionPath?, itemVariable?, indexVariable?, maxIterations?, continueOnError?, condition? }. For a Decision step: { key, state?, questions }.

    Both shapes for the same reason as the mappings: the Architect's prompt documents this field as string | object, so a model sends either, and the Architect's validator accepts either. The column stores JSON text, and that is what the runner parses, so AgentSpecSync writes an object as text. A spec read back from the database always carries text.

    Description?: string
    Height?: number
    ID: string
    LoopBodyType?: "Prompt" | "Sub-Agent" | "Action"

    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.

    Name: string
    OnErrorBehavior?: "fail" | "continue" | "retry"
    Paths?: AgentStepPath[]
    PositionX?: number

    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.

    PositionY?: number
    PromptDescription?: string
    PromptID?: string
    PromptName?: string
    PromptText?: string
    RetryCount?: number
    StartingStep: boolean

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

    StepType:
        | "Decision"
        | "ForEach"
        | "Prompt"
        | "Sub-Agent"
        | "While"
        | "Action"
        | "Human"

    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.

    SubAgentID?: string
    TimeoutSeconds?: number

    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.

    Width?: number