We grouped 31 agent memory control points into 9 groups, kept all 31 detailed checks, and put the new map through a two-week usage review instead of treating the smaller index as proof of equivalent coverage.
Agent memory is often discussed as a retrieval problem. Our recent work was about the less visible control plane, the checks that decide how a memory system reads and changes project state. We borrowed the outcome-level interface idea from an AWS MCP rebuild and applied it to that control plane.
The system had accumulated session-loading checks, write validators, evidence rules, delivery checks, periodic scans, and human approvals. Each one had a job. The flat list was the problem.
Fifteen entries merged into five groups, four became conditional checks inside a group, one moved back to ordinary reading discipline, and eleven kept their own identity. All 31 detailed rows remain available. No safety check was deleted.
Sarvar Nadaf's recent AWS MCP rebuild offered a useful comparison. He cut 15 tools to 4 outcome-level tools, and the same question took 2 tool calls instead of 7 in his test. The lesson is larger than MCP: an interface should be organized around the decision someone is trying to make, with detail available one level down.
Two mechanisms made that possible without pretending that grouping is the same as safety. The first is an outcome-level control map: start with the failure in front of you, find its group, then open the detailed check. The second is a shadow projection: derive a state view from the append-only event log, compare it with the handwritten view, and change the write path only after the differences have mechanical explanations.
The scoreboard: 31 entries, 9 groups, 0 deleted checks
The analogy with Nadaf's MCP rebuild has a limit. His main costs were tool schemas, response size, and tool-selection confusion. Our control points also consume attention, but a missing memory check can leave two versions of the truth behind. We did not treat a smaller count as evidence of equivalent coverage.
The coverage argument has to come from the mapping itself:
| What changed | Count | What it means |
|---|---|---|
| Flat control entries before | 31 | Every check competed for attention at the same level |
| Groups after | 9 | Each group answers one kind of operational question |
| Entries merged into five groups | 15 | Their actions still run inside those groups |
| Entries made conditional | 4 | They now run at a named trigger inside their host group |
| Entries reclassified | 1 | A source-priority rule moved back to reading discipline |
| Entries kept independent | 11 | Their timing or decision authority requires a separate identity |
| Detailed rows retained | 31 | The group is an index, not a replacement for the detail |
| Safety checks deleted | 0 | Consolidation changed navigation, not the required work |
That last row matters. A control map can hide a check behind a friendly group name just as easily as an oversized AGENTS.md can hide it behind three hundred lines. We kept the detailed rows beside the group index so a reviewer can trace every consolidated entry to its new home.
The groups are addresses, not nine new rituals
We grouped controls by the moment at which they act and the failure they catch. We did not group them by which script or document happened to own them.
| Group | The question it answers |
|---|---|
| Intake | Did the session read current long-term facts, active state, and the relevant domain record? |
| Admission | Should this action exist, and does it have an owner or task identity? |
| Write | Did the change pass through the approved writer, contract checks, evidence rules, and location checks? |
| Change conduction | Did this change reach every dependent document, with contradictions recorded? |
| Closeout | Is there an explicit account of unfinished artifacts and uncommitted work? |
| Periodic checks | What do the daily scan, freshness checks, projections, and weekly reconciliation say? |
| Human review | Does this action cross a red line, require authorization, touch money or credentials, or expose private data? |
| Delivery self-check | Does every status claim have evidence, and does every surprise have a classification? |
| Feedback | Is the failure registered for recurrence checks, and is the capability still earning its place? |
The first five groups roughly follow a task. The other four cut across tasks. A reviewer can say “this is a write-group failure” or “this belongs in change conduction,” then open the exact validator or receipt underneath.
This is the same reason find_waste is more useful than seven near-identical AWS wrappers in the reference article. The caller starts with an outcome. The workflow lives behind the interface.
Some controls do not get merged
Grouping works only when it preserves decision boundaries. Five kinds of human review stayed distinct inside the human-review checklist: red lines, pre-authorization, irreversible actions, data classification, and monthly audit. Sharing a checklist does not turn five decisions into one.
The periodic checks also kept separate schedules. A daily diff cannot prove that a weekly semantic review happened. A freshness light cannot stand in for either one. Closeout kept its own group because no other control accounts for unfinished files. Failure registration stayed visible because a repeated problem needs an identity before anyone can count its recurrence.
Our rule is simple: merge the lookup, not the judgment.
A shadow projection tests the source before the switch
The control-map change reduced navigation overhead. The shadow system addressed a different question: if a state view can be derived from events, why maintain that view by hand?
We started with one high-frequency view. It had collected 111 rows in 11 days, which made manual drift easy to observe and gave the experiment enough material to be useful. The existing handwritten view stayed in place. A deterministic projector read the append-only event log, matched events to rows using shared anchors, and wrote a separate shadow view.
The pipeline has three stages:
extract: read timestamped events from the append-only log project: match events to view rows with slugs, task IDs, or text anchors diff: report coverage, lag, and unexplained drift No model calls sit in this path. The projector checks that the source hash has not changed before writing, rotates five backups, and skips rows it cannot parse instead of deleting them. A person reads the diff.
The first run produced a useful, unglamorous table:
| First shadow run | Result |
|---|---|
| Handwritten rows in scope | 144 |
| Rows matched to an event | 129 |
| Coverage | 89.6% |
| Strong-signal lag | 0 |
| Rows without an event anchor | 15 |
The 15 unmatched rows had a mechanical explanation: the activity existed in the handwritten view but had never entered the event log. Increasing the matcher's vocabulary would only hide that structural gap. The better fix was to make the event log the single write entrance before asking the projection to replace the handwritten view.
Promotion changes who writes the view
A publishing view moved first. The projector produced 41 entries that matched the existing handwritten publication list. A separate activity view followed with 30 generated rows, each carrying a pointer back to its source event. Its reconciliation run reported 100% coverage and zero drift.
Those numbers describe agreement between the event log and the derived views. They do not measure whether an agent remembered the right fact, made a better decision, or saved money. A projection can be perfectly consistent with an incomplete event log. That is why the write entrance and the external audit remain separate controls.
After promotion, people stop editing the generated view. They write the event; the projector refreshes the view. The append-only log stays intact, and the generated rows retain their evidence pointers. Rollback means restoring the handwritten view, not reconstructing history from the projection.
Three kill rules stayed armed after promotion:
- Two or more unexplained drift cases trigger rollback.
- One dispute over whether the log or the projection is authoritative triggers rollback.
- Maintenance time exceeding the old handwritten workflow triggers rollback.
A shadow system needs a way to lose. Otherwise it is just a second production path with a reassuring name.
The 9-group map is still under review
The shadow results above are completed reconciliation checks. The control-map consolidation is earlier in its life. It is currently in a two-week review with three tests:
- five sample failures must be traceable to the right group within 30 seconds;
- the four newly conditional checks must have zero missed executions;
- the nine groups must be used in at least three real deliveries or reviews.
If any test fails, the detailed 31-row map becomes the primary reference again. We have not redrawn the architecture diagram around the new groups yet. A diagram would make the consolidation look settled before the usage evidence exists.
We also have not measured a token reduction for the 31-to-9 change, and we are not claiming one. The review measures lookup speed, missed conditional checks, and actual use. That is a narrower claim than “71% less governance,” which would confuse a smaller index with less work.
What to copy before you consolidate anything
Start with a control inventory that names each trigger, owner, and evidence artifact. Group entries only when they share a decision moment or failure mode. Keep the detailed inventory one level below the group index, and leave human decisions individually accountable.
Then pick one derived view, not the whole memory system. Keep its source append-only. Run the projector beside the existing view and count coverage, lag, and unexplained drift. Change the write path only when every remaining difference has a mechanical explanation. Keep the rollback criteria active after the switch.
Our earlier posts cover the adjacent layers: why memory needs an audit between its log and current state, how change-conduction receipts verify dependent documents, and why a saved status is not evidence of a durable write. The public wallaby-agent-rules repository contains the file-based memory and governance layers. This post describes our internal control map and shadow-projection work; it is not a release announcement for that projector.
Disclosure: Wallaby Token builds open-weight inference infrastructure and develops wallaby-agent-rules. We use the memory controls described here on our own projects.
Originally published on the Wallaby Dispatch.
