The Atlas
The living map of your product — how documents cluster into areas and stay organized without a librarian.
A knowledge base that actually works gets big. Hundreds of entries, and a flat list of hundreds is a pile, not a map. The Atlas is the map: every document is filed under an area — a real subsystem of your product, like "PR & merge workflow" or "Sandbox & thread lifecycle" — and areas group under emergent parents into a shallow tree.
An area is a chapter, not a folder
A folder holds things. An area explains them. Each one carries:
| Part | What it gives you |
|---|---|
| Name | The subsystem as your team would say it out loud. |
| Description | What the subsystem covers, and where its edges are. |
| Covered paths | The repo paths the area maps to, so a claim has an address. |
| Members | The knowledge entries and plans filed under it. |
So opening an area isn't opening a directory listing — it's reading a chapter about one part of your product, with the source documents attached.
Nobody maintains the tree by hand
The tree is built by the Organizer, a standing automation that rebuilds the Atlas from the corpus itself. Four things happen on a pass:
- Clusters by meaning. Every document is embedded; similar documents cluster into leaf areas, and similar leaves group under parents. The shape is derived from your corpus, not poured into a template someone else chose.
- Names what it finds. A small model labels each cluster with a title, a description, and the paths it covers.
- Keeps identities stable. An area that still matches its documents is kept, not re-minted — keys, links, and classifications survive a rebuild. Areas that empty out retire, and their documents forward to the closest live area. A rebuild reorganizes; it doesn't reset your bookmarks.
- Curates each area. It then reviews the members of each area: identical entries fold automatically, near-duplicates become merge proposals in your Inbox, and contradictions get flagged for you. Nothing merges without your yes. Areas already settled on an earlier pass are skipped, so no model spend goes into re-reading what hasn't changed.
That last point is why the Atlas can run continuously without becoming expensive: the work scales with what moved, not with how much you know.
Agents navigate it the way you do
The Atlas isn't a browsing convenience bolted onto a store agents read differently — it's the same map. The manifest every agent starts a turn with is grouped by area: the areas and what each covers, then the entries inside. An agent working on checkout opens that area's chapter, sees how the subsystem fits together, and only then reads the one entry it needs.
manifest (areas + one-liners)
└─ area chapter (how the subsystem works + its members)
└─ the single entry the task needs
That drill-down is what keeps grounding cheap — the full mechanics are on Structured memory.
One taxonomy, everything classified
Areas don't only file knowledge. Threads and plans are classified against the same tree, which is the taxonomy behind the Project Map's pills. Ask "what's happening in checkout?" and it's one filter: the knowledge that describes it, the plans proposed for it, and the threads in flight against it, together.
The map of your product stops being something you keep in your head — and stops going stale the moment someone ships.