CSE Roadmap

Core tier · about 6 hours · 7 parts

Part 1 of 7 · 3 min read

Overview

In this module you will

  • Explain why a program cannot use a model's sentences directly, and what a schema is.
  • Describe the data you want once, as a small Python class, and check any reply against it.
  • Pull JSON out of messy model text, repair the harmless slips, and refuse to guess at the rest.
  • Ask the model again with the exact error message, and stop after a fixed number of tries.
  • Measure how often the whole process gives you valid data.

Why this matters for agents

A person can read "this looks urgent, probably billing". A program cannot. A program needs priority to be exactly one of low, normal or high, so that it can decide what to do next.

An agent is a program that keeps asking a model for its next step. Each answer must become something code can act on: which tool to call, which route to take, which record to save. If the answer arrives in the wrong shape, the agent crashes, or worse, it acts on a wrong value that happened to look fine. Structured output is the work of making that hand-over reliable.

The problem: a program needs data, not sentences

A language model produces text, one piece at a time. It does not produce data. Ask it to classify a support message and you may get any of these:

  • This looks like a billing problem and it seems fairly urgent.
  • Sure! Here is the ticket: {"category": "billing", ...} Let me know if you need anything else.
  • {"category": "billing", "priority": "urgent", ...}

All three are reasonable answers for a person. Only a shape your code can check is useful to a program.

JSON

A plain-text format for data that almost every language can read. It looks like this: {"category": "billing", "priority": "high", "needs_human": true}. Curly braces hold an object. Inside are names in double quotes, each followed by a colon and a value. Values can be text (in double quotes), numbers, true or false, lists in square brackets, or more objects. You met JSON in Level 0, module 3.

Schema

A written description of the shape that data must have: which fields exist, what type each one is, which values are allowed, and which fields are required. A schema is the form; a reply is the filled-in form. Validating means checking that the form was filled in correctly.

So the goal is simple to say: ask for JSON that matches a schema, and check it before using it. The checking matters because models are not reliable. Asking for JSON only makes it more likely that the text is JSON. The usual failures are:

  • Extra words around the JSON, such as "Sure! Here is..." or a code fence (three backticks).
  • Small syntax slips, such as a comma after the last item, or single quotes instead of double quotes.
  • Wrong content: a value that is not allowed ("urgent"), text where true or false belongs, or a field that is missing.
  • A reply that stops halfway, because it hit the length limit. The braces never close. (The stop reason you saw in module 1 tells you this happened.)
  • A refusal or an apology instead of JSON.

Check yourself

  • Why can a program not use "this looks urgent" as a priority?
  • What is the difference between JSON and a schema?
  • Name two ways a model's reply can fail to be valid JSON.