Figma Agent Features Put Design Rules Between AI and the Canvas

Figma introduced new Figma agent features that give teams more control over AI output, despite the technology’s unpredictable behavior. The release connects agents with written specifications, design libraries, code sources, and working prototypes inside the same platform.

This is more than another assistant gaining more commands. Figma is trying to define the operating environment around agents before generated interfaces spread across product teams. Its bet is that shared context, visible work, and enforceable design rules matter more than unrestricted generation.

That position puts Figma between designers and external coding agents such as Claude Code, Codex, GitHub Copilot, and Cursor. Instead of competing only on model performance, Figma wants its canvas to become the control plane where teams decide what agents should build.

The New Figma Agent Features Define the Rules Before Generation

Figma is moving agent control from individual prompts into shared product infrastructure.

The company announced the expanded workflow during its first Config event in India. The central addition is Figma Specs, a Markdown-based workspace for recording product requirements, decisions, references, and technical context.

A spec can live as its own Figma file or alongside work on the canvas. Teams can reference designs, FigJam diagrams, code layers, and other materials without reducing everything to detached text.

That structure matters because an agent rarely fails only from weak language generation. It often lacks the relationships between a requirement, a visual component, a code implementation, and a previous team decision.

A conventional Markdown file can describe those relationships, but it does not automatically preserve them. Links become stale, images lose context, and different files can present conflicting instructions.

Figma Specs is designed to make those connections native. According to the company’s launch overview, teams can turn rough ideas into detailed specifications and pass them to coding agents through Figma’s MCP server.

Model Context Protocol, or MCP, is a standard that lets AI systems connect with external tools and structured context. In Figma’s implementation, it can move product information between the canvas and supported development agents.

The workflow starts before an agent writes code. A team can assemble requirements, diagrams, design references, and code context inside a spec, then use that material during generation.

The same context can support a code layer, which is an interactive prototype backed by running code on the Figma canvas. That makes the prototype inspectable alongside the designs and decisions that produced it.

Figma also expanded the information available through design systems. Teams can add written guidelines to published libraries and connect code sources from GitHub repositories or npm packages.

Guidelines can document rules, preferred patterns, prohibited treatments, and implementation details. Agents can read that material when a relevant library is enabled.

Code sources add another grounding layer. They give an agent access to implemented components, rather than forcing it to infer every interface element from screenshots or visual frames.

This combination creates a hierarchy of context. Specs describe what a team intends to build, design libraries define its visual language, and code sources show how elements work in software.

The agent announcement also highlighted centralized management for design libraries, code libraries, and guidelines. Figma says agents can consult this system while creating or editing work.

Those controls address a recurring problem with generative interfaces. A model can produce a credible screen while still ignoring the organization’s component rules, interaction patterns, or accessibility practices.

A polished result is not necessarily a valid product result. It can look correct while creating duplicated components, unsupported states, or implementation work that developers must later replace.

Figma’s answer is not to eliminate prompting. It is to surround prompts with durable context that belongs to the team, rather than the person starting one chat.

That changes the role of the prompt itself. It becomes a request inside a governed workspace, not the only instruction standing between an agent and the product.

Figma Code Layers Bring Running Software Onto the Canvas

Figma code layers turn the canvas into a place for testing behavior, not just reviewing visual representations.

Code layers moved from closed beta into open beta as part of the release. Figma says the feature is gradually rolling out across its plans, although individual accounts may receive access at different times.

A code layer contains a functioning interface backed by running code. Teams can place it beside conventional design frames, duplicate it, test different directions, and inspect interactive states.

The distinction is important. Traditional prototypes can simulate a path through linked frames, but they may not represent the behavior of a real component.

A running implementation can expose loading behavior, empty states, errors, responsive layouts, and complex interactions. Those details often reveal product questions that static screens leave unresolved.

The code layers guide describes several starting points. Users can generate a layer through the Figma agent, convert a design, import code, or begin from an existing team codebase.

A designer could select an established checkout flow and ask the agent to add an alternative delivery option. The resulting code layer could show validation, loading, success, and failure behavior.

The team could then duplicate that version and test another interaction beside it. Product managers, designers, and engineers would compare working options in one shared file.

Figma says changes can move back into the code layer and, in supported workflows, the connected codebase. That promise remains more consequential than simple design-to-code export.

An export is usually a handoff artifact. A connected code layer is intended to remain part of an iterative loop between design exploration and implementation.

Figma first introduced code layers in closed beta in June 2026. Its earlier canvas preview supported GitHub imports, local folders, templates, Figma Make output, and agent-generated starting points.

Open beta brings that model to a broader audience. It also creates a larger test of whether code-backed collaboration works outside carefully selected teams.

The immediate use case is not automatically shipping generated code. It is making code cheap enough to use during product discovery.

Figma Chief Design Officer Loredana Crisan described a widening gap between code creation and actual releases. She told TechCrunch that organizations produce 17 times more code, while releases have increased only 1.3 times.

Those figures are company-provided and should not be treated as an independent industry benchmark. Still, they explain the strategy behind Figma code layers.

Generated code is increasingly used to explore possibilities that never reach production. Figma wants that exploratory work to happen where teams can see, discuss, and refine it together.

This reframes code from a final implementation medium into a design material. Product teams can use working software to clarify what they should build before committing to production architecture.

The approach also recognizes that terminal-based agent sessions are often difficult to share. A developer can generate several interfaces quickly, but collaborators may only receive a link or recording afterward.

That process hides the alternatives, prompts, and tradeoffs behind the result. Bringing a working version onto the canvas makes the exploration visible and easier to challenge.

However, visibility does not make prototype code production-ready. Teams still need engineering review, testing, security controls, accessibility validation, and maintainable architecture.

The value of code layers therefore depends on how teams classify their output. Used as an exploratory artifact, they can shorten feedback loops without pretending that generated prototypes are finished software.

The Real Contest Is Shared Context Versus Isolated Agent Chats

Figma is betting that governed context will matter more than whichever agent generates the fastest first draft.

The primary opponent in this story is not another design vendor. It is the isolated agent workflow that places product work inside private chats, terminals, or disconnected browser sessions.

Coding agents already generate interfaces from text and images. Their speed creates a new coordination problem when every participant works from different instructions and local context.

One designer may attach the latest component library. A developer may use an older repository branch, while a product manager supplies requirements copied from a separate document.

Each agent can return a plausible answer. The outputs can still conflict because the systems never received the same source of truth.

Figma Specs attempts to reduce that fragmentation by giving context a visible home. It keeps requirements near the diagrams, designs, code layers, and decisions they reference.

The design system expansion tackles a related problem. Figma wants agents to understand not only available components, but also the rules governing their use.

A library might contain several button variants without explaining which one belongs in a destructive action. Guidelines can supply that missing decision logic.

Similarly, access to code sources can show an agent whether a component already exists. That can reduce the temptation to generate a visually similar replacement with incompatible behavior.

Figma’s existing agent now supports searching across files, attaching platform content, referencing library elements, and running multiple prompts concurrently. Its agent documentation also distinguishes the built-in agent from external MCP clients.

The built-in agent works directly in design files. External agents can use Figma’s write-to-canvas capabilities to bring content from codebases or other AI projects into the platform.

This distinction lets Figma support several agents without requiring one assistant to handle every task. The company can remain the shared layer beneath a changing group of models and development tools.

Its MCP support now includes more than 20 new partners, according to the company. The announced list includes OpenCode, Dia, Meta Muse, and Indian AI startup Sarvam.

Figma had already named Claude Code, Codex, GitHub Copilot, and Cursor as examples of external agents that can write into files. The expanded partner support makes model neutrality part of the platform strategy.

That is a defensible position because model rankings change quickly. A team may prefer one agent for interface code and another for research, documentation, or image generation.

Figma does not need to win every model comparison if it controls the shared product context. It needs agents to treat Figma’s files, libraries, and rules as authoritative inputs.

The company’s MCP canvas update makes that ambition explicit. Skills can instruct external agents how to execute workflows, sequence steps, and follow team conventions.

Here, a skill is a reusable set of instructions that shapes an agent’s behavior. It can encode operational knowledge that would otherwise remain inside one employee’s prompt history.

A design systems team could create a skill for building forms. The instructions might require approved field components, accessible labels, documented validation states, and specific spacing tokens.

An external coding agent could then apply those rules while creating or updating assets. Figma’s canvas would show the resulting work where the broader team already collaborates.

This resembles a structured engineering knowledge base, but the context is attached directly to product artifacts. The difference is where decisions become actionable.

The emerging competition is therefore about orchestration. Design tools, code editors, repositories, and documentation systems all want to become the place where agents receive trustworthy context.

Figma has an advantage because many interface decisions already live on its canvas. Yet that advantage holds only if the platform keeps those decisions synchronized with production code.

Predictable Agents Still Depend on Imperfect Inputs

Figma can constrain agent behavior, but it cannot guarantee that every rule is complete, current, or correctly interpreted.

The company is introducing these controls because generative AI remains nondeterministic. The same request can yield different structures, details, and implementation choices across runs.

Guidelines can narrow that variance. They cannot remove it, especially when instructions conflict or fail to cover a new situation.

A team might tell an agent to use a preferred component while its connected repository contains two implementations. The design library may identify one version, but production code may depend on another.

Specs introduce another maintenance obligation. A well-structured specification helps only when its requirements reflect current decisions.

Outdated context can make an agent consistently wrong. That failure is more dangerous than an obvious hallucination because the output may appear governed and trustworthy.

Design system teams will need ownership rules for agent instructions. They must decide who can publish guidelines, connect code sources, resolve conflicts, and approve changes.

Figma is previewing centralized design system management with maps and system checks. These tools are intended to expose dependencies and gaps, including missing descriptions or interaction states.

That administrative layer is necessary because agent access increases the consequences of weak system documentation. An undocumented component was once harder for people to use correctly.

Now an agent can reproduce the misunderstanding across many screens within minutes. Faster generation magnifies both good standards and neglected ones.

Access control presents another concern. Connecting agents to designs, specifications, repositories, and external services expands the surface containing proprietary product information.

Figma says the MCP capability benefits from its security and reliability controls. Enterprise teams will still need to review permissions, data retention, connected clients, and repository access.

The platform lets administrators disable AI features, but the available controls may be too broad for some organizations. Disabling code layers can also disable other AI functionality, according to Figma’s support documentation.

Teams may want narrower policies based on project sensitivity, repository, model provider, or user role. The effectiveness of governance will depend on how those controls develop.

Adoption also remains uncertain. Designers may appreciate code-backed exploration without wanting to maintain agent instructions or troubleshoot imported repositories.

Developers may resist generated structures that look convincing but conflict with established architecture. Product managers may create detailed specs that become another document requiring synchronization.

Early user discussion has already raised questions about repository imports, infrastructure errors, and whether AI features distract from longstanding product requests. These anecdotes do not establish broad product quality.

They do show what open beta must test. Figma needs to prove that code layers work reliably with real repositories and everyday team constraints.

The platform also faces a conceptual risk. Combining requirements, design, code, content, and agent controls can reduce fragmentation, but it can also make Figma itself more complex.

A shared canvas succeeds when each participant can understand the relevant state without mastering every underlying system. Too many overlapping surfaces would recreate the coordination problem inside one product.

Figma’s claims about higher-quality, brand-aligned generation also require independent evidence. The company has shown how context enters the workflow, not how consistently agents follow it.

Teams should measure outcomes rather than assume them. Useful indicators include component reuse, accessibility defects, rework, review time, and divergence between prototypes and production code.

The central question is not whether an agent can generate an attractive screen. It is whether that screen survives contact with a real design system and codebase.

Figma Specs Extend the Platform Beyond Design Files

Specs turns Figma’s agent strategy into a broader bid to own product decisions before and after the canvas.

A product specification has traditionally lived in a document tool, ticketing system, or repository. Visual work then moved into Figma, while technical implementation moved elsewhere.

Every transition created a translation step. Requirements could lose nuance, designs could drift from approved behavior, and developers could interpret incomplete handoff notes differently.

Figma Specs challenges that separation. It treats Markdown as a flexible medium while embedding it within Figma’s network of visual and technical artifacts.

A product manager can draft a requirement and reference a FigJam diagram. A designer can connect relevant screens, while an engineer can add code context from GitHub.

An agent can then use the combined material to create a code layer or transfer the specification through MCP. The spec becomes an active input, rather than a document reviewed only by people.

This expands Figma’s addressable workflow. The platform is no longer limited to creating interface designs and handing them to development teams.

It wants to participate in product definition, prototyping, implementation context, and content operations. Each additional surface makes the shared context more valuable to agents.

Figma’s Payload integration reinforces that direction. Payload is an open-source headless content management system that joined Figma in 2025.

The new integration connects Payload with Figma Make, the platform’s prompt-based application and website builder. Teams can create data-backed experiences and manage content without separating the visual prototype from its content model.

Figma says Payload downloads increased sixfold during the previous 12 months. That is a company-reported measure and does not reveal how many projects use the new integration.

Still, the combination addresses a practical limitation of generated websites. A polished page becomes less useful when content remains hard-coded or disconnected from publishing workflows.

Payload supplies content storage, APIs, workflows, and an administrative interface. Figma says marketers can manage content while developers retain access to the open-source framework.

This also sharpens the distinction between building to explore and building to ship. A disposable prototype needs only enough behavior to test an idea.

A production site requires persistent content, permissions, data structures, and operational workflows. Integrating a CMS moves Figma Make closer to that second category.

The company is careful to preserve an exit path. It says teams can take their Payload-based work outside Figma, which matters to developers concerned about platform lock-in.

However, portability must be evaluated through actual projects. Exportable code is not automatically easy to maintain without the environment that generated it.

The broader strategy puts pressure on several categories at once. Document tools host specifications, coding agents generate implementations, and website builders combine visual editing with deployment.

Figma is not replacing all of them with one model. It is attempting to become the shared substrate where their outputs connect.

That approach fits the company’s existing collaboration model. Figma became central to product teams because files supported multiplayer editing, comments, components, and shared libraries.

Agents add a new kind of participant. Unlike human collaborators, they can modify large areas quickly and operate across tools through machine-readable interfaces.

The platform must therefore support both collaboration and constraint. It needs to make agent work visible while limiting how far an incorrect instruction can spread.

Figma Specs, code sources, and guidelines are separate features, but their value compounds when used together. Each one addresses a different part of the context problem.

Specs explain intent. Libraries express reusable design decisions, while code sources ground those decisions in implementation.

Code layers provide an executable place to test the result. MCP then connects that process with agents operating elsewhere.

This is how Figma agents work in the company’s emerging model. They do not simply receive a prompt and produce a screen.

They operate inside a chain of product context, shared rules, working artifacts, and human review. The chain is the product strategy.

Three Signals Will Show Whether Figma’s Agent Strategy Works

The next test is whether governed agent workflows improve real team outcomes without adding another layer of maintenance.

The first signal is code layer adoption after the open beta rollout. Access alone will not establish value.

Teams must repeatedly create, duplicate, review, and refine running prototypes on the canvas. Continued use would suggest that code-backed exploration solves a real collaboration problem.

The most useful evidence would compare workflows before and after adoption. Shorter review cycles, fewer handoff revisions, or better representation of interactive states would support Figma’s thesis.

Abandoned imports, unreliable execution, or frequent recreation in external tools would weaken it. Open beta gives Figma a larger population for finding those problems.

The second signal is whether design guidelines and code sources reduce agent errors. Teams should see more reuse of approved components and fewer brand or implementation mismatches.

Figma’s October release notes confirm that the agent can read library guidelines, search files, attach platform context, and support custom skills. These capabilities establish the mechanism, not the outcome.

The decisive evidence will come from repeated production use. A successful system should help agents follow conventions without requiring users to restate them in every prompt.

It should also make conflicts visible. If the design library and code repository disagree, the system must help teams identify which source is authoritative.

Otherwise, additional context may increase ambiguity. An agent can receive more information while becoming less certain about which instruction to follow.

The third signal is how external agent support develops. Figma’s platform argument grows stronger when teams can change models without rebuilding their design context.

Support for more MCP clients creates distribution, but compatibility must extend beyond basic write access. External agents need reliable access to components, variables, guidelines, images, and code relationships.

Figma has said it is working toward broader parity with its Plugin API. Progress there will determine whether outside agents become full collaborators or limited import tools.

The competitive response will matter as well. Code editors and development platforms can deepen their own design integrations, while document systems can make specifications more agent-readable.

If those tools preserve context without routing work through Figma, teams may prefer a distributed workflow. Figma must prove that consolidation produces clearer decisions, not merely more platform dependence.

For designers, the practical question is whether the canvas remains a place for judgment. Agents should accelerate variations and routine edits without turning design review into output cleanup.

For developers, the question is whether code layers preserve useful implementation context. Generated prototypes must reveal tradeoffs without being mistaken for reviewed production code.

For product leaders, the value lies in traceability. A requirement should connect to the design, prototype, code source, and decision that shaped it.

Figma agent features now provide the pieces for that workflow. The coming months will show whether teams can keep those pieces synchronized under everyday pressure.

Treat the open beta as an operational experiment. Choose one bounded workflow, connect current sources, define ownership, and measure rework before expanding.

The important question is no longer whether an AI agent can draw an interface. It is whether your team can explain why that interface follows its standards, and correct it when it does not.