Your product is rarely one repository. Why should your agent's memory be?

I kept doing the same thing without noticing. A session in one repo would work something out about another, that the bug isn't in the UI, it's in the SDK, that the retry belongs one layer down. Then the session ends, and a fresh one in that other repo starts from nothing.

My workaround was pasting the old conversation in. That's bad in two specific ways: it carries no provenance, you can't tell which commit the claim was true at, and it silently ages. Pasted context happily asserts things about code that changed last Tuesday.

The boundary nothing I looked at drew

The framing I landed on splits into two questions that most tools answer with one boundary: what can this agent edit, and what related evidence can it retrieve. The repo should stay the edit boundary. The workspace should become the context boundary.

I surveyed ten similar projects first. Two came close. context-router already does multi-repo workspaces, but its unit of memory is an observation written at commit time. anchor already does confidence and freshness, derived from merged GitHub PRs. Neither captures the thing I actually wanted: most agent work never becomes a commit or a PR. The dead ends, the “it's actually the SDK's fault” moment, the question left open, that is the material worth keeping, and it only exists in a finished session.

The bug that broke the exact case the tool exists for

My first version stamped every finding with the session's commit. A finding about the SDK carried the UI's SHA, which doesn't exist in the SDK's history, so every cross-repository freshness check silently returned unknown. I only found it by importing a real coding-agent session instead of my own fixture. Provenance is per repository or it is meaningless.

A confident wrong answer is the failure mode worth engineering against. Freshness returns unknown rather than guessing.

There is no heuristic inferring findings from transcript prose. A regex for “I found that” produces exactly the plausible nonsense the whole trust model exists to prevent, so it didn't get built. Retrieval has to explain itself instead: every result says “docs-ui uses upload-sdk (direct consumer)” or “matches symbol uploadDocument”, never just a score.

The result I didn't want but published anyway

On a 15-query evaluation, plain SQLite full-text search matched my relation-aware ranking on hit-rate. The corpus wasn't hard enough to tell them apart, and the honest read is that this proves topology helps order results, not that it helps find them. That's a narrower claim than I set out to make.

What topology measurably bought: cleaner ranking, exact repository attribution, and zero context pollution from an unrelated project. A harder corpus with near-duplicate findings is the experiment that would settle whether it helps find rather than only order, and it is top of the roadmap for exactly that reason.

What it became

A local-first MCP server and CLI. SQLite and FTS5, four runtime dependencies, no cloud account, no embeddings, nothing leaves the machine.

wctx capture --summary "traced the upload failure into the SDK" \
  --finding "SDK swallows the 419 :: returns it terminal, no retry" \
  --repo my-sdk --file "src/upload/upload.ts#uploadDocument"

# later, from a different repo:
wctx search "has anyone looked at this?"

Verified against a live coding-agent session, not just fixtures, which is how the provenance bug surfaced in the first place. Still honest about what it doesn't do: no automatic capture yet, evidence exists only when an agent or a person records it. Retrieval is keyword-shaped. Freshness answers “did the files change”, never “is the claim still true”. Relations are declared, not inferred.