Five lessons layering agent calls onto search. Summaries, classifications, batches, Pydantic extractions, counts. What feels like the single most useful pattern?
The Literal constraint. Once I saw that the agent is guaranteed to return one of a fixed set of strings, every downstream if/dict/switch got simpler. No defensive .get(), no strip().lower(), no branch for weird capitalization.
That is the power of declaring the output shape upstream — defensive code disappears at the call site. Let's confirm the edges before Week 3 upgrades retrieval with embeddings and caching.
One thing I want to double-check — when I use result_type=SomeModel, is result.output still a string or something else?
Not a string. The type of result.output is always exactly what you passed as result_type — a Fact instance, a Literal string, a list, whatever. .model_dump() is the serialization step that turns a Pydantic instance into a plain dict when you want one.
Five search-plus-agent functions:
summarize_top_result — search + Agent(model).run_sync(prompt).outputclassify_result_relevance — result_type=Literal[...] two-value classifierbatch_summarize_results — for-loop agent calls, preserve orderextract_fact_from_search — result_type=Fact(BaseModel) + .model_dump()classify_all_results — Literal + counter dict for sentiment totalsKey patterns: build the agent once, reuse in the loop. result_type removes parsing. system_prompt shapes intent; result_type shapes structure.
Five lessons layering agent calls onto search. Summaries, classifications, batches, Pydantic extractions, counts. What feels like the single most useful pattern?
The Literal constraint. Once I saw that the agent is guaranteed to return one of a fixed set of strings, every downstream if/dict/switch got simpler. No defensive .get(), no strip().lower(), no branch for weird capitalization.
That is the power of declaring the output shape upstream — defensive code disappears at the call site. Let's confirm the edges before Week 3 upgrades retrieval with embeddings and caching.
One thing I want to double-check — when I use result_type=SomeModel, is result.output still a string or something else?
Not a string. The type of result.output is always exactly what you passed as result_type — a Fact instance, a Literal string, a list, whatever. .model_dump() is the serialization step that turns a Pydantic instance into a plain dict when you want one.
Five search-plus-agent functions:
summarize_top_result — search + Agent(model).run_sync(prompt).outputclassify_result_relevance — result_type=Literal[...] two-value classifierbatch_summarize_results — for-loop agent calls, preserve orderextract_fact_from_search — result_type=Fact(BaseModel) + .model_dump()classify_all_results — Literal + counter dict for sentiment totalsKey patterns: build the agent once, reuse in the loop. result_type removes parsing. system_prompt shapes intent; result_type shapes structure.
Create a free account to get started. Paid plans unlock all tracks.