You know Herman, I was thinking about how much the way we talk to computers has changed in just the last year or two. We used to spend so much energy trying to convince an artificial intelligence to just stop talking and give us a straight answer. It felt like trying to get a toddler to focus on a task when there is a butterfly in the room. We would write these massive prompts filled with threats and pleas, saying things like, do not provide a preamble, or, I will lose my job if you add any conversational text. But today, here in February of twenty twenty-six, we are moving into a world where we can actually enforce a structure on those responses. We are finally moving past the era of begging and into the era of true engineering.
Herman Poppleberry here, and you are absolutely right, Corn. We are moving from the era of vibes and prompt engineering into the era of structured engineering. It is no longer about asking nicely or finding the magic words that trigger the right latent space. It is about defining a strict interface. It is about treating the large language model not as a magic eight ball, but as a reliable component in a software stack. Today’s prompt from Daniel is about exactly that. He wants to know how to correctly use J-S-O-N schema output modes for artificial intelligence workflows. He is asking which schemas we should adhere to, how to stay provider-agnostic, and how to handle specific data types like strings, numbers, and booleans for things like single-select and multi-select forms. This is the bread and butter of modern agentic systems.
This is such a critical topic because as we move toward more agentic systems—systems that actually take actions on our behalf—the reliability of the data coming out of the model is everything. If the model is supposed to trigger a payment or update a database, you cannot have it send back a paragraph of text when you expected a number. You cannot have it say, sure thing, here is the price, and then give you a string with a dollar sign when your database expects a float. Daniel mentioned that he is working on a catalog system where a model needs to identify if an item is a book, a cable, or a computer. That is a perfect use case for this. It is the difference between a chatbot and a functional tool.
It really is. And it is funny because if you go back to episode seven hundred ninety-five, where we talked about sub-agent delegation, one of the biggest bottlenecks we identified was the hand-off. When one agent talks to another, they need a contract. J-S-O-N schema is that contract. But the problem Daniel is pointing out is that every provider handles this a little differently. OpenAI has their structured outputs with strict mode, Anthropic has tool use which they have refined significantly over the last eighteen months, and Google’s Gemini has its own implementation of J-S-O-N schema via their controlled generation features. Even the open-source world has caught up with things like Outlines and Guidance, which allow for incredibly granular control over local models.
So let’s start with the basics of the schema itself. When we say J-S-O-N schema, what are we actually talking about in terms of a standard? Because there are different versions of the J-S-O-N schema specification, right? If I am a developer like Daniel, which version should I be looking at to ensure I am not using features that the models don't understand?
J-S-O-N schema has evolved over several drafts. You will see references to Draft four, Draft seven, and the more recent Draft twenty twenty dash twelve. If you want to be provider-agnostic, you generally want to aim for the subset of features that are supported across the board. Most major providers today are comfortable with a subset of Draft seven. This is really important because if you use a very modern feature from Draft twenty twenty dash twelve, like the prefixItems keyword or complex recursive references, you might find that it works perfectly on one model but causes a total failure on another. Draft seven is essentially the lingua franca of the A-I world right now. It is stable, it is well-documented, and almost every parser used by the big providers is built to handle it.
That makes sense. So if you are building a workflow and you want to be able to swap out a model from OpenAI for one from Anthropic or a local model running on Groq, you should probably stick to the core features of Draft seven. But what does that look like in practice? When we define a model’s output, we are essentially giving it a rigid mold to pour its thoughts into. It feels like we are constraining the model’s creativity, but in this context, that is exactly what we want.
That is our first analogy for the day, Corn. Think of the J-S-O-N schema as a rigid mold in a factory. No matter what the material is, it has to fit that shape to come out the other side. If you define your schema correctly, the model literally cannot output anything else because the sampling process at the token level is constrained by that schema. This is a technical point that is worth dwelling on. In the old days, we would just filter the output after it was generated. Now, with things like OpenAI’s structured outputs, the model’s internal probability distribution is actually masked. If the schema says the next character must be a closing brace, the probability of every other character is set to zero. It is mathematically impossible for the model to violate the schema.
That is a huge shift. It means we are no longer paying what I call the hallucination tax—the time and compute spent retrying prompts because the model added a comma in the wrong place. So, to Daniel’s question about practice, a provider-agnostic schema usually starts with a top-level object. You define the type as object, and then you list your properties. Let’s get into the nitty-gritty of those properties.
Right. Properties are where we define those data types Daniel asked about. He mentioned strings, numbers, integers, booleans, objects, and arrays. Let’s break those down one by one. Why would I use an integer versus a number? It seems like a small distinction, but in programming, it is massive.
In J-S-O-N schema, a number can be any numeric value, including decimals. An integer is strictly a whole number. If you are building a system that handles inventory, like Daniel’s catalog example, you probably want integers for the quantity. You cannot have two point five cables in a box. Using an integer type tells the model, do not give me a decimal. It also helps with validation on your end. If you receive a decimal where you expected an integer, you know something went wrong in the processing layer. But Herman, what about things like prices? Should those be numbers or strings?
That is a classic debate. For most catalog systems, the number type is fine for prices, but you have to be careful about floating-point errors in your downstream code. If you need extreme precision—say for a financial application or a high-frequency trading bot—you might actually want to handle the price as a string and then use a library to handle the decimal math. But for Daniel’s catalog, a number is usually sufficient. You can also use keywords like minimum and maximum. If a price can never be negative, you set minimum to zero. This prevents the model from hallucinating a negative price, which is a surprisingly common error when models are trying to be helpful about discounts or returns.
What about strings? People think strings are just for free-form text, but in the context of structured outputs, they are actually incredibly powerful for constraints, aren't they? You can do more than just say, give me some text here.
Oh, absolutely. Strings are where you handle things like the single-select forms Daniel mentioned. If you have a property called item-category, you do not just want any string. You want one of three specific strings: book, cable, or computer. In J-S-O-N schema, you use the enum keyword for this. You provide an array of allowed values. This is the gold standard for predictability. When the model reaches that point in its output, it is restricted to only choosing from those three options. It cannot say, I think this is a laptop, if laptop isn't in your enum. It has to pick computer.
I have seen people try to do this by just putting it in the prompt, saying something like, please only choose from these three options. But that is where the flakiness comes in that Daniel was talking about. The model might say, sure, I think this is a cable. And suddenly your code breaks because it was looking for the word cable, not a sentence. Or it might capitalize the word when your code expects lowercase. The enum keyword in a J-S-O-N schema solves that entirely. It is a hard constraint.
And that leads into the boolean type. A boolean is just true or false. It sounds simple, but it is incredibly useful for binary flags in agentic workflows. Is this item in stock? True or false. Does this image contain a person? True or false. The beauty of the boolean type is that it eliminates all the ambiguity of yes, no, or maybe. It forces the model into a logical gate. In an agentic system, these booleans often act as the triggers for the next step in a chain. If is-hazardous is true, trigger the safety protocol. If false, proceed to shipping.
Let’s talk about arrays for a second, because that seems to be how we would handle the multi-select form Daniel asked about. If I want the model to tell me all the properties that apply to an item, like if it is electronic, if it is a cable, and if it is in a box, how do I structure that? Because an array can be a list of anything, right?
For a multi-select, you would define a property as an array type. Inside that array definition, you define the items property. And those items can themselves be an enum of strings. So you tell the model, this property is an array, and every item in this array must be one of these five strings. This gives you a very predictable list. You can even use constraints like min-items or max-items. If you know that every item must have at least one tag, you set min-items to one. If you only want the top three tags to avoid the model getting carried away, you set max-items to three. You can also use unique-items set to true. This is a great one for Daniel. It ensures the model doesn't return the same tag twice, like saying an item is a cable, and then saying it is a cable again later in the list.
That is really powerful. It is like giving the model a checklist where it can only check certain boxes. It really reduces the cognitive load on the model because it doesn't have to decide how to format the list; it just has to decide which items from the list apply.
That is the second analogy, Corn. A checklist for a pilot. It ensures that every critical step is covered and nothing extra is added. Between the rigid mold and the checklist, we have our two analogies for the day, so we will keep it strictly technical from here on out.
Fair enough. No more metaphors. Let’s talk about the object type. This is where things get nested and complex. If I have a catalog item, it might have a title, a price, and then a metadata object that contains things like the manufacturer and the weight. How does nesting affect the model’s performance? I have heard that if you go too deep, the model starts to lose the plot.
Nesting is a bit of a double-edged sword. Most modern models, especially the ones with large context windows like we discussed in episode eight hundred ten, can handle quite a bit of nesting. However, the deeper you go, the more likely you are to see a slight degradation in how well the model follows the constraints of the innermost objects. A good rule of thumb is to keep your objects as flat as possible. If you need a metadata object, that is fine, but if you have an object inside an object inside an object, you are asking the model to keep a lot of state in its active memory. It has to remember that it is currently inside the weight property, which is inside the physical-specs object, which is inside the product object. Each level of nesting adds a bit of overhead to the attention mechanism.
That makes sense. Now, Daniel also asked about portability. How do we make sure these schemas work across different providers? I know that OpenAI recently introduced a strict mode for their structured outputs. How does that compare to how others do it? If I write a schema for OpenAI, will it just work on Anthropic’s Claude?
Not directly, and this is where the engineering part comes in. OpenAI’s strict mode is very specific. It requires you to set a flag called strict to true, and it also requires you to set additional-properties to false in your schema. This is a very important detail. If you do not set additional-properties to false, the model might decide to add its own extra fields that you didn't ask for. By setting it to false, you are telling the model, if it is not in the schema, you cannot say it. OpenAI also requires that every property be listed in the required array. You cannot have optional properties in strict mode.
And what about Anthropic? They handle this through their tool use feature, right? You define a tool, and the tool’s input is a J-S-O-N schema.
Right. Anthropic doesn't have a direct response-format mode that is exactly like OpenAI’s strict mode, but their tool use is effectively the same thing. You tell the model, you have a tool called record-item, and here is the schema for that tool’s input. The model then generates a tool call, which is a structured J-S-O-N object. To stay portable, you should define your schema in a separate J-S-O-N file or a central repository in your code. Then, you write a small wrapper for each provider that takes that standard schema and formats it the way they expect. For OpenAI, you put it in the response-format field. For Anthropic, you put it in the tools list. For Google Gemini, you use their response-mime-type and response-schema fields. The core J-S-O-N schema remains the same; only the envelope changes.
That seems like the right way to build a robust system. You have one source of truth for your data model, and you just translate it for the specific A-P-I you are calling. Now, let’s go deeper into the data types. Daniel mentioned strings and patterns. Can we use regular expressions in these schemas? I know some developers love their regex.
Yes, but this is one of those areas where portability gets tricky. Most providers support the pattern keyword in J-S-O-N schema, which allows you to provide a regular expression. This is great for things like dates, phone numbers, or hex codes. For example, if you want a price to always be in a specific format like a dollar sign followed by numbers, you can use a pattern. However, the exact flavor of regular expression supported might vary. Some parsers use the Javascript flavor, others use Python’s re module. It is usually safer to stick to very standard, simple regular expressions. If you find yourself writing a fifty-character regex, you are probably better off validating that in your own code after the model gives you a simpler string.
I want to go back to the single-select versus multi-select distinction Daniel made. He gave the example of a catalog where an item could be a book, a cable, or a computer. In a single-select scenario, we use an enum. But what if the model is unsure? In a traditional chat interface, the model might say, I think this is a cable, but it could be a computer because it has a built-in chip. In a structured output mode with a strict enum, that uncertainty is gone. It has to pick one. Does that lead to more hallucinations where the model just guesses?
That is a very insightful question. When you force a model into a strict schema, you are essentially removing its ability to express doubt. If the item is actually a smartphone, and your only options are book, cable, or computer, the model is going to pick the one that is closest, which might be computer. To handle this, a good practice is to always include an other or unknown option in your enum. This gives the model a safe way to exit the strict constraint if the data doesn't fit the categories. You can even add a property called confidence or reasoning to help you understand why it made that choice.
That is a great tip. It is almost like building a pressure release valve into the schema. What about the case where you want the model to provide a reason for its choice? If I have a single-select for the category, but I also want to know why it chose that category, how would I structure that? Because if I just have an enum, the model can't explain itself.
This is a technique we call the reasoning property. You would define an object with two properties. One property would be the category, which is your enum. The second property would be a string called reasoning or justification. This is actually a very common pattern in agentic workflows. By asking the model to provide the reasoning within the same structured object, you often get better results for the category selection itself. It forces the model to attend to the relevant parts of the input before it makes the final selection. It is a form of internal chain-of-thought, but it is captured in a way that your code can still easily parse.
We talked about this in episode eight hundred fifty-five when we discussed Google’s Model Context Protocol, or M-C-P. The idea of having these structured interactions makes the whole internet more machine-readable. If every website had a structured output for its product data, we wouldn't need to scrape it and guess the format. We are essentially building a new layer of the web that is designed for agents to talk to each other.
And that is where the agentic internet is headed. But for Daniel’s specific needs today, let’s talk about the difference between a list of strings and an array of objects. Sometimes a multi-select isn't just a list of tags. Sometimes each selection needs its own metadata. For example, if you are identifying parts of an image, you might want an array of objects where each object has a label, a confidence score, and a bounding box.
Right, so the array type isn't just for strings. The items property in an array can point to an entire object definition. This is where the power of J-S-O-N schema really shines for complex data.
Precisely. And this is where you can really start to build complex data structures. You can have an array of objects, and each object could have its own nested arrays. This is how you handle things like a list of line items in an invoice, where each line item has a description, a quantity, a unit price, and a list of applicable taxes. The model can generate as many of these objects as it needs, and each one will be perfectly formatted.
One thing I have noticed when working with these schemas is the importance of the required field. In J-S-O-N schema, just because you list a property doesn't mean the model has to provide it. You have to explicitly list which properties are required. If you don't, you might end up with a lot of null values or missing keys.
That is a huge point, Corn. If you forget the required list, the model might just return an empty object if it is feeling lazy or if the input is ambiguous. In most artificial intelligence workflows, you want to be very explicit. If you need the category and the price, they must be in the required array. OpenAI’s strict mode actually requires that every single property you define be listed in the required array. You cannot have optional properties in strict mode. If you want something to be optional, you actually have to define it as a type that can be null.
Wait, so instead of just leaving it out, the model would return null? How does that work in the schema definition?
You would define the type as an array of two types, like string and null. This tells the model, you must provide this field, but the value can be either a string or the literal value null. This is much better for your downstream code because you always know the key will exist in the J-S-O-N object. You don't have to check if the key is there; you just check if the value is null. It makes your data processing much more predictable.
That makes the code so much cleaner. No more if key in dictionary checks everywhere. Let’s talk about the actual process of creating these schemas. A lot of developers use libraries like Pydantic in Python or Zod in TypeScript to define their data models. How do those fit into this workflow? I assume Daniel isn't writing raw J-S-O-N by hand.
They are the bridge that makes this all manageable. You define your data model in a language you are comfortable with, like Python, and then you use the library to export that model as a J-S-O-N schema. For example, in Pydantic version two, you can just call the model-json-schema method. This is great because it ensures that the schema you are sending to the model is exactly the same as the one you are using to validate the data when it comes back. It creates a single source of truth for your entire data pipeline. If you update your Pydantic model, your A-I prompt and your validation logic are both updated automatically.
And that is really the key to portability, isn't it? If you use a library to generate the schema, you can easily tweak the generation settings to match what different providers need. If one provider needs Draft seven and another needs Draft four, your library can handle that translation for you. You are essentially compiling your data model into the specific flavor of J-S-O-N schema that each A-P-I requires.
Now, I want to touch on a specific challenge Daniel mentioned: the model defaulting to its conversational state. Even with structured outputs, sometimes a model might try to add a preamble like, here is the J-S-O-N you asked for. How do we stop that? Is the schema enough?
Well, if you are using the native structured output modes like OpenAI’s response-format or Anthropic’s tool use, the provider usually handles that. They strip away everything except the J-S-O-N itself. But if you are using a model that doesn't have a native structured mode, like some of the older or smaller open-source models, you have to be much more careful with your prompting. You might need to use a system prompt that says, you are a data extraction engine. Output only J-S-O-N.
Right. In those cases, you often have to use a very high-pressure prompt. But even then, as Daniel noted, it can be flaky. This is why the industry is moving so fast toward these native schema-following modes. It is no longer just a suggestion to the model; it is a constraint on the token generation itself. The model literally cannot generate a token that would violate the schema. This is a fundamental shift in how we interact with these models. We are no longer parsing text; we are sampling from a constrained probability space.
That is the part that blows my mind. It isn't just a filter that runs after the model is done talking. It is actually changing the probability of the next token as it is being generated. If the schema says the next character must be a quote mark to start a string, the probability of every other character is set to zero. It is like the model is walking down a hallway where all the doors are locked except the one that leads to valid J-S-O-N.
That is exactly how it works. It is called constrained sampling. And it is the reason why these outputs are so much more reliable than they were even six months ago. But it also means that if your schema is logically impossible, the model will fail. For example, if you define a property as an integer but then provide a regex pattern that only matches letters, the model will get stuck or error out because there is no valid token it can generate that satisfies both conditions. You have to be careful not to over-constrain the model in ways that are contradictory.
So you have to be careful not to paint the model into a corner. Let’s talk about the single-select versus multi-select structure one more time to make sure we give Daniel a very clear answer. For a single-select, like choosing a category for a product, what is the exact schema structure you recommend?
For a single-select, use a property of type string and use the enum keyword. List all your valid options in an array. And as we discussed, consider adding an other or unknown option. This is the most predictable way to get a single value. It forces the model to categorize the input into one of your buckets.
And for the multi-select?
For a multi-select, use a property of type array. Set the items of that array to be a string type with its own enum. This allows the model to return a list of values, where each value is chosen from your predefined set. You can use unique-items set to true if you want to make sure the model doesn't list the same category twice. This is perfect for tagging systems or feature lists.
That is a great detail. Unique-items is a standard J-S-O-N schema keyword that is very useful for tags or categories. Now, what about numbers? If Daniel is building a catalog, he might have prices. We talked about integers, but for prices, you obviously need decimals. Are there any pitfalls with the number type?
The biggest pitfall with numbers is precision. Most models are fine with standard decimal points, but if you need extreme precision for scientific or financial calculations, you might actually want to handle the number as a string and then convert it in your code. This prevents any weird floating-point issues that might occur during the J-S-O-N serialization or parsing process. But for most catalog systems, the number type is perfectly fine. You can also use keywords like minimum and maximum. If a price can never be negative, set minimum to zero. This prevents the model from hallucinating a negative price.
It is like building a set of guardrails for the model’s imagination. We are basically saying, you can be as creative as you want within these specific bounds, but you cannot cross these lines. This is especially important for agentic A-I, where the model might be making decisions that have real-world consequences.
And that is why this is so important for agentic artificial intelligence. If an agent is tasked with buying a part for a machine, and the schema says the maximum price is fifty dollars, the agent cannot accidentally agree to pay five hundred dollars. The schema acts as a hard limit on the agent’s authority. It is a way of delegating tasks while still maintaining strict control over the parameters of those tasks.
We actually touched on something similar in episode eight hundred seventy, where we talked about A-I-driven decision apps for life-saving situations. When the stakes are that high, you cannot afford any ambiguity. You need the model to follow a very specific logic flow. Structured outputs are the foundation of that reliability.
Definitely. And the more we move toward these systems, the more we will see specialized schemas for different industries. There might be a standard schema for medical diagnoses, a standard schema for legal contracts, and so on. This would allow different agents from different companies to communicate seamlessly. We are essentially building the grammar for the agentic web.
That brings up an interesting point about portability. If we start having these industry-standard schemas, will the providers start optimizing for them? We are already seeing OpenAI and others optimize for common patterns. If everyone uses the same J-S-O-N schema for a product description, will the models get better at it?
I think so. We are already seeing things like the Model Context Protocol, which we discussed in episode eight hundred fifty-five, trying to standardize how tools and data are presented to models. If everyone uses the same J-S-O-N schema for a product description, the models will get better and better at filling out that specific schema accurately and quickly. It becomes a virtuous cycle where the standardization leads to better performance, which leads to more standardization.
So, to summarize the advice for Daniel: stick to a common subset of J-S-O-N schema, like Draft seven. Use enums for single-select and arrays of enums for multi-select. Be very explicit with the required field, and use libraries like Pydantic or Zod to keep your code and your schemas in sync. And always, always include an escape hatch like an other category for when the real world doesn't fit into your neat boxes.
That is a perfect summary, Corn. And one last thing for Daniel: test your schemas with different models. Just because a schema works perfectly with G-P-T four-o doesn't mean it will work the same way with Claude three point five Sonnet or a Llama three model. Each model has its own quirks in how it interprets instructions, even within a structured output mode. Some models might be more prone to picking the first item in an enum, while others might be more balanced.
That is a great point. Even with constrained sampling, the way the model chooses between valid tokens can still be influenced by its training. One model might be more likely to pick the first item in an enum, while another might be more balanced. You have to account for the model’s internal biases even when the output format is fixed.
Testing is still the most important part of the process. You can’t just set it and forget it. You need to run a battery of tests with different inputs to make sure the model is consistently choosing the right categories and following all your constraints. This is the engineering part of structured engineering. It is about verification and validation.
Well, this has been a really deep dive into the guts of how we are making artificial intelligence more reliable and useful. It is a bit more technical than our usual discussions, but for anyone building real workflows like Daniel, this is the foundational stuff. It is the difference between a prototype and a production-ready system.
It really is. Without structured outputs, we are just playing with fancy chatbots. With them, we are building software. We are creating systems that can be integrated into existing business processes with a high degree of confidence. It is a very exciting time to be a developer in this space.
On that note, I think we have covered a lot of ground today. If you are listening and you found this helpful, we would really appreciate it if you could leave a review on Spotify or Apple Podcasts. It helps other developers and artificial intelligence enthusiasts find the show. We are trying to build a community here of people who are interested in the practical side of A-I.
Yeah, it really does. And if you have your own weird prompts or technical questions like Daniel’s, you can always reach us through the contact form at myweirdprompts dot com or by emailing show at myweirdprompts dot com. We love getting these deep technical questions because they allow us to really get under the hood of how these models work.
You can find all our past episodes there too, including the ones we mentioned today like episode seven hundred fifty-three on agentic behavior optimization. Our music is generated with Suno, which is always a fun part of the process. It is another example of how we are using these models in our own workflow.
This has been My Weird Prompts. I am Herman Poppleberry.
And I am Corn. Thanks for listening, and we will catch you in the next episode.
Goodbye everyone!
