INTRODUCTION
MEMORYFIELD
Project memory for AI tools
I built Memoryfield so AI coding and design agents can pick up a project without losing context. It’s a context memory compiler: it compresses what an AI-assisted project has done into a notebook the next session reads, so the AI remembers its own work instead of starting every project with amnesia. One rule runs through it, which I call physics over liturgy: evidence can never be claimed without a bounded source.
- WHAT
An AI context compiler, workspace monitor, and mf CLI. In a 101-file workspace: 66.56% AST compaction of estimated tokens and 2.88ms p50 incremental graph compile, timed locally. Fact recall: 100/100 vs. 19/100 tail truncation. Handoff: 30/30 tasks vs. 26/30 bounded excerpts. Eight-worker lock test: 0/200 lost writes.
- ROLE
Founder & Systems Architect
About 4 min read
- SCOPE
A convincing answer isn’t enough
My lightbulb moment came from hitting the same pain points with every frontier model at once. Then it bit me. I was building Diamond Hands, my own Bloomberg-style terminal, with a built-in AI chief investment officer called QuantGoblin. QuantGoblin kept reporting hard-coded numbers while the model told me they were live. I only caught it by auditing with several models and reading the Python myself.
The model wasn’t maliciously lying. It had a blind spot: it reported the result I wanted without producing it. I needed a way to find out, with evidence, why AI starts to drift.
My role
I designed the Memoryfield workspace UI and inspection flows, and built the Python context compiler, AST dependency parser, file-hash watchdog, and mf CLI from scratch.
I separated deterministic verification gates from model generation so designers, PMs, and engineers agree on explicit pass/fail rules and test receipts first, then spend human review on the judgment calls no check can make.
Organize the context
I indexed repository files into a directed AST dependency graph so an agent pulls only the relevant context slice in milliseconds, with a SHA-256 hashed receipt attached to each check.
Coordinate the writers
I serialized concurrent multi-agent writes with a POSIX kernel advisory lock so parallel workers take turns updating shared state.
Require the evidence
I keep the check separate from the generated answer. A missing runtime record stops a claim from advancing, even when its offline check passed.
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.
Architecture schematic: working context, dependency graph and evidence store.
Local graph timings: receipt 979cce2b (2.88ms p50). Workspace compaction: receipt 58b0499d (66.56%).Carry the memory and its evidence
So I moved the math out of the model. My agents work in a narrator pattern: the model narrates, code does the arithmetic, and a watchdog stamps a hashed receipt on every memory update. A claim without a bounded source fails the gate, so the record stays honest even when a model isn’t.
Instead of rereading old chats, the compiler maps the repo’s code structure (AST) into a dependency graph, tiers files hot, warm or cold, and seals carried decisions inside a hash-checked snapshot. If a file changes between sessions, the watchdog flags the stale note before the next prompt runs.
When parallel agents edit the same repo, race conditions overwrite files. Think of multiplayer editing with one shared key: an agent requests its turn, takes the key before reading and writing, then hands it back. Every writer has to use that same operating-system lock.
I rejected bigger context windows and longer pasted transcripts, because more history buried the rules that mattered. A compiled, hash-checked snapshot refuses stale notes, so the next session starts from what is true now.
人工知能
前の会話を全部渡すより、何を決めたかと、その根拠をちゃんと残しておきたい。
The notebook analogy and trade-offs
The goldfish assistant with a notebook
Imagine an assistant who needs the project explained again each morning. Handing them a growing 500-page binder of chat logs causes context rot and attention dilution. I built an embedded repo compiler and health watchdog that keeps a 1-page map with a tamper seal on every note.
| Question | Raw chat context (Before) | Memoryfield compiled context (After) |
|---|---|---|
| What should I read? (AST Graph) | A growing pile of raw chat transcripts. | A one-page map of the code structure (AST) and what depends on what. |
| Did the code change? (Hash Snapshot) | Guess from old chat history and hope nothing moved. | Check the SHA-256 tamper seal on the receipt before running the prompt. |
| Can two agents edit at once? (POSIX Lock) | Competing writes overwrite each other’s files. | Each cooperating agent requests the shared OS key, writes during its turn, then releases it (0/200 lost). |
| What does it cost? (Token Budget) | The recorded 101-file corpus estimates 145,119 tokens. | 48,534 estimated tokens; input costs scale with your rate and usage. |
Scroll the comparison to read both sides.
What improves
Less context rot, a third of the tokens to carry, inspectable receipts, and agents that take turns writing.
What it requires
Maintained references, cooperating writers, and a host that enforces the gate. A receipt verifies a record, not the truth of every model answer.
01 · ONE SESSION, START TO FINISH
How Memoryfield keeps agent memory from degrading
Shrink repo context by 66.56%
Maps a 101-file repo into a 1-page dependency graph and archives older session notes out of the prompt.
Audit fleet health & stale edits
Checks health across 20 repos and seals carried rules in SHA-256 snapshots to catch stale edits early.
100/100 facts recalled & 0 lost writes
Recalls 100/100 verbatim facts (vs 19/100 with tail truncation) and serializes parallel agents with one OS lock.
02 // HASH-CHECKED CONTEXT HANDOFF · RECORDED LOCAL FIXTURE
Keep the decision. Catch the change.
I dogfooded Memoryfield while building this portfolio across multi-agent sessions, using its AGENTS.md project order to test a simple failure: what happens when the source changes after I’ve prepared the handoff?
- 01 / Carry
A decision with its source
The handoff carries the selected project order, its source reference and a hash of that source.
Oooh → Eternity → Memoryfield → Tripletap
Homepage project order · source passage - 02 / Change
The repository moves on
I swap two projects in an isolated copy. The prepared handoff still contains the earlier order.
Oooh → Memoryfield → Eternity → Tripletap
Controlled edit in a local snapshot - 03 / Refuse
The old source no longer matches
Retrieval refuses the stale handoff. It does not silently return the old passage as current.
Stale source · refused - 04 / Recover
Refresh, then retrieve
I rebuild the handoff against the changed source. Retrieval returns the updated order.
Oooh → Memoryfield → Eternity → Tripletap
Current source · matched
Inspect the memory behind a claim
I put the result, its scope and its supporting record together. The same workspace shows what was checked and what still needs evidence.
- Find a result
Start with the compiled workspace and its recorded checks.
- Inspect the record
Open a run to see its scope, receipt and qualifications.
- See what’s missing
The evidence view makes an offline check and missing runtime evidence distinct.
MemoryfieldWorkspace overview
Context, checks and the records behind them
- AST compaction (101 files)
- 66.56%48,534 / 145,119 tok · 58b0499d · 63.50% on 20 repos · 6f40789f
- Incremental compile p50
- 2.88msone changed file, local · 979cce2b
- Verbatim fact recall
- 100 / 100vs. 19 / 100 tail truncation · 728dc1df
- Handoff fact availability
- 30 / 3012 dev + 18 held-out · vs. 26 / 30 bounded · fd86c860
- Protected writes lost
- 0 / 200vs. 186 / 200 unlocked · 8 workers · 126a5298
Recorded runs
Open a result to see what the check establishes
| Run | Result | Kind | Scope | Inspect result |
|---|---|---|---|---|
Workspace compilation58b0499d | 66.56% | Recorded benchmark | 101-file workspace145,119 → 48,534 tokens · 101 files | |
Less context to carry I compiled one 101-file workspace from 145,119 estimated prompt tokens to 48,534 (20.09ms cold), and re-linking one changed file took 2.88ms at the median. Across a 20-repo fleet, the same compiler cut carried context by 63.50%. Tokens estimated as characters divided by four (receipts 58b0499d, 979cce2b, 6f40789f). Receipt 58b0499d | ||||
Coordinated writes126a5298 | 0 / 200 | Recorded stress test | 8 cooperating workers8 workers × 25 updates · 186/200 lost unprotected · 19.73ms lock wait | |
Protected writes lost Eight workers made 25 updates each. The unprotected run lost 186 updates; the locked run lost none (19.73ms median lock wait). Cooperating processes sharing one advisory lock. Receipt 126a5298 | ||||
Context perturbationsfa289286 | 30 / 30 | Recorded test | 100 constructed draws0 false alarms on 70 clean draws | |
Injected drift caught The shadow check caught all 30 injected perturbations in a 100-draw run, with no false alarms on its 70 clean draws. Constructed perturbations, scored on catches and false alarms together. Receipt fa289286 | ||||
Input-token cost model58b0499d · model inputs | $3,187 | Projection | 22-day cost scenario$56,366/mo modeled for a 20-repo org | |
Modeled monthly input savings Five developers, 100 turns a day, 22 working days and a recorded $3 per million input-token scenario ($56,366/mo modeled across a 20-repo org). Caching is off. Input tokens only; excludes output tokens, tools and hosting. Receipt 58b0499d · model inputs | ||||
4 of 4 results · projections use stated assumptions, not measured customer savings
04 // COMPACTION & RECALL EVAL · 101-FILE WORKSPACE
66.56% less context in one workspace
In one recorded 101-file workspace, the source text was estimated at 145,119 tokens; the serialized compiler output was 48,534 (74.55% mean across its 6 submodules, up to 84.99% on behavior specs).
This earlier benchmark measures output size, not preserved meaning or a completed AI task. The source passages and retrieval needed by the new handoff add their own context cost. Separate benchmarks record 100.0% verbatim fact recall with +0.2296 U-curve positional salience gain (receipt 728dc1df) and a handoff that carried the needed facts in 30 of 30 tasks across 3 repositories (receipt fd86c860), which measures fact availability, not completed model work.
Context before and after compilation
66.56% less context in this run · 74.55% submodule mean
- behavior
- 84.99% (24,461 → 3,672 tok)
- spec
- 79.15% (23,469 → 4,894 tok)
- architecture
- 74.27% (15,183 → 3,907 tok)
- docs
- 71.35% (26,373 → 7,555 tok)
- design
- 69.96% (8,940 → 2,686 tok)
- workflows
- 67.58% (14,453 → 4,686 tok)
04B · CHECKING AI DESIGNS IN TWO LAYERS · WORKED EXAMPLE
Why structural AST checks aren't enough to judge good design
Fast AST checks filter out broken drafts automatically so human raters only spend budget grading visual hierarchy, user intent, and reversibility.
Broken geometry & detached tokens
Rigid 220px width, raw #ef4444 hex, and 2.5x German clipping caught automatically before human review.
Auto Layout · Tokens · ContrastPasses every AST rule, fails user intent
Passes 4/4 AST rules, but equal 1:1 button weight invites accidental destructive clicks.
1:1 Weight · Hierarchy RuleResolving inline vs. modal disagreement
Scopes inline vs. modal layouts by reversibility and requires a neutral secondary Cancel.
Reversible vs. PermanentInspect interactive 3-stage UI evaluation fixture (AST floor, 1:1 hierarchy false positive, and inline-vs-modal rater calibration)
Taking Memoryfield beyond my own workspace
Memoryfield is now my cold start: every new project, branch or version starts by running it, so changes get logged the same way and long sessions stay inside firm boundaries. It made me more methodical. I dogfooded Memoryfield while building this portfolio: when one agent edited AGENTS.md mid-session, the file-hash watchdog caught the mismatch before a second agent could overwrite it.
The same gate carries over to design files. I ran it on my blog’s Figma file: 1,595 of 1,671 UI colors were hard-coded hex, none of its 398 text layers used a text style, and one token name hid a trailing space. Every alias resolved, and every run left a hashed receipt. What a gate can’t judge is taste. As the judge, jury and executioner, I put the file on hold: a hygiene pass to unify the grays first, then an audit, then tokens.
My most useful result was a failure. My first 1,000-draw drift baseline flagged 99.62% of injected perturbations, but all 740 clean draws raised errors too, and my false-positive formula halved that to 50%. A check that always fires gets credit for catching everything. Now every catch rate sits beside its false-alarm rate: the next check, forty minutes later, caught 30 of 30, with 0 false alarms on 70 clean draws.
If I started over, I’d build in more counterfactual evaluations from day one and give parallel agents across models more coordination and less conflict. I’d design the compiler, its health observability and its evals as one deterministic system instead of cobbling on add-ons.
Model input-token costs and operating assumptions
Model the cost of carrying context
The token counts come from one recorded compiler benchmark. Rates, cache behavior, recovered time and platform cost are editable assumptions. This model does not measure customer savings.
$3,187 / mo modeled input savings (66.56% reduction) · 101-file workspace (145,119 → 48,534 tokens) across 5 developers × 100 turns/day × 22 working days at $3/M input tokens ($4,789 raw → $1,602 compiled). Receipt 58b0499d
The recorded baseline uses $3. Edit this assumption to compare another rate; this is not a current price feed.
Off by default. Enabling it applies the same hit and rate fractions to both raw and compiled inputs; the benchmark does not establish a cache hit rate.
Monthly input-token savings
$3,187$4,789 raw → $1,602 compiled
66.56% modeled reduction · $38,248 / year
Assumed recovered time
Enter hoursEnter recovered hours and an hourly value to model time savings. Write-loss tests do not measure recovered engineering hours.
Modeled net return
Enter costIncludes token savings and assumed time value, less $0 / month platform cost.
Modeled payback
UnavailableBased on 22 working days per month. This is a scenario, not an observed deployment result.
Explore the engineering, test records and visual references
What the checks show
Less context to carry
I compiled one 101-file workspace from 145,119 estimated prompt tokens to 48,534 (20.09ms cold), and re-linking one changed file took 2.88ms at the median. Across a 20-repo fleet, the same compiler cut carried context by 63.50%.
Tokens estimated as characters divided by four (receipts 58b0499d, 979cce2b, 6f40789f).
Protected writes lost
Eight workers made 25 updates each. The unprotected run lost 186 updates; the locked run lost none (19.73ms median lock wait).
Cooperating processes sharing one advisory lock.
Injected drift caught
The shadow check caught all 30 injected perturbations in a 100-draw run, with no false alarms on its 70 clean draws.
Constructed perturbations, scored on catches and false alarms together.
Modeled monthly input savings
Five developers, 100 turns a day, 22 working days and a recorded $3 per million input-token scenario ($56,366/mo modeled across a 20-repo org). Caching is off.
Input tokens only; excludes output tokens, tools and hosting.
Require evidence before moving forward
根拠を 確かめる
確かめた範囲と、まだ分からないことを分けて残したい。AIの出力がすべて正しいと保証するものではない。
Each claim advances through four explicit states: proposed, offline receipt check, runtime receipt check on the same artifact, and separate approval.
Claim lifecycle: proposed, then offline with an offline receipt, then runtime verified with a runtime receipt for the same artifact, then accepted with a separate approval.
I require evidence before a claim advances to the next state. A canary that references a class that doesn’t exist makes the gate fail on purpose, so a green check actually means something.
The worked example below shows where promotion stops when a citation check passes but no runtime receipt exists for the same artifact.
Failed checks stay linked beside their eventual repair so the next session sees the full diagnostic history instead of an unexplained green light.
Historical records · 2 Oct 2026 (UTC)
Canary
Fails on purpose
- check
- css-references
- input
- references a class that doesn’t exist
- result
- FAIL, exit 1
Canary check
VALID: the gate failed on the canary run (FAIL, exit 1)
Gate
Normal run
- check
- css-references
- input
- no injected reference
- result
- PASS, exit 0
Historical records, 2 Oct 2026 (UTC). The canary references a class that doesn’t exist, so the gate should fail, and it did. That expected failure is what makes the gate’s pass worth reading. The gate covers literal style references only.
Inspect compiler architecture and recorded checks
CONTEXT ARCHITECTURE
Give each record a job
Working context
The current task, constraints and decisions. Cooperating writers acquire the same advisory lock before updating shared state.
Dependency graph
Repository records connected by references. The compiler resolves those links and reports structural problems.
Evidence store
Content-addressed receipts retain check results. A matching hash detects changed content; it does not authenticate the operator.
RECORDED BENCHMARKS
Inspect the recorded fields
Workspace compaction
One 101-file workspace, 162 nodes and 298 edges (74.55% mean across 6 submodules, 84.99% max on behavior). Token counts are estimated as characters divided by four.
{
"raw_estimated_tokens": 145119,
"compiled_estimated_tokens": 48534,
"reduction_percent": 66.56,
"mean_submodule_percent": 74.55,
"max_submodule_percent": 84.99,
"compile_ms": 20.09
}A shared visual language
I designed one shared visual system across the Memoryfield web app, my CLI tools, and GetSocrates.dev (my macOS AI coding partner): dark glass panels, status badges, and monospace run traces that keep dense logs scannable.
Memoryfield.ai screen
Memoryfield.ai landing page: the memory governance headline beside a compile trace you can inspect, on a dark glass panel.
Memoryfield workspace
Memoryfield SaaS workspace: separates empirical compiler benchmark receipts from clearly labeled API cost projections.
Socrates
GetSocrates.dev desktop environment: my macOS AI coding partner, sharing the same dark-glass workspace and compact terminal skills panel.
Memoryfield
Memoryfield About page: restrained spectral accents and high-contrast monospace readouts for long reading sessions.
Start with one check
The four evidence figures below trace how a claim is graded from initial gate to handoff. Claim E-1 is a reading-time test fixture: its offline receipt matches, but promotion stops at the runtime gate because no runtime receipt names the same artifact. The optional citation fixture tests a separate question: whether a written number matches its receipt.
Reading-time model · test fixture
Claim E-1: The model estimates 0.3 min for 61 words.
Estimated human reading time: about 18 seconds. This fixture does not measure AI response latency.
- proposed, needs claim filed
- offline, needs offline receipt
- runtime-verified, needs runtime receipt for the same artifact
- accepted, needs separate approval
Offline receipt
- kind
- offline
- exit
- 0
- word_count
- 61
- reading_minutes
- 0.3
receipt 9e9acef3 · artifact 5c056e6f
citation check: 3 of 3 cited numbers in the fixture match
Runtime gate
- proposed to offline
- Allowed
- cites receipt 9e9acef3
- offline to runtime-verified
- Refused
- runtime_receipt_required
- state stays offline
exit 1 · a row was refused
Claim E-1 estimates 0.3 minutes for 61 words. The offline receipt matches, so that check passes. Promoting the same claim to runtime-verified is refused because no runtime receipt names the same artifact. The state stays offline. This worked-example test fixture (v17.2 proposal, 29 Sep 2026) illustrates the gate, as asserted by the validator suite. It is not live production telemetry. The gate reports the refusal; enforcing it is up to the host.
Inspect the citation-check fixture
Receipt · test fixture
- p95_ms
- 41.83 test value
cited as [r:…
Citation check
Cited value ± half its last written digit
| Measured cell | Written to (ms) | Accepts (ms) | Receipt (ms) | Citation check |
|---|---|---|---|---|
| Test 1 41.8 ms [r:… | 0.1 | 41.75–41.85 | 41.83 | PASS, exit 0 |
| Test 2 42 ms [r:… | 1 | 41.5–42.5 | 41.83 | PASS, exit 0 |
| Test 3 44.0 ms [r:… | 0.1 | 43.95–44.05 | 41.83 | FAIL, exit 1: citation_ |
Test 2 also cites the receipt by a 12-character id prefix
Validator test fixture. Values are test values, not measured product latency. A cited number in a governed field passes when the receipt falls inside the band its written precision allows; the checker doesn’t judge units or whether the right input was measured. Test 3’s 44.0 ms would clear the gate (p95 under 50 ms); it fails because the number doesn’t match its receipt. It hasn’t yet compared a number in a real checkpoint record.
Connect the next session to the record
When a check fails, the handoff keeps the failed run linked to its repair in the kept-failure slip below so the next session can inspect what changed. Matching hashes prove file consistency across runs, while the chapter on coordinated writes covers multi-agent lock stress tests.
Inspect the failed run and its repair
Historical records · 2 Oct 2026 (UTC)
interaction check
Run 1
- css
- PASS
- invitation
- PASS
- lint
- 4 errors, 2 warningsFAIL
- build
- BLOCKED
- not run: lint failed first
- browser
- BLOCKED
- not verified
3,414-byte failing test source, hash matches the receipt
interaction check
Run 2
- css
- PASS
- invitation
- PASS
- lint
- 0 errors, 2 warningsPASS
- build
- PASS
- browser
- BLOCKED
- not verified
- owner acceptance
- NOT MEASURED
- not verified
links to run 1 (VERIFY.md)
- Kept, not relabeled. Run 1 still records its failure and its exit code.
- Build wasn’t run. Lint failed first, so the build was skipped, not passed.
- The same two warnings. Run 2 keeps the same two lint warnings run 1 recorded; they were already there.
- The repair links back. Run 2’s verification notes link to run 1: a document link, not a hash chain.
- Not everything is green. In run 2 the browser check stayed blocked and owner acceptance wasn’t measured.
Two runs of one check, 2 Oct 2026 (UTC). The failure stays on the record and the repair links back to it. Browser checks stayed blocked in both runs. The store is advisory: matching hashes show the files are consistent, not who ran the commands.
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