Randnotiz

Wenn SaaS-Produkte Agenten onboarden

Handgezeichneter Grundriss eines Arbeitsraums mit einem Agenten-Terminal in der Mitte und mehreren SaaS-Modulen an den Rändern. Ein bernsteinfarbener Pfad unter der Oberfläche markiert die versteckten Vendor-Defaults.

Resend hat diese Woche ein offizielles Claude-Code-Plugin vorgestellt. Klingt erst einmal nach einer kleinen Produktmeldung. Noch ein Plugin. Noch ein Integrationspunkt. Noch ein Changelog-Eintrag, den man überfliegt und wieder vergisst.

Sollte man nicht.

Das Interessante an der Meldung ist nicht Resend. Das Interessante ist das Paketformat. Resend liefert nicht nur eine API, ein SDK oder eine Dokumentation. Das Plugin bündelt MCP-Server, Resend-Skills, React-Email-Kontext, Best Practices für SPF, DKIM, DMARC und Deliverability, einen Skill für die Verarbeitung eingehender E-Mails durch Agenten und CLI-Unterstützung.

Anders gesagt: Resend onboardet nicht mehr nur Entwickler. Resend onboardet den Agenten.

Das Muster sieht man inzwischen an mehreren Stellen im Claude-Plugin-Verzeichnis. Vercel gibt Claude Code Zugriff auf Deployments, Logs, Domains und Umgebungsvariablen. Supabase bietet SQL, Migrationen, TypeScript-Types, Logs und Edge Functions als Agenten-Workflow an. Figma liefert Design-Kontext, Tokens, Komponenteninformationen und Code-Connect-Mapping. GitHub verbindet Issues, Pull Requests, Actions, Releases und Security Findings mit dem Agenten.

Das ist mehr als eine bequemere API-Anbindung.

Bleib auf dem Laufenden

Erhalte eine Nachricht, wenn ein neuer Essay erscheint. Jederzeit abbestellbar.

APIs waren Schnittstellen für Maschinen. Dokumentation war die Schnittstelle für Menschen. Plugins und Skills werden zur Schnittstelle für Agenten.

Damit verschiebt sich eine alte Machtfrage. Früher kämpften SaaS-Anbieter darum, welche API Entwickler zuerst integrieren. Dann darum, welches SDK im Stack landet. Dann darum, welche Doku in Google oder Stack Overflow auftaucht. Jetzt entsteht eine neue Schicht: Welches Handlungsmodell bekommt der Agent, wenn jemand sagt: „Deploy das“, „prüf den PR“, „bau das Template“ oder „setz die Datenbank auf“?

Das klingt abstrakt, ist aber ziemlich praktisch. Ein Agent, der Vercel als Default-Weg für Deployment gelernt hat, wird anders handeln als ein Agent, der erst neutral aus Projektkontext, Infrastrukturregeln und vorhandenen Skripten ableiten muss, was zu tun ist. Ein Agent, der Resend-Best-Practices eingebaut bekommt, wird E-Mail anders bauen als einer, der sich aus allgemeinen Webquellen etwas zusammenliest. Ein Agent, der Figma-Tokens direkt ziehen kann, hat eine andere Vorstellung von Design-Konsistenz als einer, der einen Screenshot interpretiert.

Das ist der Nutzen. Weniger Reibung. Weniger Kontextverlust. Weniger zufällige Umsetzung.

Aber natürlich kommt die Gegenrechnung mit.

Wer den Skill liefert, liefert nicht nur Zugriff. Er liefert auch Framing. Der Agent lernt nicht neutral „wie E-Mail geht“, sondern „wie E-Mail mit Resend geht“. Er lernt nicht neutral „wie Frontend-Deployment geht“, sondern einen bevorzugten Pfad durch Vercel. Das muss nicht schlecht sein. Defaults sind nützlich. Ohne Defaults würden die meisten Systeme nie benutzt.

Nur sind Defaults nie unschuldig.

Das ist App-Store-Logik, aber tiefer im Arbeitsprozess. Nicht mehr: Welche App installiere ich? Sondern: Welche operative Gewohnheit bekommt mein Agent mitgeliefert? Wer diese Schicht besetzt, sitzt nicht nur im Tooling. Er sitzt im Entscheidungsfluss.

Für Unternehmen wird das unbequem. Auf dem Papier klingt es rational, den Agenten mit den besten offiziellen Plugins auszustatten. In der Praxis entsteht damit ein neuer Schattenstandard. Teams installieren ein Plugin, weil es Arbeit spart. Danach folgen mehr Prompts diesem Pfad. Danach werden Prozesse um diesen Pfad herum gebaut. Danach ist der Wechsel nicht mehr nur ein Toolwechsel, sondern ein Wechsel gelernter Handlungen.

So entsteht Lock-in selten durch einen großen Vertrag. Meistens entsteht er durch Bequemlichkeit, die jeden Tag ein bisschen plausibler wird.

Die Frage für AI-Transformation ist deshalb nicht: „Welche Plugins gibt es?“ Die bessere Frage lautet: „Welche Defaults dürfen unsere Agenten überhaupt haben?“

Denn wenn Agenten künftig operative Arbeit ausführen, dann ist ihr Kontext keine Doku-Beilage mehr. Er ist Prozessarchitektur.

Und Prozessarchitektur überlässt man ungern komplett dem Vendor. Sollte man zumindest nicht. Ist aber bequem. Genau deshalb wird es passieren.

Prüffrage für morgen früh: Welche SaaS-Tools in eurem Stack liefern bereits MCP-Server, Skills oder Agenten-Plugins? Und wichtiger: Welche impliziten Defaults kaufen eure Teams damit gleich mit?