Every AI coding agent starts each session with amnesia. The code is on disk, so it can read that. But why you chose Yjs over a CRDT you wrote yourself, which of the four half-built features is actually next, what you tried in March that failed - none of that is in the code, and none of it survives the end of a conversation.

So you re-explain. Every session. And because re-explaining is tedious, you compress, and because you compress, the agent works from a worse picture of your project than you have in your head.

The usual fix is to write it down: a TODO list, a plan file, a folder of markdown. That is the right instinct with the wrong shape.

The problem with a list is retrieval, not storage

A list is a fine place to put information. It is a bad place to get it from, if the reader has a fixed context budget and no idea which entries matter.

Give an agent a 200-item backlog and it has exactly two options. Read all of it, and spend a large slice of the context window on 190 items that have nothing to do with today's task. Or read the top N, and miss the blocker sitting at position 143.

Neither is a knowledge problem. Both are retrieval problems. The list has no structure to route by, so every read is either everything or a guess.

A graph is a structure you can walk

Develosaur puts the whole project into one primitive: a node. A plan is a node. A decision is a node. A task, a bug, an architecture note, a piece of memory - all nodes, each holding markdown, tags, value and effort scores, deadlines, and typed relationships to other nodes.

That sounds like a philosophical difference. It is a practical one, because a structure gives an agent somewhere to start and a reason to stop.

The agent's read order is fixed, and it goes widest-first:

1. The digest. Generated fresh on every read, never stored: what is in the backlog, how the pipeline currently ranks, what was completed recently, what has gone stale, and the tag vocabulary. One call, and the agent knows the shape of the project without having read a single node body.
2. The tree. Structure only - titles, tags, hierarchy. Enough to know which branch the work lives in.
3. Node bodies, last, and always scoped. By id, or by one branch, paged.

There is deliberately no unscoped read of every body. Not as a limitation - as the whole point. By the time an agent reaches step three it knows exactly which handful of nodes it needs, so it fetches those and stops.

The retrieval routing, concretely

The verb set maps onto how you would actually ask the question:

• review_tree for the digest and the structure - the two widest reads.
• find for a search, with an exact-substring default and a placement mode that answers "does this already exist?" before you create a duplicate.
• gather_context for the shape of a topic: which nodes matched and why, titles only, no bodies. You follow up with read_nodes on the ids worth reading.
• edges to walk derived relationships out from an anchor node.
• prioritize for the ranked queue.

Notice how much of that returns metadata rather than content. gather_context deliberately hands back titles and match reasons instead of text, because the expensive thing is not finding the node - it is pouring the wrong nodes into a context window.

Structure carries instructions, not just data

The part I did not expect to matter as much as it does: tags carry their own instructions, and the digest ships them with every read.

A tag is not a label on this board. IN-PROGRESS says it may only be applied by starting work, never by hand. REFERENCE says this branch holds data you may read and extend but never derive work from. COMPLETED says the server will refuse writes to this node.

The agent does not need those rules in its system prompt, where they would compete with everything else for attention and drift out of date. They arrive attached to the thing they govern, at the moment it is read. A list of task titles cannot do that.

Bodies are claims, not facts

One design decision worth stealing even if you never use this tool: a number written in a node body is treated as a historical claim, not a fact.

If a node says "cut the bundle to 492 kB", that was true when someone wrote it. The rule is to verify it live before quoting it. This sounds like pedantry until you have watched an agent confidently report a six-week-old measurement as the current state, because a document said so and documents do not have timestamps attached to their sentences.

The graph holds the claim. Reality settles the argument.

What this buys you in practice

The loop an agent runs is: plan, tag, prioritize, update, validate, complete. It reads the digest, picks up the next ranked task, does the work, writes the outcome back, and closes the node with evidence naming where the result is visible.

The next session - a different agent, a different vendor, a different week - reads the same digest and picks up exactly where that one stopped. Nothing was re-explained, because nothing was lost.

You stay editor-in-chief throughout. The graph is a live canvas you can see: re-rank it, add a blocker, restructure a branch, correct a decision the agent got wrong. It is not a black-box memory backend you have to trust. It is a structure you can look at and fix.

Try it without an account

Paste this into any MCP-compatible client, with authentication set to none:

https://mcp.develosaur.com/v1/mcp

There is nothing to install and no API key. On first contact the gateway hands the agent a throwaway board and returns a link you can open to watch the graph build in real time.

For Claude Code:

claude mcp add --transport http develosaur https://mcp.develosaur.com/v1/mcp

More on how the pieces fit together in Features, or read the rest of the blog. If you want the version of this argument aimed at agents doing the work rather than the theory, Agentic Workflow MCP walks through a single prompt becoming a whole feature tree.