Tool use and structured output
Function calling makes the model return JSON your code can use · know the contract before you build on it.
::TL;DR · the whole lesson in three lines
- MOVEFunction calling makes the model return JSON your code can use · know the contract before you build on it.
- DRILLYou will define one tool with a real schema, ask the model to call it on a real input, and validate the output · the full structured-output loop in under 20 minutes.
- WINYou have one working extraction prompt with a real schema.
::concept · what's actually happening
Tool use (also called function calling) is the mechanism by which an AI model emits structured output that your code can act on · instead of returning prose, the model returns a JSON object matching a schema you defined. The model says 'call send_email with these arguments,' your code actually sends the email.
read full concept · 4 more paragraphs →collapse concept ↑
The contract is shaped like a function signature · you describe each tool with a name, a one-paragraph description, and a JSON Schema for its arguments. The model decides when (or whether) to call a tool, and what arguments to pass. The same primitive underlies every agentic system.
Quality of the tool description is everything · the model picks tools based on what the descriptions say. A description like 'gets data' will be invoked at random. A description like 'fetches the user's current Stripe subscription status by customer email · use this when the user asks about their plan or billing' will be invoked correctly.
Structured output (the simpler cousin) does not involve calling external tools · you just ask the model to return JSON matching a schema, and you get parseable output for downstream code. Strict JSON modes (OpenAI's response_format, Anthropic's tool_use coerced as output) make this reliable.
The biggest reliability win: validate the output against your schema before you act on it. Models occasionally drift on edge cases · null where you expected a string, extra fields, missing required fields. The validation step is what separates 'works in the demo' from 'works in production at 3am.'
::drill · do the thing
You will define one tool with a real schema, ask the model to call it on a real input, and validate the output · the full structured-output loop in under 20 minutes.
::L43 drill · copy-paste into any AI chat
I want to learn structured output / tool use end-to-end with a real task of mine. The task: take this messy unstructured input · [PASTE A REAL EXAMPLE · e.g. a recipe in prose, a casual meeting note, a free-form support email] · and turn it into structured JSON I could store in a database. Walk me through: 1) propose the JSON Schema (3-7 fields, with types and which are required), 2) write the exact prompt I would send to the model to extract those fields from input like mine, 3) show me one valid output and one likely-invalid output (so I know what to guard against), 4) give me a 10-line Python or Node validator using a real schema library (Pydantic or Zod, whichever I want · I pick [LANGUAGE]). End with one concrete edge case I should test against.
::steps
- 01Pick a real unstructured input you would love to turn into structured data.
- 02Run the prompt and design the schema together.
- 03Run the extraction prompt on your real example.
- 04Validate the output against your schema using the validator code.
- 05Try the extraction on a deliberately weird input · see what breaks.
- 06Decide whether to wire this into a real workflow.
::outcome · what should be true
- You have one working extraction prompt with a real schema.
- You validated at least one output against the schema.
- You saw at least one edge case that broke or stressed the extraction.
- You can explain why tool descriptions matter for model behavior.
::trap · the most common failure
Operators ask for 'JSON output' and skip the schema validation step · then ship code that crashes the first time the model returns a slightly-off field name. The schema is the contract. Without validation, the contract is unenforced.
::end of the curriculum
You're at Pilot level. There's no Level 6.
The next move is doing the work, not another lesson. If you want operator-grade infrastructure, that's /orangebox. If you want the lab's working journal, /founders-view. If you want to collaborate on the curriculum itself, the source is public on GitHub.
::other lessons at Operator level
Local AI · Ollama — privacy, offline, and the limit of free
At Operator level you need an honest opinion about local-only AI. Even if you don't use it daily, you should have run it once.
Model routing — switching between Claude, GPT, Gemini mid-task
Operators don't pick one AI. They route each task to the model that does it best. Knowing the strengths is the skill.
MCP servers — the plug socket that turned AI into a real tool
Model Context Protocol is the standard plug. Knowing what plugs in changes what your AI can actually touch — your files, your inbox, your calendar, your repos.
Agent mode — when AI takes action, not just answers
The frontier of useful AI is agents that DO things — browse, click, file, send. The actual skill is the safety pattern, not the magic.
Computer use — when AI takes the mouse and keyboard
Claude in Chrome, ChatGPT Atlas, computer-use beta — the frontier is AI that drives your browser like a human. Knowing the safety pattern is the actual skill.
What AI cannot replace — taste, judgment, relationships
The operators winning in 2026 are the ones who learned what AI is for and what is theirs. Knowing the line is more valuable than any prompt.
Agents 101: model plus tools plus loop
An agent is a model with tools running in a loop until done · know when you need one and when you don't.
MCP: structured tools for AI
Model Context Protocol is the USB-C of AI tooling · learn the shape before you wire anything.
Skill primers: teach a session your context in 30 seconds
A skill is a reusable file that primes a fresh AI session with your project, voice, and rules · stop re-explaining yourself.
Local models with Ollama
Run Llama, Qwen, or Mistral on your own laptop · no API, no logs, no monthly bill for the work that should stay home.
Vision models: when to use them
Vision lets the model see images · powerful for screenshots and diagrams · weak for precise spatial work · know the line.
Audio and Whisper transcription
Whisper turns audio into text · meetings, voice memos, interviews · the AI-era replacement for note-taking.
RAG vs long context: when to retrieve, when to dump
RAG fetches the right slice of your data at query time · long context stuffs everything in · know which problem you actually have.
Embeddings: meaning as numbers
An embedding is a list of numbers that captures the meaning of text · learn the shape and you unlock semantic search, deduplication, and clustering.
Fine-tuning vs prompt engineering
For individuals, fine-tuning is almost never worth it · know exactly when it actually is.
AI safety in personal use
PII, NDAs, financial data, and other people's secrets · know the rules of what you do not paste.
Multimodal prompting: combining text, image, audio
The strongest prompts use the medium that fits the question · sometimes you describe, sometimes you show, sometimes you do both.
Chain-of-thought: making the model show its work
Asking the model to reason step-by-step before answering raises accuracy on hard problems · know when it earns its cost.
Cost optimization: tokens, caching, model selection
AI is metered · the operators who stay profitable measure what they spend and choose the model that fits the task.
::part of the AtomEons /learn curriculum · 45 lessons · 5 levels · cc-by 4.0