ACP : deux protocoles, un sigle, zéro rapport

Kernpunkte

1. Datum / Quelle. 2. August 2026, Tech-Watch-Notiz von Didier Girard.
2. Kernaussage. Drei Protokolle konkurrieren um das Akronym ACP, ohne jede technische Überschneidung, und die oberflächliche Ähnlichkeit ist maximal ("Protokoll", "Agenten", "Open Source", "2025–2026"). ### Die Entwirrung | Akronym | Vollständiger Name | Verbindet | Herkunft | |---|---|---|---| | ACP #1 | Agent Client Protocol | einen Client mit einem Agenten | Zed, August 2025 | | ACP #2 | Agentic Commerce Protocol | einen Agenten mit einem Händler | OpenAI + Stripe, 29. Sept. 2025 | | ACP #3 | Agent Communication Protocol | einen Agenten mit einem Agenten | IBM Research / BeeAI | Eine Analogie, die trägt: ACP #1 ist für den Agenten das, was LSP für die Sprache ist — zuvor N Editoren × M Agenten = N×M maßgeschneiderte Integrationen; danach genügt N+M. Und die Abgrenzung zu MCP passt in zwei Zeilen: MCP verbindet einen Agenten mit seinen Tools und Daten, ACP verbindet einen Client mit einem Agenten; beide stapeln sich. ### Die Kuratierungsregel, die eigentliche Leistung der Notiz "Ein nacktes Akronym wird nie indexiert." Die kanonische Entität ist der vollständige Name; das Akronym ist nur ein Alias, und ein Alias kann von mehreren Entitäten getragen werden. Direkt auf dieses Repository anwendbar — siehe [docs/reference/ontologie-kg.md](docs/reference/ontologie-kg.md) und scripts/entity_aliases.tsv. ### Am 2. August 2026 an diesem Korpus durchgeführte Überprüfung | Aussage der Notiz | Ergebnis | |---|---| | "Nichts zum Zed-Protokoll" | bestätigt — die Zeichenkette "Agent Client Protocol" fehlte in fiches/ und kb/; die Lücke wurde noch am selben Tag durch [[agentclientprotocol-introduction-2026-08-02]] geschlossen | | "Zwölf Treffer" | per grep nicht reproduzierbar — 3 Fiches enthalten das Token ACP, mit 32 Vorkommen. Die "zwölf" stammen wahrscheinlich von einer semantischen Engine. Die Zahl lässt sich nicht verifizieren; die qualitative Schlussfolgerung schon | | War die Falle überhaupt möglich? | bereits scharfgestellt — das nackte Akronym ACP war im Graphen als Entität typisiert, Subjekt von Triples in zwei Fiches, neben einer Variante Agentic Commerce Protocol (ACP), d. h. drei Entitäten für dasselbe Protokoll | | Manifestierter Fehler | die Seite kb/Agentic-Commerce-Protocol.md lautete "category: Google agentic commerce protocol" und die Relation Google created → Agentic Commerce Protocol (Konfidenz 0,99), obwohl ACP OpenAI + Stripe gehört und Googles Protokoll UCP (+ AP2) ist | Die beschriebene Kollision hatte also bereits einen Zuschreibungsfehler im Graphen erzeugt. Am 2. August behoben: Varianten auf Agentic Commerce Protocol normalisiert, und symmetrisch UCP → Universal Commerce Protocol, ACS → Agentic Commerce Suite. Die Regel war hier nicht präventiv, sondern korrektiv. ### Governance von ACP #1, eine hinzuzufügende Nuance Die Notiz stellt fest: "Zed hat die Sache lanciert und dann losgelassen". Der Eröffnungsschritt ist real und verifizierbar (eigene Organisation, versionierte Spezifikation, öffentliche Registry, JetBrains-Implementierung), doch öffentliche Quellen beschreiben eine geteilte Governance zwischen Zed und JetBrains — eine im Januar 2026 gemeinsam lancierte Registry —, wobei ACP auf Zeds Seite weiterhin als dessen offener Standard und Vorzeigefunktion von Zed 1.0 präsentiert wird. Offenheit ja, Loslassen nein. Ein seither durch die Primärquelle widerlegtes Detail: Die Zahl ACP 1.2 wird nicht bestätigt, die Navigation der Spezifikation zeigt v1 (Latest) und v2 (Draft). Die URL cdn.agentclientprotocol.com/registry bleibt unbestätigt. ### Buzz, der konkrete Fall — verifiziert und korrekt Von Block am 21. Juli 2026 veröffentlicht, Apache-2.0. Ein selbst hostbarer Arbeitsbereich auf Nostr; jeder menschliche oder agentische Teilnehmer ist ein Schlüsselpaar (Schnorr); jede Nachricht, jeder Workflow-Schritt und jeder Git-Push ist ein signiertes Ereignis in einem Append-only-Log. Drei Bausteine: buzz-acp (ein Harness, das Buzz-Ereignisse in ACP über stdio an einen Agenten übersetzt), buzz-agent (ein ACP-Agent, der ein LLM aufruft und MCP-Tools nutzt), buzz-dev-mcp (ein MCP-Shell- + Editier-Server). Drei Harnesses werden von Haus aus mitgeliefert: Goose (Block), Claude Code (Anthropic), Codex (OpenAI). Das ist nicht "ein Produkt, das ACP nutzt", sondern eine Demonstration, dass die Entkopplung trägt: drei Agenten dreier konkurrierender Anbieter, angedockt über dasselbe Harness, und ein vierter — Hermes (Nous Research) — verbunden, ohne dass Block eine Zeile geschrieben hätte. Das N+M-Versprechen wird zu einer beobachtbaren Tatsache. Nuance: Auf Hermes' Seite rahmt die öffentliche Quelle die Ergänzung als ACP-Servermodus, der Zed, JetBrains und Neovim öffnet — der Nutzen für Buzz ist also eher eine Folge von ACP als eine gezielte Integration, was das Argument stärkt. Lesart aus Sicht der Unternehmensarchitektur: Buzz stellt ein souveränes, auditierbares Multi-Agenten-Substrat bereit, ohne Abhängigkeit von Dritt-SaaS — signiertes Log, selbst gehosteter Relay, kryptografische Identitäten. Es ist die selbst gehostete Option für den in [[janakiram-agent-platform-portability-contract-2026-07-20]] analysierten Portabilitätsbedarf. ### Claude-Abonnement und Drittanbieter-Agenten 2026er-Zeitleiste, wie von der Notiz berichtet, nicht erneut verifiziert: 9. Januar, stille technische Blockade von Abonnement-OAuth-Tokens außerhalb offizieller Tools → 17.–20. Februar, Formalisierung in der Dokumentation und den Consumer Terms (die OpenClaw-Episode) → 4. April, vollständige Durchsetzung → 13.–14. Mai, Ankündigung separater Agent-SDK-Credits (20 $ Pro / 100 $ Max 5x / 200 $ Max 20x), wirksam ab 15. Juni → 15. Juni, die Änderung wurde am selben Tag ihres Inkrafttretens ausgesetzt. Stand laut Bericht vom 2. August 2026: Das Agent SDK, claude -p und Drittanbieteranwendungen greifen auf die Limits des Abonnements zurück, ein separates Guthaben existiert nicht. Konstruktionsbedingt datiert: vor jeder Entscheidung erneut zu verifizieren. ### Die Regel, die die Nutzungsbedingungen überdauern wird Die gezogene Grenze trennt die "gewöhnliche, individuelle" Nutzung von der Weiterleitung fremder Anfragen über Free-/Pro-/Max-Zugangsdaten. Ein owner-only-Agent verbraucht Ihr Abonnement für Sie; ein anyone-Agent in einem gemeinsamen Kanal leitet die Anfragen Ihrer Kollegen über Ihr Konto, und das ist der Moment, um auf einen nutzungsbasiert abgerechneten API-Schlüssel umzusteigen. Die Unterscheidung ist nicht rechtlicher, sondern architektonischer Natur: wer konsumiert, und in wessen Auftrag — eine Frage, die bereits beim Design zu klären ist. Dies ist die ambient authority aus [[valente-zalewski-beyond-zero-enterprise-security-ai-era-2026-07-20]], übertragen von der Autorisierung auf die Abrechnung: Ein Agent, der die Berechtigungen seines Menschen erbt und im Auftrag eines Dritten handelt, stellt dasselbe Grenzproblem dar, ob er nun auf ein Dokument zugreift oder ein Kontingent verbraucht.