Closing the visibility gap between agents and engineers

AI coding agents are merging PRs faster than teams can review them. That speed introduces a hidden cost: every change that lands without deep human review adds confusion and complexity to the codebase. For engineers who think visually, keeping track of what agents are doing—let alone explaining it to teammates—quickly becomes impossible.

Figma's answer is to turn FigJam into the shared whiteboard where engineers and agents map out systems together before a single line of code changes. The company is launching a set of MCP tools and skills today that let agents research, plan, visualize, and revise architecture directly in FigJam boards.

New MCP skills for reading and writing boards

The release builds on use_figma, an MCP tool shipped last month that lets AI agents create or edit designs directly on the Figma canvas using real components, and create_new_file, which lets agents generate designs inside new Figma files. Today's additions extend that capability to FigJam.

  • figma-use-figjam: a new MCP skill that enables agents to read from and write directly to FigJam boards, covering notes, code blocks, and annotations.
  • Expanded generate_diagram: the existing tool now supports more complex architecture and ERD (entity-relationship diagram) layouts, not just basic flows.
  • generate-project-plan: a workflow skill that converts docs, codebases, and conversations into visual boards, useful for turning a spec into a collaborative artifact.

The tooling is available as a paid API, but it is free during the beta period while Figma figures out how agentic behavior fits into its paid-seat model. It works with MCP clients including Augment, Claude Code, Codex, Copilot CLI, Copilot in VS Code, Cursor, Factory, Kiro, and Warp.

A three-step workflow

The intended workflow, as the engineering team describes it, fits between the research phase and the pull request:

1. Research and plan visually

Start by having a coding agent gather context: MCP server documentation, the codebase structure, and existing patterns. The agent identifies potential solutions and research tradeoffs, summarizing which services and files are affected. That plan tends to be a wall of markdown—hard to drop into Slack for meaningful feedback.

With the new FigJam capabilities, that plan becomes an interactive diagram in minutes. Architecture and ER diagrams come from the generate_diagram tool; notes, code blocks, and annotations come from the figma-use-figjam skill. Dense text turns into something a team can engage with, making the cleanest architectural approach obvious.

2. Collaborate before committing

Sharing the board with the team opens the review earlier than usual. Teammates can leave feedback directly on the diagram, asking questions like whether a proposed tool will support multiple file types or just design files, or whether it should accept a folderId or create files in the user's Drafts folder. The format mimics the old conference-room whiteboard session, now remote and carrying all the technical context.

3. Take reviewed plans back to code

Once feedback lands, the get_figjam tool pulls everything from the board—the diagram and the decisions alike—directly into the coding environment. No more screenshotting diagrams and manually recapping comments. The agent iterates on the plan, and the PR links back to the FigJam board with all the design context. Since architecture was reviewed before implementation, the merge is easier.

Building blocks for your own process

The team positions these tools as modular building blocks rather than a fixed end-to-end pipeline. generate-project-plan can turn a spec into a board for collaboration; custom skills can be layered on figma-use-figjam and figma-generate-diagram to fit how a specific team works. Internally, the new capabilities have already spread beyond the initial use case—teams are applying them to onboarding docs, engineering critiques, tech specs, and PRDs.