Architecture
Previously has a single kernel, but two ways to run it: deployed to Vercel, it is a Next.js app with your own private GitHub repo as the store (the recommended form); on your machine, it is a local server the npm client spawns. Both run the same code and read and write the same memory format — the only difference is where the files land.
One kernel, two homes
Vercel (recommended). The same codebase deploys to Vercel, where memory reads and writes go through the GitHub API against your own private repo. No database: state lives entirely in files — the files just lie somewhere else. Deployment steps are in Deploy on Vercel; the execution machinery unique to the cloud form (durable runs, resuming after dropped connections) has its own page: How a Cloud Turn Works.
Local (npm). The kernel ships as an npm package, pinned exactly by the client, reading and writing a memory directory on the local filesystem — a git ledger maintained in pure JS (isomorphic-git), no git binary required. See Local First.
A prompt frozen to the slice
The system prompt is assembled in layers, and the ordering is a caching decision:
L0 identity constitution → L1 user card → L2 static rules
→ slice-head snapshot → timeline brief → strands menu
This layered prefix is byte-stable for the lifetime of a slice — the provider's prefix cache reuses it across turns, which makes it cheap and fast. That stability is also the reason behind a counterintuitive decision: precise time is not in the prompt, because injecting a timestamp would break byte stability. When the agent needs to know what time it is, it calls the currentTime tool — like someone who ignores the wall clock and checks their watch instead.
When a slice closes and a new one opens, the snapshot updates: the prompt's freeze is scoped to the slice.
The write path: append-only and self-healing
Memory only grows, never rewrites. When two writers commit different versions of the same turn, the kernel does an append-only turn merge keyed by turnId instead of letting one overwrite the other — history stays auditable forever, and there is no "last write wins".
Colleagues and evolution
Around the main agent sit three colleagues with independent judgment (recall, webSearch, thinkDeep) and a Darwinian self-evolution loop. Each deserves its own page: Colleagues, Not Tools and The Evolution Loop. Architecturally only one thing matters here: they all obey the same discipline — evidence anchoring, with evolution writes confined to a single writer — and where that discipline is enforced is the next section.
The security model
Security is enforced at the tool boundary, identically in both forms:
- Path whitelist — agent tools may only write under the memory-related directories; paths are normalized first, then absolute paths, drive letters, and directory traversal are rejected. The code directories simply aren't on the whitelist.
- Server-side validation — every write is re-validated on the server; the shape the client sends is not trusted.
Deployed to Vercel there is one more, optional line of defense: non-browser callers must carry ACCESS_SECRET. It belongs to the cloud form — see How a Cloud Turn Works.
In one line: one kernel, one frozen prompt, one append-only write path — every architectural decision serves "memory that is reliable and cheap".
Related
- Local First — how the kernel ships and runs as an npm package
- How a Cloud Turn Works — the durable execution machinery unique to the Vercel form
- The Memory Model — the data structure this kernel reads and writes