You need three pieces of information from one ticket: category, urgency, and a one-line summary. What is the expensive way to get them?
Call three agents in series? One for category, one for urgency, one for the summary? Three API round-trips for one ticket?
Three round-trips, three bills, and three chances for the fields to contradict each other. The Pydantic-model pattern lets you ask for everything in one call. Define a class with all three fields, pass it as result_type, and result.output is a populated instance in one network trip:
from pydantic import BaseModel
class Ticket(BaseModel):
category: str
urgency: str
one_line_summary: strCan I still constrain the values? Category should be one of four options, urgency one of three?
Yes — system_prompt constrains the vocabulary while result_type enforces the structure. Together they give you shape validation and value guidance in one call:
def triage_ticket(text: str) -> dict:
agent = Agent(
model,
result_type=Ticket,
system_prompt=(
"Triage this support ticket. "
"Category: billing, technical, account, or feature_request. "
"Urgency: high, medium, or low."
),
)
return agent.run_sync(text).output.model_dump()Without the system_prompt, the urgency field might come back as "URGENT" or "critical" even though the shape is valid?
Right. The Pydantic model guarantees three string fields exist; the system prompt narrows what goes into those strings. Both together give you clean, routable data. .model_dump() then converts the typed Ticket instance into a plain dict you can return.
So the whole production triage pipeline — category, urgency, a searchable summary — is one function and one API call?
One call, three fields, a routable dict. Companies running support desks build their triage layer on exactly this shape. Write triage_ticket(text) now: define Ticket, build the agent with result_type=Ticket and the constraining system prompt, return .model_dump().
TL;DR: put every field you need into one Pydantic model — one agent call fills them all.
class Ticket(BaseModel) — three string fields in one containerresult_type=Ticket — one round-trip, consistent fieldssystem_prompt — constrains vocabulary inside each field| Three agents | One Ticket model | |
|---|---|---|
| Calls per ticket | 3 | 1 |
| Field consistency | Can contradict | Coherent |
| Cost | 3× tokens | 1× |
Always bundle related fields into one model when a single call can fill them.
You need three pieces of information from one ticket: category, urgency, and a one-line summary. What is the expensive way to get them?
Call three agents in series? One for category, one for urgency, one for the summary? Three API round-trips for one ticket?
Three round-trips, three bills, and three chances for the fields to contradict each other. The Pydantic-model pattern lets you ask for everything in one call. Define a class with all three fields, pass it as result_type, and result.output is a populated instance in one network trip:
from pydantic import BaseModel
class Ticket(BaseModel):
category: str
urgency: str
one_line_summary: strCan I still constrain the values? Category should be one of four options, urgency one of three?
Yes — system_prompt constrains the vocabulary while result_type enforces the structure. Together they give you shape validation and value guidance in one call:
def triage_ticket(text: str) -> dict:
agent = Agent(
model,
result_type=Ticket,
system_prompt=(
"Triage this support ticket. "
"Category: billing, technical, account, or feature_request. "
"Urgency: high, medium, or low."
),
)
return agent.run_sync(text).output.model_dump()Without the system_prompt, the urgency field might come back as "URGENT" or "critical" even though the shape is valid?
Right. The Pydantic model guarantees three string fields exist; the system prompt narrows what goes into those strings. Both together give you clean, routable data. .model_dump() then converts the typed Ticket instance into a plain dict you can return.
So the whole production triage pipeline — category, urgency, a searchable summary — is one function and one API call?
One call, three fields, a routable dict. Companies running support desks build their triage layer on exactly this shape. Write triage_ticket(text) now: define Ticket, build the agent with result_type=Ticket and the constraining system prompt, return .model_dump().
TL;DR: put every field you need into one Pydantic model — one agent call fills them all.
class Ticket(BaseModel) — three string fields in one containerresult_type=Ticket — one round-trip, consistent fieldssystem_prompt — constrains vocabulary inside each field| Three agents | One Ticket model | |
|---|---|---|
| Calls per ticket | 3 | 1 |
| Field consistency | Can contradict | Coherent |
| Cost | 3× tokens | 1× |
Always bundle related fields into one model when a single call can fill them.
Create a free account to get started. Paid plans unlock all tracks.