Context architecture
MEMORYFIELD
Project memory for AI tools
I organized Memoryfield like a 3-drawer desk modeled on a CPU cache: L1 active prompt context on the desktop, an L2 AST (code structure) dependency graph in the index drawer, and L3 hash-checked context snapshots in the evidence vault.
つながり
ノートを全部読み直すより、必要な記録とその根拠をたどれるようにしたい。
The 3-Drawer Context Cache.
L1 active prompt → L2 AST dependency graph (66.56% fewer tokens) → L3 hash-pinned evidence vault
Active prompt
Only what the agent needs on the desk right now.
2.88ms p50 re-link
101 files compiled to a third of their tokens. Re-linking one changed file takes 2.88ms at the median.
Pinned receipts
Hash-checked context snapshot watched for drift.
STEP 1 / 3 · L1 · PromptELI5: The Desk TopML / Systems: L1 Working Context isolates active instructions and current task state from historical chat bloat so attention never dilutes.Plain English (ELI5): Keep only the page you are actively editing on top of the desk instead of piling up 100 old notebooks.
Architecture schematic with illustrative records and connections. References require maintenance; receipts support their named checks.
Local graph timings: receipt 979cce2b (2.88ms p50). Workspace compaction: receipt 58b0499d (66.56%).The 3-Drawer Desk: L1 Prompt, L2 AST Graph, L3 Evidence Vault
When you dump every past chat log onto the desktop, attention dilution sets in and earlier architectural decisions get buried. I separated active L1 working instructions from compiled L2 repository context and L3 historical evidence so each memory tier has one job.
Think of it like a tidy 3-drawer desk: only the current task sits on top (L1), a 66.56% smaller indexed map of your repo sits in the middle drawer (L2, 145,119 to 48,534 tokens), and tamper-sealed receipts sit in the bottom vault (L3).
Instead of re-reading raw files every turn, the embedded compiler builds an L2 dependency graph connecting routes, tokens, and modules. Each node points to its content-addressed L3 receipt so the next agent session can verify what was checked.
Across 100 local iterations (70 single-file and 30 submodule edits), incremental dependency-graph compilation runs in 2.88ms p50 (3.40ms p95, 99.2% cache hit rate) vs. 20.09ms for a cold 101-file compile: consuming 17.3% of a single 16.7ms 60 FPS frame so context updates run synchronously without UI jitter.
- INCREMENTAL p50
- 2.88ms
100 local iterations: 70 single-file and 30 submodule mutations; p95 3.40ms; the p50 is 17.3% of a 16.7ms 60 FPS frame. Compiler timing, not model latency.
- ESTIMATED TOKEN REDUCTION
- 66.56%
145,119 to 48,534 in one 101-file workspace (63.50% across 20 fleet repos, receipt 6f40789f). Tokens estimated as characters divided by four.
Why an AST dependency graph beats blind RAG chunking
An assistant should not have to reread a 100-page notebook to find one rule, and tearing pages in half at fixed 500-word boundaries destroys how code modules connect. I use the AST dependency graph as a live table of contents where every rule stays wired to its supporting receipt.
Long-context research finds that language models use facts at the start and end of a prompt more reliably than facts in the middle (Liu et al., “Lost in the Middle,” 2023). By pinning constitutional rules at the primacy boundary, active orientation knobs at the recency boundary, and compact L3 hash pointers in between, the compiler preserved 100.0% verbatim fact recall (100 of 100 facts across 25 ground-truth tasks) versus 19.0% under naive tail truncation (+0.2296 positional salience gain, receipt 728dc1df).
The 2.88ms p50 timing beside this figure measures local incremental dependency-graph compilation across single-file and submodule mutations (vs. 20.09ms cold across 101 files). Downstream LLM response latency and answer quality require separate evaluations.
Search over chunks finds text that looks similar. I wanted the next session to get the code that’s actually connected, so I map the dependencies first.
Two-layer UI evaluation: AST floor first, design judgment second
For design engineering, I treat the Figma component tree (AST) as Layer 1: a deterministic structural floor that automatically catches detached hex colors, missing Auto Layout, and 2.5x German localization clipping before a human reviewer ever looks at the screen.
Once a component passes the structural floor, Layer 2 evaluates human design judgment: visual hierarchy, user intent, valid alternative layouts, and reviewer calibration. In the interactive inspector below, an AST-valid Delete Workspace bar still fails hierarchy when Cancel and Delete share equal visual weight, while inline-vs-modal reviewer disagreement is calibrated by whether the action is reversible.
Inspect worked design-heuristic AST fixture (Auto Layout, tokens, and 2.5x German overflow)
ABOUT
I’m Matt Stenquist, a Product Design Engineer and former professional snowboarder. I started coding at nine, shipped modded hardware and games by 16, and turned pro by 22. A few broken bones and a gold tooth later, I design and code consumer apps, Figma component systems, and AI developer tools from scratch.
LEARN MORE