To protokoller, to forskellige opgaver

To protokoller, to forskellige opgaver

Forvirringen omkring MCP og A2A opstår typisk, fordi man behandler dem som konkurrenter. Det er de ikke. De løser forskellige problemer, og skellet er værd at være præcis omkring.

MCP er vertikal. Den styrer forholdet mellem en agent og dens værktøjer, datakilder og kontekst — model til maskine. Anthropic udgav den i slutningen af 2024 som en måde at standardisere, hvordan LLM'er opdager og kalder eksterne funktioner: en database, et filsystem, et CRM-system, et internt API [1][3]. Før MCP var hver værktøjsintegration en skræddersyet adapter. MCP gør det til en protokol — tænk på det som en USB-C-port til AI-værktøjer i stedet for en skuffe fuld af proprietære kabler [2][5].

A2A er horisontal. Den styrer, hvordan autonome agenter samarbejder med andre agenter som ligemænd, ikke som værktøjer, der bliver kaldt [1][2]. Det er dette lag, der gør det muligt for en planlægningsagent at uddelegere en delopgave til en specialistagent bygget af et andet team, kørende på et andet framework, muligvis ejet af en anden virksomhed — og få et struktureret resultat tilbage, uden at nogen af parterne behøver kende den andens interne opbygning [3][6].

Den enkle mentale model, der går igen på tværs af næsten alle seriøse tekniske sammenligninger af de to: MCP forbinder agenter med værktøjer. A2A forbinder agenter med agenter. [1][2][4] Google har været tydelige om, at A2A er tænkt som et supplement til MCP, ikke en erstatning — de to blev designet til at blive lagt oven på hinanden, ikke til at man skulle vælge mellem dem [1].

Hvorfor denne skelnen faktisk betyder noget for udviklere

Her bliver det praktisk. Hvis du bygger en enkelt agent, der skal forespørge en database, ramme et API og læse et regneark, kan MCP alene bringe dig i mål. Det er, hvad størstedelen af de "agentbaserede" produkter, der blev lanceret i 2024 og 2025, faktisk var — en smart model pakket ind om en håndfuld værktøjskald.

Men i det øjeblik dit system har brug for flere specialiserede agenter, der arbejder sammen — en research-agent, en kodeagent, en QA-agent, en deployment-agent — støder du på en mur, som MCP ikke var designet til at håndtere. MCP behandler værktøjer som passive: de reagerer på kald, de har ikke deres egne mål eller autonomi [1]. A2A antager det modsatte: at det, der er i den anden ende, er en autonom ligemand med sin egen ræsonnementsløkke, sin egen tilstand og potentielt sin egen ejer [1][2].

Dette er et sikkerheds- og arkitekturmæssigt skel, ikke bare et semantisk et. MCP's tillidsmodel er bygget op om, at en klient godkender adgang til et værktøj. A2A's tillidsmodel skal derimod tage højde for forhandling med et andet autonomt system, der potentielt træffer beslutninger, du ikke fuldt ud kan inspicere [2][3]. Udviklere, der udvisker denne grænse, ender enten med at overengineere simple værktøjskald med agent-forhandlingsoverhead, eller med at undersikre reelle agent-til-agent-overdragelser ved at behandle dem som simple API-kald.

Den praktiske pointe: kortlæg dit system først. Spørg, hvilke dele der handler om "agenten har brug for en funktion" (MCP) versus "agenten skal uddelegere arbejde til en anden autonom enhed" (A2A). De fleste produktionssystemer har brug for begge dele, lagdelt.

Referencearkitekturen: orkestrator, specialister, værktøjer

Mønstret, der dukker op på tværs af seriøse produktionsimplementeringer, ser sådan ud, og det er værd at tilegne sig, for det vil dukke op i næsten ethvert agentbaseret system, der er værd at bygge i løbet af de næste to år [1][3]:

1. En orkestrator-agent modtager det overordnede mål — "onboard denne kunde," "lever denne feature," "undersøg denne hændelse."
2. Orkestratoren uddelegerer delopgaver via A2A til specialistagenter — en research-agent, en kodegenereringsagent, en compliance-tjekkende agent — som hver især kan være bygget på helt forskellige teknologistakke.
3. Hver specialistagent bruger MCP til at nå ind i sine egne værktøjer: kodeagenten rammer en Git-server og en test-runner, compliance-agenten rammer en intern politikdatabase, research-agenten rammer et søge-API og interne dokumenter.
4. Resultater flyder tilbage op gennem A2A til orkestratoren, som sammensætter det endelige output.

Dette er funktionelt en lille organisation, kodet ind i en protokol. Orkestratoren er lederen, der ikke selv udfører arbejdet, men ved, hvem der gør. Specialisterne er domæneeksperterne. MCP er den måde, hver ekspert tilgår sit arkivskab på; A2A er den måde, lederen fordeler arbejde og modtager rapporter på [1][3][6].

En underprioriteret implikation: denne arkitektur er leverandøruafhængig af design. Din orkestrator behøver ikke vide, om kodegenereringsspecialisten er bygget på Claude, GPT, Gemini eller en finjusteret open source-model — den har blot brug for et velformet A2A-svar. Det er en genuint ny egenskab. For to år siden betød multi-model-systemer, at man skulle vedligeholde separat integrationskode for hver eneste udbyder. Nu absorberer protokollaget den kompleksitet.

Virkelighedens form: Hvad teams faktisk bygger

Abstraktionerne ovenfor lyder enkle; virkeligheden i produktion er mere rodet, men mønstret holder. Nogle konkrete eksempler er værd at kende:

Koordinerede engineering-teams af agenter. I stedet for én monolitisk "kodeagent", der forsøger at planlægge, skrive, teste og gennemgå kode, deler teams dette op i A2A-forbundne specialister: en planlægger, der nedbryder opgaven, en kodeagent, der implementerer, en reviewer, der tjekker op mod stil- og sikkerhedsregler, og en test-runner, der validerer. Hver specialist tilgår sine egne værktøjer via MCP — revieweren rammer måske et statisk analyseværktøj, test-runneren en CI-pipeline [1][3].

Orkestrering af virksomhedsworkflows. Store organisationer med vidtforgrenede interne systemer (ERP, CRM, ticketing, HR) bruger MCP-servere som den standardiserede indgang til hvert system, og A2A til at lade workflow-agenter — for eksempel en "medarbejderonboarding"-agent — koordinere på tværs af afdelingsagenter, der hver især ejer deres domænes værktøjer [3][4][6].

Decentraliserede, multi-leverandør agent-økosystemer. Dette er den mest spekulative, men samtidig mest betydningsfulde form: agenter bygget af forskellige virksomheder, der kan opdages og kaldes via A2A, og som danner ad hoc-samarbejdskæder. En logistikagent fra én leverandør, der forhandler med en toldcompliance-agent fra en anden, hvor ingen af dem er bygget af det samme team, men koordinerer gennem en fælles protokol frem for en fælles kodebase [1][2].

Sidstnævnte er den egentlige gevinst — og grunden til, at folk kalder det "den agentbaserede internet" frem for blot "agent-orkestrering." Internettet fungerede, fordi HTTP var ligeglad med, hvem der byggede serveren eller browseren. A2A satser på, at den samme dynamik gælder for agenter.

Økosystemet er allerede tæt befolket — og det er en fordel, ikke en fejl

MCP og A2A er ikke de eneste forkortelser på dette område. Økosystemkort fra 2026 viser allerede, at ACP og UCP er kommet ind i billedet, hver især rettet mod tilstødende problemer — opdagelse af agentfunktioner, universelle kontrolplaner og så videre [4]. Det er fristende at læse dette som fragmentering og få protokoltræthed, før man overhovedet har lanceret en eneste agent.

Modstå den impuls. Dette er præcis, hvad der skete i enhver tidligere protokolkrig — HTTP, SMTP og FTP eksisterede side om side, fordi de løste forskellige problemer, ikke fordi den ene vandt. Det, man skal holde øje med, er ikke "hvilken protokol vinder," men "hvilke protokoller opnår reel multi-leverandør-adoption uden at én virksomhed kontrollerer specifikationen." MCP's over 97 millioner downloads og hurtige support på tværs af frameworks (den understøttes nu langt ud over Anthropics eget økosystem) er det stærkeste bevis hidtil på, at det er en protokol, ikke en platform, der vinder på dette lag [1][4].

For udviklere er det praktiske råd: byg til protokollen, ikke til leverandøren. Hvis din MCP-server eller A2A-kompatible agent er genuint protokolkonform, forsikrer du dig selv mod den næste modeludbyders modeluner. Teams, der hardkoder deres orkestreringslogik til én leverandørs SDK, genopbygger den samme skrøbelige integrationsgæld, som MCP blev opfundet for at eliminere.

Standardvinklen: Hvorfor dette giver genklang i Norden

Der er en grund til, at denne protokolførst-tilgang lander godt i Nordeuropa. Den nordiske tech-kultur har en lang institutionel hukommelse for standarddrevet infrastruktur — fra telekommunikation (GSM var en europæisk standardsejr, før den var en markedssejr) til offentlige digitale ID-systemer, som de nordiske regeringer byggede som fælles infrastruktur frem for proprietære produkter.

Den instinktive tilgang — byg det fælles lag, lad konkurrencen ske ovenpå — er præcis det, MCP og A2A satser på. Et nordisk udviklingsteam, der evaluerer agentbaseret AI i 2026, bør stille sig selv det samme spørgsmål, som deres bedsteforældre i telekombranchen stillede om samtrafikstandarder: giver denne protokol os mulighed for at konkurrere på dømmekraft og specialisering, eller låser den os fast i én leverandørs lukkede have?

MCP og A2A, som åbne, multi-leverandør-understøttede protokoller, besvarer i øjeblikket det spørgsmål på den rigtige måde. Det er værd at satse infrastruktur på — selv, eller især, hvis du er et mindre team, der ikke kan overbyde de store techgiganter på proprietær tooling. Protokolførst-infrastruktur er den måde, mindre og skarpere teams kan blive i konkurrencen mod virksomheder med ti gange så mange udviklere.

Hvad ændrer sig, når agenter bygger softwaren

Lad os for et øjeblik lægge forkortelserne til side. Det, MCP og A2A i virkeligheden gør, er at forvandle "agentsystemarkitektur" til noget, der ligner distribueret systemudvikling mere end prompt-engineering. Det er et større skifte, end det lyder.

De sidste to år har flaskehalsen i AI-produkter været modellen: var den smart nok, hallucinerede den mindre, kunne den ræsonnere gennem en længere kæde af trin. Den flaskehals er ved at løsne sig. Den nye flaskehals er koordinering — hvordan får man fem specialiserede, autonome, til tider uforudsigelige agenter til at samarbejde tilstrækkeligt pålideligt til at kunne sendes i produktion? Det er et protokol- og arkitekturproblem, ikke et modelproblem.

Dette er den dybere version af vores tese hos Up North AI: kode er gratis, dømmekraft er det ikke. MCP og A2A gør det mekaniske arbejde med at forbinde agenter næsten gratis — et løst, standardiseret problem, ligesom HTTP gjorde "hvordan udveksler to computere data" til et løst problem. Det, der er tilbage, det, der har værdi, er dømmekraft: hvilke specialister man skal bygge, hvordan man nedbryder et workflow, hvornår man skal stole på en agents output versus sende det til menneskelig gennemgang, og hvordan man designer den orkestreringslogik, der forvandler en bunke kompetente agenter til et system, der faktisk udretter noget nyttigt.

De teams, der vinder denne næste fase, bliver ikke dem med de mest snedige prompts. Det bliver dem, der forstår orkestreringsarkitektur på samme måde, som en god engineering-leder forstår organisationsdesign — og som ved, hvornår man skal centralisere, hvornår man skal uddelegere, og hvornår man skal bygge en ny specialist frem for at overbelaste en eksisterende. Protokollaget bliver en standardvare. Dømmekraften om, hvordan man bruger det, bliver det ikke. Det er hele spillet nu.

Sources

1. https://www.gravitee.io/blog/googles-agent-to-agent-a2a-and-anthropics-model-context-protocol-mcp
2. https://guptadeepak.com/a-comparative-analysis-of-anthropics-model-context-protocol-and-googles-agent-to-agent-protocol/
3. https://www.teneo.ai/blog/mcp-and-a2a-protocols-explained-the-future-of-agentic-ai-is-here
4. https://www.digitalapplied.com/blog/ai-agent-protocol-ecosystem-map-2026-mcp-a2a-acp-ucp
5. https://cloudedponderings.medium.com/a-deep-dive-into-model-context-protocol-mcp-and-agent-to-agent-a2a-communication-for-advanced-f65b3ac016ea
6. https://www.linkedin.com/posts/leadgenmanthan_2026-is-the-year-of-anthropics-mcp-and-googles-activity-7458489686131474432-1rqC