Plattformen, die mit KI-Agenten kommunizieren, folgten bisher einem klaren Muster: Nachricht senden, Antwort erhalten, warten. Moderne Agenten arbeiten anders. Sie denken im Hintergrund weiter, streamen Zwischenergebnisse, führen Tools parallel aus und signalisieren Bereitschaft. Das alte Protokoll stößt an Grenzen. ACP Version 2 adressiert das.
Der erste Draft von Version 2 ist veröffentlicht. Seit v1 wurden 15 RFDs umgesetzt. Breaking Changes wurden nötig, um neue Anwendungsfälle sauber abzubilden. V2 konzentriert sich auf drei Kernbereiche: flexiblere Session-Zustände, konsolidierte Muster aus der Praxis und durchgängige Konsistenz. Ziel war die Verbesserung fundamentaler Verhaltensweisen, nicht möglichst viele Features. Neue Funktionen werden weiterhin über den RFD-Prozess eingebracht, auch für v1, solange sie optional bleiben.
Der erste große Wandel ist die Abkehr vom Turn-Konzept. In v1 war ein Prompt die zentrale Einheit: Nachricht senden, Agent antwortet, Durchgang beendet. In v2 können session/update-Benachrichtigungen jederzeit gesendet werden, unabhängig von einem Prompt. Der Agent signalisiert mit einer Prompt-Response nur den Eingang der Nachricht, nicht das Ende des Turns. Updates zur Session sind während der Arbeit möglich. So kann ein Client mehrere Anfragen in die Warteschlange stellen, der Agent arbeitet sie parallel ab, der Nutzer erhält Live-Updates. Auch mehrere Clients können dieselbe Session beobachten. Der Agent gibt an, wann er „idle“ ist, also bereit für neue Eingaben.
Ein weiterer Fortschritt betrifft das Aktualisieren und Streamen von Nachrichten und Tool Calls. V2 führt stabile IDs für alle Session-Items ein: Benutzernachrichten, Agentenantworten, Tool Calls und Terminalausgaben. Änderungen folgen einem einheitlichen Schema: Ausgelassene Felder bleiben unverändert, null löscht sie, Werte ersetzen, Arrays fügen an. Das erlaubt effizientes Streaming und nachträgliche Korrekturen – etwa das Redigieren einer Nachricht ohne Neuaufbau der Session. Tool Calls lassen sich jetzt ebenfalls streamen, ohne dass der gesamte Inhalt zwischengepuffert wird. Der Client zeigt den Beginn eines Tool Calls sofort an und erhält Parameter nach und nach.
Die Darstellung von Dateiänderungen wurde grundlegend überarbeitet. Das alte oldText/newText-Diff ist durch strukturierte Dateiänderungen ersetzt. Der Agent gibt explizit an, ob eine Datei hinzugefügt, gelöscht, modifiziert, verschoben oder kopiert wurde – inklusive binärer und nicht-textueller Inhalte. Zusätzlich kann ein git_patch geliefert werden. Clients rendern Diff-Ansichten ohne externe Tools.
Berechtigungsanfragen werden in v2 flexibler. Permission Requests haben jetzt einen eigenen title (erforderlich) und eine optionale description, sowie ein erweiterbares subject. Das erlaubt Abfragen für Tool Calls, Terminalbefehle oder andere Aktionen. Die Entkopplung von Titel und Beschreibung gibt dem Benutzer mehr Kontext, ohne die Tool Call-Daten zu überschreiben.
Ein wichtiges Prinzip von v2 ist Vorwärtskompatibilität. Enum-Werte im Schema akzeptieren unbekannte Varianten mit einem Unterstrich-Präfix (_custom). Neue Features können implementiert werden, ohne dass alte Clients oder Agents an unbekannten Werten scheitern. Entwickler können experimentelle Erweiterungen bauen, die später in den Standard einfließen.
Der Draft-Status ist bewusst gewählt. Jede Zeile des Schemas wurde mehrfach geprüft. Änderungen vor der Stabilisierung sind möglich und erwünscht. Implementierer sollen die Version hinter Feature-Flags verstecken und nicht standardmäßig in Produktion schalten. V1-Clients bleiben lange im Einsatz, daher beide Versionen parallel anbieten. Die SDKs werden darauf vorbereitet. Ein Migrationsguide mit Before/After-Beispielen hilft.
ACP v2 bleibt seiner Philosophie treu: Freiheit für Agenten und Clients, klare semantische Vereinbarungen dort, wo sie nötig sind. Die Änderungen lösen echte Probleme – Hintergrundarbeit, Streaming von Tool Calls, konsistente Darstellung von Änderungen. Wer heute mit ACP arbeitet, sollte den Draft studieren und testen. Der RFD-Prozess bietet eine Möglichkeit, Feedback zu geben, bevor die Spezifikation finalisiert wird. Dokumentation anschauen, Implementierung hinter einem Flag migrieren, Erfahrungen teilen. Das Agent Client Protocol wächst.
Quelle: agentclientprotocol.com
