Combining Agents

An agent is one definition: one model, one set of prompts, its own tools. It doesn't call other agents from its form. When a job is bigger than one agent should hold, you have two ways to split it:

• A workflow runs several agents, and tools, in an order you draw. Each agent stays its own definition, with its own prompts, evaluation set, and revision history.
• Parallel sub-tasks let one agent fan out copies of itself to work on parts of a task at the same time.

When to split work across agents

Use separate agents when:

• A piece of behavior is reusable across multiple jobs (e.g., a "draft email" agent used by sales, support, and ops).
• A piece of behavior is distinct enough to deserve its own evaluation set, prompts, and revision history (e.g., a classifier independent of what runs after it).
• One agent's prompt is getting too big to read because it tries to cover several jobs.
• A piece needs different guardrails — a stricter model, a tighter system prompt, sandboxed integrations.

If a piece of behavior is small and only ever needed by one agent, keep it in that agent's prompt, or package it as a skill. Don't pre-factor.

Agents in a workflow

A workflow is a graph built on a canvas in the workflow builder. Its Agent step runs an existing agent:

1. The workflow reaches the Agent step.
2. It passes the agent's parameters, mapped from the workflow's inputs and earlier steps' outputs.
3. The agent runs as a normal agent — its own tools, memory, knowledge.
4. Its reply, or its structured output if it has a JSON output format, becomes the step's output.
5. Later steps reference it as {{step.<step_name>}}, or a field of it as {{step.<step_name>.<field>}}.

The agent's run shows up as a nested trace inside the workflow's trace — you can drill into it without leaving the workflow's view.

Sequential

The straightforward chain — each agent's output feeds the next.

extract_text → summarize → translate

Parallel

Steps with no shared dependencies run at the same time — there's no extra wiring needed.

              ┌─ sentiment_analyzer
input  ──────┼─ keyword_extractor    →  merge
              └─ language_detector

Revisions

The agent's revision is pinned when you publish the workflow, so deploying a new revision of the agent later won't silently change the workflow. To pick up the agent's changes, publish the workflow again.

Parallel sub-tasks

Turn on Parallel sub-tasks under Execution in the agent's form to let the agent split a task into parts and work on them at the same time. Each sub-task is a copy of the same agent; Sub-task timeout caps how long the agent waits for one. Sub-tasks run on background (queued) runs.

Cost and latency

An agent run inside a workflow costs roughly what the agent costs standalone — there's no platform overhead worth worrying about. The trace breaks costs down per nested run, so per-workflow reporting stays accurate.

For latency-sensitive paths, prefer parallel steps over deep sequential chains. A 4-stage sequential chain costs the sum of the stages; a parallel fan-out costs the slowest stage.

Best practices

• One job per agent. An agent that does three things is harder to evaluate than three agents that each do one.
• Stable output shapes. Later steps depend on the field names. Don't rename without coordinating.
• Evaluate each agent independently. Each gets its own golden dataset.

Next steps

• Agent Studio — the agent editor in depth
• Versioning — revisions and rollback
• Evaluations — per-agent quality gating
• Use Cases — patterns built from agents