ADI
ADI Blog A2A-Grundlagen 2 Min. Lesezeit

Was A2A ist und was es nicht ist

A2A gibt Agenten eine gemeinsame Sprache für Discovery, Nachrichten und Tasks. Es löst aber nicht automatisch Identitätsbindung, delegierte Autorität, Auditierbarkeit oder Payment-Kontrolle.

A2A ist ein Kommunikations- und Discovery-Protokoll, kein vollständiges Trust- oder Payment-System.

Eine AgentCard sagt anderen, wie man mit einem Agenten spricht; sie beweist nicht automatisch, ob dieser Agent handeln darf.

Sobald ein Agent Enterprise-Daten, Geld oder delegierte Autorität berührt, braucht man Schichten oberhalb von A2A.

Das richtige mentale Modell

A2A sollte ähnlich verstanden werden wie HTTP oder gRPC: Es definiert, wie Systeme kommunizieren, nicht ob eine bestimmte Handlung legitim ist.

Diese Unterscheidung ist zentral, weil viele Teams eine Discovery-Datei und einen funktionierenden Protokollaustausch sehen und daraus schließen, das Governance-Problem sei gelöst. Das ist nicht der Fall. A2A macht einen Agenten erreichbar und verstehbar, aber Erreichbarkeit ist nicht dasselbe wie Verantwortlichkeit.

Was A2A tatsächlich standardisiert

Wie ein Agent eine AgentCard publiziert und gefunden wird.

Wie Tasks, Nachrichten und Protokollmethoden strukturiert sind.

Wie Fähigkeiten und deklarierte Sicherheitsanforderungen angekündigt werden.

Wie Multi-Agenten-Systeme eine gemeinsame Sprache statt punktueller Sonderintegration bekommen.

Wo A2A sitzt

A2A liefert die gemeinsame Transport- und Interaktionsschicht. Es ist nur eine Schicht im Gesamtstack.

flowchart TD
    user["Nutzer oder Organisation"] --> app["Business-Anwendung"]
    app --> a2a["A2A-Kommunikationsschicht"]
    a2a --> agent["Externer oder interner Agent"]
    a2a --> trust["Trust- und Governance-Schicht"]
    trust --> audit["Audit- und Policy-Schicht"]
    trust --> payment["Payment- und Mandatsschicht"]

Was A2A nicht löst

A2A entscheidet nicht, ob ein entdeckter Agent tatsächlich an einen Operator, ein Unternehmen oder einen delegierenden Nutzer gebunden ist. Es kann Sicherheitsmerkmale deklarieren, aber nicht die Governance-Entscheidung ersetzen.

A2A löst auch keinen Widerruf, keine Spending-Limits, keine Organisationsfreigabe und keine Aussage darüber, ob eine Zahlungsanfrage durch ein gültiges Mandat gedeckt ist. Diese Fragen leben in angrenzenden Schichten.

Identitätsbindung

Delegierte Autorität

Widerruf von Credentials und Zertifikaten

Policy-Durchsetzung

Transaktionsevidenz

Payment-Mandate und Receipts

Warum dieses Missverständnis immer wieder passiert

Das Missverständnis entsteht oft aus Demo-Erfolgen. Zwei Agenten tauschen Tasks aus, ein Prompt wird beantwortet und alle glauben, die Architektur sei im Wesentlichen fertig. In Produktion kommen die harten Fragen erst danach: Welches Unternehmen besitzt diesen Agenten, wer hat ihn freigegeben, mit welchen Händlern darf er arbeiten und wie stoppt man ihn schnell?

Diese Fragen sind keine Randfälle. Sie sind die normalen Betriebsbedingungen von Enterprise- und Commerce-Agenten.

Wo ADI hineinpasst

ADI ist wertvoll, gerade weil es A2A nicht ersetzen will. Es lässt die Protokollschicht bestehen und ergänzt darüber die Trust-Schicht: Identitätsbindungen, Policy Claims, Delegation, Zertifikatsstatus und Payment-Kontrollpunkte.

So kann ein Team A2A für Interoperabilität nutzen und trotzdem echte Governance um den Agenten herum aufbauen.

WEITERLESEN

Weitere Artikel aus der technischen Wissensschicht.

OFFENE AGENTENVERTRAUENSKETTE Agenten-Interoperabilität

Wie externe Agenten einen ADI-Merchant-Agenten verifizieren

Ein Buyer-Agent muss nicht innerhalb von ADI laufen, um einem ADI-Merchant-Agenten zu vertrauen. Er braucht öffentliche Discovery, eine auflösbare Agentenidentität, signierte Credentials und einen klaren Mandats- und Payment-Pfad.

A2A-Discovery macht den Merchant-Agenten erreichbar.

ADI-Trust-Discovery macht den Merchant-Agenten zurechenbar.

MERCHANT TRUST Agent Commerce

Wie der Merchant-Trust-Katalog funktioniert

Ein Merchant-Agent kann aus dem Shop verkaufen, aber ADI braucht eine unabhängige Referenz dafür, was dieser Agent überhaupt verkaufen darf. Der Merchant-Katalog in ADI ist genau diese Referenz.

Der Shop-Katalog betreibt das Geschäft.

Der ADI-Katalog beweist, was der Händler freigegeben hat.

AP2-VALIDIERUNG Agent Commerce

Wie ADI validiert, was ein Merchant-Agent verkauft

Ein Merchant-Agent kann ein Angebot beschreiben, aber ADI zahlt nicht auf Basis einer Beschreibung. ADI validiert AP2-Mandate, Händlerorganisation, Produkt-SKU, Trust-Katalog, Buyer-Wallet und virtuelle Karten-Policy vor der Autorisierung.

Das Gespräch erzeugt Intent.

AP2 erzeugt strukturierte Mandate.

SHOP-INTEGRATIONEN Systemarchitektur

Warum Shop-Integrationen Trust-Inputs und nicht die Trust-Schicht sind

Shopify, WooCommerce oder ERP-Integrationen liefern wertvolle Commerce-Daten. Sie sind aber nicht die Trust-Schicht selbst. Sie speisen Trust-Entscheidungen mit Bestand, Preisen und Produktzuständen, ersetzen aber weder Delegation noch Governance.

Shop-Systeme liefern Daten.

Die Trust-Schicht bewertet Rechte, Scope und Kontrollfähigkeit.

INTEGRATIONSMODI Agenten-Integration

Drei Wege, einen externen Agenten mit der ADI-Trust-Schicht zu verbinden

Ein externer Agent muss nicht innerhalb von ADI laufen, um von ADI regiert zu werden. Entscheidend ist, wie das Zielsystem diesen Agenten technisch authentisiert und wann es ADI für Trust, Delegation und Zertifikatsstatus befragt.

Standardmodus: API-Key oder Agent-Token plus Online-Trust-Lookup

Enterprise-Modus: OIDC plus Trust-Lookup

TRUST-GRUNDLAGEN Agent Trust

Warum Agenten eine Trust-Schicht brauchen

Ein API-Token sagt nur, ob eine Anfrage authentisiert ist. Eine Trust-Schicht sagt, welcher Agent handelt, für wen er handelt, welche Nachweise gültig sind und ob dieser Agent gestoppt werden kann.

Wann OAuth nicht mehr ausreicht

Welche Fragen eine Trust-Schicht beantworten muss

ARCHITEKTUR Systemarchitektur

A2A, Trust und AP2 sauber trennen

Das zentrale Architekturprinzip ist die Trennung der Schichten. A2A ist Kommunikation. Trust ist Governance. AP2 ist das Verhalten im Zahlungs- und Mandatskontext.

Was A2A tatsächlich standardisiert

Wann zusätzlich Trust nötig ist

PRODUKT ADI-Stack

Wie ADI als Agent-Trust-Stack funktioniert

ADI ist keine einzelne Oberfläche. Es ist eine operative Schicht, die Discovery, Identität, Trust und Payment-Flows für agentische Systeme miteinander verbindet.

Die vier Schichten der Plattform

Wo A2A, MCP und AP2 zusammenkommen

AP2-GRUNDLAGEN AP2-Payments

Was AP2 für Agent Commerce löst

AP2 gibt Agent Commerce ein strukturiertes Modell für Intent, Cart, Payment-Autorisierung und Receipts. Ohne dieses Modell erfindet jede Agenten-Payment-Integration ihre eigene fragile Semantik.

AP2 führt ein gemeinsames Vokabular für Agenten-Payment-Flows ein.

Mandate trennen Scope, Intent und finale Zahlungsfreigabe.

TRUST-GRUNDLAGEN Agent Trust

Was Agent Trust tatsächlich bedeutet

Agent Trust ist kein Marketingbegriff. Es ist die operative Fähigkeit zu beweisen, wer ein Agent ist, in wessen Namen er handelt, was er tun darf und wie diese Autorität widerrufen oder auditiert werden kann.

Trust beginnt dort, wo reine Authentisierung endet.

Eine echte Trust-Schicht muss Widerruf, Inspektion und Evidenz unterstützen.

PRODUKT-ERKLÄRUNG ADI-Stack

Was ADI in einem Agenten-Stack macht

ADI ist die Trust- und Kontrollschicht zwischen Agenten-Interoperabilität und echter Geschäftshandlung. Es hilft Organisationen, Agenten handeln zu lassen, ohne sie wie ungeregelte Black Boxes zu behandeln.

ADI ist der Punkt, an dem Governance in den Agenten-Stack eintritt.

Die Plattform verbindet externe Agenten, Enterprise-Kontrollen und Transaktionspolicies.

SIGNATUREN UND ESEALS Trust Services

Menschliche Signaturen vs. organisatorische eSeals

Eine menschliche Signatur beweist den Willen oder die Freigabe einer natürlichen Person. Ein organisatorisches eSeal beweist, dass ein Trust-Objekt von einer juristischen Person ausgestellt oder versiegelt wurde. In Enterprise-Agentensystemen sind das verschiedene Aufgaben.

Menschliche Signaturen beantworten: Wer hat persönlich zugestimmt?

OrganisationseSeals beantworten: Welche juristische Person steht hinter diesem Artefakt?