Capstone: Designing Juno
One agent, every lesson.
This is it. The founder walks over, and says, three hundred tickets a day, and my team's exhausted. Can you build it? You've got every skill that you need. And we won't start with code. We'll start the way that professionals do. With a design.
- Three hundred tickets a day
- Can you build it?
- We start with a design
The design decisions
For each question, we've got an answer from this course. Workflow or agent? A small agent, as the steps vary. Which tools? Few and narrow. Refunds? A gate in code, not model judgment. Big refunds? A human, using interrupt. Reading attacks? Treat all customer text as data, and assume that the model can be tricked. Quality? An eval set.
| Question | Decision |
|---|---|
| Pattern | One small agent, graph-based |
| Tools | Three reads, one refund request |
| Refund rules | Enforced in code |
| Large refunds | Human approval |
| Attacks | Data, not instructions |
| Quality | Evals on every change |
The final graph
Here's Juno's graph. The agent thinks. It can read orders, stock, and policy. If it asks for a refund, control leaves the model's hands completely, and passes to a gate written in plain code. That gate decides, or it asks a person. No model output can skip the gate.
What makes this design strong
Look at the key idea. The model has a tool called request refund, not refund. It can ask, but it can't act. Money only moves after the gate, so a tricked model can't do any harm. The lethal trifecta's broken too, because Juno can't send data to outsiders. That's what good agent architecture looks like.
Summary
Design first, and make safety part of the structure, not a suggestion. Now we'll build it.
Key takeaways- Start with a design
- The model asks, code decides
- Safety is structural