Agentic Resource Discovery: Ressourcensuche, ai-catalog.json und Vertrauen für Phone Agents
Agentic Resource Discovery erklärt: wie Kataloge, Register, Verifikation und native Protokolle zusammenarbeiten und warum Entdeckung keine Autorisierung auf dem Smartphone ist.
- Agentic Resource Discovery ist eine offene Spezifikation, mit der Tools, Skills und Agenten über veröffentlichte Kataloge gefunden und verifiziert werden können.
- Eine ai-catalog.json kann Fähigkeiten, Herausgeberdaten, Protokollhinweise und Verweise auf weitere Kataloge beschreiben, ersetzt aber nicht MCP, A2A, OpenAPI oder App-Verträge.
- Verifikation stärkt das Vertrauen in Herausgeber und Metadaten, beweist aber nicht automatisch, dass eine Fähigkeit für einen konkreten Nutzer, ein Gerät oder eine Aktion autorisiert ist.
- Für Phone Agents muss nach der Entdeckung eine zweite Prüfung folgen: Tool-Aktivierung, Android-Berechtigungen, Zielprüfung, Freigabe, sichtbares Ergebnis, Protokoll und Widerruf.
Inhaltsverzeichnis
- Was Agentic Resource Discovery löst
- Wie Kataloge und Register Fähigkeiten auffindbar machen
- Was Herausgeberprüfung beweist und was nicht
- Wie ARD an MCP, A2A, OpenAPI und App-Verträge übergibt
- Warum Entdeckung auf dem Smartphone keine Autorisierung ist
- Prüfliste vor Verbindung und Ausführung
- Wie FoneClaw Katalogsichtbarkeit von Telefonbefugnis trennt
- Was Teams vor einem Agenten-Register testen sollten
Was Agentic Resource Discovery löst
Agentic Resource Discovery, kurz ARD, beantwortet eine praktische Frage: Wie findet ein KI-Agent verlässliche Tools, Skills oder andere Agenten, ohne dass jede Integration vorher fest in ein einzelnes Produkt eingebaut werden muss? Laut der Ankündigung der Agentic-Resource-Discovery-Spezifikation vom 17. Juni 2026 ist ARD eine offene Spezifikation zum Veröffentlichen, Entdecken und Prüfen agentischer Ressourcen im Web.
Der Kern ist ein veröffentlichter Werkzeugkatalog, häufig als ai-catalog.json beschrieben. Eine Organisation kann unter ihrer eigenen Domain angeben, welche Fähigkeiten sie für Agenten bereitstellt, welche Schnittstelle dahinterliegt, wer der Herausgeber ist und wie weitere Kataloge erreichbar sind. Damit wird Ressourcensuche für KI-Agenten weniger abhängig von privaten, geschlossenen Listen.
Wichtig ist die Grenze: ARD sagt einem Agenten, dass eine Fähigkeit existiert und wie sie beschrieben ist. ARD führt die Fähigkeit nicht selbst aus und gibt dem Agenten keine Telefonrechte. Für einen Phone Agent ist das entscheidend, weil ein entdeckter Kalender-, Karten- oder Nachrichten-Endpoint noch lange nicht bedeutet, dass der Nutzer genau diese Aktion auf diesem Android-Gerät erlaubt hat.
Wie Kataloge und Register Fähigkeiten auffindbar machen
Ein Katalog ist die veröffentlichte Selbstbeschreibung eines Anbieters. Er kann Tools, Skills, Agenten, MCP-Server, A2A-Agenten, OpenAPI-Tools oder verschachtelte Kataloge aufführen. Das macht ai-catalog.json zu einem Werkzeugkatalog, nicht zu einem Ausführungsserver. Der Katalog beschreibt, was angeboten wird; die eigentliche Verbindung läuft später über die angegebene native Schnittstelle.
Ein Register ist eine Such- und Indexschicht. Nach der ARD-Beschreibung können Register Kataloge crawlen, indexieren und auf Absichtsanfragen passende Fähigkeiten zurückgeben. Ein Client kann also sagen: „Finde eine verifizierbare Ressource für Versandstatus“ oder einen bekannten Partnerkatalog direkt von dessen Domain abrufen. Beides sind unterschiedliche Wege zur gleichen Frage: Welche Fähigkeit ist auffindbar und wie wird sie geprüft?
| Phase | Eingabe | Ausgabe |
|---|---|---|
| Veröffentlichen | Anbieter stellt einen Katalog bereit | Beschriebene Fähigkeiten, Herausgeberdaten, Protokollhinweise |
| Suchen | Absicht oder bekannte Domain | Passende Katalogeinträge oder direkter Katalogabruf |
| Prüfen | Metadaten, Signale zur Herausgeberidentität | Mehr Vertrauen in Ursprung und Integrität |
| Verbinden | Ausgewählte Fähigkeit und native Schnittstelle | MCP-, A2A-, OpenAPI- oder App-spezifische Verbindung |
Die öffentliche ARD-Spezifikation und das Repository zeigen, dass Schema, Vertrauensarchitektur und Referenzarbeit offen weiterentwickelt werden. Für Teams ist das nützlich, weil sie nicht nur eine einzelne Demo bewerten, sondern die Katalogstruktur, Metadaten und Prüfpfade nachvollziehen können.
Was Herausgeberprüfung beweist und was nicht
Ein vertrauenswürdiger Agenten-Werkzeugkatalog beginnt nicht mit einer schönen Beschreibung, sondern mit der Frage: Kommt dieser Katalog wirklich vom behaupteten Herausgeber? ARD kann in produktiven Entdeckungspfaden verifizierbare Herausgebermetadaten einbeziehen, bevor ein Agent eine direkte Verbindung über das native Protokoll aufbaut. Das verbessert die Ausgangslage erheblich, weil ein Agent nicht blind auf eine beliebige URL reagieren muss.
Verifikation löst aber nur einen Teil des Problems. Sie kann helfen, Domainkontrolle, Herausgeberidentität oder Katalogintegrität zu prüfen. Sie beweist nicht, dass jede beschriebene Fähigkeit für jeden Nutzer sinnvoll, risikofrei, aktuell oder autorisiert ist. Ein korrekt signierter Katalog kann trotzdem eine Aktion beschreiben, die in einem konkreten Unternehmen nicht erlaubt ist oder auf einem Telefon eine zusätzliche Freigabe braucht.
Für Phone Agents bleibt deshalb eine zweite Beurteilung nötig. Ist der Endpoint erreichbar? Passt das Protokoll zur Laufzeit? Welche Daten würden übertragen? Welche App oder welches Konto wäre betroffen? Welche Android-Berechtigung ist erforderlich? Eine gute Herausgeberprüfung ist der Startpunkt für Vertrauen, nicht das Ende der Entscheidung.
In der Praxis sollten Teams die Prüfergebnisse getrennt speichern. Ein Nachweis über die Herausgeberidentität beantwortet, wer veröffentlicht hat. Ein Integritätsnachweis beantwortet, ob die geprüften Metadaten unverändert vorliegen. Die fachliche Freigabe bewertet dagegen, ob Name, Beschreibung, Datenumfang und behauptete Wirkung zur eigenen Richtlinie passen. Diese Aussagen haben unterschiedliche Lebensdauern: Eine Identität kann weiter gültig sein, obwohl ein Katalogeintrag inzwischen veraltet oder ein Endpoint ausgetauscht wurde. Deshalb braucht jede Verbindung einen nachvollziehbaren Bezug auf Katalogversion, Prüfzeitpunkt und ausgewählten Eintrag.
Wie ARD an MCP, A2A, OpenAPI und App-Verträge übergibt
ARD ersetzt MCP, A2A oder OpenAPI nicht. Die Spezifikation hilft beim Finden und Prüfen; danach muss der Agent über die beworbene native Schnittstelle arbeiten. Ein Katalogeintrag kann zum Beispiel auf einen MCP-Server zeigen, einen A2A-Agenten beschreiben, ein OpenAPI-Tool nennen oder auf einen weiteren Katalog verweisen. Aus Sicht der Laufzeit ist das eine Übergabe, keine Vereinheitlichung aller Protokolle.
Gerade mobil ist diese Trennung mehr als Architekturkosmetik. Ein Android-Agent braucht nach der Entdeckung einen ausführbaren Vertrag: Welche Eingaben sind erlaubt? Welche App oder welcher Dienst ist Ziel? Welche Antwort gilt als Erfolg? Was passiert, wenn der Nutzer die Berechtigung verweigert oder die App nicht installiert ist? Wer tiefer in solche maschinenaufrufbaren App-Verträge einsteigen möchte, findet den nächsten Schritt in App Intents und maschinenaufrufbare Apps für KI-Agenten.
Vor dem ersten Aufruf reicht es nicht, nur den Protokollnamen abzugleichen. Die Runtime sollte auch die konkrete Version, Authentifizierungsmethode, Eingabe- und Ausgabeschemata, Zeitlimits, Fehlercodes und Abbruchmöglichkeit prüfen. Bei OpenAPI zählt etwa, ob die benötigte Operation tatsächlich beschrieben ist; bei MCP oder A2A müssen angebotene Fähigkeiten und erwartete Nachrichtenform zusammenpassen. Ein syntaktisch erreichbarer Endpoint kann fachlich inkompatibel sein, wenn Pflichtfelder fehlen, Datentypen abweichen oder eine Antwort keinen belastbaren Erfolgszustand liefert.
Für mobile Abläufe kommt der Gerätevertrag hinzu. Die entfernte Schnittstelle kann eine Terminaktion anbieten, während die lokale Android-Umgebung nur das Öffnen einer Kalenderansicht unterstützt. Dann darf die Planung nicht aus einem erfolgreichen Netzwerkaufruf auf einen erfolgreichen Telefoneffekt schließen. Ein sauberer Ablauf prüft erst den entfernten Vertrag, dann die lokal unterstützte Aktion und ordnet beide über eindeutige Parameter, Zielkonto und erwartetes sichtbares Ergebnis ein.
So bleibt ARD schlank. Es beschreibt, wie ein Agent eine Fähigkeit findet und mit mehr Vertrauen auswählt. Ob diese Fähigkeit korrekt aufgerufen, vom Nutzer erlaubt, auf dem Gerät unterstützt und sichtbar abgeschlossen wird, entscheidet die jeweilige Protokoll- und Laufzeitumgebung.
Warum Entdeckung auf dem Smartphone keine Autorisierung ist
Auf einem Telefon liegen Entdeckung und Autorisierung besonders weit auseinander. Ein ai-catalog.json Werkzeugkatalog kann sagen, dass ein Dienst eine Nachrichten-, Kalender- oder Kartenfähigkeit anbietet. Das Android-Gerät muss trotzdem prüfen, ob die App verfügbar ist, welche Berechtigung benötigt wird, welches Konto betroffen ist und ob die konkrete Aktion eine Nutzerfreigabe verlangt.
Android behandelt Berechtigungen kontextbezogen. Die Android-Anleitung zu Laufzeitberechtigungen beschreibt, dass Apps Berechtigungen dann anfragen sollen, wenn eine Funktion sie benötigt, und dass der Umgang mit verweigerten Berechtigungen Aufgabe der App bleibt. Eine ARD-Verifikation prüft keinen Android-Berechtigungsdialog. Umgekehrt beweist eine Android-Berechtigung nicht, dass eine entfernte Ressource vertrauenswürdig oder eine geschäftliche Folge erlaubt ist.
| Kontrolle | Was sie klärt | Was offen bleibt |
|---|---|---|
| Herausgeberidentität | Wer den Katalog veröffentlicht | Ob die Aktion für diesen Nutzer erlaubt ist |
| Metadatenintegrität | Ob der Katalog unverändert wirkt | Ob die Fähigkeit korrekt implementiert ist |
| Endpoint-Kompatibilität | Ob die Laufzeit sprechen kann | Ob ein Telefonziel unterstützt ist |
| Tool-Aktivierung | Ob die Fähigkeit lokal nutzbar ist | Ob Android die nötige Berechtigung hat |
| Android-Berechtigung | Ob eine Gerätefunktion zugänglich ist | Ob Senden, Teilen, Löschen oder Kaufen freigegeben ist |
| Aktionsfreigabe | Ob der Nutzer die konkrete Folge akzeptiert | Ob spätere Nutzung weiter erlaubt bleibt |
| Widerruf | Wie Zugriff beendet wird | Ob alte Ergebnisse noch extern bestehen |
Die lokale Autorisierung sollte außerdem an Aufgabe und Ziel gebunden sein. Die Erlaubnis, einen Kalender zu lesen, umfasst nicht automatisch das Erstellen eines Termins; die Freigabe für einen privaten Kalender gilt nicht zwingend für ein Arbeitskonto. Ebenso kann ein Tool aktiviert sein, während eine einzelne Aktion wegen Empfänger, Datenart oder Außenwirkung eine zusätzliche Bestätigung braucht. Die Runtime muss daher nicht nur fragen, welches Tool aufgerufen wird, sondern auch mit welchen Parametern, für welches Konto und mit welcher erwarteten Folge.
Für die Sicherheit von Skills und Berechtigungen zählt deshalb die Laufzeitprüfung. Die vertiefende Perspektive steht in Sicherheit von KI-Agent-Skills: Warum Phone Agents Laufzeitprüfungen brauchen. Wer zusätzlich Identität, Rollen und Aktivitätsnachweise einordnen will, findet den größeren Governance-Rahmen in KI-Agent-Identität, Berechtigungen und Audit-Trails: Der Sicherheitsstack fürs Telefon.
Prüfliste vor Verbindung und Ausführung
Eine brauchbare ARD-Nutzung auf dem Smartphone beginnt nicht mit „gefunden, also ausführen“. Sie beginnt mit einer kurzen, wiederholbaren Prüffolge. Die Liste muss vor der Verbindung andere Fragen stellen als vor der Ausführung, weil beide Phasen unterschiedliche Risiken tragen.
- Herausgeber prüfen: Stimmt die Domain, und sind die verifizierbaren Metadaten plausibel?
- Katalogfrische prüfen: Ist der Eintrag aktuell genug, oder zeigt er auf veraltete Endpoints?
- Schnittstelle validieren: Passt MCP, A2A, OpenAPI oder der App-Vertrag zur eigenen Laufzeit?
- Scope lesen: Welche Daten, Konten oder Gerätebereiche wären betroffen?
- Lokal aktivieren: Ist das Tool bewusst freigeschaltet, oder bleibt es nur sichtbar?
- Android-Berechtigung anfragen: Wird die Berechtigung im passenden Nutzungskontext erklärt?
- Ziel bestätigen: Geht die Aktion an den richtigen Kontakt, Kalender, Ort, Dienst oder Account?
- Risikoabhängig freigeben: Lesen, Öffnen und Anzeigen sind anders zu behandeln als Senden, Teilen, Löschen oder Kaufen.
- Ergebnis anzeigen: Der Nutzer braucht einen sichtbaren Abschluss oder eine klare Fehlermeldung.
- Widerruf und Stopp testen: Zugriff, Tool-Aktivierung und laufende Aufgabe müssen beendet werden können.
Die Reihenfolge sollte als zwei Prüfpunkte umgesetzt werden. Vor der Verbindung zählen Herausgeber, Katalogfrische, Protokoll und angeforderte Scopes. Unmittelbar vor der Ausführung werden dagegen der aktuelle App-Zustand, das konkrete Ziel, die Parameter, vorhandene Android-Berechtigungen und die Freigaberegel erneut bewertet. Zwischen beiden Zeitpunkten kann sich etwas ändern: Der Nutzer wechselt das Konto, eine Berechtigung wird entzogen oder die Ziel-App öffnet einen anderen Datensatz. Eine frühere Prüfung darf diese aktuelle Zustandskontrolle nicht ersetzen.
Auch der Fehlerpfad gehört zur Abnahme. Teams sollten testen, ob eine abgelaufene Authentifizierung zu einer verständlichen erneuten Anmeldung führt, ob ein Schemafehler ohne Teilwirkung endet und ob ein abgebrochener Vorgang eindeutig als unvollständig erscheint. Aktivitätsdaten sollten erkennen lassen, welcher Katalogeintrag, welcher Endpoint, welches Tool und welche Freigaberegel beteiligt waren. Beim Widerruf ist zu prüfen, ob neue Aufrufe wirklich blockiert werden und wie bereits extern erzeugte Ergebnisse behandelt werden.
Der erste Test sollte niedriges Risiko haben: einen Status lesen, eine App öffnen, eine nicht sensible Information strukturieren. Erst wenn Verbindung, Fehlerbild und Berechtigungsführung stabil sind, lohnt sich eine Aktion mit Außenwirkung. Ein stiller Wechsel auf einen anderen Endpoint ist dabei kein guter Rückfall; der Nutzer muss erkennen, welches Tool gerade verwendet wird.
Wie FoneClaw Katalogsichtbarkeit von Telefonbefugnis trennt
Bei FoneClaw ist die praktische Lehre aus ARD klar: Sichtbarkeit im Katalog ist nicht dasselbe wie Befugnis auf dem Telefon. FoneClaw ist ein Android-Phone-Agent-Runtime. Ein kompatibel konfiguriertes Modell übernimmt Verstehen, Schlussfolgern und Planen innerhalb des Agentenablaufs; FoneClaw ruft unterstützte, kontrollierte Android-Tools auf und führt die passenden Telefonaktionen aus.
Die aktuelle FoneClaw-Produktlinie trennt Built-in-Tools, Tool-Management und Plugin-Pfade bewusst. Die FoneClaw-Release-Daten zu Version 0.1.0 nennen per-Tool-Verwaltung, sicherere Verträge, Berechtigungswiederherstellung und vertrauenswürdige Plugin-Fortsetzung. Der öffentliche FoneClaw-Toolkatalog ist ein datierter Snapshot mit 100+ Built-in-Tools, Risikohinweisen und Freigabelogik; er ist kein ARD-Register und keine automatische Drittanbieterautorisierung.
Das Modell kann also einen Plan vorschlagen: Bildschirm lesen, App öffnen, Nachricht vorbereiten, Standort prüfen oder einen Workflow starten. FoneClaw entscheidet anhand der unterstützten Tools, lokalen Aktivierung, Berechtigungen, Tool-Richtlinien und sichtbaren Zustände, wie daraus eine Android-Aktion wird. Plugin-Installation beginnt mit einem sichtbaren Vorschlag und einem kontrollierten Pfad; sie ist keine stille Entdeckung im Hintergrund.
Für Leser, die das gesamte Modell von Wahrnehmung, Entscheidung, Ausführung und Bestätigung auf Android nachvollziehen möchten, ist Telefonsteuerung mit KI-Agent: Wie Android Phone Agents wirklich arbeiten die passende Vertiefung. Hier bleibt der Fokus enger: Ein gefundener oder katalogisierter Werkzeughinweis muss erst durch die Telefonruntime, bevor er Handlungsmacht bekommt.
Was Teams vor einem Agenten-Register testen sollten
Wer ein Agenten-Register einführt, sollte nicht nur messen, ob die Suche Treffer liefert. Entscheidend ist, ob richtige Treffer, falsche Treffer und alte Kataloge unterscheidbar werden. Ein gutes Testset enthält normale Suchanfragen, mehrdeutige Absichten, absichtlich veraltete Einträge, fehlgeschlagene Verifikation und Endpoints, die zwar gefunden, aber lokal gesperrt sind.
Für Phone-Agent-Teams kommen Gerätefälle hinzu. Wird eine Berechtigung erst im passenden Kontext angefragt? Wird ein gefährliches Tool trotz Katalogtreffer durch Richtlinie blockiert? Ist sichtbar, warum eine Aktion nicht ausgeführt wurde? Kann ein Nutzer Tool-Aktivierung, Plugin-Zugriff oder eine laufende Aufgabe beenden? Discovery-Qualität und Autorität müssen getrennt beobachtbar sein, sonst sieht ein Erfolg im Register wie ein Erfolg auf dem Gerät aus.
Der beste Einstieg ist ein kleiner Integrationskorridor: wenige geprüfte Herausgeber, klare Protokolle, niedriges Aktionsrisiko, explizite Tool-Aktivierung und ein dokumentierter Widerrufspfad. Erst wenn diese Kontrollen im Alltag funktionieren, sollte ein Team breitere Ressourcensuche für KI-Agenten zulassen. ARD kann die Suche ordnen; die Verantwortung für sichere Telefonaktionen bleibt bei Runtime, Richtlinie und Nutzerentscheidung.