ACP vs MCP: Was das Agent Client Protocol im Editor leistet

Beim Vergleich ACP vs MCP zeigt sich der Nutzen des Agent Client Protocol (ACP) direkt im Editor: Der Coding-Agent lässt sich wechseln, ohne den Editor auszutauschen – sofern beide ACP unterstützen. Mit Android Studio Rabbit 2 macht Google diese Wahl für Android-Entwickler praktisch nutzbar. Die Ankündigung vom Oktober nennt über 40 Coding-Agenten, die sich direkt in der IDE auswählen lassen. Der entscheidende Vorteil: Die Entwicklungsumgebung bleibt, während man den Agenten für die eigentliche Arbeit frei wählen kann.

Die Zahl stammt aus Googles Ankündigung zu Android Studio vom 28. Oktober 2026. Die folgenden Angaben zu Unterstützung und Einrichtung wurden am 3. November 2026 anhand der Protokollwebsite und der Dokumentation der Editoren geprüft. Dieser Leitfaden beruht auf Dokumentation, nicht auf einem Praxistest zur Leistung der Agenten.

Was ändert sich durch das Agent Client Protocol?

ACP gibt Editoren und Coding-Agenten eine gemeinsame Schnittstelle für Prompts, Fortschrittsmeldungen, Berechtigungen und Ergebnisse. Ein Agent ist das Programm, das mithilfe eines Modells, verschiedener Tools und einer Verarbeitungsschleife eine Aufgabe ausführt. Im Editor beziehungsweise in der integrierten Entwicklungsumgebung (IDE) wird Code geprüft, werden Änderungen begutachtet und wird mit diesem Programm gearbeitet.

Ein guter Vergleich ist das Language Server Protocol (LSP). Es hat die Verbindung zwischen Editoren und Sprachservern vereinheitlicht. Ein Sprachserver liefert sprachspezifische Funktionen, etwa zur Fehlerdiagnose. ACP überträgt diese Trennung auf Coding-Agenten: Der Editor implementiert die Clientverbindung, der Agent unterstützt ACP direkt oder über einen Adapter. Beide Seiten müssen miteinander kompatibel sein. Die Einführung zu ACP beschreibt das Ziel so: Nicht jede Kombination soll eine eigens entwickelte Integration benötigen.

Wer zwischen Anthropics Claude Code, OpenAIs Codex und Googles Gemini CLI wechselt, kann dadurch in derselben Arbeitsumgebung bleiben. Ein anderer Agent lässt sich erproben, ohne zugleich den Editor wechseln zu müssen. Wie die folgende Übersicht zeigt, unterscheiden sich die Wege zur ACP-Anbindung allerdings weiterhin.

Wer hat ACP ins Leben gerufen?

Zed Industries hat ACP entwickelt und gemeinsam mit Google Gemini CLI als erste Referenzimplementierung umgesetzt. Zed kündigte diese Zusammenarbeit am 27. August 2025 an. Später kam JetBrains hinzu. Auf seiner aktuellen ACP-Seite beschreibt JetBrains das Protokoll als offene Entwicklung von JetBrains und Zed. Google ist ein früher Implementierungspartner und setzt ACP in Android Studio ein. Diese unterschiedlichen Rollen gehen aus Zeds Ankündigung zum Start und der ACP-Seite von JetBrains hervor.

Für die Bewertung der Unterstützung ist diese Unterscheidung wichtig. Ein Protokoll zu entwickeln, einen Adapter zu pflegen und einen Editorclient auszuliefern sind unterschiedliche Beiträge.

Welche Editoren und Agenten unterstützen ACP?

Für Zed, JetBrains-IDEs und Android Studio sind Wege zur Anbindung von ACP-Agenten dokumentiert. Andere Editoren nutzen Plugins oder Erweiterungen. Maßgeblich ist deshalb die Integration, die tatsächlich installiert werden soll. Ein Eintrag im Verzeichnis belegt, dass es eine Integration gibt; er garantiert kein identisches Verhalten aller Funktionen.

Die Pluginnamen stammen aus dem ACP-Clientverzeichnis. Die Angaben zu Zed, JetBrains und Android Studio beruhen auf deren eigener, weiter unten verlinkter Dokumentation. Die Auswahl konzentriert sich auf die Softwareentwicklung und ist keine vollständige Liste aller ACP-Clients.

Zed: Externe Agenten behalten ihre eigene Konfiguration

Zed stellt ACP-Agenten im Agent Panel und in der Threads Sidebar bereit. Die aktuelle Dokumentation nennt Claude, Codex, OpenCode, Copilot, Cursor und Pi als verbreitete externe Agenten und enthält außerdem eine Anleitung zur Einrichtung von Gemini CLI. Der vorgesehene Installationsweg führt vor allem über die ACP Registry. Die Dokumentation zu externen Agenten in Zed erläutert sowohl die Installation als auch die Zuständigkeit für die Konfiguration.

Die praktische Grenze liegt bei der Übernahme von Einstellungen. Profile von Zed Agent und Zed Skills werden nicht automatisch zu Einstellungen des externen Agenten. Eine Dokumentation der Teameinrichtung sollte deshalb auch die eigenen Anweisungen, Zugangsdaten und Tools des Agenten festhalten.

JetBrains: Organisationsvorgaben und Arbeitsumgebung prüfen

JetBrains AI Assistant stellt ACP-Agenten über AI Chat bereit. Ein Agent lässt sich unter Settings > Tools > AI Assistant > Agents installieren; eigene Agenten können über acp.json hinzugefügt werden. Laut Dokumentation werden ACP-Agenten derzeit außerdem nicht im Windows Subsystem for Linux (WSL) unterstützt. Administratoren können Registry-Einträge oder eigene Agenten einschränken. Maßgeblich für diese Einschränkungen ist die ACP-Dokumentation von JetBrains.

Für die technische Leitung heißt das: Vor einer Empfehlung muss die Arbeitsumgebung geprüft werden. Wenn die Einrichtung auf dem Laptop eines Kollegen funktioniert, belegt das noch keine Unterstützung für den zentral verwalteten WSL-Workflow des Teams.

Agenten: Native Unterstützung ist etwas anderes als ein Adapter

Das ACP-Agentenverzeichnis benennt die jeweiligen Integrationen genau:

• Claude Agent wird mit Zeds SDK-Adapter aufgeführt. So bezeichnet das Verzeichnis die Claude-Integration. Daraus folgt nicht, dass die Claude Code CLI selbst ACP nativ unterstützt.
• Codex CLI wird mit dem Adapter von ACP aufgeführt. Dieser Adapter gehört deshalb in die Liste der Komponenten, die der Editor startet.
• Gemini CLI wird als implementierender Agent ohne Adapterzusatz aufgeführt.
• GitHub Copilot ist auf der Seite ausdrücklich als Public Preview gekennzeichnet.

Dieselbe Seite nennt außerdem Augment Code, Cline, Cursor, Dockers cagent, Factory Droid, Goose, Hermes Agent, Junie by JetBrains, Kimi CLI, Kiro CLI, Mistral Vibe, OpenCode, OpenHands und Qwen Code. Pi wird mit einem pi-acp-Adapter aufgeführt. Diese Auswahl übernimmt die Namen des Verzeichnisses; die vollständige Liste steht auf der verlinkten Seite.

Das Verzeichnis ist keine pauschale Kompatibilitätsbewertung für sämtliche Editoren. Welche Kombination nutzbar ist, hängt vom Agenten, einem gegebenenfalls nötigen Adapter, der Editorintegration und den zwischen beiden Seiten ausgehandelten Funktionen ab.

Was bringt „Bring Your Own Agent“ in Android Studio?

In Android Studio lässt sich der Coding-Agent auswählen, während die Werkzeuge für die Android-Entwicklung erhalten bleiben. Googles Ankündigung der stabilen Version nennt Claude Agent, Codex, Junie und Google Antigravity. Laut Ankündigung können Agenten auf den Android Emulator, Build-Systeme, Logcat und Android-Skills zugreifen. Logcat ist die Anzeige für Anwendungs- und Systemprotokolle von Android. Diesen Werkzeugzugriff beschreibt Googles Ankündigung zu Rabbit 2.

Ein typischer Fall aus der Android-Entwicklung ist die Untersuchung eines Absturzes. Der Agent soll mit den Build- und Diagnosewerkzeugen des Projekts arbeiten, während die Korrektur in der vertrauten Umgebung geprüft wird. BYOA macht die Wahl des Agenten unabhängig von diesem Arbeitsplatz. Wie gut der gewählte Agent den Absturz tatsächlich diagnostiziert, muss weiterhin getestet werden.

Für die technische Leitung entstehen dadurch aussagekräftigere Pilotversuche. Repository, Aufgabe und Prüfverfahren bleiben gleich; innerhalb dieser Umgebung werden freigegebene Agenten verglichen. Bewertet werden sollten der entstandene Patch, die angeforderten Befehle und die Belege für die Antwort. Eine erfolgreiche Verbindung allein bedeutet noch keine erfolgreiche Einführung.

Als Preview gestartet, inzwischen stabil verfügbar

Google stellte BYOA am 24. September 2026 als Preview vor, zunächst in Android Studio Rabbit 2 Canary. Am 28. Oktober 2026 folgte die Ankündigung der stabilen Version von Rabbit 2 einschließlich BYOA. Die neuere Ankündigung löst den Preview-Status aus dem ursprünglichen Beitrag ab. Preview-Ankündigung, Ankündigung der stabilen Version.

Die Kennzeichnung als Preview muss immer der jeweiligen Komponente zugeordnet bleiben. Eine stabile Android-Studio-Version hebt weder den Public-Preview-Status eines anderen Agenten auf noch garantiert sie einen identischen Funktionsumfang bei Adaptern.

Wie läuft eine ACP-Sitzung ab?

Der Editor startet den Agenten und tauscht strukturierte Nachrichten mit ihm aus. Beim lokalen Transport startet der Editor einen Unterprozess, also ein weiteres Programm, das unter dem Betriebssystem läuft. Die Verbindung nutzt JSON-RPC 2.0, ein Format für Anfragen, Antworten und Benachrichtigungen, über stdio, die Standardein- und -ausgabe des Prozesses. Es werden somit strukturierte Nachrichten übertragen, statt den angezeigten Text eines Terminals auszulesen. Protokollübersicht, Transportspezifikation.

Eine Sitzung folgt einem klaren Ablauf:

1. Starten und Funktionen aushandeln. Der Editor startet den Agenten oder Adapter und sendet initialize. Beide Seiten tauschen Protokollversionen und unterstützte Funktionen aus.
2. Bei Bedarf authentifizieren. Die vom Agenten angegebene Authentifizierungsmethode wird durchlaufen. Eine erfolgreiche Verbindung zum Editor stellt noch kein Agentenkonto bereit.
3. Das Gespräch eröffnen. Der Editor sendet session/new mit dem Arbeitsverzeichnis und den von ihm bereitgestellten MCP-Servern. Der Agent antwortet mit einer Sitzungskennung.
4. Aufgabe senden und Fortschritt empfangen. Der Editor sendet session/prompt; der Agent meldet Nachrichten und Werkzeugaktivitäten über session/update-Benachrichtigungen.
5. Angeforderte Aktionen behandeln. Fordert der Agent eine Berechtigung an, zeigt der Editor die verfügbaren Optionen an und sendet die Entscheidung zurück. Der Durchlauf endet schließlich mit einer Antwort, die den Grund für sein Ende angibt.

So beschreiben es der dokumentierte Nachrichtenablauf und die Regeln zur Sitzungserstellung. Eine Sitzung ist das Gespräch des Agenten mit eigenem Kontext und Zustand. Sie ist keine universelle Gesprächsdatei, die alle Anbieter gemeinsam nutzen.

Dateien bearbeiten und Terminalbefehle ausführen

Datei- und Terminalzugriffe gehören zu den ausgehandelten Funktionen. Wenn die Unterstützung vorhanden ist, kann ein Agent mit fs/read_text_file über den Editor lesen, einschließlich ungespeicherter Änderungen, und mit fs/write_text_file über ihn schreiben. Das ist relevant, wenn der im Editor angezeigte Puffer vom gespeicherten Dateiinhalt abweicht. ACP-Dateisystemspezifikation.

Bei Befehlen fordert terminal/create den Client auf, einen Prozess zu starten. Weitere Methoden rufen die Ausgabe ab, warten auf den Abschluss, stoppen den Befehl und geben das Terminal frei. Bevor der Agent diese Methoden verwendet, muss er prüfen, ob der Client Terminalunterstützung angekündigt hat. ACP-Terminalspezifikation.

Ein Agent kann Änderungen auch als Diffs und Werkzeugfortschritte über ACP melden, während er die eigentlichen Operationen selbst ausführt. Sichtbare Aktivität im Editor bedeutet daher nicht, dass jede Operation vom Editor ausgeführt wurde. Spezifikation der Werkzeugaufrufe.

ACP vs MCP: Welche Verbindung übernimmt welches Protokoll?

ACP verbindet den Editor mit dem Agenten; das Model Context Protocol (MCP) verbindet eine KI-Anwendung oder einen Agenten mit Werkzeugen und Daten. Beide können in derselben Sitzung zusammenarbeiten. Der Vergleich folgt der ACP-Sitzungsspezifikation und der Einführung zu MCP.

Fehlt ein Werkzeug, muss neben der Editorverbindung auch die Werkzeuganbindung geprüft werden. JetBrains hat beispielsweise separate Einstellungen für die Übergabe eigener MCP-Server und seines integrierten IntelliJ-MCP-Servers an Agenten. ACP-Unterstützung allein aktiviert nicht jedes Werkzeug. Diese Optionen sind in den Registry-Einstellungen von JetBrains dokumentiert.

Bei der Gestaltung der zugrunde liegenden Dienstschnittstelle geht es um eine andere Entscheidung: wie Anwendungsfunktionen bereitgestellt werden. Darauf geht MCP vs API ein. Wer eine Anwendung rund um Coding-Agenten entwickelt, findet im Erklärartikel zum ACP-Adapter des Vercel AI SDK die passende Integrationsebene.

Claude Agent mit Android Studio verbinden

Die Einrichtung erfolgt über die Agentenauswahl in Android Studio und die Authentifizierung beim jeweiligen Anbieter. Googles aktueller Einrichtungsweg führt über das Agentenfenster oder Settings > Tools > AI > Agents. Die Anleitung zum Start nennt eine Anmeldung oder die Eingabe eines API-Schlüssels; welche Kontotarife unterstützt werden, bestimmt der Anbieter. Aktuelle Einrichtung, Authentifizierungsanleitung.

1. 1

   Eine Version mit BYOA verwenden

   Geeignet sind Android Studio Rabbit 2 in der stabilen Version oder eine spätere Version, deren Dokumentation BYOA aufführt. Die ursprüngliche Beschränkung auf Canary bezog sich auf den Preview-Start.

2. 2

   Claude Agent auswählen

   Im Agentenfenster Claude Agent auswählen. Alternativ lassen sich Agenten unter Settings > Tools > AI > Agents auswählen.

3. 3

   Beim gewählten Agenten authentifizieren

   Dem Anmeldeablauf des Agenten folgen oder einen API-Schlüssel eingeben, sofern diese Option angeboten wird. Dabei das für das Projekt freigegebene Konto und Zugangsverfahren verwenden. Für einen anderen Agenten sind dessen eigene Authentifizierung und Zugangsberechtigung erforderlich.

4. 4

   Mit einem klar begrenzten Prompt beginnen

   Googles Einrichtung endet mit dem Absenden eines Prompts. Als erste Aufgabe bietet sich an: „Erkläre, wie dieses Projekt gebaut wird, und benenne den relevanten Test-Task. Ändere keine Dateien.“ Dieser Prompt ist ein Vorschlag für den Einstieg, kein Testergebnis eines Anbieters.

5. 5

   Vor der Ausweitung den Ablauf prüfen

   Anschließend eine kleine, gut prüfbare Änderung auf einem Arbeitsbranch anfordern. Den Änderungsvorschlag, die Berechtigungsoptionen und alle angeforderten Befehle kontrollieren. Vor einer größeren Aufgabe muss das Ergebnis nachvollziehbar sein. Diese Empfehlung zur Einführung geht über die Verbindungsschritte des Anbieters hinaus.

Scheitert die Authentifizierung, liegt der Ansatzpunkt bei der Konto- oder Schlüsselkonfiguration des ausgewählten Agenten. Verbindet sich der Agent, kann aber ein Werkzeug nicht nutzen, sind die von der Integration bereitgestellten Funktionen zu prüfen. Diese Fehlerquellen gehören in der Einrichtungsdokumentation getrennt erfasst.

Welche Grenzen müssen Teams berücksichtigen?

Die Verbindung lässt sich vereinheitlichen; das Verhalten muss für jeden Agenten geprüft werden. Das Protokoll erspart wiederholte Integrationsarbeit, macht Agenten aber nicht in jedem betrieblichen Detail austauschbar.

Die Authentifizierung bleibt beim einzelnen Agenten. Für jeden ausgewählten Anbieter ist eine eigene Anmeldung oder API-Schlüsselregelung einzuplanen. Eine Implementierung kann vorhandene Zugangsdaten wiederverwenden, doch ACP ist weder ein gemeinsames Konto noch ein gemeinsamer Kontingentpool. Zed dokumentiert beispielsweise, dass externe Agenten ihre eigene Authentifizierung und Anbieterbeziehung behalten. Konfigurationsgrenzen in Zed.

Sitzungen lassen sich nur unter bestimmten Voraussetzungen wiederherstellen. Die Protokolloperation session/load setzt beim Agenten die Fähigkeit loadSession voraus. Wo sie implementiert ist, kann eine vorhandene Sitzung geladen werden. Daraus folgt nicht, dass ein anderer Anbieter den internen Zustand des ursprünglichen Agenten übernehmen kann. Bevor ein nahtloser Wechsel zugesagt wird, muss das konkrete Verhalten beim Umgang mit dem Verlauf geprüft werden. Spezifikation zum Laden von Sitzungen.

Remote-Unterstützung muss an der konkreten Implementierung geprüft werden. Die aktuelle Transportseite definiert stdio und erklärt, dass ein Streamable-HTTP-Transport spezifiziert wird. Eigene Transportwege sind zulässig. Eine funktionierende lokale Integration arbeitet deshalb nicht automatisch auch mit einem entfernten Agentenendpunkt zusammen. ACP-Transportspezifikation.

Berechtigungsanfragen ersetzen keine Sandbox

ACP legt ein Nachrichtenformat für Berechtigungsentscheidungen fest; eine Abschottung auf Betriebssystemebene erzwingt es nicht. Laut Spezifikation läuft der Agent mit den Berechtigungen seines Prozesses. Berechtigungsanfragen haben lediglich hinweisenden Charakter, und der Agent ist dafür verantwortlich, Entscheidungen einzuhalten. Der Client führt davon getrennt die über seine eigenen Funktionen angeforderten Dateisystem- und Terminalmethoden aus. ACP-Sicherheitshinweise.

Eine Anfrage kann Optionen für einmalige oder gespeicherte Freigaben und Ablehnungen anbieten. Geltungsbereich und Speicherdauer gespeicherter Entscheidungen liegen beim Agenten. Bevor „immer“ als Beschränkung auf den aktuellen Befehl oder das aktuelle Verzeichnis verstanden wird, muss die angebotene Option genau gelesen werden. Bedeutung der Berechtigungsoptionen.

Wer die Plattform betreibt, sollte neben der Editoreinrichtung auch die ausführbare Agentendatei, die Ausführungsumgebung und die Berechtigungsrichtlinie prüfen. Ein Freigabedialog schafft hilfreiche Transparenz, belegt für sich genommen aber keine wirksame Isolation.

Was ist überzogen – und für wen lohnt sich der Einstieg?

Der belastbare Vorteil liegt in der geringeren Abhängigkeit zwischen Editor und Agent. ACP-Unterstützung belegt weder bessere Codequalität noch die Übertragbarkeit der Konfiguration eines anderen Agenten oder identische Abläufe in jeder Kombination. Diese Ergebnisse müssen direkt bewertet werden.

Wer bereits zwischen Agenten wechselt, kann jetzt loslegen. Dafür bietet sich ein unterstützter Agent im ohnehin genutzten Editor an. Entscheidend ist, ob die Änderungsprüfung, die Sichtbarkeit von Befehlen und der Umgang mit Kontext bei einer repräsentativen Aufgabe helfen.

Technische Leitungen sollten vor einer Standardisierung einen Pilotversuch durchführen. Aufgabe und Abnahmekriterien bleiben über alle Agenten hinweg gleich. Authentifizierung, unterstützte Werkzeuge, Sitzungswiederherstellung und Berechtigungsverhalten werden dokumentiert. Die Auswahl sollte sich nach Arbeitsergebnis und Kontrollierbarkeit richten, nicht nach der Größe einer Registry.

Plattformverantwortliche sollten abwarten, wenn eine erforderliche Umgebung nicht unterstützt wird. Die dokumentierte WSL-Einschränkung von JetBrains ist ein konkretes Beispiel. Auch ein Remote-Workflow, der von noch nicht bestätigtem Transportverhalten abhängt, ist ein Grund, die Kombination vor der Einführung zu validieren.

Wer mit der Arbeit im Terminal zufrieden ist, ist kaum betroffen. Die bloße Existenz eines Protokolls ist kein Grund, die Oberfläche zu wechseln. Ist noch offen, welcher Agent die eigene Arbeit besser erledigt, liefert der Vergleich von Codex und Claude Code einen Rahmen für die Entscheidung. Die Bewertung sollte anschließend am eigenen Repository erfolgen.

Häufige Fragen

Was ist das Agent Client Protocol?

Das Agent Client Protocol ist die gemeinsame Schnittstelle zwischen einem Coding-Agenten und einem Editor oder einem anderen Client. Kompatible Implementierungen können damit Prompts, Fortschrittsmeldungen und Aktionen austauschen, ohne für jede Kombination eine eigene Integration zu benötigen.

Was unterscheidet ACP von MCP?

ACP übernimmt die Verbindung zwischen Editor und Agent. MCP verbindet eine KI-Anwendung oder einen Agenten mit externen Werkzeugen und Daten. Eine ACP-Sitzung kann MCP-Serverkonfigurationen bereitstellen. Beide Protokolle können somit am selben Arbeitsablauf beteiligt sein.

Was ist der Unterschied zwischen A2A und MCP?

Agent2Agent (A2A) vereinheitlicht die Kommunikation zwischen unabhängigen Agenten. MCP verbindet KI-Anwendungen mit externen Funktionen und Daten. A2A betrifft die Zusammenarbeit von Agenten; das hier behandelte ACP betrifft dagegen die Verbindung zum Editor. Weitere Angaben enthält die Erklärung des A2A-Projekts.

Unterstützt Claude Code das Agent Client Protocol?

Der genaue Verzeichniseintrag lautet Claude Agent mit Zeds SDK-Adapter. Maßgeblich ist die unterstützte Integration, die der jeweilige Editor dokumentiert. Der Eintrag belegt keine native ACP-Unterstützung in jeder ausführbaren Datei von Claude Code. Zed dokumentiert Claude Agent als externen Agenten mit eigener Authentifizierung.

Ist Claude Code weiterhin der beste Coding-Agent?

Das lässt sich nicht an der ACP-Unterstützung ablesen. Agenten sollten am eigenen Repository mit derselben Aufgabe, denselben Prüfkriterien und denselben zugelassenen Werkzeugen verglichen werden. Vorzuziehen ist der Agent, dessen Änderungen sich validieren lassen und dessen Ablauf zu den regelmäßig anfallenden Aufgaben passt.

Wer hat das Agent Client Protocol entwickelt?

Zed hat ACP entwickelt und gemeinsam mit Google Gemini CLI als erste Referenzimplementierung umgesetzt. JetBrains schloss sich dem Vorhaben an. Die aktuelle JetBrains-Dokumentation beschreibt ACP als offene Entwicklung von JetBrains und Zed.

Was unterscheidet das Agent Client Protocol vom Agent Communication Protocol?

Es handelt sich um unterschiedliche Projekte mit derselben Abkürzung. Das Agent Client Protocol verbindet Editoren und Coding-Agenten. IBMs Agent Communication Protocol befasste sich mit der Kommunikation zwischen Agenten; laut IBM Research ist es inzwischen Teil von A2A.

Wie funktioniert ACP?

Für eine lokale Sitzung startet der Editor den Agenten als Unterprozess und kommuniziert über JSON-RPC und stdio mit ihm. Beide handeln Funktionen aus, führen eine gegebenenfalls erforderliche Authentifizierung durch, eröffnen eine Sitzung und tauschen Prompts, Aktualisierungen und Berechtigungsentscheidungen aus.

Wofür steht ACP bei agentischer KI?

Bei einer Editorintegration steht ACP üblicherweise für Agent Client Protocol. Beim Lesen einer Architekturbeschreibung oder bei der Auswahl einer Bibliothek sollte der Name ausgeschrieben werden: Die Abkürzung für Agent Communication Protocol bezeichnet ein anderes Projekt.

So beginnt die nächste Arbeitssitzung

Der Editor bleibt, hinzu kommt ein freigegebener ACP-Agent. Den Anfang macht eine kleine Aufgabe im Repository, deren Ergebnis sich prüfen lässt. Dokumentiert werden der eingesetzte Agent samt Adapter, die Authentifizierungsmethode, verfügbare Werkzeuge und das Berechtigungsverhalten. Der Pilotversuch sollte erst ausgeweitet werden, wenn der gesamte Arbeitsablauf klar ist – einschließlich dessen, was beim Ablehnen einer Aktion passiert.

Praxisnahe Anleitungen zu Veränderungen in der Softwareentwicklung gibt es im Newsletter.