Guide

1. Make a plan

Three levels, and you already have the first two after signing up:

Workspace      people, roles, and the keys agents connect with
  └─ Project   one thing you are building
       └─ Plan one graph

Open your workspace, pick a project — a General one is there from the start — and press New plan. A plan is a graph, not a document: you will be adding things and saying how they relate, rather than writing top to bottom.

2. Draw it

Add node puts a node where you are looking. Click it and the panel on the right opens: give it a title, a kind, a status, and as much detail as you want. The detail becomes the body of that node’s Markdown file when you export, so it is worth writing properly.

Five kinds carry different meanings, and the outline of a node tells you which is which: a feature and a task are solid, a decision has a clipped corner, a note is dashed, and a group is drawn as a boundary around whatever it holds.

Four buttons in the title block say what the next line you draw will mean, and each one shows the line itself rather than an icon standing in for it:

• Flows to — drag the way the system actually moves: this screen calls that endpoint, that endpoint reads that table. Say what sets the hand-off off and what it carries, and both are written on the line. A reply is a second flow pointing back. This is the one that draws a system rather than a list.
• Contains — drag from the container to what goes inside it. This is what becomes a directory on export, and dragging a group moves everything in it.
• Depends on — what has to exist first, which is not the same as what calls what. It becomes the order the export numbers files in.
• Relates to — a plain association, carrying no structure.

Click a line to change what it means, say what it carries, or remove it.

Arrange lays the graph out for you. It will not move anything you have dragged by hand — a node you place is pinned from then on, and only you can unpin it by moving it again.

3. Connect an agent

Open Agents in your account settings, create a key, and paste the URL and key into your MCP client. Nothing is installed on your machine; the server is reached over HTTP. The docs have the exact configuration block and the full tool list.

A key acts as you everywhere you are a member, so one key is enough however many workspaces you have. Give it to one client, name it after that client, and revoke it when the machine changes hands.

4. Let the agent draw

Ask your agent to write the plan the way it normally would, then to put it on the canvas. It has two ways in. For a whole plan at once, create_plan:

{
  "name": "create_plan",
  "arguments": {
    "title": "Billing rework",
    "nodes": [
      { "slug": "ledger-schema", "title": "Ledger schema" },
      { "slug": "pricing-rules", "title": "Pricing rules" },
      { "slug": "render-pdf",    "title": "Render PDF" }
    ],
    "edges": [
      { "from": "pricing-rules", "to": "ledger-schema" },
      { "from": "render-pdf",    "to": "pricing-rules" }
    ]
  }
}

For everything after that, apply_ops — one batched, atomic call that appears on every open canvas at once:

{
  "name": "apply_ops",
  "arguments": {
    "planId": "…",
    "ops": [
      { "op": "upsert_node",
        "node": { "slug": "tax", "title": "Tax by region",
                  "kind": "decision", "status": "blocked" } },
      { "op": "upsert_edge",
        "edge": { "from": "tax", "to": "pricing-rules" } },
      { "op": "upsert_node",
        "node": { "slug": "ledger-schema", "status": "done" } }
    ]
  }
}

Notice what is not there: coordinates. Agents declare structure and the server runs the layout, because a language model asked for positions produces a diagram nobody wants to read and spends your context doing it. Notice also that a node is addressed by its slug, so the same call sent twice changes nothing the second time.

One thing worth asking your agent for: slugs you would recognise. pricing-rules is a name you can refer to in the next message. node-7 is not.

5. Take the files

Export downloads a zip. Containment becomes directories, dependency order becomes the number on each filename, and every node carries its own frontmatter, so the bundle describes the graph completely rather than being a picture of it.

plan-export.zip
├── README.md                 overview and a table of contents
├── 01-foundation/            a node that contains others becomes a directory
│   ├── README.md             …and its own notes live here
│   ├── 01-ledger-schema.md
│   └── 02-pricing-rules.md   numbered by what depends on what
├── 02-invoicing/
│   └── 01-render-pdf.md
├── plan.canvas               opens in Obsidian, layout intact
└── plan.json                 the same content, machine readable

Drop the folder into an Obsidian vault and plan.canvas opens as the same diagram. Or commit it next to your source, where your agent will read it on every run — which is the point of the whole exercise.

A dependency cycle does not block an export. It is broken in a stable way and reported in the README, so the same plan always exports to the same files.

6. Work with other people

Editing is live. Two people on one plan see each other’s changes as they happen, and two people typing in the same node’s detail merge rather than overwrite. An agent writing through MCP is just another participant.

Share produces a link that anyone can open, read, and export from, without an account. Stop sharing and the link stops working.

Members in your workspace lists who is there, changes roles — owner, admin, editor, viewer — and produces an invitation link. There is no email yet, so send the link yourself.

7. Run your own

The whole stack is AGPL-3.0 and needs Node, Postgres and nothing else. Clone the repository, copy .env.example, start Postgres, apply the migrations, and run it. The README has the exact commands.

Everything is configured through environment variables, and the web app reads its server address at runtime rather than at build time, so one built bundle runs in every environment.

What is not built yet

Being straight about it, since you will run into these: no email is ever sent, so an invitation is a link you pass along and an email address cannot be changed. Sign-in is email and password only. There is no undo on the canvas, no search across a large plan, and no version history.

If one of those is in your way, say so on GitHub Issues; it moves what gets built next.