Agent Client Protocol — Introduction

Kernpunkte

1. Der Satz, den man sich merken sollte. „AI coding agents and editors are tightly coupled but interoperability isn't the default.“ Das gesamte Protokoll ergibt sich aus dieser Beobachtung.
2. Die drei Kosten der Kopplung. (Struktur, die sich unverändert in Präsentationen übernehmen lässt): Integrationsaufwand — jede Agent×Editor-Kombination erfordert eigene Arbeit; eingeschränkte Kompatibilität — ein Agent erreicht nur eine Teilmenge der Editoren; Developer-Lock-in — die Wahl eines Agents bedeutet, seine Schnittstellen zu akzeptieren. Die drei sind unterschiedliche Kosten (Produktion, Distribution, Freiheit), nicht drei Formulierungen derselben.
3. Die LSP-Analogie leistet die eigentliche Arbeit. „similar to how the Language Server Protocol standardized language server integration.“ Sie wirkt, weil der Präzedenzfall bereits akzeptiert ist. ⚠️ Aber genau hier ist auch Vorsicht geboten: LSP standardisiert einen weitgehend deterministischen Austausch (Positionen, Symbole, Diagnosen); ACP standardisiert die Schnittstelle eines nicht-deterministischen Agents, der Berechtigungen aushandelt, Diffs erzeugt und dessen Verhalten von Durchlauf zu Durchlauf variiert. Die Form des Problems ist dieselbe; die Natur dessen, was hindurchfließt, ist es nicht. Die Seite thematisiert diese Lücke nicht.
4. ⭐ Zwei Transportmodi, nicht einer. — der am meisten unterschätzte Punkt in der Sekundärberichterstattung:
5. Lokale Agents. Subprozess des Editors, JSON-RPC über stdio. Das ist der bekannte Modus, derjenige, den alle zitieren.
6. Entfernte (remote) Agents. gehostet in der Cloud oder auf separater Infrastruktur, HTTP oder WebSocket. Als „work in progress“ bezeichnet, mit aktiver Zusammenarbeit mit agentischen Plattformen. → Konsequenz: ACP ist strukturell kein „Workstation“-Protokoll. Seine Entwicklungsrichtung zielt auf den gehosteten Agent, also auf das Unternehmensumfeld. ACP als „JSON-RPC über stdio“ zusammenzufassen, beschreibt seinen gegenwärtigen Stand, nicht sein Ziel.
7. ⭐ Die Beziehung zu MCP ist eine Abstammung, keine bloße Komplementarität. „The protocol re-uses the JSON representations used in MCP where possible.“ Es wird häufig gesagt, dass „ACP und MCP sich stapeln“ (der Client spricht ACP mit dem Agent, der Agent spricht MCP mit seinen Tools) — architektonisch zutreffend, aber unvollständig: ACP übernimmt die Datenstrukturen von MCP. Die beiden Protokolle sind nicht nur Nachbarn, sie teilen ein Serialisierungsvokabular. Siehe [[girard-acp-deux-protocoles-un-sigle-2026-08-02]] für die funktionale Unterscheidung.
8. Die Erweiterungen, die spezifisch für agentisches Codieren sind. ACP fügt „custom types for useful agentic coding UX elements, like displaying diffs“ hinzu. Das rechtfertigt die Existenz von ACP neben MCP: Ein zu genehmigender Diff ist kein Tool-Aufruf, sondern ein Interface-Element, das eine menschliche Entscheidung erfordert. Das Protokoll kodiert den Review-Moment, nicht nur die Ausführung.
9. Markdown als Standard, und der genannte Grund. „which allows enough flexibility to represent rich formatting without requiring that the code editor is capable of rendering HTML.“ Eine Designentscheidung, die durch die Last gerechtfertigt wird, die sie dem Implementierer erspart — der richtige Instinkt für ein Protokoll, das Adoption anstrebt. Bemerkenswert für alle, die ein Protokoll entwerfen: die Einstiegshürde auf der Seite senken, die man gewinnen will.
10. ⚠️ Korrektur zur Versionierung. Die Navigation der Spezifikation zeigt v1 (Latest) und v2 (Draft). Sie zeigt kein „ACP 1.2“. Diese Zahl, die in der Sekundärberichterstattung kursiert (und in [[girard-acp-deux-protocoles-un-sigle-2026-08-02]] als unverifiziert vermerkt wurde), wird von der Primärquelle nicht bestätigt. Zu zitieren: v1 / v2 draft.
11. ⚠️ Korrektur zur Governance. Die Formulierung „Zed hat es gestartet und dann losgelassen“ ist zu stark. Die Navigationsleiste verlinkt Zed Industries und JetBrains auf derselben Ebene, und die Struktur der Website (ACP Registry, RFDs, Community, Publications, Updates, Brand) ist die eines gemeinsam verwalteten Projekts mit einem Prozess, nicht die eines verwaisten Protokolls oder einer Produktdokumentation. Die korrekte Einordnung: echte Offenheit und gemeinsame Governance, keine Aufgabe.
12. Ökosystem-Signal. offizielle Bibliotheken in Kotlin, Java, Python, Rust, TypeScript + ein Community-Track. Das Paar Kotlin/Java ist der JetBrains-Marker — das Vorhandensein beider signalisiert, dass die JVM-IDE-Implementierung erstrangig ist, kein später Port.
13. Ein aufschlussreiches Detail. Die Seite beginnt mit einem Verweis auf /llms.txt — „Use this file to discover all available pages before exploring further.“ Die Dokumentation eines Protokolls für Agents ist selbst für Agents aufbereitet. Konsistenz der Anlage, und ein schwaches Signal dafür, wohin sich technische Dokumentation entwickelt.
14. Was die Seite nicht sagt. (nicht durch Rückschluss zu ergänzen): kein Datum, keine im Text genannte Versionsnummer, keine auf dieser Seite angezeigte Lizenz, kein formalisiertes Governance-Modell, keine Liste der Implementierer. Die für ACP oft zitierte Apache-2.0-Lizenz stammt aus dem Repository, nicht von dieser Seite.
15. Meta / Querverweise. Primärquelle für die Aussagen zu ACP #1 in [[girard-acp-deux-protocoles-un-sigle-2026-08-02]] (die sie bei der Versionierung korrigiert und bei der Governance nuanciert); zu lesen zusammen mit [[dethlefsen-zed-anthropic-subscription-changes-2026-05-14]], das zeigt, was die hier versprochene Optionalität wert ist, sobald ein Anbieter seine Preisgestaltung ändert; die hier beschriebene Entkopplung knüpft an den in [[janakiram-agent-platform-portability-contract-2026-07-20]] analysierten Portabilitätsvertrag an; eine Referenzimplementierung auf Produktseite in [[block-goose-mcp-ui-future-agentic-interfaces-2025-08-25]]. ⚠️ Verpflichtende Begriffsklärung: „ACP“ bezeichnet hier ausschließlich das Agent Client Protocol. Das Akronym niemals als Entität erfassen — siehe docs/solutions/conventions/sigles-jamais-entites-graphe.md.