# Structured memory

> How darting.dev captures project knowledge and keeps every agent's context from overflowing.

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](https://darting.dev/docs/collections-and-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](https://darting.dev/docs/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.

```text
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](https://darting.dev/docs/built-in-automations/) keeps the Atlas's shape true to the corpus — you review and approve in the [Inbox](https://darting.dev/docs/inbox-and-proposals/).

## 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](https://darting.dev/docs/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](https://darting.dev/docs/compaction-and-context/) covers the mechanism and the per-thread controls.

## Context you can see

The [context inspector](https://darting.dev/docs/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

| Kind          | Lifetime   | Role                                          |
| ------------- | ---------- | --------------------------------------------- |
| Stream        | per turn   | raw audit trail of one execution attempt      |
| Knowledge doc | persistent | structured architecture, shared across the team |

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.