A model that writes nice paragraphs is great for a human reading a chat window. It's terrible for your code. Your code wants fields: a category, an order ID, a yes or no. And for the model to be truly useful, it often needs to do something: look up an order, check a refund rule, create a ticket.
This lesson covers both directions. Getting reliable structure out of a model, and letting a model ask your system to run functions. If you skipped the previous lesson: a model call takes text in and returns generated text, it is slow and billed per token, and the same input can produce different outputs.
Why free text breaks your code
Say Tiffin wants to route incoming support messages into queues: late_delivery, missing_item, refund, payment, other. The first attempt asks the model "Which category is this message?" and gets back:
refundRefund.The category is refund.This looks like a refund request, though it may also involve a missing item.
All four are correct. Only the first one survives if answer == "refund". And because outputs vary, a prompt that returned the clean version 99 times in testing returns the chatty version on the 100th call in production at 2am.
The fix is to stop asking for prose and start asking for data.