Kann ein KI-Agent dein Produkt benutzen, oder nur darüber lesen?

Für einen Agenten lesbar zu sein und von einem benutzbar zu sein sind zwei verschiedene Projekte, und fast jedes Team hat nur das erste gemacht. Lesbar heißt, ein Assistent kann dich zusammenfassen und zitieren. Benutzbar heißt, er kann im Namen einer konkreten Person eine Aufgabe auf deinem Produkt erledigen, und er kann gestoppt werden, wenn er es soll.

Das Zweite ist überwiegend kein Modellproblem. Es ist ein Problem von Autorisierung, Identität und Fehlersemantik, und deshalb landet es beim Engineering und nicht im Marketing.

Zwei verschiedene Fragen

Die letzte Zeile ist der Grund, warum die zweite Spalte länger dauert. Ein Lesbarkeitsbug kostet dich ein Zitat. Ein Autorisierungsbug kostet dich einen Incident, das Tempo der Arbeit richtet sich also danach, wie zuverlässig du Nein sagen kannst.

Wenn die erste Spalte noch nicht erledigt ist, fang dort an. Unser Guide zu agentenlesbaren Websites behandelt das, und es ist ein Bruchteil des Aufwands.

Was „benutzbar“ tatsächlich verlangt

Eine Tool-Oberfläche, die ein Agent bedienen kann, braucht fünf Dinge, und die interessanten sind nicht die API.

• Identität, die nicht die des Agenten ist. Der Agent handelt für einen Nutzer oder einen Mandanten. Wenn deine Tokens nicht ausdrücken können „dieser Agent, im Namen dieser Person, für diesen Scope, bis zu diesem Zeitpunkt“, ist praktisch jeder Aufruf ein Admin-Aufruf.
• Autorisierung auf der Datenebene. Im Prompt zu filtern ist keine Zugriffskontrolle. Die Grenze gehört dorthin, wo die Query läuft, damit eine überzeugende Anweisung sie nicht verschieben kann.
• Idempotenz. Agenten wiederholen. Sie wiederholen bei Timeouts, die sie falsch gelesen haben, und bei Teilantworten, die sie nicht verstanden haben. Jeder zustandsändernde Aufruf braucht einen Key, der den zweiten Versuch zu einem No-op macht.
• Fehlersemantik, mit der ein Modell etwas anfangen kann. Ein 400 mit „invalid request“ erzeugt eine Retry-Schleife. Ein 400, das sagt, welches Feld fehlgeschlagen ist und welche Form erwartet wurde, erzeugt einen korrigierten Aufruf. Das ist Dokumentation als Steuerungsfläche.
• Discovery. Irgendetwas muss dem Agenten sagen, dass die Tools existieren, was sie kosten und wofür sie da sind. Genau das leisten MCP und veröffentlichte Agent Skills.

Wo MCP hingehört und wo nicht

MCP gibt dir einen standardisierten Weg, Tools und Ressourcen einem Modell anzubieten, und es ist der richtige Transport. Es ist kein Autorisierungsmodell, und es dafür zu halten ist der häufigste Fehler in diesem Bereich. Das Protokoll trägt deine Entscheidungen; es trifft sie nicht.

Die Designfragen darunter sind die bekannten. Für welchen Mandanten ist dieser Aufruf. Welche Datensätze dieses Mandanten darf dieser Scope sehen. Wer genehmigt einen Schreibzugriff. Was wird geloggt, damit ein Incident rekonstruierbar ist. Wir haben beide Hälften ausführlich aufgeschrieben: Enterprise-MCP-Autorisierungsarchitektur für das mandantenfähige Referenzdesign und MCP-Sicherheitsgrenzen dafür, warum nur Durchsetzung auf Datenebene hält.

Agent Skills sitzen über den Tools als Instruktionsschicht: wann welches Tool, was die Hausregeln sind, was nie passieren darf. Tools ohne Skills werden falsch benutzt; Skills ohne Tools sind Ratschläge. Wir veröffentlichen unsere als statische Dateien mit Prüfsummen, damit jeder lesen kann, was unseren Agenten gesagt wird.

Ein Vorgehen, das keinen Glauben braucht

Du musst nicht glauben, dass Agent-Traffic groß wird, um die ersten zwei Schritte zu rechtfertigen, denn sie sind günstig und zahlen sich auch für Menschen aus.

1. Zuerst lesende Tools. Suche, Lookup, Status. Keine Schreibzugriffe, keine Genehmigungen zu designen, und es übt Identität und Rate Limits unter echten Bedingungen.
2. Veröffentliche die Karte. Ein MCP-Endpoint plus Skills, die die Tools ehrlich beschreiben, inklusive dem, was sie ablehnen.
3. Ein Schreibzugriff, hinter Genehmigung. Nimm die harmloseste Zustandsänderung, ergänze Idempotency-Keys und setze eine menschliche Bestätigung davor. Logge alles.
4. Erweitere nach Evidenz. Entferne das Genehmigungs-Gate nur bei Operationen, bei denen das Log zeigt, dass der Agent konsistent richtig lag, und behalte es überall sonst.

Schritt eins und zwei sind bei einer gut geschnittenen API ein paar Tage Arbeit und sofort nützlich, denn dieselben Schemas und Fehlermeldungen machen deine eigenen Integrationen einfacher. Schritt drei ist dort, wo die echte Designarbeit liegt.

Der ehrliche Teil

Niemand kann dir heute sagen, wie viel Umsatz über Agenten kommt. Wer dir eine Zahl nennt, rät, und wir raten nicht für dich.

Verteidigbar ist die Form der Wette. Die lesende Oberfläche ist günstig, die Standards konvergieren, und die Arbeit ist nicht verloren, wenn Agent-Traffic klein bleibt, denn typisierte Tools, echte Autorisierungsgrenzen und maschinenlesbare Fehler sollte eine erwachsene API sowieso haben. Was wir nicht täten: ein Produkt um einen Kanal herum neu bauen, der sich noch nicht bewiesen hat. Fang mit dem Teil an, der so oder so nützlich ist.