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 database — the source of truth — and is materialized as a file under .agent-swarm/knowledge/ inside every sandbox, so any agent can read it. You browse, edit, or delete them in the Collections view, and every entry shows which agent wrote it.

Knowledge is injected, not pasted

Every agent — the lead and every sub-agent — starts each turn with a manifest of the knowledge base: each entry's title, path, and one-line summary. It's cheap (just an index), and it's always there.

When an agent needs the detail, it reads 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 ─▶ knowledge manifest (titles + one-liners)
             └─ agent reads the entry it needs, on demand

The base maintains itself. A background knowledge automation keeps entries current as the code changes and proposes new ones — you review and approve.

Context that manages itself

Within a single thread, the conversation can still grow long. darting.dev handles that at two levels.

Delegation keeps the lead lean. Heavy exploration, UI validation, and review run in sub-agents with their own fresh context. The lead gets a short result back, not the entire investigation — so the main thread's context stays small while real work still happens.

Compaction at the wall. When a thread approaches the model's context limit, darting.dev compacts it automatically — first by dropping the bulky tool output the agent has already acted on, then, if needed, by summarizing earlier turns into a single note. The thread keeps going instead of hitting a wall. You can change the strategy, trigger it manually, or turn it off per thread.

Context you can see

A 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 — with a warning as the window fills. 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.