Build a support agent around one permitted outcome

This is lesson 1 of Production AI Agents. Let the model interpret the support request and propose the next step, and keep identity, policy eligibility and permission to request a replacement in ordinary code, with a receipt that proves what happened.

Start here if you can write a Python function but have never built an agent. You will turn a support conversation into a small system whose decisions you can inspect.

Part one: the customer asks for an outcome. Calder Equipment is a fictional supplier of industrial pumps.

Its support team receives messages such as: "The pump stopped during the morning shift. Can you send another?" An operator currently finds the serial number, checks the service policy and requests a replacement when the case qualifies. The exercises use synthetic records; none describe a real customer deployment.

The initial request sounds like a chatbot. The useful outcome is more specific: help an operator reach the right next step for one support case. Sometimes that means a replacement request; sometimes it means asking for a missing serial number; and a safety concern goes to a person who can handle it. A convincing paragraph does not establish which of those happened.

Start with an assistant that reads evidence and proposes a decision, let the operator inspect the policy and the proposed action, and add write access only after the read path works and the write boundary has its own checks. That is a small first system to test. It still keeps a path to useful automation.

The course builds that path in Python, and you need only functions, dictionaries and basic exceptions. When a later lesson introduces a transaction or an evaluation manifest, it explains the term at the point where the support system needs it. The local companion uses recorded model decisions, so you can study failures without an API account. Connecting a live model is a separate adapter exercise, and passing the local tests establishes behavior of the code, not the quality of a model you have not evaluated.

Part two: decide where uncertainty belongs. A workflow follows a path chosen by the programmer. An agent lets a model choose some of the next steps from observations.

Both can contain model calls. Neither description says anything about who may change customer records.

For Calder, policy selection by tenant, product and effective date is a rule, and so is checking whether a serial number belongs to this case. Interpreting an unfamiliar customer description may benefit from a model. Put the model there, then validate its proposed decision before anything happens.

Walk the four steps. Locate the case by its exact identifier under the caller's scope, select the policy with product and date filters, interpret the issue with a small decision model or a simple baseline, and request a replacement only through an authorized service operation.

What would justify changing each one? For missing identifiers, a separate, evaluated disambiguation step; for policy, more complex rules, still evaluated independently; for the interpreter, a measured improvement over the baseline on difficult messages. The replacement request is never a free-form model instruction.

A model can choose clarify, deny, handoff or replace. Here, replace means "propose a replacement request." It does not mean permission was granted, or a shipment was dispatched. Those distinctions will appear in the data model, tests and user-facing status.

Part three: follow the two paths in the lesson's diagram. An authenticated case lookup gives scoped evidence, and from policy and observed facts, the model proposes a next step.

From the proposal, two paths leave. Clarify or hand off goes to the operator work queue. A replacement proposal goes to a check of current permission and approval; an accepted command reaches the replacement service, which returns a durable receipt, a confirmed request.

The arrow into the replacement service is the important boundary. A model output reaches a check, and only an accepted command reaches the service. The service returns the evidence needed to display "replacement requested."

The customer product also needs recorded operator work, with a case identifier and an owner. Printing "please contact support" does not implement that path. The companion later records local queue acceptance, while dispatcher ownership and customer notification remain integration work.

For the first iteration, leave the last two boxes disconnected. Produce an inspectable proposal, with its supporting policy identifier. This is enough to discover wrong policy selection, invented serial numbers and poor issue classification, before remote write operations complicate diagnosis.

Part four: what you will keep after each module. Your first artifact is a one-page acceptance contract.

Then you will build an evidence selector, a bounded decision adapter, an approval check and an action ledger, one per module. The evaluation projects use the same case identifiers to expose a release that looks better in aggregate, but makes an unauthorized change. The capstone combines the pieces, and requires a decision about what may actually be enabled.

You can use an orchestration framework after you understand those responsibilities. A framework can manage calls and state transitions. You still need to decide what a support action means, which identity it runs under, and how its completion will be verified.

Your turn. Pause the video here. Write the initial contract for case C01: Calder tenant, pump serial P-17, mechanical defect, policy P2, record revision 3, the counter that advances each time the case record changes. Give the assistant access to read and proposal output only. Name the evidence the operator must see, and the operation the assistant cannot yet invoke.

A sufficient proposal will name C01, P-17 and P2, states why the defect appears eligible, and asks the operator to review it. The assistant cannot create a replacement request. A paragraph claiming "your replacement is on its way" fails, because no service receipt exists.

Now change the input: remove the serial number. The next step becomes clarification, and the proposal must preserve that missing fact. Choosing a likely serial from another case would turn a language interpretation problem into an identity error.

To recap. Put the model at the uncertain interpretation step, treat a replacement proposal and a confirmed request as different states, and start with access to read, then earn each additional capability through evidence.

That's lesson 1. Next in the series: define agent success before writing the prompt. The full lesson, with its exercise and drill, is on fdeinterviews.com.