Working memory the agent edits itself
Fitting a full task into the context window is not the goal. When old tool outputs, dead-end attempts, and stale search results pile up, they crowd out the current instruction and degrade judgment. The memory tool exposes four operations — recall, remember, forget, list — so the agent curates its own working memory: it writes down facts worth keeping, drops evidence that is no longer relevant, and pulls back what a later step needs.
The point is separation. Persist "facts" and "in-progress reasoning" in distinct stores, so a discarded hypothesis does not later masquerade as an established fact. remember records durable facts, forget removes obsolete assumptions, and recall/list bounds retrieval quality.
Context editing and server-side compaction
As the conversation approaches the window limit, server-side compaction summarizes older turns and reclaims space. In Anthropic's internal agentic-search evaluation, context editing alone improved results by +29%, and combining it with the memory tool reached +39%. Compaction is not free, though: over-aggressive summarization drops details the next step depends on, so preserve identifiers, decisions, and unresolved items as fields rather than prose.
A4 detailed guide: from planning to operations
An agent feature is not finished by model quality alone. In production, user questions arrive incomplete, tool responses lag, and policy constraints fire at the same time. So the design document must state, in sentences, "under which conditions and by what criteria the system acts." Readers need the decision rationale before the code to build a reproducible operating pattern.
The most common failure in practice is ambiguous requirements. "Keep the working memory lean" collides at implementation time unless you fix a balance point among latency, accuracy, and cost. Write target metrics as numbers: recall hit rate 90% or higher, working-memory footprint held under 40% of the window before compaction triggers, and post-compaction detail-loss rate under 5%. With such baselines, you can detect quality regressions quickly when you swap models or change the compaction threshold.
Failure is closer to the default than the exception. recall returning stale facts, forget deleting an entry still in use, and compaction dropping a key identifier all recur. Branch the recovery explicitly: a stale recall triggers a re-fetch, an ambiguous deletion routes to human confirmation, and a lossy compaction falls back to a safe, narrowed summary. Recovery must also define when to stop — cap retries and set a backoff so infinite loops do not worsen cost and latency together.
Pre-deployment checks cannot end at a feature list. Run scenario tests for a full window, empty recall results, conflicting remember/forget calls, and compaction at the boundary. Unify observability into standard log fields — request ID, per-step tool timing, failure code, whether the fallback path was entered, and memory-operation type — and state a PII masking rule so personal data does not leak into logs or alert channels. Keep the masking policy in text as well as code; rules held only in code are easily missed.
Finally, include a continuous-improvement loop. Weekly, tabulate the top failure types and fix the highest-recurrence items first. Model prompt changes, tool-contract changes, and memory-policy changes each carry different risks, so keep separate change logs to trace causes quickly.
Executive summary
In short, let the agent edit its own working memory with recall/remember/forget/list, and let server-side compaction reclaim space near the window limit. Anchor the design on numeric targets, branch recovery by failure type, and record observability and masking rules together. Built this way, the document becomes an execution asset for onboarding, incident response, and feature expansion — not a one-off writeup.