Guardrails and Multi-Agent Patterns

A guardrail is an automatic check; human review is a deliberate pause for a person to decide. The two work together to define when a run continues, pauses, or stops. OpenAI's Agents SDK names three kinds of guardrails by where they sit: input guardrails validate a request before the expensive or side-effecting part of a run starts, and — importantly — only run for the first agent in a chain; output guardrails validate or redact the final result before it leaves the system, and only run for whichever agent actually produces that final output; tool guardrails check arguments or results around one specific tool call, wherever that call happens in the chain.

Each of these can raise what the SDK calls a tripwire: when a guardrail's check fails, it raises an exception and halts execution immediately, rather than letting a bad input or output continue quietly through the rest of the run.

from agents import Agent, GuardrailFunctionOutput, Runner, input_guardrail

@input_guardrail
async def scope_guardrail(ctx, agent, user_input):
    check = await Runner.run(scope_checker_agent, user_input, context=ctx.context)
    return GuardrailFunctionOutput(
        output_info=check.final_output,
        tripwire_triggered=check.final_output.out_of_scope,
    )

support_agent = Agent(
    name="Support agent",
    instructions="Help customers with support questions.",
    input_guardrails=[scope_guardrail],
)

Guardrails handle checks a program can run automatically; some actions need a person instead. The Agents SDK's approval pattern marks a specific tool as needing review — cancelling an order, deleting a record — and when the model wants to call it, the run pauses rather than executing: it returns a list of pending interruptions alongside a resumable state. Your application approves or rejects each one, then resumes the exact same run from that state, rather than starting a fresh turn.

One boundary is easy to miss: agent-level guardrails don't cover everything. Input guardrails only run for the first agent in a chain, and output guardrails only for the one that produces the final answer — so in a manager-style, multi-agent workflow, a tool call buried in the middle of the chain isn't covered by either. The documented fix is to put validation next to the specific tool that creates the side effect, rather than assuming an agent-level guardrail reaches every step.

The multi-agent patterns from Anthropic's own guidance map cleanly onto specific task shapes. Routing classifies an input and sends it to a specialized follow-up — different prompts (or different models) for a refund request versus a technical question — which avoids the performance hit of one prompt trying to handle every case. Parallelization runs multiple LLM calls at once and combines their outputs programmatically, in two variations: sectioning, where independent pieces of a task run in parallel, and voting, where the same task runs multiple times for a more confident combined answer — useful for something like flagging a piece of code for vulnerabilities from several independent passes.

Orchestrator-workers is the pattern for tasks whose subtasks genuinely can't be predicted in advance: a central LLM breaks the task down and delegates pieces to worker LLMs, then synthesizes what comes back. Anthropic's own coding agents use exactly this pattern to handle GitHub issues that touch an unpredictable number of files.