Der Agent benötigt lediglich 500 Token, um zu beurteilen, ob Ihre Software eingesetzt werden soll.

Jetzt nutzen fast alle Entwickler KI-Agenten für ihre Arbeit. Cursor, Claude Code, Windsurf, Gemini CLI – verschiedene Coding-Agenten sind bereits tief in die täglichen Arbeitsabläufe integriert. Eine allgemeine Erfahrung ist: Wenn man den Agenten dazu bringt, bestimmte APIs aufzurufen oder einen Dienst zu integrieren, funktioniert das manchmal so reibungslos, als hätte man Cheats aktiviert, während es manchmal wiederholt Fehler gibt oder er sogar eine Schnittstelle erfindet, die überhaupt nicht existiert.

Die meisten Menschen führen dies auf Folgendes zurück:

„Das Modell ist noch nicht klug genug“.

Aber wenn man umdenkt: Es ist nicht so, dass der Agent nicht klug genug ist, sondern dass manche Produkte von Natur aus agentenfreundlich sind, während andere von Natur aus feindselig gegenüber Agenten eingestellt sind.

Das erinnert stark an die SEO vor mehr als zehn Jahren. Du denkst, der Inhalt deiner Website ist sehr gut, aber Google indiziert ihn einfach nicht. Das Problem liegt nicht im Algorithmus von Google, sondern darin, dass deine Website keine Suchmaschinenoptimierung durchgeführt hat.

Heute spielt sich dasselbe bei Agenten ab, nur dass die meisten Produkte nicht einmal wissen, dass sie gerade „beurteilt“ werden.

Addy Osmani, Director of Engineering für Google Cloud AI, hat diesem Vorfall im April dieses Jahres einen Namen gegeben: AEO (Agentic Engine Optimization), was übersetzt bedeutet:

„Agenten-Engine-Optimierung“.

Wenn SEO die Optimierung für die Google-Crawler ist, dann ist AEO die Optimierung für KI-Agenten. Das ist kein fernes Konzept, sondern eine Reihe von bereits umsetzbaren praktischen Maßnahmen. In einer Zeit, in der Agenten zu den wichtigsten „Nutzern“ von Softwareprodukten werden, bestimmt die Art von Design, die Agenten die Nutzung erleichtert, möglicherweise die tatsächliche Entwicklung der Softwarebranche in der Zukunft.

01

Wie lesen Agenten Dokumentationen?

Im Folgenden wird ein sehr alltägliches Szenario für Nutzer beschrieben.

Ein Ingenieur öffnet Cursor und bittet den Agenten, ihm bei der Integration einer Zahlungs-API zu helfen. Der Agent sendet eine HTTP-Anfrage, ruft die Dokumentationsseite ab und trifft nach 400 Millisekunden eine Entscheidung. Diese Dokumentation hat jedoch fast 200.000 Tokens, was die Kapazität des Kontextfensters des Agenten bei weitem übersteigt. Der Agent gibt keinen Fehler aus, zeigt keine Warnung an, sondern gibt diese Dokumentation stillschweigend auf und erfindet eine Integrationslösung basierend auf den Erinnerungen aus seinen Trainingsdaten.

Und das Ergebnis? Der Nutzer erhält einen Code, der plausibel erscheint, aber beim Ausführen nicht funktioniert. Nach zwei Stunden Fehlerbehebung stellt er fest, dass der Agent einen längst veralteten Endpunkt angegeben hat.

Im Google Analytics-Backend dieses Zahlungsunternehmens hinterlässt dieser Besuch nur einen Eintrag: Die Scrolltiefe beträgt Null, die Verweildauer auf der Seite liegt bei 400 Millisekunden, es gibt keine Klicks. Im Rahmen des traditionellen Analyseframeworks handelt es sich um einen „Besucher von geringer Qualität“, eine anonyme IP mit einer Absprungrate von 100%. Niemand weiß, dass es sich tatsächlich um einen KI-Agenten handelt, und noch weniger wissen, dass dieser Agent gerade ihr Produkt „beurteilt“ und zum Tode verurteilt hat.

Das ist der grundlegende Unterschied zwischen dem Lesen von Dokumentationen durch Agenten und durch Menschen: Menschen „durchstöbern“ sie, Agenten „urteilen“ sie.

Osmani zitiert in seinem Artikel eine Forschungsarbeit über das HTTP-Verhalten von neun gängigen Coding-Agenten. Die Daten sind sehr anschaulich: Wenn Menschen Dokumentationen lesen, öffnen sie die Startseite, navigieren zu einem Bereich, überfliegen einige Überschriften, lesen einige Absätze, testen die Codebeispiele, klicken auf zwei oder drei Links und verbringen 4 bis 8 Minuten damit. Während des gesamten Prozesses wirken deine sorgfältig gestaltete schrittweise Führung, die Seitenleisten-Navigation und die interaktiven Tutorials.

Agenten verhalten sich völlig anders: Sie senden eine GET-Anfrage, rufen den gesamten Inhalt ab und entscheiden innerhalb von 400 Millisekunden, ob sie ihn verwenden oder nicht. Die „User Journey“ des Menschen wird für Agenten zu einer einzigen HTTP-Anfrage komprimiert.

Das Dokumentationsnavigationssystem, die Brotkrumen-Pfade und die schrittweise Darstellung, an denen du monatelang gearbeitet hast, sind für Agenten nur Rauschen – sie sind nutzlos und verschwenden sogar Tokens.

Es gibt drei entscheidende Unterschiede: Wenn du sie verstehst, verstehst du auch die zugrundeliegende Logik von AEO.

Die „Geduld“ von Agenten kann exakt quantifiziert werden.

Osmani nennt eine konkrete Zahl: Die ersten 500 Tokens deiner Seite müssen drei Fragen beantworten: Was ist das? Was kann es tun? Wie fange ich an? Wenn die Antwort in der Mitte oder am Ende der Seite verborgen ist, gibt der Agent wahrscheinlich auf, bevor er sie erreicht. Menschen können langwierige Einleitungen tolerieren, Agenten nicht.

Agenten haben eine strenge Obergrenze für ihre „Aufnahmekapazität“.

Osmani nennt ein echtes Beispiel: Der Schnellstartleitfaden für die REST-API des Cisco Security Firewall Management Center hat 193.217 Tokens, fast 720.000 Zeichen. Diese einzelne Dokumentation kann das gesamte Kontextfenster der meisten Agenten belegen oder sogar überlasten. Bei solchen Dokumenten reagieren Agenten entweder mit Abschneiden (wichtige Informationen gehen verloren), Überspringen (die Dokumentation wird ignoriert) oder Rückgriff auf ihre eigenen Erinnerungen (sie erfinden eine Antwort). In jedem Fall ist das Ergebnis für den Nutzer falsch.

Welche Größenordnung hat ein angemessenes Token-Budget? Osmani empfiehlt, dass der Schnellstartleitfaden weniger als 15.000 Tokens umfasst, die einzelne API-Referenzseite weniger als 25.000 Tokens und der konzeptionelle Leitfaden weniger als 20.000 Tokens. Wenn diese Grenzen überschritten werden, ist eine klare Aufteilungsstrategie erforderlich.

Agenten ignorieren dein UI-Design vollständig.

Seitenleisten, Brotkrumen-Navigation, Footer-Links, interaktive Code-Sandboxes – all diese Elemente im gerenderten HTML sind für Agenten reines Rauschen. Noch wichtiger: Bei demselben Inhalt verbraucht das HTML-Format viel mehr Tokens als das Markdown-Format, da div-Tags, CSS-Klassennamen, ARIA-Attribute und Inline-Stile alle mitgezählt werden.

Agenten lesen Text, keine Benutzeroberfläche.

Wenn du diese drei Punkte verstanden hast, taucht eine beunruhigende Schlussfolgerung auf: Deine Produktdokumentation wird wahrscheinlich stillschweigend von Agenten zum „Tode verurteilt“, und dein Analytics-Backend teilt dir nur mit, dass es heute wieder mehrere Besucher von geringer Qualität mit einer Absprungrate von 100% gibt.

Eindeutige Merkmale verschiedener KI-Agenten, die auf Servern hinterlassen werden | Bildquelle: addyosmani.com

02

Wie kann man Agenten „für sich gewinnen“?

Da Agenten Tools auf eine ganz andere Weise auswählen als Menschen, wie kann man sicherstellen, dass das Produkt von Agenten bevorzugt ausgewählt wird?

Osmani hat ein sechsschichtiges Framework vorgeschlagen. Wenn du Erfahrung mit SEO hast, wirst du feststellen, dass dieses Framework strukturell erstaunlich ähnlich ist – nur dass das Optimierungsobjekt vom Google-Crawler zum KI-Agenten gewechselt hat.

Erste Schicht: Überprüfe robots.txt.

Das ist die erste Station, wenn ein Agent deine Website besucht. Viele Unternehmen haben 2024 und 2025 aus Angst vor KI-Crawlern ihre robots.txt geändert, um die User-Agents von KI-Unternehmen wie Anthropic, OpenAI und Google zu blockieren. Die damalige Logik bestand darin, zu verhindern, dass Inhalte für das Training verwendet werden.

Aber der Nebeneffekt davon ist: Deine Dokumentation verschwindet vollständig aus der Welt der Agenten. Bevor ein Agent Seiten abruft, überprüft er robots.txt. Wenn er feststellt, dass er blockiert ist, überspringt er den Vorgang direkt, gibt keinen Fehler aus, sendet keine Benachrichtigung und hinterlässt keine Spuren in Protokollen. Dein Team weiß nicht einmal, dass dies passiert ist.

Die gute Nachricht ist, dass dies mit einer zehnminütigen Prüfung behoben werden kann. Überprüfe, ob deine robots.txt die User-Agents von KI-Agenten versehentlich blockiert – das ist wahrscheinlich die AEO-Maßnahme mit dem höchsten Return on Investment.

Eine strukturierte llms.txt-Datei sieht so aus | Bildquelle: addyosmani.com

Zweite Schicht: Veröffentliche eine llms.txt, die Sitemap für Agenten.

In der SEO-Ära benötigst du eine sitemap.xml, um dem Google-Crawler die Struktur deiner Website mitzuteilen. In der AEO-Ära heißt das entsprechende Dokument llms.txt.

Das ist eine Datei im Markdown-Format im Stammverzeichnis deiner Domain, die alle Seiten deiner Dokumentation auflistet, beschreibt, worum es auf jeder Seite geht und wie viele Tokens sie ungefähr hat. Wenn der Agent diese Datei liest, kann er genau die Seite lokalisieren, die er benötigt, anstatt deine gesamte Website blind zu durchsuchen.

Eine gute llms.txt sollte mehrere Bedingungen erfüllen: Die Beschreibung soll dem Agenten sagen, was er auf jeder Seite „finden kann“, nicht nur wie die Seite heißt. Die Anzahl der Tokens soll angegeben werden, damit der Agent im Voraus beurteilen kann, ob sein Kontextfenster diese Seite aufnehmen kann. Die Inhalte sollen nach Aufgaben organisiert werden, nicht nach Produkt hierarchien. Die Länge von llms.txt selbst soll unter 5.000 Tokens liegen – eine Indexdatei darf nicht länger sein als der eigentliche Inhalt.

Das Lighthouse-Team von Google Chrome prüft bereits experimentell, ob llms.txt vorhanden ist. Das zeigt, dass dieser Standard von einem „Experiment in der Geek-Community“ zu einer „Standardkonfiguration in der Ingenieurspraxis“ wird.

Dritte Schicht: Schreibe eine skill.md, das „Bewerbungsschreiben“ deines Produkts für Agenten.

llms.txt sagt dem Agenten, wo deine Dokumentation liegt. skill.md sagt dem Agenten, was dein Produkt kann.

Der Unterschied zwischen diesen beiden Dingen ist sehr wichtig: llms.txt ist ein Inhaltsverzeichnis, aus dem der Agent weiß, wo er Informationen finden kann. skill.md ist eine Fähigkeitserklärung: Nachdem der Agent sie gelesen hat, kann er direkt beurteilen, „ob diese API die Anforderungen des Nutzers erfüllen kann“, ohne Tokens für das Lesen der gesamten Dokumentation zu verschwenden, um am Ende festzustellen, dass die Antwort „nein“ lautet.

Eine typische skill.md-Struktur umfasst mehrere Teile: Unter „Was kann es tun“ werden die Kernfähigkeiten des Produkts aufgelistet, unter „Welche Eingaben werden benötigt“ die erforderlichen Parameter und Anmeldeinformationen, unter „Welche Einschränkungen gibt es“ Beschränkungen wie Ratenbegrenzungen und Ablaufzeiten von Tokens, unter „Wichtige Dokumente“ die relevantesten Links.

Eine gute skill.md ermöglicht es dem Agenten, innerhalb weniger Sekunden zu beurteilen, ob dieses Werkzeug für die aktuelle Aufgabe geeignet ist, und spart so eine Menge unnötiger Dokumentenlesevorgänge. Für Agenten hat diese Datei denselben Wert wie eine präzise 30-Sekunden-Selbstvorstellung in einem Vorstellungsgespräch, anstatt den Personalvermittler den gesamten Lebenslauf durchsuchen zu lassen.

Vierte Schicht: Sorge dafür, dass die Markdown-Version der Dokumentation direkt zugänglich ist.

Viele Dokumentationsplattformen unterstützen das Abrufen der reinen Markdown-Version einer Seite, indem man die Erweiterung .md an die URL anhängt. Wenn deine Plattform dies unterstützt, stelle sicher, dass diese Funktion aktiviert und auffindbar ist.

Der Grund ist einfach: Bei demselben Inhalt verbraucht die HTML-Version viel mehr Tokens als die Markdown-Version, da sie Wrapper-Divs, CSS-Klassennamen, ARIA-Attribute, Inline-Stile und Navigationselemente enthält. Für Agenten ist HTML wie ein Gericht, das in drei Lagen Frischhaltefolie eingepackt ist: Sie wollen nur das Essen essen, müssen aber viel Aufwand betreiben, um die Verpackung zu entfernen. Markdown ist der reine Inhalt ohne jegliche Verpackung.

Darüber hinaus gibt es ein leicht zu übersehendes Problem: Wenn deine Dokumentation die Ausführung von JavaScript erfordert, um Inhalte zu laden (z. B. eine Dokumentationsseite, die von einer Single-Page-App gerendert wird), erhält der Agent höchstwahrscheinlich eine leere Seite. Viele Agenten verwenden leichtgewichtige HTTP-Clients, die kein JS ausführen. Dein Inhalt ist technisch gesehen „vorhanden“, aber in der Welt der Agenten ist er gleichbedeutend mit „nicht vorhanden“.

Fünfte Schicht: Mache die Anzahl der Tokens als Metadaten sichtbar.

Diese Schicht ist am einfachsten zu implementieren, hat aber eine sehr hohe Hebelwirkung. Gib die Anzahl der Tokens der Seite in den Meta-Tags oder im HTTP-Antwortheader an.

Das gibt dem Agenten eine Grundlage zur Vorbeurteilung: Eine Seite mit 8.000 Tokens kann der Agent bedenkenlos vollständig laden. Bei einer Seite mit 150.000 Tokens weiß der Agent, dass er nur die relevanten Abschnitte extrahieren muss. Bei Seiten, die das Kontextfenster übersteigen, kann der Agent direkt die Zusammenfassung aus llms.txt verwenden.

Die Implementierung ist auch sehr direkt: Zähle die Anzahl der Zeichen auf dem Server, teile sie durch 4, um einen groben Schätzwert für die Anzahl der Tokens zu erhalten, und gib diesen dann als Meta-Tag aus.

Sechste Schicht: Füge einen „Copy for AI“-Button hinzu.

Das ist eine sehr kleine UX-Funktion, aber sie löst ein echtes Problem.

Wenn Entwickler in ihrer IDE mit KI-Assistenten zusammenarbeiten, müssen sie oft Dokumentationsinhalte als Kontext einfügen. Die meisten Menschen kopieren Inhalte direkt von der gerenderten Webseite, aber der kopierte Inhalt enthält viele störende Tex