Collections & history

A collection is a named set of durable documents on a project. Conversations are transitory; collections are what survives them. Every project starts with three, and automations can maintain as many more as you wire up.

The collections you start with

Beyond those, a standing loop can own its own collection: a changelog, triaged feedback, drafted posts. Same store, same history, same review path.

Documents are the state

This is the part that makes standing agents possible at all. An automation's state lives in its documents, not in a conversation — so a loop that ran on Monday and wakes again on Thursday reads its own collection and picks up exactly where it left off, with no transcript to replay and nothing to remember. What a run "knows" is whatever it wrote down.

The same property is what lets a person and an agent share memory. You edit an entry by hand, and the next run reads your edit as fact.

Everything is versioned

Every change to a document records what changed, which agent made it, the reason it gave, and when — a diffable timeline per document. You can read a knowledge entry as it stands today, then walk back through how it got there.

Deletion is versioned too. Removing a document keeps its prior body and the stated reason in history, so "who dropped this and why" is always answerable. Nothing quietly disappears.

Every entry also shows which thread wrote it, so a document is one click from the conversation that produced it, and you can read the work that led to the claim.

Status, not deletion

Documents carry a status — open, done, deprecated. A plan can be accepted, worked, and completed; a knowledge entry can be retired when the subsystem it describes is gone. None of that requires destroying the record. Deprecated documents stop being the thing agents act on while remaining something you can read.

Browsing and editing

The Collections view is where you browse, edit, or delete any document, across every collection. It's the human end of the same store agents read through their tools — no export step, no separate wiki that drifts.

Writes are staged behind the code

One subtlety worth knowing. When a thread writes knowledge or rules while its own code is still unmerged, that write is staged: it's recorded, but it only applies when the thread's pull request merges.

The reason is straightforward. A thread that refactored your auth layer knows something true about a codebase that doesn't exist on main yet. If that entry went live immediately, every other thread would be grounded in architecture nobody can see — and if the PR never lands, the knowledge base would be describing code that was never written. Staging keeps the memory and the repository in step: the knowledge base never gets ahead of the code it describes.

Everything else — the Atlas reorganizing, the Inbox approvals, an automation's own collection — writes against that same versioned, attributable store.