Structured memory

The context-window problem is really a memory problem. darting.dev splits it in two: a durable knowledge base that lives across threads, and per-thread context management that keeps a single conversation from overflowing. You manage neither by hand.

The knowledge base: a company brain

Most tools store memory as flat text — rules, AGENTS.md, skills. darting.dev keeps those, but adds a materialized knowledge base: structured documents that capture how your project actually works.

These aren't shallow summaries. A background agent reads the codebase and writes durable entries on the things that span many files and that the code alone can't tell you — for example:

• System architecture — the services, where they integrate, and the seams between them
• Data model — what owns the schema, how it's queried, and the invariants that hold
• Request lifecycle — the path from edge to handler to database, and the patterns in between
• Conventions & bans — the "one right way" your linter actually enforces
• Security model — trust boundaries, auth, and how input is validated
• Tech-debt map — what's canonical, what's vestigial, and what's mid-migration

Each entry lives in the project's document store — the source of truth, versioned like everything else (Collections & history). Agents read it through tools, not files, so nothing has to be committed to your repo for the swarm to know it. You browse, edit, or delete entries in the Collections view, and every entry shows which agent wrote it and why it changed.

The Atlas: a map, not a pile

A knowledge base that works gets big — hundreds of entries — and a flat list of hundreds is a pile, not a map. The Atlas keeps it navigable: every document is filed under an area (a real subsystem of your product), areas group under emergent parents into a shallow tree, and a standing Organizer automation rebuilds the whole thing from the corpus itself — clustering by meaning, folding duplicates, and flagging contradictions for your review.

The Atlas has the full story; the same taxonomy classifies threads and plans, which is what the Project Map is built on.

Knowledge is injected, not pasted

Every agent — the lead and every sub-agent — starts each turn with a manifest of the knowledge base, grouped by the Atlas's areas: each area's name and what it covers, plus a one-line "use this when…" trigger for entries not yet filed. It's cheap (just an index), and it's always there.

When an agent needs the detail, it drills in: open the area's chapter — how that subsystem works, plus the entries and plans filed under it — then read the one entry it needs. So agents stay grounded in your architecture without you pasting background into every new chat, and without paying to carry the whole knowledge base in every request.

new turn ─▶ manifest (areas + entry one-liners)
             ├─ open the area chapter it's working in
             └─ read the one entry it needs, on demand

The base maintains itself. A background sync automation keeps entries current as the code changes and proposes new ones, and the Organizer keeps the Atlas's shape true to the corpus — you review and approve in the Inbox.

Context that manages itself

Within a single thread, the conversation can still grow long. Delegation keeps the lead lean — heavy work runs in sub-agents with their own fresh context — and when a thread approaches the model's limit anyway, it compacts automatically and keeps going. Compaction & context covers the mechanism and the per-thread controls.

Context you can see

The context inspector shows exactly what each agent knows this turn — every fragment, the rules and skills in scope, the knowledge manifest, and the live token count. Memory in this system is inspectable, not a black box.

Streams vs. documents

Streams are the transitory record of what an agent did. The knowledge base is the durable record of how your project works — and it's what future agents are grounded in.