Chapter 21
A Role Is a Node
Chapter 7 stated the principle: an Agent is defined by what it reads, and its role can be a Node in the graph. This chapter looks at how that principle is actually laid down in the graph.
1. Where a role lives
One role is a Concept with the id concept:agent-<name>. Its topic is agent, a topic the product reserves, so it does not count against a free account's topic cap: what the product writes in on its own must not be taken out of the user's allowance. The graph that builds this product, and spaces that received roles before, keep them at the old place, vinc/agent, and both places are read together.
Why a Concept is in Chapter 10. Only the closed kinds keep their properties, so coining a new agent type would land the node in an open type and lose every field this design depends on. Concept carries it.
The graph this product is built in holds 23 roles in six teams. Every other space receives four when it is created; section 4 shows them.
2. What a role node carries
The role's contract lives in its properties.
tier orchestrate | execute | verify | deliver | knowledge rung strongest | strong | fast | cheapest mission what this role is for, in one line reads the document ids to read before the first edit, in order paths, repos the surface it may touch gates the checks to pass before moving on never hard prohibitions person_only steps that exist but belong to a person
Two choices hold this schema up. A rung is not a model name. Model names change every few months, and writing one into 23 nodes means 23 edits per model release. The mapping from rung to name lives in one decision, and escalation is one rung up. The mission is the same sentence as the description column. One shows in the roster and one in the contract, and two strings drift. So they are kept equal and a test pins it.
Editing a role's properties comes with a decision. Properties overwrite, so what a role read in the last release is gone the moment it is edited. So any write that changes reads, gates, never or person_only carries, in the same payload, a Decision that names the change, and the decision's note keeps the value that was replaced.
3. Handoffs are Edges
The order between roles is written as prerequisite_of, each one measured rather than invented. Design comes before app development because a screen built on unsynced tokens fails the gate; core development comes before account development because a contract change has to be registered in three places in one pass. Loose pairs are relates_to.
A decision attaches two ways. A standing decision that constrains a role precedes the work, so it attaches with prerequisite_of; a decision about the role itself attaches with about.
The memory of failure from Chapter 7 §6 becomes concrete here. A trap found during one task was attached to the concept it was found on. Now that Record is also attached to the role that must not repeat it. And each run of a task is left as an Episode, which lives in the domain where the work happened and is joined to the role by a second about. Filing it under the role's domain instead would leave a hole in that domain's timeline exactly where the last releases went.
4. The default roster
A new space is not empty. When an account is created or a team is made, the account service writes in the Default Agents pack: four roles chosen to fit a graph about anything.
| Role | Mission | Never |
|---|---|---|
| steward | Keep the graph honest. Propose merges and retopics with evidence, and never apply them | delete, fold, ratify a type or topic |
| researcher | Measured research that ends in a document. Assemble the material a decision needs, and never take the decision | write a decision in a person's name |
| curator | Take documents in: write, extraction preview, mention links, one topic proposal per document | apply an extraction unreviewed |
| reviewer | Check every claim against the graph and label it cited, assumed or unsourced | edit |
Researcher and curator stand before the reviewer, and steward is loosely tied to curator. There is no orchestrator role. The graph is not the scheduler, and the order between roles sits on the edges.
5. A role is visible from outside too
A role that exists only inside the graph never reaches the outside system meant to carry it out. So the MCP door of Chapter 20 offers roles as prompts. The prompt list is the roster and each description is the mission. Open one prompt and that role's contract is filled from the graph on the spot: mission, the reading list in order, gates, prohibitions, and the traps attached to that role.
Everything read from the graph is wrapped in an explicit data boundary, a fenced block marked as untrusted material rather than instructions. Record notes and properties are content a person wrote, and instruction injection through hydrated text is the most concrete risk on this surface. A graph with no roles answers with an empty list. That is not an error.
6. The graph is not a scheduler
Making a role a Node does not make the graph direct execution. When a role runs, how many times, and on which worker are the runtime's business. In this product that runtime is sub-agents, worktrees, pull requests, CI, and a person merging.
The graph is the memory and the contract around that loop. Start mixing execution state into it and the graph of meaning and the state of execution tangle into one structure. The separation is what lets changing what a role means and changing the infrastructure that runs it move at different speeds.
But a name only points at a role. What the role actually holds an Agent to is a different question. That is the next chapter.
Continue with Chapter 22, How a Role Becomes a Contract.