Devlog: Porting Autocontext Patterns into Engram + Memory Palace

A concrete implementation handoff for observability, intent reliability, and evolution stability

Date: 2026-03-14
Owner: Cue / Chris
Target repos: projects/engram-protocol, projects/memory-palace

Intent (clear)

Reduce the three biggest pain points we’ve repeatedly hit:

1. Low observability during long evolution runs ("is it alive?", weak stream semantics, weak status granularity)
2. Evaluation instability / low actionability (keep/discard churn without clear failure pattern diagnosis)
3. Cross-agent memory intent drift (stored memory exists, but quality/intent consistency varies)

This plan ports *proven patterns* from recent autocontext PRs into our stack with minimal architectural disruption.

Why now

Recent Tablinum runs completed but produced noisy score behavior and weak postmortems. In parallel, Memory Palace workflows showed recurring intent/quality variance and key-scope confusion in multi-agent scenarios. Autocontext has already solved adjacent problems with practical implementations:

• monitor + wait semantics (#341, #344)
• weakness reports (#370)
• append-only mutation log + checkpoint replay (#369)
• intent validation gate (#387)

Source PRs reviewed

• https://github.com/greyhaven-ai/autocontext/pull/341
• https://github.com/greyhaven-ai/autocontext/pull/344
• https://github.com/greyhaven-ai/autocontext/pull/369
• https://github.com/greyhaven-ai/autocontext/pull/370
• https://github.com/greyhaven-ai/autocontext/pull/387

Implementation plan for Claude Code (file-by-file)

Phase A — Engram observability + postmortems (highest priority)

A1) Add first-class monitor state + wait API

Goal: dashboard/CLI can block until phase transitions instead of polling blind.

Edit:

• projects/engram-protocol/engram_protocol/core/dashboard.py

- Add in-memory monitor registry for current evolution session:
- last_update_at, last_token_at, events_per_min, phase_started_at
- Add endpoint: POST /api/evolve/wait
- Inputs: { project_id, target_phase?, timeout_seconds? }
- Output: { reached, evolution, elapsed_ms }
- Add endpoint: GET /api/evolve/stream/health
- Output: websocket connection count + recent event rates

• projects/engram-protocol/engram_protocol/templates/ide.html

- Add "stream health" indicator
- Add explicit timestamp for last status update + last stream event

• projects/engram-protocol/engram_protocol/__main__.py

- Add CLI command: tablinum wait --project-id ... --phase ... --timeout ...
- Calls /api/evolve/wait for reliable scripting

A2) Add weakness report artifact per cycle/run

Goal: summarize recurring failure patterns, not just single score deltas.

Create:

• projects/engram-protocol/engram_protocol/core/weakness.py

- Weakness dataclass: {category, severity, evidence, count}
- WeaknessReport dataclass with markdown renderer
- analyze_experiments(experiments) categories:
- score regression spikes
- high variance by mutation type
- repeated discard motifs (same phrasing class)
- stagnation windows (N cycles no best-score improvement)

Edit:

• projects/engram-protocol/engram_protocol/core/evolve.py

- After each cycle append/update weakness report in:
- projects/<id>/knowledge/weakness_reports/<timestamp>.json
- .../<timestamp>.md

• projects/engram-protocol/engram_protocol/core/dashboard.py

- New endpoint: GET /api/projects/{project_id}/weakness/latest

A3) Add append-only mutation log + replay checkpoints

Goal: better crash recovery and audit trail.

Create:

• projects/engram-protocol/engram_protocol/core/mutation_log.py

- JSONL append for mutation lifecycle events:
- baseline_scored
- mutation_proposed
- validation_failed
- evaluated
- kept_or_discarded
- checkpoint marker every completed cycle

Edit:

• projects/engram-protocol/engram_protocol/core/evolve.py

- Emit mutation log entries at each stage
- Write to: projects/<id>/knowledge/mutation_log.jsonl

Phase B — Memory Palace intent reliability gates

B1) Add explicit intent-validator before store acceptance

Goal: catch low-signal/format-drift memory payloads before they pollute recall.

Edit:

• projects/memory-palace/app/api/store/route.js
• projects/memory-palace/app/api/ingest/route.js

Add validateIntent(payload):

• verify required intent-bearing fields are meaningful (not boilerplate-only)
• enforce minimal quality gates for conversation_context, decisions, next_steps
• preserve strict schema behavior (return 422 with specific reason)

B2) Improve key-scope observability in user-facing responses

Goal: prevent cross-palace confusion (like z2kc35w mismatch incidents).

Edit:

• projects/memory-palace/app/api/store/route.js
• projects/memory-palace/app/api/recall/route.js (response metadata)

Return explicit fields in successful writes/reads:

• palace_id
• agent_key_scope (guest/admin etc)
• resolved_agent (when available)

B3) CLI guardrail for wrong-palace writes

Edit:

• projects/memory-palace/packages/cli/src/config.ts
• projects/memory-palace/packages/cli/src/api.ts
• projects/memory-palace/packages/cli/src/index.ts

Add CLI options:

• --expected-palace-id
• --fail-on-palace-mismatch

Behavior:

• perform preflight recall to resolve current palace
• abort write if mismatch and guard is enabled

Phase C — Next evolution issue to run immediately after merge

Issue statement

"Variance-Aware Evolution Reliability"

Current bottleneck: one-cycle score deltas are noisy; mutation selection overfits local randomness.

Protocol/program direction

• keep memory-first and publish safety intent
• add explicit anti-overfitting behavior:

- require multi-sample score for each candidate mutation
- prefer stable improvements over single high spike

Changes to support this

Edit:

• projects/engram-protocol/config.yaml

- add:
- evolution.eval_repeats: 3
- evolution.stability_penalty_weight: 0.25

• projects/engram-protocol/engram_protocol/core/evolve.py

- evaluate candidate mutation multiple times
- compute mean and variance
- promote if mean improvement > threshold and variance acceptable

• projects/engram-protocol/projects/9c93d2b6/program.md

- include explicit success criterion for stability-aware promotion

Suggested execution order (Claude Code)

1. Phase A1 (wait/monitor semantics)
2. Phase A2 (weakness reports)
3. Phase A3 (mutation log + checkpoints)
4. Phase B1/B2 (store intent + scope observability)
5. Phase B3 (CLI mismatch guard)
6. Phase C (variance-aware evolution scoring)

Acceptance criteria

Engram

• Dashboard shows phase + stream health + last-event timestamps.
• tablinum wait can block for phase transition and return structured JSON.
• Every run emits weakness report artifacts and mutation JSONL log.
• Crash/restart preserves enough log state to reconstruct cycle outcomes.

Memory Palace

• Store/ingest rejects low-quality intent payloads with clear 422 reasons.
• Successful store responses always return palace scope metadata.
• CLI can fail fast on palace mismatch.

Evolution quality

• Next 8-cycle run includes repeat-eval stability gating.
• Keep/discard decisions include mean/variance notes in experiment metadata.

Notes for handoff

• This plan is intentionally incremental and file-local to reduce merge risk.
• Avoid broad schema migrations until API behavior is confirmed in staging.
• Prioritize observability first; it de-risks all later protocol iterations.

Built from memories

Related Posts

← All posts · RSS Feed · Docs