The policy library is five Sundry-wide documents plus roughly 2,000 per-seller supplements, it changes every week, and 99% of it is irrelevant to any one ticket. Six topics on giving the agent a way to look things up instead of being told everything: the three unrelated problems the word "memory" covers, conversation state as plain application data, retrieval as a tool the agent chooses to call, what vector search is good and bad at, the three ways retrieval fails, and an honest account of writing facts back about customers.
6 topics
Chapter 5 named the drift, measured it and slowed it down. It could not cure it, because the cure was never in the prompt. The agent kept quoting Sundry's own 30-day return window at buyers whose seller runs the statutory 14 days for one flat reason: both documents were in the context, and nothing in the buffer said which one governed this seller. Budgeting, compaction and careful ordering can decide what the model sees; none of them can add the fact that decides between two things it already sees.
This chapter fixes it at the source. search_policy becomes a tool the agent calls after it has read the ticket, passages come back carrying their document title, effective date and scope, and every policy-based answer has to name the clause it used. On the 32 tickets in the 120-ticket eval set whose answer turns on a policy document, policy-correct resolutions went from 20 to 26 — 63% to 81%, six tickets, and the second wound closed. Chapter 9 is where it is proved closed and kept closed.
The other half of the chapter is the word "memory" itself, which covers three unrelated problems: what was said in this thread, what this task has done so far, and what the system knows about a customer across months. Three problems, three stores, three retention rules. The most useful page here is the one about failure — retrieval misses in three distinct ways, and at Sundry the most common one was the model having the right passage in context and answering from a different one, which no retrieval metric can see. The last page is the awkward one: writing facts back about customers moved resolution by two points and produced two incidents in its first month.
Three problems called memory, and a fourth thing that is not memory at all
Conversation statewhat was said in this thread
The messages as sent, re-sent whole on every turn and rewritten whenever the thread outgrows its budget. It is the agent's account of the ticket, and accounts get shortened.
Task statewhat this task has done
Order, decision, and one row per completed side effect, written by code the moment a tool returns. An irreversible action lives here or it does not survive a summary.
Long-term factswhat is known across months
Dated observations about a buyer or a seller, each with the ticket it came from. Two points of resolution and two incidents in its first month, which is why it ships last and narrowest.
Retrieved knowledgenot memory at all
The policy library is looked up, not remembered. Passages arrive carrying a document title, an effective date and a scope — the fields that took the 32 policy tickets from 20 correct to 26.