Structured Outputs and Tool Calls

A chat answer is text for people. Software needs more. It needs a fixed shape it can read. It also needs a way to ask the world for things, such as weather or an order status. Both companies solve this with two features. Structured outputs give answers in a set shape. Tool calls let the model ask your code to do something.

Structured outputs

You give the model a schema. A schema is a plan of the fields you want and their types. The model then must follow it. OpenAI describes the difference clearly. JSON mode only promises valid JSON. Structured outputs promise that the JSON matches your schema.

• Required fields are always there.
• A field that must be one of three words will be one of those three.
• You do not need to retry because the shape was wrong.

Return an object with:
  category   one of: billing, delivery, other
  urgent     true or false
  summary    text, one sentence

Tool calls in plain steps

Tool use is also called function calling. Both docs describe the same loop.

Write tool descriptions like a good label

• Use a clear name and say what the tool does and when to use it.
• Describe each input and its format. Add an example when mistakes repeat.
• Use fixed choices where you can, so bad values are hard to send.
• Do not ask the model for things your code already knows, such as an ID from a previous step.
• If two tools are always used together, merge them.
• Keep the list short. The OpenAI docs suggest staying below about twenty.

Check for the unexpected

• The model may refuse a request for safety reasons. A refusal might not match your schema, so your code must check.
• A reply can be cut off at the length limit. Check that it finished.
• The model will try to fit any input into the schema. Tell it what to do when the input makes no sense.

A small example

Imagine a support tool. A customer writes in. You want the model to label the message and then look up the order. First, a structured output labels the message as billing, delivery or other. Your code reads that label with no guessing. Next, a tool call asks your system for the order status. The model then writes a friendly reply from the real data.

Notice the split. The model handles language. Your code handles facts and actions. This split makes the whole system easier to test and to trust.

When something fails, look at each step alone. Was the label right? Was the tool called with the right inputs? Was the reply true to the data? Small steps are easier to fix than one big blur.