Write it once · any agent, any project, any machine runs it · never pruned


Your agent draws the map of your whole system. Every session after loads it.

A playbook is a procedure written once — the deploy, the translation run, the weekly report — and run by any of your agents, in any project, on any machine, the same way every time. Notes carry the handover from one session to the next. And the atlas is what playbooks make possible: a map of your whole system, drawn by your agent from the code and the live system, that every future session opens with.

Free tier · no credit card · playbooks and notes on every plan

Write a procedure once. Every agent runs it.

A playbook is plain markdown: headings for the stages, fenced blocks for the commands, and what to read back afterwards to know it worked. It is stored for your whole account, not for one project — your projects stay separate, your procedures are shared. Any agent fetches it and runs it in its own harness; the memory only stores it. Say "save this as a playbook" and it is one. Say "use playbook deploy" and it runs.

Never pruned

Curated records hold the current truth and are tidied as it moves on. A playbook holds how, and nobody prunes a procedure. A recipe that took a week to find stays exactly as it was found.

The same way, everywhere

Five agents on one project, or one agent on five machines — the deploy is the same deploy. What you learned once about a run is what every run knows from then on.

📋

Written the way you'd hand it to a colleague

The steps, the exact commands, what to check afterwards, what went wrong last time and when. Your agent adds what it learns running it, in the same session.

Notes — the handover

Where a session stopped, what is live, what comes next — written by your agent, kept per project, the last five always at hand. The next session opens with it. Start the PC, say "continue," and it carries on.

The atlas: a map of your whole system, kept true

The atlas is a playbook that teaches your agent how to map a project — and the map it draws is itself a playbook, so every session can open it. One root map per project: the boxes, the wires and what travels on them, the stores, and an index of plates. Four to eight plates, one per plane of the system, with the procedures inside the plate they belong to. Written by the agent from the code and the live system, never from memory.

The three rules of a map

  • Topology is drawn once, in the root. A plate never restates the wires; it carries only its own detail and its procedures. Duplication is where drift starts, so there is none by construction.
  • Values live nowhere in the map. No ports, caps, prices or counts — a page says where the number lives, never what it is. A map that carries values is wrong within a week.
  • Whoever changes a wire updates the map in the same session. The root carries a line — verified <date> against <what> — and a reader trusts the map exactly that far.

What the root map holds, in order

  • What the project is, in two sentences, and the verified line.
  • The diagram: boxes and arrows, one arrow per wire with what travels on it. Direction matters more than anything else on the page.
  • The wires, listed: who initiates, what travels, what never travels. This is the section that catches the lies.
  • The stores: every place state lives, what it holds, what it never holds.
  • The index: each plate by name, each procedure by plate and section.

What a plate holds

  • For each part of its plane: what it is, what it holds, what it talks to and in which direction, what it never does, and what happens when it runs.
  • Where the values live — pointers, never values.
  • Its procedures: the exact commands, what to read back to know it worked, and what has actually gone wrong doing it, with the date.

A root map, in shape

my-app-map — verified 2026-09-04 against commit a1b2c3d and the live containers

  browser ──(requests, session cookie)──▶ api ──(SQL)──▶ postgres
                                          │
                                          └──(jobs)──▶ worker ──(files)──▶ object store

Wires: the browser never talks to the worker; the worker never reads a cookie.
Stores: postgres (users, orders — never card numbers) · object store (uploads).
Plates: my-app-map-api · my-app-map-worker · my-app-map-data · my-app-map-ops
Procedures: deploy → my-app-map-ops, deploy · restore → my-app-map-data, restore

Three sentences to your agent

The atlas method is a playbook like any other. You give it to your memory once; from then on every project can be mapped with one sentence, and the map's own last step makes sure every future session knows the map is there.

1 · once

Give your memory the method

Copy the atlas text and tell your agent: save this as playbook atlas. It is now in your account, for every project.

2 · per project

Have the map drawn

In the project, tell your agent: use playbook atlas to write the map of this project. It reads the code and the live system, verifies every wire, and writes the root map and its plates.

3 · done by the method

The project learns it has a map

The method's last step saves a rule for the project: where its map lives, read it before changing a wire, update it in the same session. Every session from now on opens knowing the map is there.

Playbooks, notes and the atlas are on every plan, including the free one. Get started free

Hear it when it ships

New releases, real benchmarks and the occasional deep-dive. No spam, unsubscribe in one click.

Everything we build

External:   YouTube · GitHub