ADI BLOG
Das ADI-Journal sammelt die tieferen technischen Hintergründe der öffentlichen Website: wie Agenten identifizierbar werden, wie Vertrauen durchgesetzt wird und wo A2A, Policy und Payment-Kontrolle in realen Systemen zusammenlaufen.
ALLE ARTIKEL
Die folgenden Artikel sind die migrierten Longform-Beiträge der früheren öffentlichen Flutter-Website, jetzt in einer sauberen Blog-Struktur.
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.
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.
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.
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.
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
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
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
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
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 standardisiert Discovery, Nachrichten, Tasks und deklarierte Sicherheitsfähigkeiten.
A2A beantwortet nicht von selbst, wen ein Agent repräsentiert oder was er darf.
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.
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.
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.
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?
