Ein Modell kann nichts tun. Es liest Text und produziert Text. Jede Handlung, die ein Agent zu vollziehen scheint — das Meeting buchen, die Rechnung anlegen, den Datensatz aktualisieren — passiert, weil etwas diesen Text in einen API-Aufruf verwandelt hat.
Was heisst: Die interessante Ingenieursfrage ist still umgezogen. Nicht welches Modell — sondern was es erreichen kann, und wie gut.
Die Fähigkeitsdecke sind Ihre Endpunkte
Tauschen Sie ein gutes Modell gegen ein besseres, wird ein Agent etwas klüger. Geben Sie ihm Zugriff auf ein System, das er vorher nicht berühren konnte, kann er etwas, das er vorher fundamental nicht konnte.
Das sind verschiedene Grössenordnungen von Veränderung — und Teams überinvestieren konsequent in die erste.
Die praktische Konsequenz: Agentenfähigkeit ist durch die API-Oberfläche begrenzt. Hat Ihr Billing-System keine API, wird kein Modell je ein Abo aktualisieren — egal, wie clever es wird. Die Decke ist architektonisch, nicht kognitiv.
Deshalb erzielen Organisationen mit reifen internen APIs Ergebnisse mit Agenten, während Organisationen mit denselben Modellen und besseren Ingenieuren es nicht tun. Der Unterschied wurde Jahre früher entschieden — dadurch, ob jemand darauf bestand, dass interne Systeme Schnittstellen anbieten.
Für Menschen entworfene APIs scheitern an Agenten — spezifisch
Die meisten APIs wurden für einen Entwickler gebaut, der Dokumentation liest, die Domäne versteht und bewussten Code schreibt. Agenten verletzen alle drei Annahmen, und die Fehler sind konsistent.
Geschwätzige Endpunkte. Ein Ablauf, der sechs sequenzielle Aufrufe braucht, ist im Code in Ordnung und für einen Agenten schlecht — jeder Roundtrip ist verbrauchter Kontext und eine weitere Gelegenheit, den Faden zu verlieren. Endpunkte, die einen ganzen Job in einem Aufruf erledigen, performen dramatisch besser.
Mehrdeutige Namen. Ein Entwickler mit Doku findet heraus, was /v2/entities liefert. Ein Agent, der zwischen getEntity, fetchRecord und lookupItem mit knappen Beschreibungen wählt, wählt halbwegs zufällig.
Nutzlose Fehler. 400 Bad Request sagt einem Agenten nichts Umsetzbares — also wiederholt er denselben Aufruf. Ein Fehler, der das betroffene Feld und das erwartete Format nennt, wird beim zweiten Versuch behoben.
Riesige Antworten. Neunzig Felder zurückzugeben, wo der Agent drei wollte, verbrennt Kontext und begräbt die Antwort. Schlanke Antworten mit expliziter Feldauswahl zählen weit mehr als früher.
Abb. — Das Modell ist das Denken. Die API ist alles, was tatsächlich passiert.
Was sich an Ihrem Design ändert
Beschreibungen als Anweisungen schreiben, nicht als Dokumentation. «Liefert Bestelldaten» ist ein Docstring. «Schlage die Bestellungen eines Kunden nach, wenn er nach Lieferstatus oder Rückerstattung fragt. Braucht E-Mail oder Bestell-ID.» sagt einem Modell, wann es zugreifen soll. Dieser Satz leistet mehr für die Zuverlässigkeit als die meisten Code-Änderungen.
Endpunkte um Absichten herum entwerfen. Menschen komponieren Primitive; Agenten sind besser mit Endpunkten in Form des Jobs — rescheduleAppointment statt eines Fetch, eines Delete und eines Create, die in Reihenfolge passieren müssen und nicht halb passieren dürfen.
Idempotenz explizit machen. Agenten wiederholen. Sie wiederholen nach mehrdeutigen Fehlern, nach Timeouts — und manchmal, weil sie den Überblick verloren haben. Ein Endpunkt, der bei Wiederholung eine doppelte Bestellung anlegt, wird doppelte Bestellungen anlegen. Idempotenz-Schlüssel hören auf, eine Nettigkeit zu sein.
Maschinenlesbare Fehler zurückgeben. Ein Code, ein Feld, ein Korrekturhinweis. Diese eine Änderung verbessert Agenten-Erfolgsquoten messbar — denn die meisten Agentenfehler sind behebbare Fehler, die nutzlos beschrieben waren.
Über Berechtigungs-Granularität nachdenken. Ein Agent sollte Zugangsdaten halten, die auf seinen Job beschränkt sind — was nur geht, wenn Ihre API Scopes enger als «Vollzugriff» kennt. Viele tun das nicht, und diese Lücke ist der Grund, warum so viele Deployments überprivilegiert laufen.
Die Integration, aus der man sich nicht herauskaufen kann
Es gibt eine verlockende Abkürzung: die API-Arbeit überspringen und den Agenten stattdessen die Benutzeroberfläche bedienen lassen. Computer-Use-Modelle können sich durch Screens klicken, und für Systeme ohne jeden programmatischen Zugang ist das manchmal die einzige Option.
Man sollte wissen, was man akzeptiert. UI-Automatisierung ist um eine Grössenordnung langsamer, bricht, sobald der Anbieter einen Button verschiebt, und produziert keine saubere Audit-Spur — Sie bekommen Screenshots, keine strukturierten Änderungsprotokolle. Sie erbt zudem die Session, unter der sie läuft, womit Berechtigungs-Scoping weitgehend verschwindet.
Nutzen Sie sie als Brücke für das eine Altsystem, das niemand je modernisieren wird. Bauen Sie keine Strategie darauf. Teams, die UI-Automatisierung als API-Äquivalent behandeln, entdecken den Unterschied beim ersten Anbieter-Update — meist im schlechtesten Moment.
Der haltbarere Zug ist unglamourös: herausfinden, welche Systeme wirklich keine API haben — und das Schliessen dieser Lücke als das Projekt behandeln statt als Voraussetzung des Projekts.
Die betriebliche Verschiebung, die niemand eingeplant hat
Traffic-Muster ändern sich auf Arten, die Annahmen aus menschlicher Nutzung brechen.
Agenten sind stossweise. Ein Mensch browst in Menschengeschwindigkeit; ein Agent feuert zwanzig Aufrufe in zwei Sekunden, dann eine Stunde nichts. Rate-Limits, die auf interaktive Nutzung getrimmt sind, drosseln legitime Agentenarbeit — und tun nichts gegen den echten Missbrauchsfall.
Nutzungsbasierte Preise werden seltsamer. Ist Ihre API pro Aufruf bepreist und der Aufrufer eine Schleife, kann ein Kunde eine Rechnung erzeugen, die niemand beabsichtigt hat. Ausgabendeckel und klare Pro-Schlüssel-Limits wandern von nett zu nötig — zu seinem Schutz und Ihrem.
Und die Observability muss eine neue Frage beantworten. Nicht nur, was aufgerufen wurde — sondern in wessen Auftrag und als Teil welcher Aufgabe. Denn wenn etwas schiefgeht, ist «der Agent war's» keine Antwort, die irgendjemand akzeptiert.
Interne APIs werden an einem neuen Standard gemessen
Das meiste hier klingt nach öffentlichen APIs — aber der schärfere Einschlag landet intern, und er legt etwas Unbequemes offen.
Interne APIs entstehen üblicherweise im Wissen, dass die einzigen Konsumenten zwei Tische weiter sitzen. Die Doku ist dünn, weil man fragen kann. Die Namen sind inkonsistent, weil jedes Team auf seine Art benannt hat. Die Fehlerbehandlung ist lässig, weil der Aufrufer die Logs liest. Nichts davon zählte, solange jeder Konsument ein Kollege war.
Ein Agent hat keinen Kollegen zum Fragen. Er liest die Beschreibung, trifft eine Wahl und lebt mit der Konsequenz. Die interne API, die fünf Jahre still funktionierte, weil alle ihre Eigenheiten kannten, wird zu der, die ein Agent falsch benutzt — wiederholt.
Die Teams, die mit Agenten am schnellsten vorankommen, sind fast ausnahmslos die, die aus einem anderen Grund längst zu disziplinierten internen Schnittstellen gezwungen waren — ein Plattform-Team, eine Microservice-Migration, eine Übernahme, die Integration verlangte. Sie haben nicht für Agenten gebaut. Sie hatten zufällig das gebaut, was Agenten brauchen.
Starten Sie aus einem Gewirr interner Systeme mit Teil-Schnittstellen, ist genau das die Arbeit. Sie ist unglamourös, sie demonstriert sich nicht — und sie ist die eigentliche Voraussetzung.
Wo anfangen
Nehmen Sie den Ablauf, den ein Agent am liebsten übernehmen soll, und verfolgen Sie ihn Ende zu Ende. Jeder Schritt muss über eine API erreichbar sein — und ist es meistens nicht: Es gibt einen Schritt, den jemand in einer UI erledigt, oder ein System ganz ohne Schnittstelle. Diese Lücke ist Ihr tatsächlicher Blocker, und keine Modellwahl adressiert sie.
Versionieren Sie ab jetzt bewusst. Eine API mit Agenten-Konsumenten hat Aufrufer, die keinen Migrationsleitfaden lesen können, über keine Breaking Change gemailt werden können — und die alte Form selbstbewusst weiter aufrufen, bis sie bricht. Additive Änderungen sind sicher; ein Feld umzubenennen ist es nicht. Teams, die Breaking Changes hinter gut kommunizierten Deprecation-Fenstern gewohnt sind, brauchen eine neue Gewohnheit — denn den Kommunikationskanal gibt es nicht.
Und verbessern Sie zuerst die Beschreibungen. Es ist die billigste Änderung mit dem grössten Effekt — und die meisten Teams springen direkt dazu, Werkzeuge auf Endpunkte zu bauen, die niemand sauber beschrieben hat.
Die unbequeme Fassung des Ganzen: Ihre Agentenstrategie ist überwiegend eine API-Strategie in anderem Vokabular. Teams, die das früh erkennen, stecken ihren Aufwand in die Integrationsoberfläche. Teams, die es nicht tun, stecken ihn in Modellvergleiche — und bleiben an derselben Decke hängen, mit besseren Benchmarks.
Die meisten unserer Agent-Projekte beginnen genau dort: erst die Integrationsfläche richten, dann das Modell anfassen. Wenn Ihre APIs die Decke sind, lohnt sich das Gespräch früh.
