TL;DR: Self-driving agents are the destination everyone agrees on. The bottleneck isn’t autonomy or planning - it’s memory. Forkable experience is the property that turns one car into a fleet.
Cursor has been pushing “self-driving codebases.” Anthropic’s harness research and OpenAI’s Codex work converge on the same destination: an agent that runs autonomously over hours and days. Plans, executes, recovers, ships.
They’re right about where this is going. I think the conversation is wrong about what blocks the road.
Most of the discussion focuses on autonomy: longer horizons, better planning, more reliable tool use, lower error rates. All real problems. None of them are the bottleneck.
The bottleneck is memory architecture. Specifically: whether your agent’s experience is forkable.
One car or a fleet
An agent that self-drives without forkable memory is a single instance re-learning every lesson from every fork. Whatever it figured out in session A is gone by session B. Whatever fork #237 painfully discovered, fork #238 has to discover again.
Self-driving without forkable memory is one car hitting every pothole. Self-driving with it is a fleet that learns each pothole exactly once.
The fleet model is what makes self-driving economically viable. Tesla doesn’t ship millions of cars where each one learns from scratch. The fleet shares experience because the cars share a memory layer that consolidates what every instance saw. Agents need the same thing. Most don’t have it.
A worker without memory is a goldfish with a PhD, reasoning about whatever’s in front of them and then forgetting. Add memory and the agent remembers across sessions. Add forkable memory and every other instance of the same agent inherits the lesson - a new fork doesn’t onboard, it boots with the institutional memory loaded.
Human memory is bound to one body. When a person leaves a company, their experience leaves with them. The next person learns from scratch, and companies spend enormous effort fighting this with wikis and runbooks and still lose most of it. Agent memory has none of those constraints. Forking is the asymmetric advantage of digital workers, and the design constraint most memory systems aren’t built for.
The architecture that delivers it
Model + harness + memory is the anatomy of the agent. Each layer plays a different role in delivering forkability.
The brain. The model is raw reasoning. Tokens in, tokens out. No state, no awareness of yesterday. Useful only with the rest of the anatomy. The model layer is also commoditizing: models converge on benchmarks every quarter, and almost no production system survives by betting on a specific one. The work has moved to what wraps around it.
The body. The harness is the runtime where the agent runs - Claude Code, Hermes, OpenClaw, NemoClaw. Its core job is one thing: decide which fragments of context the brain sees on every turn. Every object loaded into the context window is a fragment with a token cost: the system prompt, a retrieved page, the result of the last tool call. The harness is the policy that decides which fragments are worth their weight on this turn, and which ones get evicted. Tool routing, error recovery, observability all fall out of this single job.
The experience. This is where forkability lives or dies.
What forking forces
Two primitives, not one. Memory splits into atomic facts and compressed summaries - memories and knowledge pages. The reason isn’t aesthetic. Forking pulls reads and writes in opposite directions. Writes are massively parallel, contradictory, append-only by necessity: ten thousand forks each retaining what they observed, no coordination, full history preserved so contradictions can be resolved later. Reads are the opposite - they have to be fast, prompt-sized, and consistent across forks, because every fork is reaching into the same shared store on every turn. A single layer that tries to be both either overwrites history (and loses the audit trail) or re-summarizes from scratch on every fetch (and dies on cost). The split isn’t a feature. It’s what you’re forced into the moment forking is real.
The worker reads, the system writes. The agent only does two things with memory: read pages on demand, retain memories as it talks (the harness streams the conversation in automatically). The agent can declare what a page tracks - its scope, its query - but never the body. The reason is structural: only the system has the cross-fork, cross-session view that makes a good body.
The failure modes stack up:
- One conversation is the wrong input. A good page summarizes across all sessions and all forks. The agent inside any single chat only sees the slice in front of it.
- Drift compounds. If any agent could write back to pages, the next agent loads its confabulations as fact. Server-side refresh grounds every regeneration in retained memories and breaks the feedback loop.
- Concurrency. A thousand forks can retain memories in parallel without coordinating. They cannot all edit the same page. The fleet model collapses under write contention the moment writers proliferate.
The read side splits for a related reason: the agent sometimes knows which document it wants and sometimes doesn’t. A single read interface forces it to either always load too much (slow, expensive) or always search (lossy when the answer was right there). Two read modes - whole-document fetch and semantic search across memories - covers both cases without compromise.
This is what Hindsight is built around. Every alternative I’ve tried - letting the agent edit pages in-loop, single-tier vector stores, no separation between facts and summaries - broke on one of those axes the moment forking became real.
What’s still unsolved
The framing is settling. The hard problems inside it aren’t.
Distilling experience over ultra-long horizons. Agents produce massive volumes of raw interaction data: every tool call, every observation, every retry. Dumping traces into a vector store is the easy thing. The hard thing is distilling them into higher-level primitives that capture causal patterns, recurring failures, durable preferences. Hindsight’s consolidation pipeline - memories distilled into facts, facts regenerated into pages - does this at session and week scale, and I haven’t seen another architecture even attempt the substrate problem at this layer. Stretching the same pipeline to month- and year-long timescales is still open. But the precondition for any answer is the two-primitive split: you can’t distill what you didn’t preserve.
Just-in-time retrieval vs. baked-into-weights. Right now memory is mostly external. A chunk of what an agent learns will eventually want to live in model weights, distilled and fine-tuned. The split between “search this every time” and “internalize this once” is one of the biggest open architectural questions of the next few years. The likely answer is dynamic: items get promoted from storage to weights as their access patterns prove they’re durable.
Models self-managing context. Today the harness decides what enters and exits the context window. Models are getting better at metacognition, but every time a model operates on its own context, error rates compound. Reducing those compounding errors is what will let agents run for hours and days without intervention.
Some of this will get absorbed by better models - distillation will improve, metacognition will reduce error rates. But forking is a property of how agents are deployed, not of the model. The architecture that takes forking seriously now will still take it seriously when the models are better.
Conclusion
Self-driving agents are the right destination. The conversation around it is mostly wrong about what blocks the road. The bottleneck isn’t planning quality or task horizon - it’s whether your agent’s experience replicates across forks.
If you’re building agent infrastructure, the question isn’t “how do we add memory?” It’s “how do we design for ten thousand forks from day one?” Build for the fleet. The single-car version is what gets lapped.
If you don’t want to build it from scratch, that’s what Hindsight is.