Step Types

Step type defines what a step does.

Different step types are available for different Action Flow needs, such as language model calls, decision logic, iteration, direct tool calls, and utility operations.

Choosing the right type early makes your Action easier to test, maintain, and troubleshoot.

Choosing a Step Type

When adding a step, choose the type based on intent:

• Generate or reason with an LLM.
• Route by conditions or confidence.
• Iterate over items in an array.
• Call connected tools and external services.
• Perform helper logic for flow control.

Current Step Types in Studio

The step picker currently supports these step types:

Agent Step

• Backend type name: Agent Step
• Best for: LLM reasoning with optional multi-turn tool use.
• Typical use: Extracting fields, summarizing content, classification, and complex problem solving where the model may need multiple calls and intermediate decisions.

Switch Step

• Backend type name: Switch Step
• Best for: Conditional branching based on previous outputs.
• Typical use: Route to different paths using values like document type, confidence bucket, or status.

Loop Over Step

• Backend type name: Loop Over Step
• Best for: Running the same route for each batch of items in a JSON array.
• Typical use: Process each contact, invoice line, document, or other repeated item from an input array. The Loop route runs once per batch, and the Done route runs after all batches complete.

OCR Step

• Backend type name: OCR Step
• Best for: Extracting text from image or PDF inputs.
• Typical use: Converting scanned content into machine-readable text for downstream steps.

Code Step

• Backend type name: Code Step
• Best for: Custom logic and transformations in JavaScript.
• Typical use: Data reshaping, custom validation, and deterministic utility logic.

Metadata Step

• Backend type name: Metadata Step
• Best for: Promoting output values into searchable run metadata.
• Typical use: Extract key values (for example vendor ID or document number) for filtering and analysis.

Trigger Action Step

• Backend type name: Trigger Action Step
• Best for: Triggering another Action asynchronously.
• Typical use: Chaining Action Flows, delegating sub-tasks, and splitting larger processes into specialized Actions.

Tool Call Step

• Backend type name: Tool Call Step
• Best for: Directly calling a configured tool with explicit parameters.
• Typical use: Calling an external service or connector when the tool and parameters are already known and no LLM reasoning is needed.

Recommended Selection Pattern

1. Start with LLM Agent Step for core extraction, reasoning, and tool-assisted work.
2. Add Switch Step only when branching is clearly needed.
3. Use Loop Over Step when the same processing should run for each item or batch in an array.
4. Use Tool Call Step when the target tool and parameters are already known.
5. Use Code Step for deterministic logic that should not depend on model variability.
6. Use Trigger Action Step when one Action becomes too broad and should be decomposed.

Design Guidelines

• Prefer the simplest type that solves the task.
• Keep prompts and settings explicit.
• Validate outputs before relying on them in later steps.
• Use clear naming so behavior is obvious in logs.

Common Pitfalls

• Overusing agent-style logic when a single general LLM step is enough.
• Putting business-critical branching into prompts instead of explicit switch logic.
• Using a Switch Step for repeated item processing when Loop Over would make the flow clearer.
• Skipping metadata extraction, which later makes run analysis harder.

---