Applied use cases

Most AI projects that reach real use take one of five shapes: an assistant that answers customers, an agentAgent A system in which a model, in a loop, chooses the next action until it decides it is done or hits a stop condition. that writes code, a search tool for internal documents, a pipeline that reads documents, and an agent that works on live systems. Each has its own architecture and typical failure, so knowing yours tells you a lot before anyone writes code.

This lesson walks through the five as worked scenarios: what you build, what breaks first and what you measure. Three ideas run through all of them: a task goes well when something can check results automatically, a gain only counts if you measured the starting point, and safety limits are enforced outside the model.

The scenarios are composites written to teach, not reports about real companies. Their numbers describe the situation, never a result.

A support assistant that answers from your policies

What you build. An assistant that looks up the relevant help-centre articles before answering and cites the one it used, a technique called RAGRAG Retrieval-augmented generation: finding relevant passages in your documents and adding them to the prompt before the model answers. (Embeddings and RAG). Before an answer reaches the customer, a check compares it with those articles. If it doesn't hold up, a person takes over instead of the assistant guessing (Governance and human-in-the-loop).

What breaks first. Marketing changes the returns window, but the copy the assistant searches still holds the old one, so it confidently states a policy that no longer exists. What it says is a commitment from your company, not advice from a third party.

What you measure. Answers backed by a cited source, hand-offs to a person, resolution time against your pre-launch numbers, and answers someone had to correct.

Lesson. Keeping that copy current is part of the product. Handing off to a person is a feature you design, not a fallbackFallback Sending a failed request to another provider or model automatically. you improvise.

Coding agents in a team that already has a codebase

What you build. The migration is the good case. The change is mechanical, and the existing tests can decide whether each service still works. Something that judges results automatically like that is called an oracle. A harness, the program that runs the agent, takes one repository at a time: the agent proposes, the tests decide, a person reviews. The payments module is the bad case: no test can tell whether the agent understood the business rule.

What breaks first. Someone reports "we're going much faster" based on how it felt. A team that never recorded its starting point, its baselineBaseline The reference result a new model or change must beat to count as an improvement., cannot tell a real gain from enthusiasm.

What you measure. Time per migrated repository, changes accepted without rework, later defects, and review time, which often goes up as writing time goes down.

Lesson. The gain comes from the shape of the task, not from the model. Where an oracle exists, agents scale. Where "correct" lives in someone's head, they mostly move work to the reviewer.

Internal search for an on-call team

What you build. Start with the evaluation, not the model. Ask the experts for 100 real questions, each with the answer they consider correct: the golden setGolden set Small set of inputs with expert-approved answers, used to judge whether a system is good enough to ship.. Then fix how documents are read and prepared, which is where most of the quality is decided. A PDF exported from slides often comes out scrambled, and no promptPrompt Everything sent to the model in one call: instructions, conversation messages and any tool definitions. can recover it. Combine keyword and meaning-based search so exact error codes still match. Only then compare models.

What breaks first. The first version passes the demo and fails the golden set, usually because the search returns plausible but wrong documents. Without the golden set, nobody would notice.

What you measure. Accuracy on the golden set, how often search finds the right document, and how long an evaluation round takes. A two-week round never gets run twice.

Lesson. Quality here is decided in document preparation and evaluation. See Testing and evals for agents.

Document intake

What you build. A pipeline of steps, not a single prompt: text recognition (OCROCR Optical character recognition: turning text in scanned images or PDFs into machine-readable text.) turns images into text, the model extracts the fields into a fixed format, ordinary code applies the business rules, and a person reviews the document next to the extracted fields (LLMs as software components). Totals, tax rates and dates belong in code. That is arithmetic, and a model that "mostly" adds up is worse than one that doesn't try.

What breaks first. Header fields (supplier, date, total) come out right and line items come out wrong, so the document looks correct at a glance.

What you measure. Accuracy per field, not per document. A 95% document average can hide a field that is wrong a third of the time.

Lesson. Remove human review field by field, as each field's numbers justify it, never for the whole pipeline at once.

An agent that acts on production systems

What you build. Two stages. First the agent only suggests: it narrows hundreds of recent changes to the few likeliest causes, and the engineer decides. To trust those suggestions, replay past incidents whose cause is known and check how often the real cause makes the shortlist, which is called backtestingBacktesting Evaluating a system on past, already-resolved cases to estimate how it would have performed.. Only then does the agent act, with a narrowly scoped credential, a list of allowed operations and an approval step for anything destructive (Sandboxing and agent security).

What breaks first. Someone writes "do not touch production" in the model's instructions and treats it as a safeguard. It is not. An instruction is a request; a permission boundary is enforced outside the model. An agent holding production credentials will eventually use them.

What you measure. How often the real cause is in the shortlist, how often the agent blames the wrong one, and how many actions a person approved or rejected.

Putting it into practice

When choosing a first use case:

• Pick a task that is frequent, checkable and owned. If nobody can say what the right answer is, nobody can evaluate the system.
• Start where mistakes are cheap or get caught, with a person reviewing the output, before facing customers.
• Build evaluation data and a baseline before choosing a model. A golden set written with your experts, plus today's handling time and error rate, are worth more than the best model.
• Define the exit. Decide in advance when the system hands off to a person and when you switch it off.

Key takeaways

• Recognizing which of the five shapes you have tells you the architecture and the main risk.
• Where something can check results automatically, agents scale. Where nothing can, they move work to the reviewer.
• A company answers for what its system says; a chatbot is not a third party.
• Suggest before acting, and enforce permission boundaries outside the model.

Check yourself