MEMORYVAULT · INTEGRATED MEMORY SYSTEM · 2026-06-16

The Vault vs. Code Search

Why grep can't answer the questions that cost us the most time — and how an accumulating, relational memory does.

Code search answers “what does this code do right now?”
The vault answers “what do we know — across repos, over time, including what isn’t in any file?”

5
Question types grep loses
~10–30×
Fewer tokens / lookup
35
Repos synthesized
Weekly
Auto-synced from git

Token figures below are order-of-magnitude estimates for an AI agent doing the search (grep + reading candidate files) vs. reading one vault page. Human minutes vary by familiarity — shown as a rough secondary signal, not a promise.

1. Cross-Repo Relationship ~25× fewer tokens

grep is blind across repo boundaries

Why does the ‘Install Steam Guard’ modal sometimes show on accounts that don’t need it?

Code search — ~18k tokens, ~10 min

  • grep the modal string in new-tradeit → finds an exact-string match, no source
  • grep tradestate across ~35 repos → tradebot publishes it
  • trace socket-server relay → back to new-tradeit's compare
  • May never connect the ends — no file references the other side

Vault — ~0.7k tokens, one lookup

  • Open string-as-protocol-coupling
  • The full contract: tradebot msg → socket-server relay → new-tradeit modal
  • Why it’s fragile + the incident that exposed it + fix direction
  • Wikilinks jump to all three repos
grep + read
~18k tokens
vault lookup
0.7k

Why grep can’t win: the knowledge lives in the connection between repos, not in any file. Grep is per-repo and per-string by construction.

2. Negative / Tribal Knowledge ~16× fewer tokens

the answer is something that isn’t in the code

Find all the logs for partner steamID 7656… to debug their failed trade.

Code search — ~5k tokens, ~5 min

  • Query Datadog for the steamID → 0 results
  • Wrong conclusion: “we’re not logging this”
  • Read the logging code to find out why
  • Eventually learn fields nest under @context.*

Vault — ~0.3k tokens, instant

  • Open infra-conventions § Datadog
  • “Bare keyword search returns 0 — query @context.partnerId:<id>”
  • DDSQL aggregation recipe included
  • Correct query on the first try
grep + detour
~5k tokens
vault lookup
0.3k

Why grep can’t win: the code looks correct and the search returns a false zero. The “looks-fine-but-here’s-the-trap” layer isn’t expressible in source.

3. Resolved Ambiguity ~30× fewer tokens

when the code itself looks contradictory

Does tradeit-backend call the tradebot directly, or go through old-tradeit?

Code search — ~15k tokens, ~8 min

  • Two architecture sources disagree
  • Read backend’s 18-guard chain and old-tradeit’s 28-guard chain
  • Across two repos, still risk landing on the stale one
  • Real chance of a confidently-wrong answer

Vault — ~0.5k tokens, one lookup

  • Open repo-tradeit-tradebot-server
  • “Both are correct — the path differs by user type”
  • Web users via backend; auto-traders direct to old-tradeit
  • “verified by Ehud 2026-05-12” — dated + attributed
grep + reconcile
~15k tokens
vault lookup
0.5k

Why grep can’t win: when two sources conflict, grep gives you both and no way to choose. The vault holds the human-verified resolution, expensive to establish once, free to reuse.

4. Relational Data & Join Paths ~12× fewer tokens

151 tables don’t document how they connect

Which table holds bot trade outcomes, and how do I join it to pricing?

Code search — ~12k tokens, ~10 min

  • Grep schema / migration SQL across repos for likely table names
  • Column names hint at relations but FKs are often implicit
  • Trial-and-error queries to find the join key
  • No business context on what each table is for

Vault — ~1k tokens, ~2 min

  • Open db-steamarbitrage-trading (categorized schema page)
  • Business purpose + key columns + documented join paths
  • Cross-schema: item_id joins pricing ↔ steamarbitrage directly
  • Pairs with the analytics-mcp table_context for live confirms
grep + trial SQL
~12k tokens
vault lookup
1k

Why grep can’t win: relationships between tables are pre-computed once in the vault. Re-deriving join paths from schema files is slow and error-prone every single time.

5. Compiled Understanding ~20× fewer tokens

onboarding: a model, not a pile of fragments

New dev: how does our pricing actually work, end to end?

Code search — ~30k tokens, 30–60 min

  • Grep ECDF / polynomial across pricing-manager + backend
  • Assemble a partial model from scattered fragments
  • Easy to miss a stage or a correction made months ago
  • Every new dev pays this cost from zero

Vault — ~1.5k tokens, ~3 min

  • Open pricing-domain
  • The full pipeline as one explained model + Mermaid diagram
  • Includes verified corrections (e.g. Doppler phase-matching)
  • Links to the code when you need the leaf detail
grep + assemble
~30k tokens
vault lookup
1.5k

Why grep can’t win: understanding is compiled once and reused. Code search recompiles the same mental model from scratch for every person, every time.

“Won’t it just go stale?”

the strongest part of the pitch

Self-maintaining

A weekly job diffs every repo’s commits and proposes vault updates automatically — it tracks the whole team’s work, not one person’s notes.

Compounding

Code search starts from zero forever. The vault gets cheaper and smarter every time someone resolves something hard.

Layer-separated

“How to work in repo X” stays in that repo’s CLAUDE.md (PR-reviewed). The vault holds cross-repo synthesis. They don’t duplicate, so neither rots.

Code search is right for “what’s the current implementation?”
The vault wins decisively on cross-repo relationships, non-obvious gotchas, and hard-won resolutions —
exactly the questions that eat senior-engineer time.

Generated 2026-06-16 · tradeit.gg · all 5 examples are real pages in the MemoryVault