Lab: First agent
Build the resolution agent v0: mock tools, the loop, a system prompt with the autonomy dial — and watch it navigate its first three cases.
You'll have a working agent in this lab — deliberately on mock tools (a fake order database, canned policy answers) so you can watch pure agent behavior before real integrations complicate the picture in Module 3.
Step 1 — The world
- 1Create
world.py: a dict of 6 fake orders (mix of delivered/in-transit/delayed, one with a damaged-item note) and 4 fake tickets referencing them. - 2Implement mock tools over it:
lookup_order,get_ticket,search_docs(return 2-3 canned policy snippets keyed on topic),update_ticket(note, status)— which just prints loudly so you SEE writes happen. - 3Write
execute_tool(name, input)dispatching to them, returning dicts, with teaching error messages for unknown IDs.
Step 2 — The system prompt (the constitution, agent edition)
You are Harbor Lane's support resolution agent.
JOB: Given a ticket, resolve it: gather facts with your tools, decide the
right action per policy, update the ticket, and summarize the resolution.
RULES
- ALWAYS look up the order and check policy before deciding anything.
- You may update tickets freely. You may NOT issue refunds or send replies
in this version — instead, end with a PROPOSED ACTION section.
- If facts conflict or policy is unclear: update the ticket with what you
found and propose escalation. Never guess amounts or dates.
- Think before each tool call: state what you need and why, briefly.
OUTPUT (when done): summary of facts found, action taken, action proposed.Step 3 — Run and watch
- 1Wire
loop.pyfrom the lesson. Add one line that prints every tool call and its input as it happens — your window into the agent's mind. - 2Run ticket 1 (simple: where's my order?). Watch the sequence: get_ticket → lookup_order → update_ticket → summary. Count the turns.
- 3Run ticket 2 (damaged item, wants refund). Verify it checked policy BEFORE proposing, and that the refund is proposed, not taken.
- 4Run ticket 3 (references order HL-9999 — doesn't exist). Does your teaching error message steer it to re-read the ticket or propose asking the customer? If it retries the same ID three times, improve the error text and re-run — your first taste of tool-design-as-debugging.
Step 4 — Trajectory notes
For each run, save the printed trajectory to trajectories/ (trajectory = the full sequence of the agent's reasoning, tool calls, and results for one task). Annotate one by hand: mark each step ✓ (right call), ○ (harmless detour), ✗ (wrong/wasteful). This annotation habit is Module 6's evaluation method in embryo — start building the reflex now.
In the workbook: four tool definitions with subtle flaws (a description that lies about behavior, a do-everything mega-tool, an unconstrained ID input, an error message that dead-ends). Identify each flaw, predict the trajectory failure it causes, and rewrite the definition.