Where Agentic Design Is Heading

This is a field note, not a research report, and most of it is opinion. Where we make a claim about what exists today, it is anchored to a published page; where we make a claim about the next year, it is our read, and we say so. The honest summary of the moment, re-checked on 9 October 2026, is this: agentic design is no longer a terminal-tool niche. Figma's remote MCP server can read a file and, still in beta, write native frames, components, and variables with use_figma. Figma Make can connect to a GitHub repository and open a pull request, and that production-codebase path is still a closed beta, Mac-only, on the Figma help center. Make output is evidence of a direction. It is not the production codebase until a reviewer merges it. Meanwhile the platform layer already churned: on 18 June 2026 Gemini CLI stopped serving individual, Google AI Pro, and Google AI Ultra requests. Antigravity CLI is the individual successor. Gemini Code Assist Standard and Enterprise, and paid API keys, stayed on Gemini CLI.

Those two facts — the canvas opening to agents, and the platforms refusing to hold still — frame everything else in this note. The first says the convergence of design and code is no longer something you have to squint at terminal demos to believe. The second says that betting your workflow on any single platform is still a mistake, and that the durable investment is the part you can carry between them.

We see three lines of travel worth planning around, with very different amounts of evidence behind each. The diagram below is the whole argument in one picture; the sections after it walk the three lines in order of confidence, and then the counterweight that applies to all of them.

Our read as of 9 October 2026: design/code convergence is shipping, with Figma write still in beta and Make's GitHub path still a closed beta. Design systems as agent contracts are shipping with a human-approval ceiling. Real-time human-plus-agent collaboration is the bet we are least sure about.

This is the trend with the strongest public evidence, because the incumbent canvas is in it. Figma's write-to-canvas tool, use_figma, entered open beta on 16 June 2026. On 9 October 2026 the developer docs still call it beta, still say it is free during the beta with usage-based pricing planned, and still limit writes outside drafts to a Full seat. Supported clients include Claude Code, Codex, Cursor, and VS Code. Dev seats stay read-only outside drafts. Code Connect still maps library components to real code, and those components have to be published before that mapping completes. Figma Make's GitHub path can clone a repo, edit the running app, and open a pull request, and the help center still marks that as a closed beta for Mac. The pull request is the production step. The Make file is not.

Our opinion on what this means: the design-to-code handoff — redlines, specs, the lossy translation step that consumed so much of product design's calendar — stops being a phase and becomes a diff. When the design artifact and the production code are connected by agents that can read both and write both, the interesting question is no longer how do we hand this over but who reviews the change and against what. That is a design-process question, and most teams have not answered it yet.

The practical consequence we already act on: design artifacts that cannot be diffed are becoming second-class citizens of this loop. Tokens as JSON, surfaces as text, decisions visible in version control — the case for that is made in the design-as-code article, and every announcement in this paragraph strengthens it. The convergence does not require you to abandon the canvas; it requires the canvas and the codebase to agree on a machine-readable contract, which is the second trend.

The second trend has good evidence and a clear ceiling. Figma's own argument — that MCP servers serving design-system context, variables, and Code Connect mappings are what make agent output usable — is vendor framing, and we attribute it as such, but it matches what we see in practice: agents produce acceptable interface work roughly in proportion to how much of the design system they can read as structured data. Token files, component inventories, usage rules, and anti-patterns are turning into the instruction set agents execute, and drift detection and token sync are becoming routine agent work rather than quarterly cleanup projects.

Call this the autonomous design system trend if you like, but the autonomy has a hard edge, and pretending otherwise is how this trend gets oversold. What agents can already do is mechanical propagation: notice that a token changed, find every surface that consumes it, open the change for review, and document what moved. What stays human — in every credible example we have seen, including our own — is approval, deprecation decisions, breaking-change judgment, and taste. The design system maintains its consistency almost by itself; it does not decide what it should become.

Our read for the next year, marked as opinion: the teams that benefit from this are the ones whose design systems are already legible to machines — tokens in a standard format, components mapped to real code, rules written down rather than tribal. The work of making a design system machine-readable is unglamorous and it is exactly the work we would prioritize this year, because it pays off under every version of this future, including the slower ones.

The third trend is the one that gets the most demo time and has the least evidence behind it: humans and agents working live on one shared surface, the way two designers multiplayer-edit a file today. We want to be precise about what actually exists. Canvas agents now work inside the same file as the team, and concurrent agent runs let several agents produce work in parallel. Both are real, both are useful, and neither is live collaboration in the multiplayer sense — the agent works, then you look. There is, as far as the public record shows, no shipping product where humans and agents co-manipulate a design surface in real time with the fluidity the demos imply.

So this section is opinion, clearly labelled. Our guess is that the live version arrives later than the excitement suggests, and that when it arrives it looks less like a colleague's cursor and more like a fast review loop: the agent proposes in seconds, the human accepts, redirects, or rejects, and the surface updates. The bottleneck is not model latency — it is that real-time collaboration only works when both parties share enough context to act without asking, and giving an agent that context is exactly the harness, brief, and design-system work the rest of this site describes. Teams hoping that a live agent will compensate for an unwritten design system will be disappointed in either order.

What we would not do is plan this year's tooling decisions around this trend. It is the most likely of the three to change shape entirely, and nothing about preparing for the first two trends is wasted if it does.

Every prediction above comes with the same caveat: the platforms delivering this future keep replacing themselves. The cleanest finished example is Gemini CLI. It stopped serving individual, Pro, and Ultra users on 18 June 2026, and Antigravity CLI took that seat. Windsurf became Devin Desktop, and Cascade has been removed from that app. We are not singling anyone out. Churn is a planning constraint.

The counter-trend is the open layer. AGENTS.md loads on every turn. A SKILL.md body loads when the task needs it. MCP, now at the stable 2026-07-28 specification, connects agents to design tools. Those three are supported across Claude Code, Codex CLI, OpenCode, and Antigravity CLI. The durable asset is the harness: DESIGN.md, the instruction files, the skills, the token contract, and the review gates.

This is the school's standing position rather than a fresh prediction, and the deep articles carry the mechanics: the platform-choice article covers what ports cleanly and what needs an adapter, and the harness article covers what to build before you prompt at all. The new announcements do not change that advice; they make it cheaper to follow, because every platform now reads the same files.

Field notes should end with something you can act on, so here is ours — four moves that are cheap, low-regret, and useful under every version of the future described above. They are recommendations, not guarantees, and they assume a product team that already ships software.

None of these require believing our predictions. They require believing only the part with receipts: agents can now read and write the surfaces designers care about, the standards for instructing them have stabilized, and the platforms hosting them have not.

• Make your design system machine-readable before making it bigger: tokens in a standard format, a component inventory that maps to real files, anti-patterns written down.
• Put your harness on the open-standards layer — AGENTS.md, Agent Skills, MCP — so the next platform deprecation is an adapter change, not a rebuild.
• Pick one design-to-code round trip and run it end to end with review gates, so your team learns where the loop breaks before it matters.
• Treat real-time agent collaboration as a demo to watch, not a dependency to plan on; revisit when a shipping product survives contact with a real design review.