# Does an Agent Need Its Own Memory If Engineering Context Is Already in GitHub? > Canonical: https://vxi.me/en/posts/beacon-local-memory-capture-causality/ > Locale: en-us > Published: 2026-10-27 > Updated: 2026-10-27 > Markdown: https://vxi.me/en/posts/beacon-local-memory-capture-causality.md

Both public suites passed, but both independent hidden checks failed. The applicability mismatch is a plausible explanation, not a proven root cause.

The first two posts in this series covered two different questions: [GitHub-first handoffs](https://vxi.me/posts/github-first-ai-coding-context-handoff-workflow/) explain how engineering state can survive across tools, while [Local-first vs. GitHub-first](https://vxi.me/posts/local-first-vs-github-first-architecture/) draws the boundary around data access and execution permissions. The remaining question is whether a separate Agent Memory layer adds anything that the repository cannot already tell an agent. My short answer: **do not add an independent memory layer just because you expect it to make coding faster.** If an agent can derive a rule from README, AGENTS.md, Makefile and tests, keep that rule there. Memory is worth exploring for historical decisions the repository no longer explains. In these three rounds, cross-harness retrieval really happened, but it did not improve the consumer task's independent acceptance result. ## When the repository already knows the answer The first round used Beacon 1.3.46 (build `f8177a68`) and Codex CLI 0.162.1 on macOS arm64, with a Local endpoint. The synthetic project had an API definition, a README explaining that generated code was checked in, a Makefile target, and tests checking consistency. At first glance, the no-memory control A0 failed while the Beacon path passed 3/3 tests. The post-run review exposed two confounders: A0 was in a read-only sandbox and could not edit files, and the first-round error output revealed `make gen`. That is a bad control and a leaked hint, not evidence that memory made the agent smarter. In round two, the sandbox was writable and the leaked hint was removed. The no-memory A0 read the README, Makefile and tests, inferred the generation rule, and passed its 1/1 test. I crossed out the claim that memory had caused repository-rule reuse. If the repo already says what to do, crediting Memory is just marketing with extra steps. | Experiment | Observed result | What it supports | |---|---|---| | Round 1: A0 vs. Beacon path | A0's read-only sandbox was invalid; the Beacon path's approved candidate was materialized as a Skill and read in a new session, followed by 3/3 passing tests | No causal memory benefit can be inferred | | Round 2: writable A0, no memory | Derived the rule from repo files; 1/1 test passed | Repository facts were sufficient for this task | | Manual Checkpoint | Read `CHECKPOINT.md`; 2/2 tests passed | A visible, versioned handoff can work too; no fair speed benchmark was run | | Round 3 training: Codex | TSV public tests 3/3 PASS; controller's hidden check PASS | The training task passed, not automatic distillation or cross-harness reuse | | Round 3 consumers: Antigravity A0 and MCP | Both CSV public suites 3/3 PASS; both independent hidden checks FAIL | Retrieval happened, but task improvement was not demonstrated | The denominators come from different synthetic fixtures and must not be compared as if they were one growing test suite. ## Checkpoint and Agent Memory serve different jobs I did not time the manual Checkpoint and Beacon paths with a common method, and their correction steps differed. Retrofitting comparable time or token numbers now would be made-up precision. Their engineering trade-off is still clear: a Checkpoint is an explicit handoff that travels with Git and can be reviewed; Agent Memory is closer to an automatically accumulated notebook. A notebook can preserve why a decision was made, but it can also preserve a stale decision. | Knowledge | Prefer | Separate memory? | |---|---|---| | Current constraints, build steps and invariants | README, AGENTS.md, Makefile, tests | Usually no; the repository should remain the authority | | Current task progress, verified SHA, blockers and next step | Issue, PR, Checkpoint, CI record | Only if cross-session recovery has a real gap | | Historical decisions absent from the repo | Reviewable decision record or approved memory | Potentially, with source and applicability attached | | Changed rules and temporary exceptions | Update current repo facts and retire old rules | Never rely on simply appending another memory | | Context that must stay inside a data boundary | Keep it inside the approved local boundary | Do not copy it to the cloud just to remember it | ## Round three: the memory was read, but the task still failed This round tested a historical compatibility rule that could not be inferred from the current repository alone: when exporting CSV and TSV, Python `None` should be serialized as the literal `\N`; empty strings remain empty and the string `NULL` stays unchanged. The Codex training trace was turned into a candidate, reviewed, approved and materialized. Antigravity then accessed the approved memory through Beacon Local MCP: the local execution summary recorded one `get_memory` and two `search_memory` calls. That proves retrieval in this run—not successful reuse. | Antigravity consumer arm | Read memory? | Public CSV tests | Independent hidden check | |---|---:|---:|---| | A0, no memory | No | 3/3 PASS | FAIL | | MCP, with memory | Yes | 3/3 PASS | FAIL | The odd part is the scope mismatch. The memory body mentions both CSV and TSV, but its `applicability` metadata only names `render_tsv` / TSV compatibility. The execution summary says Antigravity treated the CSV and TSV functions as separate implementations and did not apply a TSV-scoped rule to CSV. That is a strong explanation, not a proven root cause: the hidden checker returned only aggregate FAIL, without the failing assertion. The scope was either too narrow to transfer the rule, or the missing assertion points to another issue we cannot currently distinguish. Widening the label by hand until the test turned green would test my ability to tune the memory against the answer—not whether the system naturally captured and reused historical knowledge. I stopped instead of manufacturing a happy ending. Both consumer arms failed the same hidden check, so the result does not show that memory made things worse either. There was one synthetic task per arm, and the two underlying model settings were not recorded as a controlled comparison. No comparable wall-clock or token measurements were collected. ## Stale memory, local logs and source boundaries In a separate fixture, the Makefile target changed from `gen` to `generate`, while an old Skill still said `make gen`. The agent hit the error, reread the Makefile, switched to `make generate`, and passed 4/4 tests. The stale Skill remained. This shows that an agent can recover by checking current repository facts; it does not show Beacon automatically retired or updated the old memory. The Local runtime log also recorded the ordinary synthetic marker `PLUMOTTER9917` verbatim: the count rose from 7 to 25 matching lines across the first two rounds. A token-shaped canary `sk-canaryfake` rose from 0 to 4, and `REDACTED` from 1 to 6. I did not inspect those four canary matches, so I cannot say whether they were the test value, a residual prefix, or logged search/test text. Its redaction result remains unknown. No Beacon Cloud was connected, so local log contents are not evidence of cloud forwarding. The source audit was pinned to [Beacon commit d7a3a72](https://github.com/Asymptote-Labs/agent-beacon/tree/d7a3a72fdc0a864655cf2e85fb7de5ba974cde72). The [redaction implementation](https://github.com/Asymptote-Labs/agent-beacon/blob/d7a3a72fdc0a864655cf2e85fb7de5ba974cde72/pkg/asymptoteobserve/privacy.go#L322-L395) relies on field names and known patterns, not universal recognition of arbitrary secrets in natural language. The Codex capture matrix and OTLP conversion code did not show a mapping for Codex File/MCP events in that pinned snapshot; this was a source inspection, not a runtime packet capture. Jev's evaluator was also inspected but never run, so there are no evaluator scores or measured distillation-accuracy results. ## Keep memory for the gaps, not a second copy of the repo These experiments do not prove that Agent Memory is generally effective, nor that it has no value. They do show where I would start: - Put current, testable engineering facts in the repository. - Use Checkpoints for explicit handoffs that need review and version history. - Reserve independent memory for historical decisions that current files cannot explain, and attach source and scope. - Make stale or conflicting memories discoverable and retireable. - Verify local logging, MCP access, hosted evaluation and cloud forwarding as separate paths. The practical verdict is simple: **cross-harness reading was verified; incremental task benefit was not.** The next useful experiment would expose the hidden assertion and use controlled, repeatable tasks—not hand-tune applicability after seeing a failure. Experiment dates: rounds one and two were run on October 26, 2026; the Antigravity MCP consumer round was run on October 27, 2026.