Structured memory

A long thread cannot carry every fact about a project in its conversation. darting.dev separates shared project knowledge from the context of an individual thread: the Knowledgebase keeps durable facts, while compaction and delegation keep a conversation workable.

Knowledge you can return to

Knowledge entries explain how your project works across files: architecture, data flows, conventions, security boundaries, and decisions that code alone might not explain. They live in a versioned document store, not in your repository. The project page's Knowledgebase lets you browse an area's chapter, its entries, and the plans filed under it. The Organizer rebuilds their area map from the corpus and files proposals for overlaps, contradictions, and references to missing files. Background knowledge-maintenance runs check those proposals against the code and settle them automatically.

Rules and plans also live in the document store. Rules guide agents; plans capture work to be built. You can inspect a document's history and authorship where its history is available — see Collections & history.

An index first, detail on demand

Every lead and sub-agent starts with a Project Knowledge manifest: the product and system overview, plus an outline of area names and descriptions. Unfiled entries are not listed under an area. The manifest gives an agent a route into the knowledge, not the full bodies of all the entries.

When a task calls for detail, an agent can search the knowledge by meaning (including unfiled entries), open the relevant area for its chapter and an index of child areas, entries, and plans, then read the specific document in full. That is the same map you browse on the project page, without pasting hundreds of entries into every prompt.

new turn → project overview and area outline
             → search for a fact or open an area chapter
                → read the document needed for this task

Publish memory with the work

Knowledge and rule writes about code being added or changed stay pending in that thread. Facts already true of the shared code, or settled decisions, can be saved immediately; plan writes follow the thread's publish lifecycle. The agent can inspect its pending writes while it works, but other threads do not treat branch-specific claims as published knowledge. Ship it publishes them with the thread's work; a document-only thread can publish its pending documents without a code pull request. See Ship it & pull requests.

Context within one thread

The knowledge manifest solves shared memory; a single conversation can still grow long. Sub-agents do focused work in fresh contexts and report back. If the thread approaches the model's context window, it compacts and continues. The context inspector shows what was actually supplied to an agent on a turn; compaction & context covers the per-thread controls.