Hvorfor disse to protokollene vant standardkrigen

Hvorfor disse to protokollene vant standardkrigen

Protokolllandskapet så kaotisk ut tidlig i 2025. Anthropics MCP fikk fotfeste for verktøytilgang. Googles A2A lovet agentkoordinering. Mindre aktører presset på med ACP (Agent Communication Protocol) og ANP (Agent Network Protocol). ArXiv-undersøkelsen fra mai 2025 talte fire store konkurrerende standarder [5].

Gjennombruddet kom da utviklere innså at dette ikke var konkurrerende protokoller—de var komplementære lag. Som ISG-analytiker David Menninger sa det: "MCP først for å dele kontekst; deretter A2A for dynamisk interaksjon mellom agenter" [1].

MCP, åpen kildekode fra Anthropic i november 2024 og donert til Linux Foundation i desember 2025, håndterer "agent-til-verktøy"-laget. Det standardiserer hvordan AI-agenter får tilgang til APIer, databaser, filsystemer og eksterne tjenester gjennom et rent JSON-RPC 2.0-grensesnitt [1][3].

A2A, lansert av Google i april 2025 og donert til åpen styring i juni 2025, administrerer "agent-til-agent"-laget. Det håndterer oppdagelse, koordinering, oppgavedelegering og orkestrering på tvers av leverandører [4][7].

Arbeidsdelingen er elegant: MCP kobler agenter til verden, A2A kobler agenter til hverandre.

MCP: Ditt grunnlag for verktøytilgang

Start med MCP. Alle store plattformer støtter nå MCP-servere, og med over 10 000 servere i bruk bygger du ikke infrastruktur—du kobler deg til den [1].

MCPs arkitektur er bevisst enkel: klient-server JSON-RPC 2.0 over HTTP/SSE (Server-Sent Events). Agenter fungerer som klienter, verktøy eksponerer MCP-servere. Protokollen håndterer tre kjerneelementer: ressurser (datatilgang), verktøy (funksjonskall) og maler (kontekstmaler) [3][8].

Den virkelige kraften kommer frem i bedriftsimplementeringer. Hos Tyson Foods kobler MCP-servere AI-agenter til lagersystemer, forsyningskjede-APIer og produksjonsdatabaser. Adobe bruker MCP til å orkestrere kreative arbeidsflyter på tvers av flere AI-modeller og designverktøy [1].

Implementeringstips: Ikke bygg tilpassede MCP-servere med mindre du absolutt må. Økosystemet er modent nok til at de fleste bedriftsbehov dekkes av eksisterende servere. Fokuser utviklingsinnsatsen på forretningslogikken, ikke på infrastrukturen.

Sikkerhet skjer på MCP-laget gjennom Agent Cards—standardiserte identitets- og kapasitetserklæringer som følger med hver forespørsel. Tenk på dem som JWT-tokens for AI-agenter, som bærer autentisering, autorisasjon og revisjonsspor [1].

A2A: Orkestrering av agentsverm i stor skala

Når agentene dine kan få pålitelig tilgang til verktøy gjennom MCP, håndterer A2A koordineringskompleksiteten. Dette er hvor multi-agentsystemer går fra demoer til produksjon.

A2A løser tre vanskelige problemer: agentoppdagelse (hvordan finner agenter hverandre?), oppgavedelegering (hvordan deler du komplekst arbeid inn i agent-størrelser?) og orkestrering på tvers av leverandører (hvordan samarbeider Anthropic-, OpenAI- og Google-agenter?) [4][7].

Protokollen er tilstandsløs ved design, bruker HTTP som transportlag med standardiserte meldingsformater for forhandling, oppgavetildeling og resultatsammenstilling. I motsetning til tidligere agentkommmunikasjonsforsøk, prøver ikke A2A å være et meldingssystem—det er en koordineringsprotokoll [2][7].

Eksempel fra virkeligheten: Et nordisk logistikkselskap bruker A2A til å orkestrere etterspørselsprognoser. En agent henter salgsdata (via MCP), en annen kjører ML-modeller (via MCP), en tredje genererer rapporter (via MCP), og A2A koordinerer overleveringene, feilhåndtering og retry-logikk.

Nøkkelinnsikten: A2A handler ikke om at agenter snakker med hverandre konstant. Det handler om at agenter vet når og hvordan de skal delegere arbeid. De fleste agentinteraksjoner er korte koordineringsmeldinger, ikke utvidede samtaler.

Den fasevise implementeringsveien som faktisk fungerer

ArXiv-undersøkelsen fra mai 2025 foreslo en fire-fase adopsjonsvei: MCP → ACP → A2A → ANP [5]. I praksis hopper vellykkede implementeringer over mellomtrinnene og går rett til MCP + A2A.

Fase 1: MCP-grunnlag (Uke 1-4) Start med en enkelt agent som får tilgang til 2-3 kritiske verktøy gjennom MCP-servere. Fokuser på pålitelighet, feilhåndtering og overvåking. Ikke skaler før dette fungerer perfekt.

Fase 2: Multi-verktøy-integrasjon (Uke 5-8) Legg til flere MCP-servere. Bygg din Agent Card-sikkerhetsmodell. Etabler logging og revisjonsspor. Denne fasen ødelegger de fleste implementeringer—invester i observerbarhet.

Fase 3: A2A-koordinering (Uke 9-12) Introduser en andre agent. Bruk A2A for enkel oppgavedelegering. Start med synkrone overleveringer før du forsøker parallell utførelse.

Fase 4: Produksjonsorkestrering (Uke 13+) Skaler til flere agenter, komplekse arbeidsflyter og scenarier på tvers av leverandører. Dette er hvor den virkelige forretningsverdien kommer frem, men bare hvis fase 1-3 er steinsolide.

Kritisk innsikt fra nordiske implementeringer: Team som prøver å implementere MCP og A2A samtidig mislykkes. Protokollene er komplementære, men implementeringskompleksiteten er multiplikativ.

Sikkerhet og styring: Agent Cards og tillitsgrenser

Bedrifts-AI-orkestrering mislykkes uten ordentlige sikkerhetsmodeller. MCP + A2A-stakken adresserer dette gjennom Agent Cards—standardiserte identitetsdokumenter som bærer autentisering, kapasiteter og revisjonskontekst [1].

Agent Cards løser "confused deputy"-problemet i multi-agentsystemer. Når Agent A ber Agent B utføre en oppgave via A2A, vet Agent B nøyaktig hva Agent A er autorisert til å be om, hvilke data den kan få tilgang til, og hvordan interaksjonen skal logges for compliance.

Tillitsgrenser betyr noe. I praksis kjører de fleste bedrifter MCP-servere innenfor sin sikkerhetsperimeter og bruker A2A for koordinering på tvers av tillitssoner. Interne agenter kommuniserer fritt via A2A, men eksterne agentinteraksjoner krever eksplisitte godkjenningsarbeidsflyter.

Den tilstandsløse designen av begge protokoller hjelper med sikkerhetsrevisjon. Hver agentinteraksjon er en diskret HTTP-forespørsel med full kontekst i Agent Card. Ingen skjult tilstand, ingen persistente tilkoblinger som kan lekke data på tvers av sikkerhetsgrenser.

Nordisk perspektiv: GDPR-compliance er betydelig enklere med MCP + A2A fordi datalinjen er eksplisitt. Du kan spore nøyaktig hvilken agent som fikk tilgang til hvilke data, når og for hvilket formål.

Vanlige orkestreringsfall og hvordan du unngår dem

To år med produksjonsimplementeringer har avdekket forutsigbare feilmodi. Her er hva som går galt og hvordan du forhindrer det.

Fall 1: Sirkulære avhengigheter Agent A delegerer til Agent B, som delegerer tilbake til Agent A. A2A-protokollen forhindrer ikke dette—orkestreringslogikken din må gjøre det. Løsning: eksplisitte oppgavehierarkier og delegeringsdybdegrenser.

Fall 2: MCP-serveroverbelastning Populære MCP-servere blir flaskehalser når flere agenter hamrer på dem samtidig. Løsning: tilkoblingspooling, hastighetsbegrensning og kretsbrytere på MCP-klientnivå.

Fall 3: Feilpropageringskaskader En feilende agent bringer ned hele arbeidsflyten. Løsning: skottmønster i A2A-koordinering, med grasiøs degradering når agenter blir utilgjengelige.

Fall 4: Agent Card-oppblåsthet Team pakker for mye kontekst inn i Agent Cards, noe som skaper ytelse- og sikkerhetsproblemer. Løsning: minimale kort med just-in-time privilegieeskalering når nødvendig.

Det farligste fallet: å behandle agenter som mikrotjenester. Agenter er probabilistiske, ikke deterministiske. Orkestreringsmønstrene dine må ta høyde for usikkerhet, ikke eliminere den.

Hva som endres når AI bygger programvaren

MCP + A2A-stakken representerer noe dypere enn protokollstandardisering. Det er infrastrukturlaget for en verden hvor AI-systemer komponerer seg selv dynamisk i stedet for å være forhåndsprogrammert av mennesker.

Tradisjonell programvareorkestrering antar at du kjenner arbeidsflyten på forhånd. Kubernetes orkestrerer containere, men containerne og deres relasjoner er definert ved deploy-tid. MCP + A2A muliggjør runtime-komposisjon—agenter som oppdager kapasiteter, forhandler oppgavefordeling og tilpasser seg endrede krav uten menneskelig intervensjon.

Dette skifter byggerens rolle fra "programmering av arbeidsflyter" til "design av begrensninger." Du forteller ikke agenter nøyaktig hva de skal gjøre; du gir dem verktøy (via MCP), koordineringsmekanismer (via A2A) og grenser (via Agent Cards). Det faktiske arbeidet kommer frem fra agentinteraksjoner.

De nordiske bedriftene vi jobber med ser allerede dette skiftet. Deres AI-systemer håndterer forsyningskjedeforstyrrelser, kundeserviceeskaleringer og finansiell rapportering med minimal menneskelig tilsyn. Ikke fordi systemene er perfekt programmert, men fordi de kan omprogrammere seg selv innenfor trygge grenser.

Post-kode-æraen handler ikke om å eliminere programmerere—det handler om å løfte dem fra instruksjonsforfattere til systemdesignere. Kode blir gratis når AI kan generere den. Dømmekraft om hvilke systemer som skal bygges, hvordan de skal oppføre seg, og hvilke begrensninger de skal respektere—det er hvor menneskelig ekspertise forblir uerstattelig.

Kilder

1. https://www.digitalapplied.com/blog/ai-agent-protocol-ecosystem-map-2026-mcp-a2a-acp-ucp
2. https://dev.to/pockit_tools/mcp-vs-a2a-the-complete-guide-to-ai-agent-protocols-in-2026-30li
3. https://auth0.com/blog/mcp-vs-a2a/
4. https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/
5. https://arxiv.org/html/2505.02279v1
6. https://philippdubach.com/posts/mcp-vs-a2a-in-2026-how-the-ai-protocol-war-ends/
7. https://atlan.com/know/google-a2a-protocol/
8. https://zylos.ai/research/2026-02-15-agent-to-agent-communication-protocols/