Week 1 gave you string outputs — summaries, sentiment labels, chained classifiers. One gap: a string with 'positive' in it is not the same as a typed value you can use as a dict key or a database field. That gap closes this week.
I noticed it in summarize_then_classify — the sentiment label came back, but I had to be careful about casing. If the model decided to say 'Positive' instead of 'positive', my if-statement would break.
result_type=Literal['positive','negative','neutral'] — the type system enforces the exact value. The model cannot return 'Positive' or 'POSITIVE'. This week you build the structured output toolkit: typed contacts, Literal enums, list extraction, multi-field Pydantic models. By Friday, AI output is data you can pipe directly into your CRM, not strings you need to parse.
What's the difference between a Pydantic model and a plain dict? Why not just return a dict?
The model fills in the Pydantic fields from unstructured text — you define the schema, the AI does the extraction. A plain dict has no schema the AI can target. result_type=Contact tells the agent exactly what to extract and validates the result. If a required field is missing, it fails loudly instead of returning incomplete data silently.
Week 1: Agent(model).run_sync(text).output → free-form string.
Week 2: Agent(model, result_type=MyModel).run_sync(text).output → typed Python object.
A Lead object with typed fields is directly serialisable and passable to any function. A prose string is not.
Create a free account to get started. Paid plans unlock all tracks.
Week 1 gave you string outputs — summaries, sentiment labels, chained classifiers. One gap: a string with 'positive' in it is not the same as a typed value you can use as a dict key or a database field. That gap closes this week.
I noticed it in summarize_then_classify — the sentiment label came back, but I had to be careful about casing. If the model decided to say 'Positive' instead of 'positive', my if-statement would break.
result_type=Literal['positive','negative','neutral'] — the type system enforces the exact value. The model cannot return 'Positive' or 'POSITIVE'. This week you build the structured output toolkit: typed contacts, Literal enums, list extraction, multi-field Pydantic models. By Friday, AI output is data you can pipe directly into your CRM, not strings you need to parse.
What's the difference between a Pydantic model and a plain dict? Why not just return a dict?
The model fills in the Pydantic fields from unstructured text — you define the schema, the AI does the extraction. A plain dict has no schema the AI can target. result_type=Contact tells the agent exactly what to extract and validates the result. If a required field is missing, it fails loudly instead of returning incomplete data silently.
Week 1: Agent(model).run_sync(text).output → free-form string.
Week 2: Agent(model, result_type=MyModel).run_sync(text).output → typed Python object.
A Lead object with typed fields is directly serialisable and passable to any function. A prose string is not.