Back to course overview
Module 1Agent fundamentals 22 min

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

  1. 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.
  2. 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.
  3. 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)

resolution-system-v0.1.txttext
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

  1. 1Wire loop.py from the lesson. Add one line that prints every tool call and its input as it happens — your window into the agent's mind.
  2. 2Run ticket 1 (simple: where's my order?). Watch the sequence: get_ticket → lookup_order → update_ticket → summary. Count the turns.
  3. 3Run ticket 2 (damaged item, wants refund). Verify it checked policy BEFORE proposing, and that the refund is proposed, not taken.
  4. 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.

Problem set 1

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.