Problemet ingen av protokollene løser alene

Problemet ingen av protokollene løser alene

Før standardene var enhver forbindelse mellom AI og verktøy, og mellom AI og agenter, et N×M-problem: N agenter, M verktøy og andre agenter, og en skreddersydd integrasjon for hvert par. Det er det samme integrasjonshelvetet som har plaget bedriftsprogramvare i tiår, bare med LLM-er i miksen.

MCP løser den vertikale halvparten av dette — å koble et enkelt AI-system til dataene og verktøyene det trenger: filsystemer, databaser, kodearkiver, API-er [1][4]. Anthropic lanserte det i november 2024 som en klient-server-arkitektur, og sammenlignet det eksplisitt med USB-C: én standard kontakt i stedet for en egen kabel for hver enhet [6]. Det fungerte. Tusenvis av MCP-servere finnes nå, med SDK-er på tvers av alle større programmeringsspråk, og protokollen ble donert til den nyopprettede Agentic AI Foundation i desember 2025 for å sikre at den forblir leverandørnøytral [4].

A2A løser den horisontale halvparten — hvordan én agent finner, kommuniserer med og delegerer arbeid til en annen agent, uavhengig av hvem som har bygget den eller hvilket rammeverk den kjører på [2][5]. Google annonserte A2A i april 2025 med mer enn 50 lanseringspartnere, inkludert Atlassian, LangChain, SAP og Salesforce [8]. Budskapet var rett fram: agenter bygget av ulike leverandører, på ulike stacker, trenger et felles håndtrykk, ellers fragmenteres økosystemet før det har startet.

Som én analyse av økosystemet formulerte det, utgjør de to protokollene "det to-lags ryggraden i risikostyrte, skalerbare agentiske økosystemer" [7]. Det er ikke markedsføringsprat — det er en presis beskrivelse av det som faktisk blir satt i produksjon. MCP gir en agent verktøyene sine. A2A gir den agenten et team.

Hvordan produksjonsimplementeringer faktisk ser ut

Se bort fra leke-eksemplene et øyeblikk og se på hva som faktisk leveres. A2A har nå dokumentert bruk i produksjon i bedrifter, ikke bare pilotprogrammer — Tyson Foods kjører agentkoordinering på tvers av forsyningskjededrift, og protokollen har fått støtte i skyplattformene til AWS, Google Cloud, IBM og Microsoft [3].

Mønsteret som stadig dukker opp: en planlegger- eller orkestratoragent sitter øverst, mottar et mål, og bryter det ned i delmål. Den utfører ikke arbeidet selv — den delegerer via A2A til spesialiserte agenter (en researchagent, en skriveagent, en dataanalyseagent), som hver bruker MCP til å hente de faktiske verktøyene og konteksten de trenger for å utføre oppgaven [7].

Dette er navmønsteret ("hub-and-spoke"), og det er den dominerende arkitekturen i 2026 av gode grunner: det er lettere å sikre, lettere å feilsøke, og lettere å resonnere om feil enn en fullstendig likeverdig ("peer-to-peer") sammensetning av agenter som alle snakker direkte med hverandre [7]. Hierarkisk delegering gjenspeiler også hvordan reelle organisasjoner allerede fungerer, noe som trolig ikke er tilfeldig.

A2A-versjon 0.3 la til støtte for gRPC og "sikkerhetskort" — strukturerte metadata som lar en agent annonsere sine egenskaper og tillitsgrenser før en annen agent overlater en oppgave til den [3]. Det er det ugjeve infrastrukturarbeidet som gjør at bedrifters juridiske avdelinger og sikkerhetsteam godkjenner multiagentsystemer i stedet for å blokkere dem.

Hvorfor standardene slår alternativet

Det er verdt å være tydelig på hva alternativet faktisk innebærer, for "bare bygg skreddersydde integrasjoner" er fortsatt det de fleste team faller tilbake på — og det er fortsatt en feil i stor skala.

Uten en felles protokoll krever hver forbindelse mellom agenter skreddersydd autentisering, skreddersydde skjemaer og skreddersydd feilhåndtering. Legg til en tredje agent i pipelinen din, og integrasjonsflaten din vokser ikke lineært — den vokser kombinatorisk. Dette er nøyaktig det feilmønsteret MCP og A2A ble designet for å forhindre [4][7].

Den andre risikoen er siloer: team som bygger agentsystemer som fungerer utmerket isolert, men som ikke kan kommunisere med noe utenfor sin egen stack. Forbes kalte MCP "et stort steg i utviklingen av AI-agenter" allerede sent i 2024, nettopp fordi det adresserte dette — det ga Claude (og senere, enhver kompatibel modell) en standardmåte å nå eksterne systemer på, i stedet for å kreve en ny skreddersydd kobling for hver eneste integrasjon [6].

Google beskrev A2A på lignende måte ved lanseringen: "en ny æra for agentinteroperabilitet," eksplisitt designet slik at agenter fra konkurrerende leverandører fortsatt kunne samarbeide [2]. Det er et genuint uvanlig trekk — et stort AI-laboratorium som åpner kildekoden til en protokoll som bevisst gjør det enklere for en Google-agent å samarbeide med en Anthropic-agent eller en hjemmesnekret bedriftsagent. Det skjedde fordi alle i bransjen erkjente at et fragmentert agentøkosystem ikke gagner noen, inkludert plattformleverandørene selv.

Den praktiske konklusjonen: Hvis du vurderer om du skal standardisere nå eller senere, er senere dyrere. Hver skreddersydde integrasjon du bygger i dag, er teknisk gjeld du må rydde opp i når — ikke hvis — du trenger å koble til en ny agent, et nytt verktøy eller en ny leverandør.

En byggers blåkopi: Start med MCP, legg til A2A

Hvis du bygger et multiagentsystem i 2026, er rekkefølgen som stadig dukker opp i vellykkede implementeringer, ganske enkel.

Steg én: få verktøytilgangen din på plass med MCP først. Før du bekymrer deg om flere agenter, sørg for at én enkelt agent pålitelig kan lese databasene dine, treffe API-ene dine og samhandle med filsystemene dine gjennom MCP-servere. Dette er det ugjeve fundamentet — og å hoppe over det for å gå rett til "multiagentorkestrering" er den vanligste enkeltfeilen vi ser. En orkestrator som koordinerer fem agenter som hver har ustabil verktøytilgang, er fem ganger så mye feiloverflate, ikke fem ganger så mye kapasitet.

Steg to: definer delegeringshierarkiet ditt før du skriver orkestreringskode. Bestem om du trenger navmønster (én planlegger, flere spesialistagenter) eller en flatere peer-struktur. For de fleste forretningsarbeidsflyter — innholdspipeliner, dataanalyse, kundedrift — vinner navmønsteret fordi det er sporbart. Du kan spore nøyaktig hvilken agent som tok hvilken beslutning og hvorfor [7].

Steg tre: legg til A2A for overleveringene, og behandle skjemaer som sikringsmekanismer, ikke papirarbeid. "Sikkerhetskortene" og tillatelsesstrukturene i A2A er ikke byråkratisk merarbeid — de er det som lar deg begrense hva en delegert agent faktisk har lov til å gjøre med oppgaven den mottar [3]. Å hoppe over dette steget er hvordan man ender opp med en agent som stille overskrider sitt tiltenkte omfang, noe som er et mye vanskeligere problem å feilsøke i etterkant enn å forhindre på forhånd.

Steg fire: instrumenter alt. Feil i multiagentsystemer er sjelden dramatiske — de er som regel stille kontekst-tap mellom overleveringer. En agent oppsummerer for aggressivt, mister en begrensning, og den nedstrøms agenten utfører oppgaven trygt basert på ufullstendig informasjon. Logging av hvert MCP-kall og hver A2A-overlevering er ikke valgfritt hvis du kjører dette i produksjon; det er den eneste måten å fange denne typen feil før en kunde gjør det.

Reelle team kjører allerede dette mønsteret innen finansdrift, koordinering av forsyningskjeder og innholdsproduksjon — Tyson Foods-implementeringen er et av de mer synlige eksemplene på at A2A gjør reelt logistikkarbeid i stedet for å svare på demoprompter [3]. Mønsteret holder enten du koordinerer tre interne agenter eller kobler deg til en partners agent på tvers av en organisasjonsgrense.

Hva dette faktisk koster (og hvor verdien ligger)

Det ærlige svaret for en bygger her er: standardisering har en innledende skatt og en langsiktig rabatt. Å ta i bruk MCP og A2A betyr å lære spesifikke protokollkonvensjoner i stedet for å skrive hvilken som helst skreddersydd kode som føles raskest akkurat nå. Det er reell friksjon, spesielt for et lite team som prøver å levere en MVP på en uke.

Men regnestykket snur raskt så snart du trenger å legge til et andre verktøy, en ny agent, eller et nytt teammedlem som må vedlikeholde dette etter at du har gått videre. Et protokollbasert system er lesbart — noen andre kan se på MCP-serverkonfigurasjonen din og A2A-delegeringsgrafen din og forstå systemet uten å måtte reversere din skreddersydde orkestreringslogikk.

Det finnes også en økosystemgevinst som forsterker seg over tid. Fordi tusenvis av MCP-servere allerede finnes for vanlige verktøy og databaser, er en stor del av "integrasjonsarbeidet" ditt nå bare konfigurering, ikke utvikling [4]. Det samme begynner å skje med A2A-kompatible agenter etter hvert som flere leverandører leverer dem native i stedet for å kreve skreddersydde adaptere [3][8].

For gründere og tekniske ledere som skal bestemme hvor de skal bruke ingeniørtid i andre halvdel av 2026: det trekket med høyest gevinst er ikke å bygge en smartere agent. Det er å bygge koordineringslaget riktig fra første stund, ved å bruke protokollene resten av bransjen allerede har konvergert rundt — for du kommer til å koble deg til noen andres agent eller verktøy tidligere enn veikartet ditt for øyeblikket forutsetter.

Det store skiftet: Vurderingsevnen flyttes oppover i stacken

Her er hva som egentlig skjer under adopsjonstallene for protokollene. Når integrasjon blir standardisert — når det å koble til et verktøy eller delegere til en annen agent blir et løst, kommodifisert problem — slutter konkurransefortrinnet å være "vi bygde integrasjonen" og blir i stedet hva du ber systemet gjøre og hvordan du begrenser det.

Det er post-kode-skiftet i miniatyr. MCP og A2A gjorde ikke AI-agenter smartere. De gjorde rørleggerarbeidet usynlig, noe som skyver all den gjenværende verdien opp til beslutninger som alltid har vært menneskelige: hvilke agenter som skal bygges, hvilke grenser de skal få, hva som er "bra nok" for en gitt oppgave, og når man skal stole på resultatet versus gripe inn.

Kode — i dette tilfellet integrasjonskode — blir gratis, akkurat like kommodifisert som mantraet antyder. Det som er igjen, og det som blir vanskeligere å forfalske, er vurderingsevnen: arkitekturbeslutningene, sikringsmekanismene, følelsen for når et navmønster-system er riktig valg og når det ikke er det. Teamene som vinner med multiagentsystemer i 2026, er ikke de med de smarteste promptene. Det er de som behandlet orkestrering som det infrastrukturproblemet det er, tok i bruk standardene tidlig, og brukte den gjenværende tiden sin på delene av systemet som faktisk krever at et menneske tar en beslutning.

Det er det som er verdt å følge med på — ikke om AI-agenter kan koordinere seg, men hvem som blir god nok til å styre dem til at det slutter å være bemerkelsesverdig.

Sources

1. https://www.anthropic.com/news/model-context-protocol
2. https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/
3. https://www.linuxfoundation.org/press/a2a-protocol-surpasses-150-organizations-lands-in-major-cloud-platforms-and-sees-enterprise-production-use-in-first-year
4. https://cohorte.co/blog/comparing-anthropics-model-context-protocol-mcp-vs-googles-agent-to-agent-a2a-for-ai-agents-in-business-automation
5. https://en.wikipedia.org/wiki/Model_Context_Protocol
6. https://www.forbes.com/sites/janakirammsv/2024/11/30/why-anthropics-model-context-protocol-is-a-big-step-in-the-evolution-of-ai-agents/
7. https://www.digitalapplied.com/blog/ai-agent-protocol-ecosystem-map-2026-mcp-a2a-acp-ucp
8. https://medium.com/@yusufbaykaloglu/multi-agent-systems-orchestrating-ai-agents-with-a2a-protocol-19a27077aed8