Agent Client Protocol: een gemeenschappelijke taal tussen code-editors en AI-agents
Stel je voor dat elke laptopmerk zijn eigen soort stopcontact zou eisen. Elke keer dat je van laptop wisselde, had je een nieuw stopcontact nodig. Zoiets speelde zich tot voor kort af in de wereld van AI-programmeerassistenten: elke combinatie van een code-editor (het programma waarin ontwikkelaars code schrijven) en een AI-"agent" (een AI-systeem dat zelfstandig code kan lezen, aanpassen en uitvoeren) moest apart met elkaar leren praten. Het Agent Client Protocol, afgekort ACP, is een afspraak over hoe die twee met elkaar communiceren, zodat niet elke combinatie los gebouwd hoeft te worden.
ACP is te vergelijken met een universeel stopcontact of een USB-aansluiting: zolang de editor en de AI-agent zich allebei aan dezelfde technische afspraken houden, kunnen ze zonder extra maatwerk samenwerken. Een ontwikkelaar die in de editor Zed werkt, kan daardoor in principe verschillende AI-agents "insteken" zonder dat de makers van Zed voor elke agent apart een koppeling hoeven te bouwen, en omgekeerd hoeft de maker van een AI-agent niet voor elke editor een eigen versie te schrijven.
Wat is het precies?
Een AI-agent voor programmeren is software die, meestal aangedreven door een taalmodel zoals de modellen achter ChatGPT of Claude, zelfstandig taken uitvoert: bestanden lezen, code voorstellen, commando's draaien in een terminal, en fouten oplossen. Zulke agents bestaan vaak als losstaand programma, bijvoorbeeld iets dat je in een terminalvenster start.
Het probleem is dat een terminalvenster niet erg overzichtelijk is. Programmeurs willen liever in hun vertrouwde editor zien welke bestanden een agent wil aanpassen, met kleurtjes die laten zien wat wordt toegevoegd of verwijderd, en een knop om een voorstel goed te keuren of te weigeren. Om dat mogelijk te maken, moet de editor voortdurend berichten uitwisselen met de agent: "hier is de inhoud van het geopende bestand", "ik wil dit bestand als volgt wijzigen, mag dat?", "ik wil dit terminalcommando uitvoeren", enzovoort.
ACP legt vast hoe die berichten eruitzien. Het is gebouwd op JSON-RPC, een simpel en al lang bestaand formaat waarin computers elkaar opdrachten en antwoorden sturen in de vorm van leesbare tekstblokjes (JSON). De editor en de agent draaien meestal als twee aparte programma's op dezelfde computer en praten met elkaar via de standaard in- en uitvoer van het besturingssysteem, ongeveer zoals twee mensen die briefjes doorschuiven onder een deur.
Wie de vergelijking kent: dit principe lijkt sterk op het Language Server Protocol (LSP), een afspraak die Microsoft in 2016 introduceerde. LSP loste een vergelijkbaar probleem op voor programmeertaal-ondersteuning: in plaats van dat elke editor voor elke programmeertaal apart functies als foutcontrole en automatisch aanvullen moest inbouwen, spreken editor en taal-server nu een gedeelde taal. ACP past dat idee toe, maar dan niet voor taalondersteuning, maar voor AI-agents die zelfstandig taken uitvoeren.
Wat wil men ermee bereiken?
Het achterliggende doel is simpel te begrijpen als je bedenkt hoeveel combinaties er mogelijk zijn. Stel dat er tien populaire code-editors bestaan en tien populaire AI-agents. Zonder gedeelde afspraken zouden er in het ergste geval honderd unieke koppelingen gebouwd moeten worden, en bij elke nieuwe editor of agent komen er extra bij. Met een gedeeld protocol hoeft elke editor het protocol maar één keer te implementeren, en elke agent ook maar één keer: tien plus tien in plaats van honderd.
Daarnaast speelt een tweede belang mee: onafhankelijkheid. Ontwikkelaars willen niet vastzitten aan één AI-leverancier omdat hun editor toevallig alleen met dat ene agentsysteem samenwerkt. Een open, editor-onafhankelijk protocol maakt het makkelijker om agents te wisselen zonder van programmeeromgeving te veranderen, en maakt het voor kleinere of nieuwe partijen laagdrempeliger om een eigen agent te bouwen die meteen in bestaande editors werkt.
Tot slot gaat het om vertrouwen en controle. Een AI-agent die zelfstandig bestanden aanpast of commando's uitvoert, is krachtig maar ook risicovol als er geen toezicht is. ACP legt vast hoe een agent om toestemming moet vragen voordat hij iets ingrijpends doet, zodat de mens uiteindelijk de goedkeuring geeft. Dat is meer een kwestie van zorgvuldig protocolontwerp dan een garantie: de daadwerkelijke veiligheid hangt af van hoe zorgvuldig een editor die toestemmingsvragen implementeert en hoe alert de gebruiker blijft.
Voorbeelden uit de praktijk
Omdat ACP een jong protocol is, is het aantal concrete, breed bekende toepassingen nog beperkt. De duidelijkste voorbeelden zijn:
- Zed (vanaf 2025) — de opensource-code-editor Zed, gebouwd door een team rond mede-oprichters Nathan Sobo en Antoine Niessen (bekend van eerder werk aan de Atom-editor), is de plek waar ACP is ontstaan. Zed was de eerste editor die het protocol daadwerkelijk gebruikte om AI-agents in de gebruikersinterface te integreren, met zichtbare diff-weergaven en goedkeuringsknoppen in plaats van een kale terminal.
- Gemini CLI van Google — Googles opdrachtregel-AI-agent Gemini CLI kreeg ondersteuning voor ACP, waardoor deze agent binnen de grafische interface van Zed kan draaien in plaats van alleen in een terminalvenster.
- Editor-onafhankelijke clients zoals Neovim-uitbreidingen — de programmeergemeenschap rond de teksteditor Neovim heeft plugins ontwikkeld die ACP-ondersteuning toevoegen, zodat gebruikers van die editor eveneens ACP-compatibele agents kunnen aansturen zonder dat de Neovim-kernontwikkelaars zelf de integratie hoefden te bouwen.
Belangrijk om eerlijk te zijn: het precieze en actuele overzicht van welke editors en agents ACP ondersteunen, verandert momenteel snel doordat het een jong, actief protocol is. Voor de meest actuele lijst is de officiële projectpagina de betrouwbaarste bron; namen die vandaag ontbreken, kunnen er over enkele maanden bij staan, en andersom kunnen aangekondigde integraties weer worden stopgezet.
Hoe ver is de techniek?
ACP bevindt zich in een vroege ontwikkelingsfase. Het protocol is in 2025 als open specificatie naar buiten gebracht door Zed Industries, met de broncode en documentatie publiek toegankelijk, zodat andere partijen er zonder licentiekosten mee kunnen bouwen. Dat betekent niet dat het protocol al "af" of stabiel in de zin van jarenlange achterwaartse compatibiliteit is: net als bij veel jonge technische standaarden zijn er nog aanpassingen te verwachten naarmate meer partijen tegen praktische beperkingen aanlopen.
Het belangrijkste precedent, het Language Server Protocol, laat zien hoe zo'n traject kan verlopen: LSP werd na de introductie in 2016 geleidelijk door vrijwel alle grote editors omarmd, een proces dat jaren duurde. Of ACP eenzelfde brede acceptatie zal krijgen, is nog niet met zekerheid te zeggen. Grote, gevestigde editors zoals Visual Studio Code en JetBrains-producten (zoals IntelliJ) hebben elk ook hun eigen, deels gesloten manieren om AI-agents te integreren, en het is nog onduidelijk of en in welke mate zij een extern, door een concurrent (Zed) geïnitieerd protocol zullen overnemen.
Een aanverwant en soms verward onderwerp is het Model Context Protocol (MCP), dat door AI-bedrijf Anthropic eind 2024 als open standaard is uitgebracht. MCP regelt iets anders: hoe een AI-model of -agent toegang krijgt tot externe gegevens en hulpmiddelen, zoals een database of een zoekmachine. ACP regelt de laag daarboven: hoe een agent met de gebruikersinterface van een editor communiceert. De twee protocollen zijn dus complementair en kunnen in principe naast elkaar in hetzelfde systeem worden gebruikt, maar het onderscheid leidt in populaire berichtgeving soms tot verwarring.
Wie werken eraan?
De belangrijkste initiatiefnemer is Zed Industries, het Amerikaanse bedrijf achter de Zed-code-editor, met een team van oud-medewerkers van onder meer Atom en andere ontwikkeltools. Zij hebben het protocol als opensourceproject gepubliceerd, wat betekent dat de broncode en specificatie door iedereen in te zien en aan te vullen zijn via een openbare softwarerepository.
Google heeft zich als vroege partner aangesloten door zijn Gemini CLI-agent compatibel te maken met het protocol. Verder is er, zoals bij veel opensourceprotocollen, een bredere gemeenschap van individuele ontwikkelaars en kleinere projecten (onder meer rond de Neovim-editor) die bijdragen leveren of eigen implementaties bouwen. Een gecentraliseerd overheids- of standaardisatie-orgaan is niet betrokken; het is, net als bij veel ontwikkelaarsgereedschap, vooralsnog een door de industrie zelf getrokken initiatief zonder formele certificering.
Het is op dit moment niet duidelijk of grote spelers als Microsoft (met Visual Studio Code) of JetBrains het protocol op korte termijn zullen omarmen; dat hangt af van commerciële afwegingen en van hoeveel druk gebruikers uitoefenen om agents onderling uitwisselbaar te maken.