Lab: Memory design

You'll make the resolution agent robust over long tasks and aware across tasks — the two memory disciplines, wired and tested against trajectories designed to break a memoryless agent.

Step 1 — The scratchpad

1. 1Add a notes tool: record_finding(key, value) that writes to a per-task dict your loop keeps outside the message list.
2. 2System prompt: 'As you establish key facts (order status, damage confirmation, computed amount, decision), record each with record_finding. Consult your notes before re-fetching anything.'
3. 3Inject the current notes dict into each turn's context, pinned near the top (below the goal).

Step 2 — Compaction

1. 1In the loop, estimate token count each turn (a rough chars/4 heuristic is fine as a quick fallback; for an accurate count use the API's token counting — client.messages.count_tokens — or the usage field on each response). At 70% of your chosen limit, summarize the oldest turns with a model call and rebuild the message list: system + goal + plan + notes + summary + recent turns.
2. 2Trim used tool results: after a result has informed a turn, replace its verbatim content in history with a one-line stub ('[lookup_order HL-1042 → recorded in notes]').
3. 3Log token count per turn so you can watch the sawtooth: climb, compact, climb.

Step 3 — Long-term memory tool

1. 1Add customer_history(email) over your SQLite DB: returns the customer's last 3 tickets + resolutions, shaped and capped.
2. 2Add record_resolution(ticket_id, summary, action, amount) that writes to a resolutions table — deliberate memory, not automatic.
3. 3System prompt: 'At the start of a case, check customer_history for relevant prior interactions. At the end, record_resolution.'

Step 4 — The endurance test

1. 1Build a monster ticket: a customer with 3 orders, two issues, a question, and a reference to a past refund. The kind of case that overflows a naive agent.
2. 2Run it with memory OFF (v0.2) and ON (v0.4). Compare: did v0.2 forget a request or re-fetch an order once context filled? Did v0.4 stay coherent, hit the notes instead of re-fetching, and cite the prior refund from customer_history?
3. 3Confirm the compaction actually fired (check your token log for the sawtooth) — if the task was too short to trigger it, make the ticket meaner.
4. 4Record the comparison in LAB-NOTES: completeness, turns, whether coherence survived past the compaction point.