Draw the plan. Your agent follows it.

The loop

Four moves, and you only make the first. Once the map exists, the agent drives. You step in when something needs a human: a blocker to clear, a drift to look at.

1. Map it. Lay the app out on the canvas: screens, features, logic, data. A wire between two blocks is a dependency. That graph is the plan.
2. Pull one task. The agent asks for the next unblocked node and gets only that: its spec, what it unlocks, and matched UI references to build from. Tools: get_next_task, get_references.
3. Build and write back. The agent writes the code. Anything it discovers along the way goes back on the map as a subtask, a new dependency or a blocker. Tools: add_subtask, add_dependency, flag_blocker.
4. Check the handoff. Completion is gated. Finishing a node before its dependencies is refused and logged as drift, so the map never claims work that isn't really done. Tools: mark_task_complete.

The handoff

The agent never gets the whole plan pasted into a prompt. It gets the one node that is ready, plus the few things it needs to build it right.

• task: The node's title, type and spec. Only ever a node whose dependencies are all done.
• dependents: What this unlocks, so the agent builds an interface the next tasks can use.
• references: Up to three UI components matched to the node, with snippets one call away. Core and Pro.
• nothing else: No unrelated nodes, no history dump. Smaller context, fewer wrong turns.

A trimmed get_next_task response:

{
  "task": {
    "title": "Dashboard",
    "type": "screen",
    "description": "Signed-in home. Project cards,
      recent activity, empty state for new users.",
    "status": "todo"
  },
  "dependents": [
    { "title": "Settings" }
  ],
  "references": [
    { "name": "Sidebar nav",  "category": "navigation" },
    { "name": "Stat tile",    "category": "data-display" },
    { "name": "Data table",   "category": "data-display" }
  ]
}

A worked example

A small SaaS MVP. You draw six blocks and the dependencies between them, and the build order falls out. Screens wait on the logic they need, and everything waits on auth.

1. Users (Data), no dependencies
2. Auth (Feature), after Users
3. Access rules (Logic), after Auth
4. Landing (Screen), after Auth
5. Dashboard (Screen), after Auth and Access rules
6. Settings (Screen), after Access rules

Try finishing Settings before Access rules and the completion is refused, with the open dependency named.

The canvas

Four block types make up the whole language. Everything you plan is some arrangement of these, plus your own custom types when you need one.

• Screen: A page or view. Layout, state, and navigation.
• Feature: A capability. Auth, search, upload, checkout.
• Logic: Rules and flow. What happens, when, and why.
• Data: Models and relations. Schemas, fields, constraints.

Why a map

Re-prompting, versus a plan the agent can read.

• Context. Re-prompting: Pasted fresh into each prompt, from memory. With Nodeon: Pulled per task: the node's spec and what it unlocks.
• Order. Re-prompting: Whatever the agent decides to do next. With Nodeon: Dependency order, checked when work is marked done.
• Drift. Re-prompting: Noticed when something breaks later. With Nodeon: Out-of-order finishes refused and logged as they happen.
• New work. Re-prompting: Buried in a chat thread. With Nodeon: Written back to the map as subtasks and blockers.
• UI. Re-prompting: The agent guesses at components. With Nodeon: Matched references attached to the task (Core and Pro).
• Files. Re-prompting: Hand-maintained, quietly stale. With Nodeon: CLAUDE.md, Cursor rules and spec sheets, exported from the graph.

Setup

Add Nodeon to Claude in one click from the homepage, or paste the MCP URL into any client. Your agent opens a browser, you sign in, and it can pull tasks. Every client is covered in the docs.

Questions

The full FAQ covers pricing, plans and billing.