-
Notifications
You must be signed in to change notification settings - Fork 5
The Memex Bet
"There may be millions of fine thoughts, and the records of experience on which they are based, all encased within stone walls of acceptable architectural form; but if the scholar can get at only one a week by diligent search, his syntheses are not likely to keep up with the current scene."
— Vannevar Bush, As We May Think (1945)
In 1945, Vannevar Bush sketched the Memex — a personal, curated, associative knowledge store. Not a filing cabinet. Not an encyclopedia. A device of trails: every piece of information linked to every other piece by the user's own reasoning, building up over a lifetime into a thinking machine that augmented its operator.
The web came close. So did wikis. So did Obsidian, Roam, Notion. But none of them solved Bush's actual problem. The reason is simple:
The trails decay because no one maintains them.
Linking your notes is fun for a week. Updating them when new evidence contradicts old claims is bookkeeping. Cross-referencing fifteen pages when one new fact arrives is bookkeeping. Re-deriving a synthesis after the underlying sources change is bookkeeping. Humans abandon wikis because the maintenance burden compounds faster than the value.
Bush did not have an answer for who would do the maintenance. The answer did not exist in 1945. It does now.
Andrej Karpathy's LLM Wiki pattern (April 2026) makes this explicit:
- The wiki is the durable, compounding artifact, not the chat
- The LLM is the maintainer that humans never were
- Every source is integrated once and kept current — not re-derived per query
- Contradictions are flagged, not smoothed over
- Every claim cites a real source
This is the Memex with the maintenance problem solved. The LLM does the bookkeeping no human will. The wiki keeps getting richer with every source added and every question asked.
A senior digital forensics analyst is a Memex made of bone and coffee.
They have read tens of thousands of MFT records and recognize the timestomp pattern at a glance. They have seen comsvcs.dll loaded by rundll32 with MiniDump in the command line enough times to know it's T1003.001 LSASS access. They know that EVTX 4624 logon-type 9 with an admin token is almost always T1134 access-token manipulation. They have internalized the difference between Bianco's Pyramid layers — that an IP address is cheap to change but a TTP is not. They know, instinctively, that a contradiction between two artifacts is the most valuable signal in the entire investigation.
This knowledge does not transfer. When a senior analyst leaves the team, the team gets dumber. When the team is asked to investigate a new case at 3 AM, the analysis quality is whoever is on call.
The DFIR profession has been carrying this exact Memex problem for thirty years. Same maintenance bottleneck, different domain.
We took Karpathy's framing and asked: what if the durable, compounding artifact for DFIR is the senior-analyst loop itself?
| Karpathy's LLM Wiki | Agentic-DART |
|---|---|
| Raw sources (immutable) | Forensic evidence (read-only mount) |
| Wiki (LLM-maintained markdown) | Playbook v3 (multi-section YAML methodology — default; v2 retained as baseline) |
| Schema (CLAUDE.md / AGENTS.md) | MCP surface (the typed forensic function surface) + audit chain |
| LLM does maintenance | Agent runs every case, audit-traced |
| Every claim cites a source | Every finding cites an audit_id
|
| Contradictions flagged |
dart-corr — UNRESOLVED blocks emission |
| Wiki compounds over time | Each case adds to the playbook's case classes |
The architectural-first principle goes one step further than Karpathy's pattern: in DFIR, we cannot trust the maintainer. An LLM acting as a wiki editor in a research vault has limited blast radius. An LLM acting as a forensic analyst with shell access has unlimited blast radius. So we removed the shell. The the typed MCP surface (native pure-Python + SIFT Workstation adapters) are not a guideline — they are the entire universe the agent inhabits.
The senior analyst's reasoning is the durable artifact, not the report.
Encode it once, as architecture. Let it run on every case. Let it self-correct against contradictions. Let every claim cite the audit ID of the call that produced it.
If we are right, this is not just a SANS hackathon submission. This is what every DFIR team will look like in five years — a small number of senior analysts curating the playbook, a fleet of audit-chained agents running it, and a maintenance loop that compounds rather than decays.
If we are wrong, the architecture is still safer than the alternative. The agent cannot run rm -rf on evidence. That alone is worth shipping.
- Vannevar Bush, As We May Think — The Atlantic, July 1945
- Andrej Karpathy, LLM Wiki gist — April 2026
- David Bianco, Pyramid of Pain (2013) and Hunting Maturity Model
- Caltagirone, Pendergast, Betz, Diamond Model of Intrusion Analysis (2013)
- Mandiant, M-Trends 2026 — 500K hours of frontline incident response
- Hutchins, Cloppert, Amin, Intelligence-Driven Computer Network Defense — Lockheed Martin (2011)
- About the name
- Architecture deep dive
- Architecture: first vs prompt-first
- Threat model
- dart-playbook — the senior-analyst methodology in YAML
Agentic-DART — autonomous DFIR agent · architecture-first, not prompt-first · MIT license · github.com/Juwon1405/agentic-dart
- The Memex bet ⭐ Why this design
- About the name
- Architecture-first vs prompt-first
- Architecture deep dive
- Threat model
- Glossary
- dart-mcp — typed surface (native + SIFT adapters)
- dart-agent — senior-analyst loop
- dart-corr — cross-artifact correlation
- dart-audit — SHA-256 chained log
- dart-playbook — senior-analyst sequencing rules (v3 default)
- MCP function catalog (native + SIFT adapters)
- Comparison with adjacent tools
- FAQ
- Operator guide — distro-agnostic
- Running on SIFT
- Live mode
- Accuracy report
-
Roadmap ⭐ Phase 1 ~95% complete
- Phase 1 — Agentic DFIR ⭐ dedicated page · SANS submission
-
Phase 2 — Detection engineering
- The self-learning loop ⭐ design note
- Phase 3 — Agentic SOC
- Phase 4 — Broader agentic security