Skip to main content
By default the agent’s answer is free-form text. Set an answer_format (a JSON Schema) on the agent and it returns data that conforms to it: the answer you read from changes is then a JSON object instead of a string. Define it inline on a custom agent, or ask a catalog agent for it on a single run with overrides. The SDKs go further: pass a Pydantic model (Python) or Zod v4 schema (TypeScript) as answer_schema / answerSchema and the SDK derives the JSON Schema for you, then parses the final answer back into a validated, typed instance. A completed session whose answer is missing or doesn’t match the schema raises AnswerValidationError with the raw payload attached; the raw wire value always stays on the result’s final_changes / finalChanges, next to the parsed answer. The schema and an agent.answer_format override are two ways to set the same field, so passing both is rejected. Runs that end without reaching completed, such as an idle session that hasn’t answered yet or a failed one, skip validation: the answer passes through as-is, and is None / undefined when absent.

Chaining agents

With a typed answer, an agent behaves like any other function: call it, get data back, build on it. Here one agent gathers sources and others read them in parallel:
Parallel sessions count against your concurrency quota.