To protokoller, to forskjellige jobber

To protokoller, to forskjellige jobber

Forvirringen rundt MCP og A2A oppstår som regel fordi man behandler dem som konkurrenter. Det er de ikke. De løser forskjellige problemer, og skillet er verdt å være presis om.

MCP er vertikal. Den styrer forholdet mellom en agent og dens verktøy, datakilder og kontekst — modell til maskin. Anthropic lanserte den mot slutten av 2024 som en måte å standardisere hvordan LLM-er oppdager og kaller eksterne funksjoner: en database, et filsystem, et CRM-system, et internt API [1][3]. Før MCP var hver verktøyintegrasjon en skreddersydd adapter. MCP gjør dette til en protokoll — tenk på det som en USB-C-port for AI-verktøy i stedet for en skuff full av proprietære kabler [2][5].

A2A er horisontal. Den styrer hvordan autonome agenter samarbeider med andre agenter som likeverdige parter, ikke som verktøy som blir kalt [1][2]. Dette er laget som lar en planleggingsagent delegere en deloppgave til en spesialistagent bygget av et annet team, kjørende på et annet rammeverk, muligens eid av et annet selskap — og få et strukturert resultat tilbake uten at noen av partene trenger å kjenne til den andres interne oppbygning [3][6].

Den klare mentale modellen, som går igjen i nesten alle seriøse tekniske sammenligninger av de to: MCP kobler agenter til verktøy. A2A kobler agenter til agenter. [1][2][4] Google har vært tydelige på at A2A er ment å utfylle MCP, ikke erstatte den — de to var designet for å bygges oppå hverandre, ikke velges mellom [1].

Hvorfor dette skillet faktisk betyr noe for byggere

Her blir det praktisk. Hvis du bygger en enkelt agent som trenger å spørre en database, treffe et API og lese et regneark, kommer du langt med MCP alene. Det er flertallet av de "agentiske" produktene som ble lansert i 2024 og 2025 — en smart modell pakket rundt en håndfull verktøykall.

Men i det øyeblikket systemet ditt trenger flere spesialiserte agenter som jobber sammen — en researchagent, en kodeagent, en QA-agent, en distribusjonsagent — treffer du en vegg MCP ikke var designet for. MCP behandler verktøy som passive: de svarer på kall, de har ikke egne mål eller autonomi [1]. A2A antar det motsatte: at det som er på den andre siden, er en autonom likeverdig part med sin egen resonneringssløyfe, sin egen tilstand, og potensielt sin egen eier [1][2].

Dette er et sikkerhets- og arkitekturskille, ikke bare et semantisk et. MCPs tillitsmodell er bygget rundt at en klient autoriserer tilgang til et verktøy. A2As tillitsmodell må ta høyde for forhandlinger med et annet autonomt system som kan ta beslutninger du ikke fullt ut kan inspisere [2][3]. Byggere som visker ut dette skillet, ender enten opp med å overingeniørere enkle verktøykall med agent-forhandlingsoverhead, eller undersikre reelle agent-til-agent-overleveringer ved å behandle dem som enkle API-kall.

Det praktiske rådet: kartlegg systemet ditt først. Spør hvilke deler som er «agenten trenger en funksjon» (MCP) versus «agenten trenger å delegere arbeid til en annen autonom enhet» (A2A). De fleste produksjonssystemer trenger begge deler, i lag.

Referansearkitekturen: Orkestrator, spesialister, verktøy

Mønsteret som vokser frem på tvers av seriøse produksjonsimplementeringer, ser slik ut, og det er verdt å internalisere fordi det vil dukke opp i nesten ethvert agentisk system verdt å bygge de neste to årene [1][3]:

1. En orkestreringsagent mottar det overordnede målet — «onboard denne kunden», «lever denne funksjonen», «undersøk denne hendelsen».
2. Orkestratoren delegerer deloppgaver via A2A til spesialistagenter — en researchagent, en kodegenereringsagent, en compliance-sjekkende agent — hver av dem kan være bygget på helt ulike teknologistabler.
3. Hver spesialistagent bruker MCP til å nå sine egne verktøy: kodeagenten treffer en Git-server og en testkjører, compliance-agenten treffer en intern policydatabase, researchagenten treffer et søke-API og interne dokumenter.
4. Resultater flyter tilbake via A2A til orkestratoren, som setter sammen det endelige resultatet.

Dette er funksjonelt en liten organisasjon, kodet inn i en protokoll. Orkestratoren er lederen som ikke gjør arbeidet selv, men vet hvem som gjør det. Spesialistene er fagekspertene. MCP er hvordan hver ekspert får tilgang til sitt eget arkivskap; A2A er hvordan lederen fordeler arbeid og får tilbakemeldinger [1][3][6].

En undervurdert implikasjon: denne arkitekturen er leverandøragnostisk av design. Orkestratoren din trenger ikke å vite om kodegenereringsspesialisten er bygget på Claude, GPT, Gemini eller en finjustert åpen modell — den trenger bare et velformet A2A-svar. Det er en genuint ny mulighet. For to år siden betydde multimodell-systemer å vedlikeholde separat integrasjonskode for hver leverandør. Nå absorberer protokollaget denne kompleksiteten.

Slik ser det ut i praksis: Hva team faktisk bygger

Abstraksjonene over høres rene ut; produksjon er rotete, men mønsteret holder stikk. Noen konkrete eksempler verdt å kjenne til:

Koordinerte team av ingeniøragenter. I stedet for én monolittisk «kodeagent» som prøver å planlegge, skrive, teste og gjennomgå kode, deler team dette opp i A2A-tilkoblede spesialister: en planlegger som bryter ned oppgaven, en koder som implementerer, en gjennomgangsagent som sjekker mot stil- og sikkerhetsregler, og en testkjører som validerer. Hver spesialist når sine egne verktøy via MCP — gjennomgangsagenten kan treffe et statisk analyseverktøy, testkjøreren en CI-pipeline [1][3].

Orkestrering av bedriftens arbeidsflyter. Store organisasjoner med omfattende interne systemer (ERP, CRM, saksbehandling, HR) bruker MCP-servere som den standardiserte inngangsdøren til hvert system, og A2A for å la arbeidsflytagenter — si en «onboarding av ansatte»-agent — koordinere på tvers av avdelingsagenter som hver eier sitt fagområdes verktøy [3][4][6].

Desentraliserte, flerleverandør-agentøkosystemer. Dette er den mest spekulative, men mest betydningsfulle formen: agenter bygget av ulike selskaper, som kan oppdages og kalles via A2A, og som danner ad hoc-samarbeidskjeder. En logistikkagent fra én leverandør som forhandler med en tollagent for regelverksoverholdelse fra en annen, ingen av dem bygget av samme team, som koordinerer gjennom en delt protokoll i stedet for en delt kodebase [1][2].

Den siste er den egentlige gevinsten — og grunnen til at folk kaller dette «det agentiske internettet» i stedet for bare «agentorkestrering». Internett fungerte fordi HTTP ikke brydde seg om hvem som bygde serveren eller nettleseren. A2A satser på at samme dynamikk gjelder for agenter.

Økosystemet er allerede overfylt — og det er en styrke, ikke en svakhet

MCP og A2A er ikke de eneste forkortelsene i dette området. Økosystemkart fra 2026 viser allerede at ACP og UCP kommer inn i bildet, hver rettet mot tilstøtende problemer — oppdagelse av agentfunksjoner, universelle kontrollplan, og så videre [4]. Det er fristende å lese dette som fragmentering og få protokolltretthet før du har levert en eneste agent.

Motstå den impulsen. Dette er nøyaktig det som skjedde i alle tidligere protokollkriger — HTTP, SMTP og FTP eksisterte side om side fordi de løste forskjellige problemer, ikke fordi én vant. Signalet man bør følge med på, er ikke «hvilken protokoll vinner», men «hvilke protokoller får reell flerleverandøradopsjon uten at ett enkelt selskap kontrollerer spesifikasjonen». MCPs over 97 millioner nedlastinger og raske rammeverksuavhengige støtte (den støttes nå godt utover Anthropics eget økosystem) er det sterkeste beviset så langt på at en protokoll, ikke en plattform, vinner på dette laget [1][4].

For byggere er det praktiske rådet: bygg mot protokollen, ikke mot leverandøren. Hvis MCP-serveren din eller din A2A-kompatible agent er genuint protokollkonform, forsikrer du deg selv mot neste modelleverandørs månedens-smak-rammeverk. Team som hardkobler orkestreringslogikken sin til én leverandørs SDK, bygger opp den samme skjøre integrasjonsgjelden som MCP ble oppfunnet for å eliminere.

Standardvinkelen: Hvorfor dette resonnerer i Norden

Det er en grunn til at denne protokoll-først-tilnærmingen treffer godt i Nord-Europa. Nordisk teknologikultur har en lang institusjonell hukommelse for standarddrevet infrastruktur — fra telekom (GSM var en europeisk standardseier før den ble en markedsseier) til offentlige digitale ID-systemer som nordiske myndigheter bygde som delt infrastruktur snarere enn proprietære produkter.

Det instinktet — bygg det delte laget, la konkurransen skje ovenpå — er nøyaktig det samme veddemålet MCP og A2A gjør. Et nordisk ingeniørteam som vurderer agentisk AI i 2026, bør stille det samme spørsmålet som deres telekombransje-besteforeldre stilte om samtrafikkstandarder: lar denne protokollen oss konkurrere på dømmekraft og spesialisering, eller låser den oss inne i én leverandørs lukkede hage?

MCP og A2A, som åpne, flerleverandørstøttede protokoller, svarer per i dag riktig på det spørsmålet. Det er verdt å satse infrastruktur på, selv om — spesielt hvis — du er et mindre team som ikke kan overby de store aktørene på proprietære verktøy. Protokoll-først-infrastruktur er hvordan mindre, skarpere team holder seg i spillet mot selskaper med ti ganger så mange ingeniører.

Hva som endrer seg når agenter bygger programvaren

La oss ta et steg tilbake fra forkortelsene et øyeblikk. Det MCP og A2A egentlig gjør, er å gjøre «agentsystemarkitektur» til noe som ligner mer på distribuert systemteknikk enn på promptteknikk. Det er et større skifte enn det høres ut som.

De siste to årene har flaskehalsen i AI-produkter vært modellen: var den smart nok, hallusinerte den mindre, kunne den resonnere gjennom en lengre kjede av steg. Den flaskehalsen løser seg opp. Den nye flaskehalsen er koordinering — hvordan får du fem spesialiserte, autonome, av og til uforutsigbare agenter til å samarbeide pålitelig nok til å kunne lanseres i produksjon? Det er et protokoll- og arkitekturproblem, ikke et modellproblem.

Dette er den dypere versjonen av vår tese hos Up North AI: kode er gratis, dømmekraft er det ikke. MCP og A2A gjør det mekaniske arbeidet med å koble sammen agenter nesten gratis — et løst, standardisert problem, på samme måte som HTTP gjorde «hvordan to datamaskiner utveksler data» til et løst problem. Det som gjenstår, det som er verdifullt, er dømmekraft: hvilke spesialister som skal bygges, hvordan en arbeidsflyt skal dekomponeres, når man skal stole på en agents resultat versus rute det til menneskelig gjennomgang, og hvordan man designer orkestreringslogikken som gjør en samling kompetente agenter til et system som faktisk gjør noe nyttig.

Teamene som vinner denne neste fasen, vil ikke være de med de smarteste promptene. De vil være de som forstår orkestreringsarkitektur på samme måte som en god teknisk leder forstår organisasjonsdesign — vite når man skal sentralisere, når man skal delegere, og når man skal bygge en ny spesialist i stedet for å overbelaste en eksisterende. Protokollaget er i ferd med å bli en handelsvare. Dømmekraften om hvordan man bruker det, er det ikke. Det er hele spillet nå.

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