Et nyt navn er begyndt at dukke op i changelogs fra JetBrains, Zed og en håndfuld terminalværktøjer i 2026: Agent Client Protocol, forkortet ACP. Protokollen lover noget, udviklere har efterspurgt siden de første AI-kodeagenter landede i editorerne for et par år siden, nemlig at man kan skifte AI-agent uden at skifte editor. Den 22. juli 2026 tog JetBrains et konkret skridt i den retning, da ReSharper 2026.2 fik preview-support for agenten Junie inde i Microsoft Visual Studio via ACP. Det er første gang, JetBrains’ egen agent kører native i et Microsoft-produkt uden en separat plugin-arkitektur bygget fra bunden.
For danske og nordiske udviklerteams, der i forvejen jonglerer med GitHub Copilot, Cursor, Claude Code og en række andre AI-udviklerværktøjer, er spørgsmålet ikke længere om man skal bruge AI i sin editor. Det er hvor mange forskellige integrationer, man er nødt til at vedligeholde for at gøre det. ACP forsøger at reducere det tal til én.
Hvad er Agent Client Protocol?
Agent Client Protocol er en åben, JSON-RPC 2.0-baseret standard, der definerer, hvordan en AI-kodeagent kommunikerer med den editor eller det IDE, den kører i. Tanken minder om Language Server Protocol (LSP), som Microsoft lancerede i 2016 for at løse et lignende problem: dengang skulle hver editor bygge sin egen sprogunderstøttelse til hvert programmeringssprog. LSP gjorde det muligt for én sprogserver at betjene flere editorer på samme tid.
ACP gør det samme for agenter. I stedet for at en agentudvikler skal bygge separate integrationer til VS Code, JetBrains, Zed og Neovim, bygger de én ACP-kompatibel agent. Enhver editor, der taler ACP, kan så koble sig på. Protokollen blev skabt af Zed i august 2025 som en åben løsning på et problem, Zed selv stod med: de ville lade brugere køre eksterne agenter som Claude Code, Codex CLI og Gemini CLI direkte i deres editor uden at bygge en proprietær bro til hver enkelt, se agentclientprotocol.com for den fulde specifikation.
Det centrale skel går mellem agent og model. ACP siger intet om, hvilken sprogmodel der driver agenten. Det er alene et transportlag for, hvordan filændringer, terminalkommandoer, godkendelser, diagnosticering og session-tilstand sendes frem og tilbage mellem agent og editor. En agent bygget på Claude, GPT eller en lokal model kan i princippet tale samme sprog, så længe den implementerer ACP korrekt.
Tidslinjen: fra Zed-eksperiment til Visual Studio
ACP har bevæget sig hurtigere gennem økosystemet, end de fleste udviklerstandarder plejer. Nedenfor er de vigtigste stationer frem til september 2026.
| Dato | Begivenhed | Betydning |
|---|---|---|
| August 2025 | Zed skaber ACP som åben protokol | Første version af standarden, bygget til Zeds eget agent-økosystem |
| Januar 2026 | JetBrains og Zed lancerer ACP Agent Registry | Et fælles katalog over ACP-kompatible agenter, indbygget i JetBrains IDE’er 2025.3+ og Zed |
| 29. april 2026 | Zed 1.0 udgives | Native understøttelse af parallelle ACP-agenter som Codex CLI, Claude Agent og Gemini CLI |
| 2. juni 2026 | Microsofts eksperimentelle Intelligent Terminal 0.1 | Første tegn på ACP uden for traditionelle IDE’er, i en terminal-kontekst |
| 5. juni 2026 | ACP når protokolversion 0.13.6 | Standarden er stadig under aktiv udvikling, ikke frosset |
| 22. juli 2026 | ReSharper 2026.2 preview med Junie via ACP | ACP krydser ind i Visual Studio for første gang |
| 10. september 2026 | ReSharper 2026.2 Release Candidate | Junie-support i Visual Studio er stadig markeret som preview |
| 23. september 2026 | Opdateret ACP-klientoversigt | Officiel liste dækker nu Zed, VS Code-udvidelser og Neovim-plugins |
Det er værd at bemærke, at JetBrains selv beskriver ReSharper 2026.2 som “det første skridt” mod fuld ACP-understøttelse i Visual Studio, ikke en færdig implementering. Junie kører i preview, og der er endnu ikke bekræftet en endelig, stabil udgivelsesdato for den fulde funktion.
Hvem understøtter ACP lige nu?
Der er stor forskel på, hvad “understøtter ACP” reelt betyder fra editor til editor. Zed og JetBrains har bygget protokollen ind som en del af deres kerneprodukt. Andre platforme, herunder VS Code og Neovim, får adgang via tredjeparts-udvidelser og community-plugins snarere end officiel, indbygget support fra Microsoft.
| Editor / platform | ACP-status | Kilde til understøttelse |
|---|---|---|
| Zed | Nativ, first-party | Protokollens ophavsmand, indbygget siden 2025 |
| JetBrains IDE’er (IntelliJ IDEA, PyCharm, GoLand, WebStorm) | Nativ, first-party | ACP Registry i IDE’er fra version 2025.3 |
| Visual Studio (via ReSharper) | Preview | ReSharper 2026.2, kun Junie som agent indtil videre |
| VS Code | Tredjeparts-udvidelse | ACP Client-udvidelser fra Marketplace og Open VSX, ikke bygget af Microsoft |
| Neovim | Plugin-baseret | CodeCompanion.nvim, avante.nvim, agentic.nvim |
| Microsoft Intelligent Terminal | Eksperimentel, nativ | Terminal-fork med indbygget agent-panel siden juni 2026 |
| Cursor, Windsurf, Trae | Via VS Code-kompatible udvidelser | Samme tredjeparts-udvidelser som almindelig VS Code |
Det mest interessante datapunkt her er Microsofts position. Ifølge tilgængelig research har Microsoft ikke forpligtet sig til en nativ ACP-implementering i VS Code, det store flertal af verdens udviklere bruger dagligt. Selskabet har i stedet prioriteret Model Context Protocol (MCP) som sit foretrukne interoperabilitetslag. Det betyder, at ACP i den mest udbredte editor i verden fortsat er noget, brugerne selv skal installere, ikke noget der virker ud af boksen.
ACP versus MCP: konkurrerende eller komplementære standarder?
Forvirringen mellem ACP og MCP er forståelig, for begge dukkede op omtrent samtidig, og begge handler om at give AI-agenter mere struktureret adgang til noget. Men de løser forskellige problemer, og det er værd at holde dem adskilt.
MCP, som Anthropic offentliggjorde i november 2024, standardiserer, hvordan en model eller agent henter kontekst og kalder eksterne værktøjer: databaser, GitHub-repositories, dokumentationssystemer, issue-trackere og lignende. ACP standardiserer noget andet, nemlig hvordan agenten kommunikerer med selve editoren, den kører i: hvordan filændringer vises, hvordan terminalkommandoer eksekveres, hvordan brugeren godkender handlinger, og hvordan sessionstilstand bevares.
Man kan tænke på det sådan: MCP svarer på spørgsmålet “hvordan får agenten adgang til værktøjer og data?”. ACP svarer på “hvordan fungerer agenten inde i mit redigeringsvindue?”. En enkelt arbejdsgang kan sagtens bruge begge dele samtidig. En ACP-forbundet agent i Zed kan udmærket kalde MCP-servere for at hente data fra et internt API, mens den viser sine ændringer i editoren via ACP.
Alligevel konkurrerer de to standarder om noget: opmærksomhed og investeringsprioritet hos editor- og platformleverandører. MCP har bredere synlighed på tværs af modeludbydere og værktøjsleverandører, mens ACP er mere nichepræget og fokuseret specifikt på kodemiljøer. Når Microsoft vælger at satse på MCP i VS Code frem for at bygge nativ ACP-support, sender det et signal om, hvilken standard der reelt vinder mindshare blandt de leverandører, der former, hvordan de fleste udviklere arbejder.
Adoptionstal: stadig tidligt, men voksende
Konkrete, uafhængigt reviderede tal for ACP er endnu sparsomme, hvilket i sig selv fortæller noget om, hvor tidligt i livscyklussen protokollen befinder sig. Det mest specifikke tal, der går igen i den tilgængelige dækning, er, at ACP-registreringen talte omkring 50 agenter i juni 2026. Det tal skal læses som et rapporteret økosystem-øjebliksbillede, ikke som en revideret benchmark.
Protokollen selv var ved version 0.13.6 pr. 5. juni 2026, hvilket understreger, at ACP stadig er under aktiv, potentielt brydende udvikling. Det er en vigtig detalje for enhver virksomhed, der overvejer at bygge produktionskode oven på protokollen lige nu: et versionsnummer under 1.0 betyder typisk, at API-kontrakter kan ændre sig mellem udgivelser.
Der findes ingen pålidelige, offentligt reviderede tal for GitHub-stjerner på ACP-repositoriet, samlede downloads, antal installationer via registret eller sammenlignet brug mod MCP. Enhver artikel, der påstår at kende disse tal med præcision i september 2026, bør læses med skepsis, for de underliggende kilder findes ikke i den tilgængelige, verificerbare research.
Hvorfor JetBrains og Zed satser på ACP
JetBrains beskriver selv ACP som en åben protokol, der lader enhver AI-kodeagent arbejde i enhver understøttet editor. Målet med ACP Agent Registry, som blev lanceret sammen med Zed i januar 2026, er ifølge JetBrains’ egen annoncering at gøre agenter opdagelige og installerbare direkte fra både JetBrains-IDE’er og Zed, uden at brugeren skal konfigurere en separat integration for hver agent.
Det strategiske motiv bag Zeds oprindelige satsning er lige så tydeligt. Zed er bygget som en editor, hvor udviklere kan køre eksterne agenter som Codex CLI, Claude Agent og Gemini CLI side om side, i stedet for at være låst til én indbygget assistent, som beskrevet på Zeds egen ACP-side. Det gør Zed til en agent-neutral vært snarere end en editor, der tvinger brugeren til at vælge redskab baseret på, hvilken assistent der følger med.
For JetBrains handler ReSharper-integrationen i Visual Studio om noget lignende, men rettet mod .NET-udviklere specifikt. I stedet for at hardkode Visual Studio til én proprietær agent lader ACP JetBrains tilbyde Junie som det første eksempel, med en arkitektur der i teorien kan udvides til flere agenter senere. Ordvalget “første skridt” i JetBrains’ egen udgivelsesnote signalerer, at selskabet betragter dette som en inkrementel platformsbevægelse, ikke en færdig funktion.
Markedskonteksten: hvorfor standardisering er nødvendig nu
Presset for at standardisere agent-editor-kommunikation kommer fra en simpel observation: kodeagenter er blevet forskellige nok i deres arkitektur, at fragmentering nu koster reel udviklertid. GitHub Copilot er tæt bygget ind i Microsofts eget editor- og repository-økosystem. Cursor er en hel editor bygget omkring sin egen agentoplevelse. Claude Code er stærkt terminal-orienteret. Windsurf, som siden er omdøbt til Devin Desktop, og Junie kombinerer agent-kapaciteter med stadig mere integrerede arbejdsgange.
Uden en fælles protokol skal hver agentleverandør bygge separate integrationer til hver editor, og hver editor skal bygge skræddersyede adaptere til hver agent. Det er et problem, der vokser hurtigere, end nogen enkelt virksomhed kan følge med til, efterhånden som antallet af både agenter og editorer stiger. ACP er et forsøg på at gøre det problem lineært i stedet for eksponentielt: byg én ACP-klient i din editor, og du får adgang til hele registret af kompatible agenter, uden at forhandle en separat aftale med hver enkelt leverandør.
For danske virksomheder, der arbejder med .NET i Visual Studio, med JetBrains-værktøjer i backend-teams, og med VS Code som frontend-standard, betyder det potentielt, at valget af agent kan blive løsrevet fra valget af editor. I dag betyder et skifte fra Copilot til Claude Code ofte, at man også skifter arbejdsflow. Med en moden ACP-implementering kunne det i teorien blive en indstilling, man ændrer, ikke en editor, man forlader.
Konkurrencelandskabet: ACP-agenter mod lukkede alternativer
Det er nyttigt at sætte ACP op mod de lukkede eller halvlukkede alternativer, danske udviklerteams allerede kender, for at forstå, hvad protokollen reelt ændrer, og hvad den ikke gør.
| Løsning | Arkitektur | Editor-binding | Åben standard? |
|---|---|---|---|
| GitHub Copilot | Proprietær, tæt integreret i VS Code, JetBrains, Visual Studio | Fungerer i flere editorer, men styret af Microsoft/GitHub alene | Nej |
| Cursor | Fork af VS Code med indbygget agent | Editoren og agenten er samme produkt | Nej |
| Claude Code | Terminal-først, kan kobles til editorer via egne integrationer | Løsere binding, men ingen fælles protokol krævet | Nej |
| Windsurf / Devin Desktop | Kombineret IDE og agent-workflow | Tæt integreret i eget produkt | Nej |
| ACP-kompatible agenter (Junie, Codex CLI, Gemini CLI m.fl.) | Agent kører uafhængigt af editor via ACP | Løs, editor-agnostisk i teorien | Ja, JSON-RPC-baseret åben protokol |
Forskellen er ikke, at ACP-agenter nødvendigvis er bedre til at skrive kode end Copilot eller Cursor. Forskellen ligger i, hvor beslutningen om hvilken agent, man bruger, bliver truffet. Med lukkede løsninger er valget bundet til editoren. Med ACP flyttes valget til et lag under editoren, hvor teoretisk set enhver kompatibel agent kan tilkobles uden at skrive en ny integration fra bunden.
Historisk perspektiv: LSP-parallellen holder, men kun delvist
Language Server Protocol-sammenligningen er ikke tilfældig, og den er nyttig, fordi LSP faktisk lykkedes. Da Microsoft lancerede LSP i 2016, var problemet, at hver editor skulle bygge sin egen forståelse af hvert programmeringssprog: autofuldførelse, fejlfinding, gå-til-definition og så videre for hvert sprog i hver editor. LSP flyttede den logik til en separat sprogserver, som enhver editor kunne tale med via en standardiseret protokol. I dag er LSP så udbredt, at de fleste udviklere aldrig tænker over, at det findes.
ACP forsøger noget lignende for agenter, men konteksten er anderledes på et par afgørende punkter. LSP løste et rent teknisk koordinationsproblem uden stærke kommercielle modstridende interesser, ingen sprogserverudbyder tabte penge på, at LSP vandt. Med AI-kodeagenter er situationen mere kompleks: proprietære agentleverandører har en kommerciel interesse i lock-in, fordi differentiering på integrationsniveau kan være en konkurrencefordel. Det betyder, at ACP’s succes i højere grad afhænger af, om store leverandører som Microsoft og OpenAI reelt vælger at støtte en åben standard, når det kan underminere deres egen positionsfordel.
Kritik, risici og begrænsninger
Flere svagheder går igen i den tilgængelige dækning af ACP, og de er værd at tage alvorligt, før man baserer produktionsarbejdsgange på protokollen.
- Protokolmodenhed: ACP lå stadig på version 0.13.6 i juni 2026, og ReSharper-implementeringen var fortsat markeret preview i september. Det betyder, at brydende ændringer, ufuldstændig semantik eller ujævne implementeringer stadig kan forekomme.
- Fragmenteret implementeringskvalitet: Support spænder fra native Zed- og JetBrains-integrationer til community-plugins til Neovim og tredjeparts-udvidelser til VS Code. “Understøtter ACP” betyder derfor ikke nødvendigvis samme funktionsniveau på tværs af editorer.
- Manglende nativ forpligtelse fra Microsoft i VS Code: Så længe Microsoft prioriterer MCP for agent-integration i verdens mest brugte editor, risikerer ACP at forblive et udvidelseslag snarere end en indbygget standard, hvor flest udviklere reelt mærker den.
- Konkurrerende standard: MCP’s stærkere synlighed og bredere værktøjsøkosystem kan gøre ACP mindre nødvendig for leverandører, der allerede har proprietære editor-integrationer eller bruger MCP som deres primære interoperabilitetslag.
- Registrerings- og tillidsspørgsmål: Et register, der installerer tredjeparts-agenter direkte i udviklerens editor, rejser praktiske spørgsmål om autentificering, tilladelser, kodeeksekvering og datahåndtering. Den tilgængelige dokumentation beskriver registret, men leverer ikke en formel sikkerhedsrevision eller styringsramme.
- Leverandørincitamenter: Proprietære agentleverandører har typisk en kommerciel fordel af lock-in. En fælles protokol reducerer differentiering på integrationsniveauet, så adoption afhænger af, om selskaber accepterer interoperabilitet, selv når det strider mod deres egen forretningsinteresse.
Den mest presserende svaghed er ikke en teknisk fejl i selve protokollen, men en ujævn institutionel forpligtelse: JetBrains og Zed er first-party-tilhængere, mens Microsofts native position i VS Code fortsat virker uafklaret.
Hvad betyder det for danske udviklerteams lige nu?
For et .NET-tungt team, der bruger Visual Studio dagligt, betyder ReSharper 2026.2 konkret, at man for første gang kan prøve Junie inde i Microsofts editor uden en separat installation af et JetBrains-IDE ved siden af. Det er stadig preview, så det er ikke tidspunktet at basere kritiske leverancer på integrationen, men det er værd at teste på et sideprojekt for at forstå, hvordan ACP-baseret agentstyring føles i praksis.
For teams, der allerede bruger Zed eller et JetBrains-IDE, er ACP allerede en del af hverdagen, ofte uden at man aktivt har tænkt over det som en separat protokol. Registret gør det muligt at skifte mellem Codex CLI, Claude Agent og Gemini CLI uden at genopbygge sin arbejdsgang fra bunden hver gang.
For VS Code-brugere, som udgør langt størstedelen af danske udviklere, er billedet mere blandet. Man kan installere en ACP-klient-udvidelse fra Marketplace eller Open VSX i dag, men det er ikke en indbygget, Microsoft-forpligtet funktion. Det betyder, at man reelt vælger at satse på et community-lag, indtil eller medmindre Microsoft ændrer kurs.
Fem forudsigelser for ACP frem mod 2027
- ACP når version 1.0 i løbet af 2027. Med aktiv udvikling gennem hele 2026 og et voksende registreringsantal af agenter er en stabil, versioneret 1.0-udgivelse et logisk næste skridt, når nok editorer og agenter har testet protokollen i produktion.
- ReSharpers Junie-integration forlader preview i løbet af 2027. JetBrains har allerede beskrevet det som “første skridt”, hvilket typisk betyder, at flere agenter og en stabil udgivelse følger, når feedback fra release candidate-fasen er indarbejdet.
- Microsoft forbliver forsigtig med nativ ACP-support i VS Code. Så længe selskabet prioriterer MCP som sit foretrukne interoperabilitetslag, er det mest sandsynligt, at ACP i VS Code fortsætter som udvidelsesbaseret funktionalitet snarere end en indbygget del af editoren.
- Flere agentleverandører tilføjer ACP-support som et konkurrenceparameter. Efterhånden som udviklere begynder at forvente editor-uafhængighed, bliver ACP-kompatibilitet et argument, agentleverandører kan bruge for at differentiere sig fra fuldt lukkede alternativer.
- ACP og MCP forbliver adskilte, men i stigende grad brugt sammen. Fordi de løser forskellige lag af problemet, er det mere sandsynligt, at fremtidige agent-arkitekturer kombinerer begge standarder end at den ene fortrænger den anden.
Ofte stillede spørgsmål om Agent Client Protocol
Hvad er forskellen på ACP og MCP?
ACP standardiserer kommunikationen mellem en AI-agent og den editor, den kører i. MCP standardiserer, hvordan en model eller agent får adgang til eksterne værktøjer og datakilder. De løser forskellige lag af samme overordnede problem og kan bruges sammen i samme arbejdsgang.
Hvem har lavet ACP?
Zed skabte protokollen i august 2025 som en åben løsning på behovet for at køre eksterne agenter direkte i deres editor. JetBrains har siden været den mest markante medudvikler og first-party-tilhænger.
Understøtter Visual Studio Code ACP?
Kun via tredjeparts-udvidelser som ACP Client, hentet fra VS Code Marketplace eller Open VSX. Microsoft har ikke bygget en nativ, indbygget ACP-implementering ind i VS Code, og selskabet har i stedet prioriteret MCP i sin agent-arkitektur.
Kan jeg bruge Junie i Visual Studio i dag?
Ja, men kun som preview-funktion via ReSharper 2026.2, som nåede release candidate-status den 10. september 2026. Det er ikke markeret som en stabil, produktionsklar funktion endnu.
Er ACP klar til produktionsbrug?
Protokollen lå på version 0.13.6 i juni 2026, hvilket betyder, den stadig er under aktiv udvikling og ikke er frosset som en stabil 1.0-standard. Virksomheder bør teste ACP-baserede arbejdsgange grundigt, før de gøres til en kritisk del af udviklerværktøjskæden.
Hvilke agenter kan jeg bruge via ACP?
Registeret omfattede omkring 50 agenter i juni 2026, herunder Codex CLI, Claude Agent, Gemini CLI og JetBrains’ egen Junie. Listen vokser løbende, efterhånden som flere leverandører implementerer protokollen.
Koster det noget at bruge ACP?
Selve protokollen er gratis og åben. Man betaler stadig for adgang til de underliggende agenter og modeller, ACP forbinder til, på samme måde som man i dag betaler for Copilot-, Claude Code- eller Cursor-abonnementer uafhængigt af, hvilken editor man bruger dem i.
Bør mit team satse på ACP nu eller vente?
Hvis teamet allerede bruger Zed eller et JetBrains-IDE, er ACP i praksis allerede en del af arbejdsgangen. For teams centreret om Visual Studio eller VS Code er det fornuftigt at eksperimentere på sideprojekter, mens man venter på, at både protokollen og de konkrete integrationer forlader preview-status.
