Validators
There are 4 different validators in Agency Swarm:- Tool validators:
field_validator
: Validate individual fields independently.model_validator
: Perform complex checks involving multiple fields.
- Agent validators:
guardrails
(for v1.x and higher) orresponse_validator
(for v0.x): Validate the response before sending it to the user or other agents.
- Universal validators:
llm_validator
(v0.x): Validate outputs against specified natural language rules.
Agent Response Validator
In v1.x, validation is handled through guardrails using the agents SDK. Guardrails provide more flexible validation for both input and output.After the guardrail error is triggered, the agent will receive the error message provided in the Your guardrail will receive:This allows you to process each new input message individually or validate them as a group.Example:If set to This will not raise an exception; however, the
This event will always have an id set to
For user messages, the error processing is similar to output guardrails.Each triggered guardrail will also leave a corresponding system message containing error message inside of a chat history. Regardless of the In this example, if the CEO agent sends a message to the worker that does not start with the word “Task:”, the input guardrail will be triggered and
the CEO will be notified with an error message saying Similarly, the response of the worker to the CEO agent will be checked against the output guardrail and within
the specified number of
Output Guardrails
Output guardrails validate agent responses before they are sent to users or other agents. Each output guardrail function receives three parameters:context
, agent
, and response_text
.In most cases, you’ll only need the response_text
parameter, which contains the agent’s latest response as a simple text string if agent does not have output_type
specified or it will follow a pydantic schema provided in the output_type
parameter. This allows you to check the response against specific criteria.For more complex validation scenarios, you can utilize the context
and agent
parameters to account for run state and agent configuration during validation.Example:Validation Attempts
Thevalidation_attempts
parameter controls how many times an agent can retry when output validation fails. Default is 1 (one retry). Set validation_attempts=0
for immediate fail-fast behavior.output_info
in the form of a system message and will adjust its output accordingly.Output Guardrail Exceptions
After all validation attempts fail, theOutputGuardrailTripwireTriggered
error will be raised to allow for additional processing, if needed.Input Guardrails
Input guardrails validate incoming messages before they reach the agent. They can check both user input and inter-agent communication.Simplified Input ProcessingAgency Swarm simplifies guardrail implementation by automatically extracting text content from messages. While the Agents SDK originally passes the entire chat history to guardrails, Agency Swarm wraps your guardrail functions to provide only the relevant text content, eliminating the need for manual extraction logic.Parameters and Input TypesEach input guardrail receives three parameters:context
, agent
, and user_input
. The user_input
parameter format depends on the message structure:- Single message: A string containing the message content
- Multiple consecutive messages: A list of strings, one for each message
Note that file and image inputs inside of a user message will not be passed to the guardrail.
Input Guardrail Return Format
Agent’s configuration includes an optional parameter calledthrow_input_guardrail_error
, which defines how the guardrail error will be processed and presented to the caller:True
, triggering a guardrail will raise a corresponding exception, as described in the next section.
If set to False
(its default value), the guardrail error will be returned to the user/caller agent as if it were a genuine response from the recipient. For example, using the agent above:response.final_output
will contain the guardrail’s error message. In this case, it will be:"Prefix your request with 'Request:' describing what you need."
For streaming responses, it will emit an extra event at the end of the stream in the following format:msg_input_guardrail_guidance
, so you can further differentiate it, if needed.When to use: This feature’s primary focus is to simplify building user-facing applications and make the user experience more fluid.
When using this feature, you won’t have to add any exception handlers for the input guardrails. Instead, users will receive the response as if it were coming from the agent, so they can adjust their input accordingly.While having this feature turned on produces an agent’s response, that response is purely artificial and will not be registered in the thread history.
Instead, an appropriate system message will be added in order to log a guardrail error.
Instead, an appropriate system message will be added in order to log a guardrail error.
Input Guardrail Exceptions
Unlike output guardrails, if an input guardrail exception is raised (throw_input_guardrail_error
should be set to True
for that to happen), the error will be immediately returned back to the user/caller agent.For user messages, the error processing is similar to output guardrails.
throw_input_guardrail_error
parameter value.The validation_attempts parameter currently does not apply to input guardrails.
Agent-to-agent message validation
You can use guardrails to control how agents send messages and responses to one another. When adding communication flows between agents, the guardrails of the recipient agent will define the format of input and output messages, for example:"ERROR: Requests to this agent must begin with 'Task:'"
. Then it will either adjust the input
and try again or notify the user, as per its instructions.Agent-to-agent messages are always single strings, so if you are using a guardrail exclusively to check inter-agent communication, input guardrail will always receive a string.
validation_attempts
it will need to generate a correct response. In this case, the requirement is that the worker’s response should start with
the word “Response:”, otherwise it will receive the error message "ERROR: Your response must start with 'Response:'"
It is recommended to set throw_input_guardrail_error=True
for the agency’s internal agents. While False
value is also supported, setting it to True
will add an
extra error prefix to the recipient’s response to indicate the issue and avoid potential confusion.Due to the nature of Handoffs, using SendMessageHandoff for agent-to-agent communication will bypass input guardrails set between agents.
Tool Validators
When defining tools, you can use Pydantic validators to prevent invalid data from being passed to the tool by the calling agent. There are 2 types of validators used specifically in tools: field-level and model-level validators. Here is the comparison table to help you understand the difference between them:Type | Purpose | Usage |
---|---|---|
Field Validators | Validate individual fields independently. | Use the @field_validator decorator on methods, specifying the field(s) to validate. |
Model Validators | Validate the entire model, allowing checks involving multiple fields. | Use the @model_validator decorator on methods. |
This example ensures that the
username
field does not contain spaces using a field validator:LLM Validator (v0.x)
Thellm_validator
validates outputs against specified natural language rules. (v0.x)
Example:
llm_validator
will throw an error if the message is not related to customer support. The caller agent will then have to fix the recipient or the message and send it again.
Since
llm_validator
uses LLMs for validation, it may incur additional costs and latency due to extra API calls. Use it for fields that require complex validation beyond simple checks.