Agents draw before they build.

The story this week is that FigJam became the coding agent’s whiteboard. The May 2026 release of the Figma MCP server gives agents read and write access to FigJam boards directly, plus a handful of workflow skills that turn tickets, codebases, and chat sessions into a real visual surface.

The most material change is to the diagramming tool. It now produces architecture and entity-relationship diagrams with proper database connectors, and it accepts Mermaid as input — drop a Mermaid block into the canvas and the board renders it as a movable FigJam diagram. That second part is the part that matters: every coding agent already speaks Mermaid; the surface they have to draw on suddenly speaks it back.

The diagram surface consolidates

It is not just Figma. AI Designer MCP launched on Product Hunt at the start of April, pitched as a way to give Claude Code access to design tools so it can generate codebase-aware UI inline. Spotify exposed its Encore design system to coding agents via MCP earlier this year, and the result — Cursor generating components that already obey the spacing scale and the token palette — is the same trick by another name. The system the agent reads is a structured, visual artifact, not a paragraph of guidance.

The plan becomes machine-readable

FigJam’s plan-from-ticket skill takes a Linear ticket and a repo and produces a board with swimlanes, dependencies, and a critical path. The first time the agent drew one for a small studio in Berlin earlier this week, the planner from the design team noticed something useful: the lanes the agent picked, and the surfaces it grouped under each lane, were a near-perfect copy of the team’s actual sprint structure. The plan was already there in the codebase. What changed is that it now has a board.

The principle underneath the surface change is older than the surface. Humans need a scratchpad before they write. The agent does too — and the experiments where the scratchpad is a real visual board, instead of a hidden monologue inside the model, are returning consistently better builds.

Anthropic’s extended-thinking research already showed that giving the model a visible workspace to reason in lifts performance on multi-step coding tasks. What FigJam adds is that the workspace is shared. The designer can read what the agent is thinking — because the agent is thinking out loud, on a board, in nodes and arrows — and intervene before any code is written.

「 The first draft of the architecture is now something a designer can red-line, not something a developer has to reverse-engineer from the diff. — §02 Technique

Write the plan as a brief, not a tree

The brittle prompts ask the agent for “a project plan.” What comes back is a tree of nodes with no hierarchy of importance — every task at the same weight, no critical path, no decisions called out. The robust prompts ask for a brief: name the surfaces, name the dependencies, name the decisions, draw the critical path as a rhumb line through them. The diagram that results reads like an editor’s storyboard. It also makes the agent’s reasoning legible, which is the part of the workflow that matters.

Hand the board to the code agent, not the docs

Once the board exists, the temptation is to summarize it back to text and feed the text to the coding agent. Skip that step. Pass the board itself — the FigJam node IDs, the Mermaid source the diagram was rendered from, the connector types between the nodes — and let the code agent read the structure as structure. It picks up dependency order from the arrows; it picks up scope from the swimlanes. The diagram is doing prompt work the prose used to do.

A four-person product studio in Lisbon has been running a whiteboard-first variant of the parallel-agents pattern covered yesterday. The shape: the planning agent owns the FigJam board, the build agents own their swimlanes, the inspector agent reads the rendered page against the board. Three agents, three rooms, one shared surface — the way three illustrators might share a roll of tracing paper.

What is different from the all-text fleet pattern is that the board is the merge target. The planner does not file a plan document; it files a board. The build agents do not push commits straight to the main branch; they push to branches named after their lane on the board, and the inspector reads the diff against the swimlane it was supposed to land in. The board is the version control of the intent.

Roles on a four-agent board

The roster is shorter than it looks. A planner drafts the board from a Linear ticket and a repo, runs the plan-from-ticket skill once, then waits. A cartographer turns each swimlane into an architecture sub-board with the data flow and the API surface drawn out. A builder reads the cartographer’s board for its lane and writes code. An inspector renders the finished page and the board side by side, flagging anywhere the build diverges from the plan. Four jobs, one shared canvas, the design team holds the felt-tip.

The prompt below is the planner-agent system prompt the Lisbon studio uses to drive the FigJam plan-from-ticket skill. It assumes the agent has read access to a Linear ticket, the repo’s AGENTS.md, and the FigJam MCP. The clauses that do the heavy lifting are 3 and 5 — they force a critical path through the diagram and forbid the planner from drawing nodes it cannot defend.

You are the planner agent. You draw boards, you do not write code.

Read the Linear ticket and AGENTS.md before you draw. Then call
generate-project-plan with the following constraints:

1.  Lanes are SURFACES, not phases. One lane per page, route, or
    component the user will eventually see. Do not draw a "research"
    lane or a "deployment" lane — those are tasks within a surface.

2.  Each node is a deliverable, not a verb. Name it for the artifact
    that lands at the end of it: a route file, a schema, a component
    prop set. The arrows are the order of operations.

3.  Mark a critical path. Exactly one. It is the shortest sequence of
    nodes that, if every other lane stalled, would still ship a usable
    page. Draw it in vermillion. Refuse to draw the board if you cannot
    name the critical path.

4.  For every dependency arrow, write the contract on the arrow itself:
    the shape of the data that crosses it, in one line. Untyped arrows
    are how parallel agents collide.

5.  If you draw a node you cannot justify against the ticket, delete it.
    The board is not a brainstorm. It is the brief the build agents
    will read.

When the board renders, file a summary back to the ticket with the
FigJam URL, the critical path nodes by name, and the three lanes whose
dependencies are most likely to surprise a build agent. Stop there.
Do not write code. Do not edit the build agents' lanes.

The line that earns its keep is in clause 4 — untyped arrows are how parallel agents collide. Without it the planner happily draws an “auth → checkout” arrow with no contract attached, and an hour later two build agents have shipped incompatible session objects to the same database table. With it, the arrows turn into one-line API contracts that the cartographer and the builder both have to honour.

Track the climbing artifact and the shape of the year comes clear. A week ago the agent read a Markdown brief; days later it read a brand-book Markdown file; earlier this week it wrote into the Figma canvas; today it draws the plan on a whiteboard before anyone touches a file. The surface keeps rising up the stack and getting more visual, and the discipline that handles visual surfaces — naming, framing, hierarchy, decision-marking — is the discipline of design.

What pays the studios learning this is the part of the work that does not look like design at first. The planner’s prompt. The lane definitions. The critical path. The agent that drew the diagram knows what to do because a designer told it what a good diagram looks like, and the build agents that read it ship cleaner code because the diagram is cleaner than the brief was. The whiteboard rose up the stack. The brush followed it. The hand that holds the brush is the one the studios are hiring for.

1. FigJam is now your coding agent’s whiteboard too Figma
2. Release notes roundup — May 2026: FigJam MCP skills & generate_diagram Figma · May 2026
3. Agents, meet the Figma canvas — the write-to-canvas skill Figma
4. Figma MCP server — tools, prompts, and the figma-use skill family Figma Developers
5. How Spotify is making the Encore design system AI-ready Into Design Systems
6. AI Designer MCP — codebase-aware UI generation for Claude Code Product Hunt · April 2026
7. How we made v0 an effective coding agent — the agentic pipeline Vercel
8. AGENTS.md — the open code book stewarded by the AAIF / Linux Foundation Open spec
9. Figma’s MCP just gave AI agents ‘write’ access — a first look Bitovi
10. Extended thinking — visible reasoning workspaces lift multi-step coding Anthropic