Build a support agent around one permitted outcome
Choose the uncertain step that needs a model, then keep case identity, replacement permission and completion checks in code. Start with a read-only support assistant.
18 MIN
By FDEInterviews · Updated
TL;DR: Let the model interpret the support request and propose the next step. Keep identity, policy eligibility and permission to request a replacement in ordinary code, with a receipt that proves what happened.
Where you are. 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.
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. 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. Add write access only after the read path works and the write boundary has its own checks. This gives you a small first system to test while retaining a path to useful automation.
The course builds that path in Python. You need 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; passing the local tests establishes behavior of the code, not the quality of a model you have not evaluated.
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. 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.
| Step | Initial implementation | What would justify changing it? |
|---|---|---|
| Locate the case | Exact identifier under the caller's scope | A separate, evaluated disambiguation step for missing identifiers |
| Select policy | Product and date filters | More complex policy rules, still evaluated independently |
| Interpret the issue | Small decision model or a simple baseline | A measured improvement over the baseline on difficult messages |
| Request replacement | Authorized service operation | 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.
Follow the two paths in the diagram
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 writes complicate diagnosis.
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. 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.
Do this before moving on
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 read access and proposal output only. Name the evidence the operator must see and the operation the assistant cannot yet invoke.
Worked review. A sufficient proposal names 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.
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.
Go deeper
- Agent or workflow: compare the two control structures after drawing your first boundary.
- Bounded autonomy: study how action consequences determine the supervision a system needs.
- The FDE Engagement: connect this implementation to customer discovery and delivery responsibilities.
Key takeaways
- Put the model at the uncertain interpretation step.
- Treat a replacement proposal and a confirmed request as different states.
- Start with read access, then earn each additional capability through evidence.
Check yourself
Answer before you look. Recalling it is what makes it stick; recognising it does not.
1The model returns replace for C01. What has been established?
2Why begin with a read-only assistant?
Sign in to track which lessons you have finished.