Es begann mit einem KI-Agent, der einfach nicht aufhören wollte zu raten. Ich hatte ihn eingerichtet, einen Service in einer kleinen Multi-Service-Demo zu integrieren, und er erfand Endpunkte. Er erfand sie konsistent, höflich und mit voller Überzeugung. Wenn ich auf einen 404 hinwies, erfand er den Endpunkt um eine Ebene neu. Wenn ich ihm die OpenAPI-Spec in den Kontext klebte, ignorierte er sie still und ging zu seinen Lieblings-Mustern aus dem Training zurück. Wenn ich ihn zwang, die Spec zu lesen, las er sie, behielt sie für 200 Tokens, und glitt dann zurück.
Das ist kein Modellfehler im Sinne von Bug. Das ist die natürliche Konsequenz davon, dass Maschinen heute APIs durch Reverse-Engineering von Mustern entdecken, die andere Maschinen in Texten hinterlassen haben. Es gibt keine kanonische Quelle, die ein Agent live abfragen könnte und der er bedingungslos vertrauen darf. Was es gibt, ist Trainingsdaten, Doku-Sites, und in seltenen Fällen eine OpenAPI-Spec, deren Lokation und Aktualität ein eigenes Rätsel sind.
Das Problem ist nicht der Agent. Der Agent ist ehrlich. Er macht das, was Modelle tun: er produziert die wahrscheinlichste Fortsetzung gegeben dem Kontext. Wenn der Kontext keine glaubwürdige Quelle für API-Form enthält, gewinnen die Trainings-Priors. Was fehlt, ist ein Discovery-Mechanismus, der maschinen-native ist, nicht menschen-vermittelt durch HTML-Doku, Stack-Overflow-Antworten und Postman-Collections.
Wir hatten das schon einmal. DNS löste den Identifier-zu-IP-Punkt, weil sonst jede Maschine raten musste. robots.txt löste den Crawler-Politeness-Punkt, weil sonst jeder Crawler raten musste. Sitemaps lösten Discovery für Suchmaschinen, weil sonst jede Engine raten musste. well-known löste OAuth, OpenID, ACME und ein Dutzend andere Mechanismen, weil sonst jeder Client raten musste, wo der Endpunkt liegt. Wir bauen seit Jahrzehnten Wegweiser für Maschinen. Wir haben es nur nie für API-Verhalten getan.
TEKIR ist im Kern einfach. Es ist eine Spezifikation für eine kleine, vorhersagbare Datei unter /.well-known/tekir.json auf jedem Service, der sich von Maschinen entdecken lassen will. Die Datei sagt: hier sind meine APIs. Hier ist mein OpenAPI-Schema. Hier ist mein MCP-Endpunkt, falls vorhanden. Hier sind meine GraphQL-, gRPC- und WebSocket-Surfaces. Hier sind die Authentifizierungsmethoden. Hier sind die Rate-Limits. Hier ist die Kontaktstelle für Bot-Operatoren. Und hier ist eine Versionierungsstring, damit Agenten wissen, wann etwas neu ist.
Es ist eine flache JSON-Datei. Es gibt kein Discovery-Protokoll im engeren Sinne, keinen Service-Mesh-Anschluss, keine binär-codierte Signatur. Es ist genau das gleiche Lebensgefühl wie robots.txt: eine Datei, die jeder Webserver bedienen kann, jeder Client einlesen kann, und die menschenlesbar bleibt.
Was sie maschinen-tauglich macht, ist nicht das Format, sondern die Lokationsgarantie. Ein Agent, der einer URL begegnet, kann einen einzigen GET an /.well-known/tekir.json machen und erfährt entweder das gesamte API-Inventar oder einen sauberen 404. Es gibt keine Suche, keine Heuristik, keine HTML-Parsen. Wenn die Datei da ist, ist sie kanonisch. Wenn nicht, weiß der Agent, dass er auf alte Methoden zurückgreifen muss.
Die Spec lehnt sich absichtlich an robots.txt und sitemap.xml an. Bekannter Pfad. Vorhersagbarer MIME-Typ. Kein Server-seitiger Zustand erforderlich. Wenn Cloudflare es will, können sie es als Edge-Asset cachen. Wenn ein Container-Image es will, kann es eine statische Datei im Public-Verzeichnis sein. Es soll nichts sein, wofür eine Plattform ein neues Tool bauen muss.
Sie überlappt nicht mit robots.txt. robots.txt sagt, was Crawler nicht tun dürfen. tekir.json sagt, was Maschinen-Clients tun können und welche Surfaces sie ansprechen sollen. Die zwei Dateien können nebeneinander leben, mit unterschiedlichen Zielgruppen.
Sie verdrängt nicht OpenAPI, MCP oder die anderen Surface-Specs. Sie ist eine Datei, die auf sie verweist. Wer noch keine OpenAPI-Spec hat, hat auch keinen Grund, jetzt eine zu schreiben. Wer eine hat, fügt einen Verweis in tekir.json hinzu, und Agenten finden sie ohne Raten.
Das Discovery-Verhalten ist drei Schritte. Erstens: Agent kennt eine URL des Service. Zweitens: Agent fragt {origin}/.well-known/tekir.json ab. Drittens: Wenn die Datei da ist, hat der Agent das gesamte Inventar inklusive Zeigern auf detaillierte Specs. Wenn nicht, fällt der Agent auf bestehende Heuristiken zurück.
Das ist es. Es gibt keine vierte Stufe. Keinen rekursiven Crawl, keine Service-Discovery-Verhandlung, keinen DNS-Trick. Es ist eine flache Datei an einem vorhersagbaren Pfad.
Eine ehrliche Sorge: warum brauchen wir noch eine Datei, wenn alle Adoptionswelle bestehender Standards ohnehin lokal eintreten muss? Die Antwort ist, dass die Datei selbst der Adoptionspfad ist. Du musst nichts an deinem Server umschreiben. Du legst eine statische JSON-Datei ab. Statische Datei zu deployen ist die niedrigste Adoptionshürde, die es im Web-Space gibt.
Service-Provider können sie unter /.well-known/tekir.json einer Domain auf den CDN legen. Container-Images können sie ins Image kompilieren. CI-Pipelines können sie aus den vorhandenen OpenAPI-Quellen generieren. Es gibt keinen Software-Stack, der dafür installiert werden muss, keine Bibliothek, die importiert werden muss.
TEKIR ist auf Türkisch der Name für eine getigerte Hauskatze. Es ist auch ein Wort, das in Anatolien für eine ruhige, geduldige Hauskatze steht. Das ist die richtige Stimmung für ein Discovery-Protokoll. Es jagt nicht. Es sitzt da, ist beschriftet, und Maschinen, die wissen wollen, was es kann, können es einfach lesen.
Den Namen habe ich auch deshalb gewählt, weil die meisten Internet-Standards trockene Akronyme sind. Discovery via Well-Known Resource Endpoints für Multi-Modal API Inventories ist nicht etwas, das jemand zweimal sagt. tekir sagt jeder Türke jeden Tag. Wenn das Protokoll überlebt, soll es einen Namen haben, den Menschen ohne Zähneknirschen aussprechen.
Der Agent, mit dem alles begann, hat aufgehört, Endpunkte zu erfinden, in dem Moment, in dem ich ihm einen tekir.json-Reader-Tool gegeben habe und einen Service mit der Datei am richtigen Ort gestellt habe. Er hat einmal gefragt, gelesen, und die nächsten 200 Aufrufe waren korrekt. Das ist die kleine Demo-Skala, aber das Verhältnis von "Agent rät" zu "Agent ruft korrekt auf" hat sich von einem peinlichen Wert auf nahezu null verschoben, sobald die Discovery deterministisch wurde.
Das war für mich der Beweis, dass das Problem auf der Discovery-Seite lag, nicht auf der Modell-Seite. Modelle, denen ein wahrer kanonischer Pfad gegeben wird, halten sich daran. Modelle, die raten müssen, raten weiter. Das ist eine Aussage über das Werkzeug, nicht über das Modell.