Verification
By default, any agent session that completes without throwing an exception is treated as success. Verification lets you define stricter success criteria — for example, checking that the agent actually produced output that satisfies a condition, or having a separate "judge" agent evaluate the result.
If verification fails, the record is treated as a failure and added to the dead letter queue.
Two strategies are supported: a lightweight condition expression, or a full judge agent.
Condition verification
Evaluates a
UserFn expression
against the agent session's context and expects a boolean result. If the
expression returns true, the record is considered successfully processed.
The expression uses the same UserFn language as User Defined Function
rerankers — it supports get() with JSONPath, comparisons (==, !=,
<, >), boolean operators, arithmetic, and the built-in time/math
functions. See the
UserFn reference
for full syntax.
Available fields
The context passed to the expression has the following shape:
VERIFICATION CONTEXT
Code example with json syntax.1
| Path | Description |
|---|---|
$.agent.key | The worker agent's key. |
$.session.key | The agent session created for this record. |
$.output | The agent's final output. For structured output agents, this is the parsed object (access fields with $.output.<field>). For plain text agents, this is { "text": "..." }. Absent if the agent produced no output. |
$.tools.<tool_name>.outputs.latest | The most recent output of each tool that was called during the session. Only tools that produced output are included. Values are the raw tool output (typically a JSON string). |
Examples
REQUIRE ANY OUTPUT
Code example with sql syntax.1
REQUIRE A SPECIFIC STRUCTURED OUTPUT FIELD
Code example with sql syntax.1
REQUIRE A MINIMUM CONFIDENCE SCORE
Code example with sql syntax.1
REQUIRE A SPECIFIC TOOL TO HAVE RUN
Code example with sql syntax.1
COMBINE MULTIPLE CHECKS
Code example with sql syntax.1
TRANSFORM FIELD (CONDITION VERIFICATION)
Code example with json syntax.1
Condition verification is lightweight — it runs locally without calling out to another agent. Use it when success can be expressed as a simple structural check on the session's output or tool outputs.
Agent verification
Uses a separate judge agent to evaluate the worker agent's session. The
judge agent receives a summary of the worker session and must return a
structured output with a success boolean and a reason string.
TRANSFORM FIELD (AGENT VERIFICATION)
Code example with json syntax.1
Judge agent requirements
The judge agent must be configured with a structured output parser on its first step, and the output schema must define exactly these properties:
| Property | Type | Description |
|---|---|---|
success | boolean | Whether the worker agent's session should be considered successful. |
reason | string | A human-readable explanation of the verdict, surfaced in dead letters when success is false. |
Pipeline creation and update requests validate that the judge agent
exists and that its structured output schema has both properties with the
correct types. Requests that don't meet these requirements are rejected
with 400 Bad Request.
Example judge agent configuration
FIRST_STEP FIELD ON THE JUDGE AGENT
Code example with json syntax.1
See Structured output for more on configuring structured output parsers on agents.
When to use agent verification
Agent verification is more powerful but also slower and more expensive — each record triggers a second agent session. Use it when success requires semantic judgment that a simple expression can't capture.
Choosing between the two
| Use condition verification when... | Use agent verification when... |
|---|---|
| Success can be determined from a field in the output | Success requires understanding the content of the output |
| You want minimal latency and cost overhead | You're willing to pay for an extra agent session per record |
| The check is a structural comparison | The check requires semantic reasoning |