Figma erläutert Leitplanken für Agenten mit Specs, Bibliotheken und Zugriffsregeln

Auf der Config India 2026 hat Figma einen deutlich konkreteren Rahmen vorgestellt, wie der eigene Agent des Unternehmens und Agenten von Drittanbietern innerhalb der Plattform arbeiten können. In den Release Notes und in einem Bericht von TechCrunch beschrieb das Unternehmen eine Reihe von Werkzeugen, die Agenten mehr Kontext und zugleich mehr Einschränkungen geben sollen: einen neuen Markdown-basierten Editor namens Specs, Richtlinien an Designbibliotheken, Codequellen, zentralisierte Designsysteme und eine breitere Unterstützung über Figma MCP. Der gemeinsame Nenner ist Governance. Figma fügt also nicht nur KI-Funktionen hinzu, sondern versucht auch festzulegen, wie Teams das Verhalten von Agenten mit Regeln, Dateien und gemeinsam genutzten Referenzen formen können.

Der Fokus auf Leitplanken scheint mit einer Grenze zusammenzuhängen, die Figma selbst einräumt. Laut TechCrunch stellt Figma, nachdem der Agent auf dem Canvas in der vergangenen Woche für einen größeren Nutzerkreis verfügbar gemacht wurde, zugleich Werkzeuge bereit, um ihn in Richtung besser vorhersehbarer Ergebnisse zu lenken, weil KI nicht deterministisch ist. Diese Einordnung ist wichtig. Anstatt Agenten standardmäßig als vollständig verlässlich darzustellen, positioniert das Unternehmen Kontext und Systemregeln als Mittel, um die Variabilität zu verringern.

Ein nativer Ort für Absicht und Kontext

Die zentrale Ankündigung ist Figma Specs. In den Release Notes beschreibt Figma Specs als eine native Heimat für Kontext, die schriftlich formulierte Absicht, visuelle Exploration und technische Details für Teams und Agenten zusammenführt. TechCrunch ergänzt, dass es sich dabei um einen Markdown-Editor handelt, mit dem Nutzer ihre Designsprache auf einfache Weise definieren können. Dem Bericht zufolge kann Specs als eigenständige Datei in Figma existieren oder neben dem Canvas, und Nutzer können auf andere Figma-Elemente verweisen, etwa Canvas-Elemente, FigJam-Diagramme, Code-Layer und Designs.

Zusammengenommen legen die beiden Quellen nahe, dass Specs mehr leisten soll, als ein Projekt für Menschen zu dokumentieren. Es soll auch maschinenlesbarer Kontext für KI-Systeme werden, die in Figma arbeiten. Die Release Notes gehen nicht im gleichen technischen Detailgrad wie TechCrunch auf das Einbetten oder Referenzieren anderer Figma-Objekte ein, doch beide Quellen stimmen in der übergeordneten Rolle überein: Agenten sollen denselben schriftlichen und visuellen Kontext heranziehen können wie menschliche Mitwirkende.

Die Verfügbarkeit ist hier klarer als bei manchen anderen Ankündigungen. Figma sagt, dass Specs ab sofort als Open Beta in kostenpflichtigen Tarifen ausgerollt wird. Diese Unterscheidung ist für Governance-Diskussionen in Organisationen wichtig: Die Funktion wird weder als allgemein verfügbar beschrieben noch für alle Tarife aufgeführt.

Bibliotheken, Richtlinien und Code als Einschränkungen für Agenten

Über Specs hinaus formalisiert Figma auch weitere Ebenen der Kontrolle. Laut den Release Notes können Teams veröffentlichten Designbibliotheken Richtlinien hinzufügen, damit der Agent etablierten Mustern folgt und Anti-Patterns vermeidet. Diese Funktion wird ab sofort als Open Beta ausgerollt. Figma sagt außerdem, dass Code aus GitHub-Repositories oder npm-Paketen als Codequellen importiert werden kann, um dem Agenten beim Erstellen und Bearbeiten von Komponenten und Code-Layern zu helfen, die reale Designsysteme widerspiegeln. Diese Funktion wird ab sofort als Closed Beta ausgerollt.

TechCrunch zeichnet ein ähnliches Bild und schreibt, dass Teams mehr Designkontext einbringen können, darunter Designbibliotheken, Codebibliotheken und Richtlinien, um den Kontext für das Designsystem zu verwalten, und dass Agenten auf dieses zentralisierte System verweisen können, um Regeln einzuhalten. Figmas eigene Release Notes sind bei der Produktverpackung konkreter. Dort werden zentralisierte Designsysteme als Bündel aus Designbibliotheken, Codebibliotheken und Richtlinien beschrieben, die zu einem einzigen Designsystem zusammengefasst werden, damit die Pflege für Autoren einfacher und die Einhaltung für alle leichter wird. Figma kennzeichnet zentralisierte Designsysteme jedoch nur als Vorschau.

• Specs: Open Beta in kostenpflichtigen Tarifen.
• Richtlinien in veröffentlichten Designbibliotheken: Open Beta.
• Codequellen aus GitHub-Repositories oder npm-Paketen: Closed Beta.
• Zentralisierte Designsysteme: nur Vorschau.
• Figma MCP mit 20 neuen Partnern: ab sofort verfügbar.

Diese Aufschlüsselung ist wichtig, weil sich die Governance-Erzählung über Funktionen mit unterschiedlichem Reifegrad verteilt. Einige Kontrollen sind für zahlende Kunden bereits recht breit nutzbar, einige sind auf ausgewählte Nutzer begrenzt, und andere bleiben vorerst nur eine Vorschau. Jedes Unternehmen, das beurteilen will, wie viel Richtlinie und Prozess sich heute mit Figma-Agenten tatsächlich durchsetzen lassen, muss daher zwischen angekündigter Richtung und aktueller Verfügbarkeit unterscheiden.

Code-Layer erweitern den Handlungsspielraum des Agenten

Figma verschärft nicht nur die Vorgaben, sondern erweitert auch, was Agenten tun können. Code-Layer, die laut TechCrunch im Juni zunächst als Private Beta angekündigt wurden, werden nach Angaben beider Quellen nun als Open Beta ausgerollt. Figma beschreibt sie als Möglichkeit, interaktive, codegestützte Prototypen auf dem Canvas zu erstellen, indem ein Design-Frame konvertiert, ein GitHub-Repository importiert, eine Website mit der Figma-Chrome-Erweiterung erfasst oder ein Prompt von Grund auf erstellt wird.

TechCrunch ergänzt ein weiteres für Governance relevantes Detail: Nutzer können den Agenten bitten, ein Design in Code umzuwandeln oder einen Teil des Codes zu ändern, um einen Prototyp weiterzuentwickeln. Mit anderen Worten: Der Agent rückt näher an eine Build-Oberfläche heran und ist nicht mehr nur ein Assistent fürs Brainstorming. Figmas Release Notes unterstreichen diese Richtung, indem sie sagen, dass Figma MCP nun aus externen KI-Tools heraus genutzt werden kann, um Code-Layer zu erstellen, Specs zu bearbeiten oder Bilder auf dem Canvas zu generieren.

Diese Kombination hat zwei Folgen. Erstens werden Kontextkontrollen bedeutsamer, wenn der Agent codegestützte Prototypen beeinflussen kann und nicht nur statische Designartefakte. Zweitens wird Interoperabilität selbst zu einem Governance-Thema. Figma erklärt, MCP biete nun eine schnellere Leistung, Unterstützung für mehr Figma-Produkte und Unterstützung für 20 neue Partner. TechCrunch nennt unter den hinzugefügten Werkzeugen Open Code, Dia, Grok Bot und Sarvam. In dem vorliegenden Auszug aus Figmas Notizen werden diese Namen nicht aufgeführt, daher stammt dieses Partnerdetail von TechCrunch.

Payload-Integration und der Übergang vom Prototyp zur App

Ein weiterer Teil der Ankündigung reicht über Design-Governance hinaus in die Bereitstellung von Anwendungen hinein. Figma sagt, dass Make nun nativ ein Payload-Backend aufsetzt und dabei ein CMS, eine Datenbank, Medien, APIs, Authentifizierung und ein Admin-Panel bereitstellt, wobei Figma das Hosting übernimmt, sodass Inhalte und Daten am selben Ort liegen wie die Designs, die sie prägen. Laut den Release Notes wird dies für alle Tarife ausgerollt.

TechCrunch berichtet ähnlich, dass Figma Payload in Figma Make integriert, um dynamische Websites zu generieren und Inhalte direkt zu verwalten. Der Artikel weist außerdem darauf hin, dass Figma das Open-Source-Headless-CMS Payload im vergangenen Jahr übernommen hat. Auch wenn diese Integration nicht primär als Funktion zur Agenten-Governance eingeordnet wird, stärkt sie die breitere Produktlogik hinter den Ankündigungen: Designkontext, Codekontext und Inhaltskontext werden in eine gemeinsame Umgebung gezogen, in der Agenten handeln können.

Was bestätigt ist und was richtungsweisend bleibt

Über die Quellen hinweg ist die Kernaussage konsistent: Figma will Teams in die Lage versetzen, festzulegen, wie Agenten sich verhalten, indem ihnen expliziter Kontext und Regeln gegeben werden. Dennoch ist bei zwei Punkten Vorsicht geboten. Erstens sind mehrere Fähigkeiten noch nicht vollständig verfügbar. Open Beta, Closed Beta und reine Vorschau bedeuten operativ nicht dasselbe. Zweitens erscheinen einige Umsetzungsdetails nur in jeweils einer Quelle. So beschreibt TechCrunch Specs als Markdown-basiert und sagt, dass eingebettete Figma-Elemente referenziert werden können, während sich Figmas Release Notes stärker auf den allgemeinen Produktzweck als auf genau diese Mechanik konzentrieren.

Auch in der Gewichtung unterscheiden sich die Quellen. TechCrunch hebt die Begründung hervor, dass KI nicht deterministisch ist und Figma versucht, Ergebnisse in Richtung Vorhersehbarkeit zu lenken. Figmas Release Notes betonen dagegen Workflow und Produktabdeckung und beschreiben Wege, mit Code zu bauen und zusammenzuarbeiten, Kontext zu erfassen und zu teilen sowie mit echten Daten und Inhalten zu entwickeln. Diese Darstellungen sind miteinander vereinbar, aber nicht identisch.

Für Unternehmen im deutschsprachigen Raum besteht die praktische Veränderung darin, dass Figma Teams konkretere Hebel an die Hand gibt, um zu entscheiden, was ein Agent sehen soll, welchen Regeln er folgen soll und wo er handeln darf. Heute kann das bedeuten, Absichten in Specs zu dokumentieren, Richtlinien an veröffentlichte Bibliotheken anzuhängen und codegestützte Workflows in der Open Beta zu testen, während zugleich zu berücksichtigen ist, dass einige Kontrollen in der Closed Beta oder in der Vorschau verbleiben. Kurz gesagt: Organisationen können beginnen, Agentenverhalten weniger als ad hoc formulierte Prompt-Aufgabe und stärker als gesteuerten Bestandteil des Designsystems zu behandeln, müssen diesen Anspruch aber mit dem aktuellen Rollout-Status jeder einzelnen Funktion abgleichen.