Class 3 · Add intelligence, then prove it works
By the end of this session QuoteDesk reads a pasted customer message into a table of order lines, answers policy questions from company documents, and your team can show a test set with results before and after a guardrail.
- Read the topics in order. Each one opens with a guiding question, explains the idea with the Cerro Azul case, gives you one simulator to play with, one “In the business” note and a short practice set.
- The simulators are safe. Predict what will happen before you move a slider, then check.
- The build lab is what your team does in the 120-minute block. The prompts are meant to be copied and adapted.
- The lab checklist is saved in your browser, so you can pick it up between sessions.
- Prices and token counts on this page are illustrative. They change every few months; the reasoning does not.
What you will be able to do
- Explain what happens in one model call: tokens in, tokens out, latency, cost, and why the instructions you write are paid for on every request.
- Estimate the monthly cost of an AI feature and compare it with the value of the time it saves.
- Choose the right pattern (classification, extraction, summarization, assistant) for a business task, and say how each one is tested.
- Explain when retrieval over company documents is needed, how it fails, and what it costs.
- Build a test set of 20 to 30 real examples, run it, and report a pass rate.
- Add one guardrail and show, with numbers, what it changed.
Route of the session
- 25 min1One model call, and what you pay forsimulator · 3 questions
- 15 min2Four patterns that cover most business casessimulator · 2 questions
- 20 min3Answering from company documents (retrieval)simulator · 2 questions
- 20 min4Agents and automations: when autonomy is worth its risk2 questions
- 20 min5Prove it works: test sets and guardrailssimulator · 3 questions
- ☕Break. Open the 20 to 30 examples you collected as pre-work.
- 120 min6Build lab: the AI feature, the test set, the guardrailteam build · checklist
- 45 minCritique: two teams report their pass rate before and after the guardrail
Topic 1 · One model call, and what you pay for
Guiding question: when QuoteDesk "uses AI" to read a customer's message, what exactly is sent, what comes back, and what does it cost?
Until now QuoteDesk stored what a rep typed. Today it starts reading. A customer of Cerro Azul writes on WhatsApp: “hola, necesito 20 cajas de aceite 900cc, 5 sacos de arroz y lo de siempre de lácteos para el jueves”. The rep pastes it into QuoteDesk, and the app sends it to a language model together with a short set of instructions. The model sends back a table: product, quantity, unit, and how confident it is about each line.
That round trip is a model call, and it is the unit everything else is measured in. Three things matter about it:
- Tokens. The model does not read words, it reads tokens, roughly three quarters of a word in English and a bit less in Spanish. You pay for tokens going in (your instructions plus the message) and tokens coming out (the table). Long instructions are paid for on every call, which is why a two-page system prompt is an expense, not a free lunch.
- Latency. A call takes between half a second and several seconds depending on the model and the length of the answer. For a rep pasting a message, three seconds is fine. For a page that fires ten calls, it is not.
- Model size. Small, medium and large models of the same family differ in price by roughly ten to fifty times, in speed by a few times, and in quality by a few percentage points. The right default is the smallest model that passes your test set, not the largest one that exists.
The fourth thing to notice is the shape of the answer. QuoteDesk does not want a chatty paragraph; it wants a table it can put into a quote. Asking the model for structured output (a fixed set of fields, one per line) is what turns a chatbot into a feature. The confidence column is the part you will use for the guardrail in Topic 5.
A single call costs a fraction of a cent. That number is not the decision. The decision is the cost of a month of calls against the value of a month of rep time, and the quality of the output. Managers who stop at “it is cheap” tend to ship a feature nobody trusts; managers who stop at “it is expensive” tend to compare the wrong numbers. The next simulator puts both on the same chart.
Practice · Topic 1
QuoteDesk's instructions to the model grow from 120 to 1,200 tokens after the team adds every edge case they can think of. What happens to the monthly bill?
The instructions (the system prompt) travel with every message. At 2,000 requests a month, a thousand extra tokens each is two million tokens, paid again next month. Keep instructions short and put the edge cases into the test set instead.
The large model scores 97% on the test set and the small model scores 86%. The medium model scores 94% at a fifth of the large model's price. Which should QuoteDesk use first?
Price differences between model sizes are large; quality differences are often small once a guardrail catches the uncertain lines. Start with the medium model, measure, and only pay for the large one if the test set says you must.
Why does QuoteDesk ask the model for a table with fixed fields instead of a free-text answer?
A paragraph needs a human to read it; a table with product, quantity, unit and confidence feeds the quote, the database and the evaluation. Structured output is what makes the feature testable.
Topic 2 · Four patterns that cover most business cases
Guiding question: there are thousands of "AI use cases". How many kinds of thing are you actually asking the model to do?
Four, most of the time. Naming the pattern before you build is useful because each pattern has a different way of being tested, a different failure mode, and a different conversation with the assistant.
| Pattern | What goes in | What comes out | How you test it | Cerro Azul example |
|---|---|---|---|---|
| Classification | one item | one label from a fixed list | count the labels that match | route an email to sales, billing or logistics |
| Extraction | unstructured text or a document | a table with fixed fields | compare field by field | order lines from a pasted message |
| Summarization | many items | one short text for a human | a reader judges it with a rubric | Monday digest of the week’s complaints |
| Assistant | an open question plus context | a conversational answer | a set of questions with expected answers | “what is the delivery policy for Rancagua on Saturday?” |
QuoteDesk’s first feature is extraction. The pasted message goes in; product, quantity, unit and confidence come out. The failure mode is specific: inventing a product that was not mentioned, or guessing a quantity. “Lo de siempre de lácteos” (“the usual dairy”) is the interesting line: a good extraction does not guess, it returns the line with low confidence so a rep looks at it.
The pattern also tells the assistant what to build. Saying “add AI to the quote page” produces a chat box. Saying “add an extraction step: when the rep pastes a message, call the model with these instructions, expect this table, show it in the form with the low-confidence lines highlighted” produces a feature.
Most “AI transformation” roadmaps are a list of these four patterns applied to different documents and queues. When a vendor or a colleague proposes a use case, ask which pattern it is. If they cannot say, they have not yet thought about how it will be tested.
Practice · Topic 2
The returns team wants "AI to handle returns of perishable goods". The first thing the model would need to do is decide, for each incoming message, whether it is a return request at all. What pattern is that?
"Handle returns" is a workflow made of several patterns: classify the message, extract the product and the reason, then maybe draft a reply with an assistant. Separate them and each piece becomes small, testable and cheap.
Which pattern is hardest to test automatically?
A summary can be accurate, complete and useless, or incomplete and exactly what the manager needed. Test summaries with a short rubric (nothing invented, the three biggest issues present, under 120 words) read by a person, not by a script.
Topic 3 · Answering from company documents (retrieval)
Guiding question: the model has read most of the internet, but it has never read Cerro Azul's delivery policy. How does QuoteDesk answer "can we deliver to Rancagua on Saturday?"
A model answers from what it learned during training plus what you put in the request. Cerro Azul’s policies, price lists and customer history were never in the training data. If a rep asks a bare model about Saturday deliveries, it will produce a fluent, confident sentence built from what delivery policies usually look like. That is a hallucination, and the dangerous part is that it reads exactly like a correct answer.
The fix is simple to describe: before calling the model, search the company’s documents for the passages most related to the question, and attach the best few to the request. The model then answers from those passages and cites them. This is called retrieval, or RAG (retrieval-augmented generation). It needs three things the assistant can build for you in an afternoon:
- The documents split into chunks of a few hundred words (a policy section, a price-list page).
- A way to find the chunks most similar to a question (an embedding, a numeric fingerprint of meaning, stored in the database).
- Instructions that say: answer only from the attached passages, cite them, and say “I don’t know” when they do not cover the question.
Retrieval is needed when the answer lives in documents that change (policies, prices, contracts). It is not needed to extract order lines from a message, because everything the model needs is in the message. Do not add retrieval because it sounds advanced; add it because the question cannot be answered without the documents.
How it fails is as important as how it works. The right chunk may not be in the top few results (a recall problem). The chunks may be stale (the October price list when November is out). Too many chunks cost tokens and confuse the model with irrelevant passages. The simulator shows the trade-off.
A citation is a trust device, not decoration. When QuoteDesk answers “[policy-04]” the rep can click and read the policy in ten seconds. A sales manager who insists on citations in every document-based answer is not being pedantic; they are the reason the assistant stays in use after the first wrong answer.
Practice · Topic 3
Which QuoteDesk feature needs retrieval?
Retrieval is for answers that live in documents the model has never seen and that change over time. Policies, prices and contracts qualify; a message that contains its own answer does not.
The assistant answered a price question correctly in testing. A month later it quotes last month's price. What is the most likely cause?
Retrieval is only as fresh as the documents behind it. Someone owns the re-indexing, on a schedule or on every change. Put that owner's name in your risk memo.
Topic 4 · Agents and automations: when autonomy is worth its risk
Guiding question: if the model can read the message and answer policy questions, why not let it create the quote, check stock and send it to the customer by itself?
Because each of those steps is an action, and actions have consequences that a wrong word in a chat does not. An agent is a model that is allowed to call tools: look up stock, create a record, send an email, run a search, and then decide what to do next based on the result. The same assistant you build QuoteDesk with is an agent; that is why it can create files and run your app.
Agents are useful when the task is a chain of small decisions over tools you already have. They are risky in proportion to three things:
- Blast radius. A wrong extraction shows a wrong line in a form a rep will see. A wrong email goes to a customer. A wrong price change goes to 1,800 customers.
- Reversibility. Drafting is reversible; sending is not. Reading stock is reversible; reserving it is not.
- Volume. An agent that acts a thousand times a day repeats its mistakes a thousand times a day.
The practical rule for a first product: let the model propose, let a person approve, and let the system execute only the approved action. QuoteDesk’s extraction already follows it: the table is a proposal, the rep confirms, the quote is created. Full autonomy is something you earn with a test set and months of logs, not something you switch on because the demo looked good.
A useful word to know: tool calling. It means the model does not send the email itself; it returns a structured request (“send_email to X with body Y”) and your app decides whether to run it. That boundary is where every guardrail for agents lives.
The dental clinic case makes the rule obvious. An assistant that triages appointment requests and suggests a slot is fine. An assistant that books, cancels and moves appointments on its own without a receptionist’s approval will, on a bad day, cancel the wrong patient. Same model, different blast radius.
Practice · Topic 4
Which of these QuoteDesk actions should stay behind a rep's approval the longest?
Sending is irreversible, customer-facing and repeated hundreds of times a month. Propose, approve, execute: the model proposes the quote, the rep approves, the system sends.
What does "tool calling" mean for the manager who owns QuoteDesk?
The boundary between "the model wants to do X" and "the app does X" is where you put approvals, limits and logs. Ask the assistant to show you that boundary in your own app.
Topic 5 · Prove it works: test sets and guardrails
Guiding question: the extraction worked on the three messages you tried in class. How do you know it works on the next 3,000?
You do not, until you measure. The habit that separates a demo from a feature is the test set: a list of real inputs with the answer a good rep would give, that you run every time something changes (the model, the instructions, the chunks). For QuoteDesk that is 20 to 30 real customer messages and, for each one, the table of lines the rep would have typed. Your pre-work was to collect them.
Running the set gives you a pass rate: how many messages came out exactly right. The first number is usually humbling. The three questions that follow are what matter:
- Where does it fail? Nearly always on the same kind of message: abbreviations, “the usual”, two products in one line, a quantity written in words.
- Does the model know when it is unsure? If the confidence it reports is low on the lines it gets wrong, you can use it.
- What does a guardrail change? A guardrail is a rule outside the model: flag lines with confidence below a threshold for a rep to review; refuse to create a quote with a product not in the catalog; never apply a discount the model proposes. Each one trades silent errors for review work.
The second kind of failure is a hallucination: a product that was not in the message, a quantity invented to fill a gap. Count them separately; a single invented line in a quote costs more trust than ten lines flagged for review.
Keep a human in the loop at the point where a wrong answer would reach a customer. The loop is not a sign the feature failed; it is the design. As the pass rate climbs and the logs accumulate, you lower the threshold and the reps review less.
A pass rate is a number you can put in front of the commercial manager: “the extraction is right on 21 of 24 messages, the three misses are flagged, and the reps review four messages a day instead of retyping ninety.” That sentence wins the budget. “It uses AI” does not.
Practice · Topic 5
Your team's test set has 24 messages, all written by the team during the session. What is the problem?
Collect real messages (anonymized) from the reps' phones and the shared inbox. The abbreviations, typos and "lo de siempre" are exactly what the model must handle.
After adding a guardrail that flags low-confidence lines, the number of wrong quotes dropped from 6 to 1, and 7 of 24 messages now go to review. The sales manager says the review work is too much. What do you do?
A guardrail is a dial, not a switch. The threshold is a business decision (how many wrong quotes per month is acceptable versus how many minutes of review) and the test set is how you make it with numbers instead of opinions.
Which failure should count as the most serious in QuoteDesk's test set?
An invented line with high confidence slips past every guardrail based on confidence and ends up in a quote. Count hallucinations separately and treat even one as a reason to tighten the instructions ("do not invent products; return low confidence instead").
Build lab · The AI feature, the test set, the guardrail
What your team builds in the next 120 minutes
Teams of 2 to 3 · the instructor circulates · save a checkpoint every 20 minutes
- Pick the one capability that matters most to your user (10 min). Name its pattern: classification, extraction, summarization or assistant. If you cannot name it, split the idea until you can. Write one sentence: "When the user does X, the app sends Y to the model and shows Z."
- Get a model key into your app the right way (10 min). Ask the assistant to add the model provider, store the key as a server-side secret (never in the page), and confirm with a test call from the app. Set a monthly spending limit in the provider's dashboard before you go further.
- Write the instructions and the output shape (15 min). Use the first prompt below. Keep the instructions under 200 words. Ask for structured output with a confidence field on every item, and an explicit rule not to invent.
- Build the feature in the smallest step that works (20 min). One screen, one call, the result shown next to the original input so the user can compare. Save a checkpoint when it works on one real example.
- Load your 20 to 30 real examples as a test set (15 min). Use the second prompt below. Each example needs the input and the expected answer. Ask the assistant to build a page or a script that runs all of them and reports pass / fail per example.
- Run it and write down the pass rate (10 min). Look at every failure. Group them: abbreviations, missing information, invented items, wrong quantity. Count hallucinations separately.
- Add one guardrail (15 min). The most common: flag items below a confidence threshold for human review; refuse items not in a known list; never let the model set a price or discount. Pick the one that addresses your biggest failure group.
- Run the test set again (10 min). Record pass rate, hallucinations, and how many examples now go to review. These three numbers are what you present in the critique.
- Only if it needs documents: add retrieval (15 min). Ask the assistant to chunk two or three real documents, store them, and attach the top three chunks to the request, with citations in the answer. Add five document questions to your test set.
- Save, deploy, and write the build log entry: what the model got wrong, what you decided about the threshold, and what the assistant did that you did not expect.
Weak
"Add AI to the quote page so it understands the customer messages."
The assistant will build a chat box. Nobody said what goes in, what comes out, or what happens with the result.
Strong
"When the rep pastes a message and clicks Read, call the model with these instructions, expect this table, show it under the message with low-confidence rows in amber, and save only after the rep confirms."
Pattern named, output shape fixed, human in the loop, nothing to guess.
That last question is yours to answer, not the assistant’s. Adding abbreviations to the instructions costs tokens on every call and fixes three cases; raising the threshold costs review time and catches cases you have not seen yet. Decide, write the reason in the build log, and re-run.
- The capability is named with its pattern and one sentence: when the user does X, the app sends Y and shows Z.
- The model key is a server-side secret and a monthly spending limit is set in the provider's dashboard.
- Instructions are under 200 words, ask for structured output with a confidence field, and forbid inventing items.
- The feature works end to end on one real example and the user can edit the result before anything is saved.
- The test set has at least 20 real, anonymized examples with expected answers.
- First run: pass rate and number of invented items are written in the build log.
- One guardrail is added and the reason for choosing it is written down.
- Second run: pass rate, invented items and review count are recorded next to the first run.
- If retrieval was added: documents chunked, citations shown, five document questions in the test set.
- Deployed, checkpoint saved, build log entry written by each member.
Critique and reflection
Two teams present for five minutes each: the feature working on one real example, then the evaluation page with the numbers from the first run and from the run after the guardrail. The class scores with the rubric; the criterion in focus is AI quality and safety: is the capability useful to the named user, is it evaluated with real examples, and is there a guardrail where a wrong answer would reach a customer?
Questions the class should ask the presenting teams:
- How many of the test examples are real messages, and where did they come from?
- Which failure group is the largest, and did the guardrail address it?
- How many examples now go to a human, and who is that human in the real workflow?
- Did the model ever invent something? What stopped it, or what will?
Build-log reflection prompt for everyone, written before leaving: What did the first pass rate make you feel, and what did you decide because of it? Was there a moment where the assistant proposed a fix and you had to say no?
Before next session
Milestone M3 (team, 25%, due before session 5): the AI feature in production, the test set with its results before and after the guardrail, and a two-page risk memo. The memo is completed after session 4, which covers security, data, cost and maintainability; start a draft now with the numbers from today.
Pre-work for session 4 (60 min):
- Read the summary of the OWASP Top 10 for LLM Applications 2025 and the course note on Chile’s Ley 21.719 on personal data.
- Run the course security checklist on your own app and bring the results. Expect to find at least one issue; everyone does.
- Note the monthly spending limit you set today and the cost of your test-set run. You will scale those numbers in class.
Summary
- A model call is tokens in, tokens out, latency and cost. The instructions you write are paid for on every call; keep them short.
- Decide model size with the test set: the smallest model that passes your bar, not the largest that exists.
- Four patterns cover most business cases: classification, extraction, summarization, assistant. The pattern decides how you test it.
- Structured output turns a chatbot into a feature: a table with fields you can put in a quote and score automatically.
- Retrieval is for answers that live in documents the model has never seen. It needs chunks, search and citations, and someone who owns re-indexing.
- Agents act. Let the model propose, a person approve, the system execute; earn autonomy with logs, do not switch it on.
- A test set of real examples with expected answers is the difference between a demo and a feature. Report pass rate and hallucinations separately.
- A guardrail trades silent errors for review work. The threshold is a business decision made with numbers from the test set.