Problemet ingen af protokollerne løser alene

Problemet ingen af protokollerne løser alene

Før standarderne var enhver AI-til-værktøj- og AI-til-agent-forbindelse et N×M-problem: N agenter, M værktøjer og andre agenter, og en skræddersyet integration for hvert par. Det er det samme integrationshelvede, der har plaget virksomhedssoftware i årtier, blot med LLM'er i spil.

MCP løser den vertikale halvdel af dette — at forbinde et enkelt AI-system til de data og værktøjer, det har brug for: filsystemer, databaser, kodearkiver, API'er [1][4]. Anthropic lancerede det i november 2024 som en klient-server-arkitektur og sammenlignede det eksplicit med USB-C: én standardforbindelse i stedet for et forskelligt kabel til hver enhed [6]. Det virkede. Der findes nu tusindvis af MCP-servere med SDK'er på tværs af alle større programmeringssprog, og protokollen blev doneret til den nyoprettede Agentic AI Foundation i december 2025 for at sikre, at den forbliver leverandøruafhængig [4].

A2A løser den horisontale halvdel — hvordan én agent finder, taler med og uddelegerer arbejde til en anden agent, uanset hvem der har bygget den, eller hvilket framework den kører på [2][5]. Google annoncerede A2A i april 2025 med mere end 50 lanceringspartnere, herunder Atlassian, LangChain, SAP og Salesforce [8]. Budskabet var lige på og hårdt: agenter bygget af forskellige leverandører på forskellige teknologistakke har brug for et fælles håndtryk, ellers fragmenteres økosystemet, før det overhovedet kommer i gang.

Som en analyse af økosystemet formulerede det, udgør de to protokoller "de to lag i rygraden i risikostyrede, skalerbare agentiske økosystemer" [7]. Det er ikke markedsføringssnak — det er en præcis beskrivelse af, hvad der faktisk bliver implementeret. MCP giver en agent dens værktøjer. A2A giver den agent et team.

Hvordan produktionsimplementeringer faktisk ser ud

Spring legetøjseksemplerne over et øjeblik, og se på, hvad der reelt bliver leveret. A2A har nu dokumenteret brug i produktion i virksomheder, ikke blot pilotprojekter — Tyson Foods kører agentkoordinering på tværs af forsyningskædeoperationer, og protokollen har fået understøttelse i AWS, Google Cloud, IBM og Microsofts cloudplatforme [3].

Det mønster, der bliver ved med at dukke op: en planlægger- eller orkestreringsagent sidder øverst, modtager et mål og bryder det ned i delopgaver. Den udfører ikke selv arbejdet — den uddelegerer via A2A til specialiserede agenter (en research-agent, en skrive-agent, en dataanalyse-agent), som hver især bruger MCP til at hente de faktiske værktøjer og den kontekst, de har brug for for at udføre opgaven [7].

Dette er hub-and-spoke-mønsteret, og det er den dominerende arkitektur i 2026 af gode grunde: det er lettere at sikre, lettere at fejlsøge og lettere at ræsonnere om fejl end et fuldt peer-to-peer-netværk af agenter, der alle taler direkte med hinanden [7]. Hierarkisk uddelegering afspejler også klart, hvordan reelle organisationer allerede fungerer, hvilket næppe er en tilfældighed.

A2A's version 0.3-udgivelse tilføjede understøttelse af gRPC og "sikkerhedskort" — struktureret metadata, der lader en agent annoncere sine kapabiliteter og tillidsgrænser, før en anden agent overdrager en opgave til den [3]. Det er det ukarismatiske infrastrukturarbejde, der får virksomheders juridiske og sikkerhedsafdelinger til at godkende multi-agent-systemer i stedet for at blokere dem.

Hvorfor standarderne slår alternativet

Det er værd at være eksplicit om alternativet, fordi "byg bare skræddersyede integrationer" stadig er det, de fleste teams falder tilbage på — og det er stadig en fejl i stor skala.

Uden en fælles protokol kræver hver agent-til-agent-forbindelse skræddersyet autentificering, skræddersyede skemaer og skræddersyet fejlhåndtering. Tilføj en tredje agent til din pipeline, og din integrationsflade vokser ikke lineært — den vokser kombinatorisk. Det er præcis den fejlmåde, MCP og A2A blev designet til at forhindre [4][7].

Den anden risiko er siloer: teams, der bygger agentsystemer, som fungerer smukt isoleret, men ikke kan tale med noget uden for deres eget teknologistack. Forbes kaldte MCP "et stort skridt i udviklingen af AI-agenter" tilbage i slutningen af 2024, specifikt fordi den løste dette — ved at give Claude (og senere enhver kompatibel model) en standardmåde at nå eksterne systemer på i stedet for at kræve en ny skræddersyet forbindelse for hver eneste integration [6].

Google formulerede A2A på lignende vis ved lanceringen: "en ny æra for interoperabilitet mellem agenter," bevidst designet, så agenter fra konkurrerende leverandører stadig kunne samarbejde [2]. Det er reelt et usædvanligt træk — et stort AI-laboratorium, der open-sourcer en protokol, som bevidst gør det lettere for en Google-agent at arbejde sammen med en Anthropic-agent eller en hjemmebygget virksomhedsagent. Det skete, fordi alle i branchen erkendte, at et fragmenteret agentøkosystem ikke gavner nogen, heller ikke platformsleverandørerne.

Den praktiske pointe: hvis du overvejer, om du skal standardisere nu eller senere, er senere dyrere. Enhver skræddersyet integration, du bygger i dag, er teknisk gæld, du skal afvikle, når — ikke hvis — du har brug for at koble en ny agent, et nyt værktøj eller en ny leverandør på.

En bygherres blueprint: Start med MCP, læg A2A ovenpå

Hvis du bygger et multi-agent-system i 2026, er rækkefølgen, der bliver ved med at dukke op i succesfulde implementeringer, ligetil.

Trin ét: få din værktøjsadgang på plads med MCP først. Før du bekymrer dig om flere agenter, sørg for at én enkelt agent pålideligt kan læse dine databaser, ramme dine API'er og interagere med dine filsystemer gennem MCP-servere. Dette er det ukarismatiske fundament — og at springe det over for at hoppe direkte til "multi-agent-orkestrering" er den mest almindelige fejl, vi ser. En orkestrator, der koordinerer fem agenter, som hver har en ustabil værktøjsadgang, er fem gange fejlfladen, ikke fem gange kapaciteten.

Trin to: definér dit uddelegeringshierarki, før du skriver orkestreringskode. Beslut, om du har brug for hub-and-spoke (én planlægger, flere specialistagenter) eller en fladere peer-struktur. For de fleste forretningsarbejdsgange — indholdspipelines, dataanalyse, kundeoperationer — vinder hub-and-spoke, fordi det er revisionsvenligt. Du kan spore præcis, hvilken agent der traf hvilken beslutning, og hvorfor [7].

Trin tre: tilføj A2A til overdragelserne, og behandl skemaer som beskyttelsesbarrierer, ikke papirarbejde. "Sikkerhedskortene" og tilladelsesstrukturerne i A2A er ikke bureaukratisk ballast — de er det, der lader dig begrænse, hvad en delegeret agent faktisk må gøre med opgaven, den har fået overdraget [3]. At springe dette trin over er, hvordan du ender med en agent, der stille og roligt overskrider sit tilsigtede omfang, hvilket er et langt sværere problem at fejlsøge bagefter end at forebygge på forhånd.

Trin fire: instrumentér alt. Fejl i multi-agent-systemer er sjældent dramatiske — de er normalt stille tab af kontekst mellem overdragelser. En agent opsummerer for aggressivt, taber en begrænsning, og den efterfølgende agent udfører selvsikkert på ufuldstændig information. At logge hvert MCP-kald og hver A2A-overdragelse er ikke valgfrit, hvis du kører dette i produktion; det er den eneste måde at fange denne type fejl på, før en kunde gør det.

Reelle teams kører allerede dette mønster inden for finansoperationer, koordinering af forsyningskæder og indholdsproduktion — Tyson Foods-implementeringen er et af de mere synlige eksempler på, at A2A udfører reelt logistikarbejde snarere end at besvare demoprompts [3]. Mønsteret holder, uanset om du koordinerer tre interne agenter eller kobler dig på en partners agent på tværs af en organisatorisk grænse.

Hvad dette faktisk koster (og hvor værdien ligger)

Det ærlige svar til bygherren her er: standardisering har en forudgående afgift og en langsigtet rabat. At tage MCP og A2A i brug betyder at lære specifikke protokolkonventioner i stedet for at skrive hvad som helst skræddersyet kode, der føles hurtigst i dag. Det er reel friktion, især for et lille team, der forsøger at levere en MVP på en uge.

Men regnestykket vender hurtigt, når du har brug for at tilføje et andet værktøj, en anden agent eller et andet teammedlem, der skal vedligeholde tingen, efter du er gået videre. Et protokolbaseret system er læsbart — en anden person kan se på din MCP-serverkonfiguration og din A2A-uddelegeringsgraf og forstå systemet uden at skulle reverse-engineere din skræddersyede orkestreringslogik.

Der er også et økosystemudbytte, der forrentes over tid. Fordi der allerede findes tusindvis af MCP-servere til almindelige værktøjer og databaser, er en enorm del af dit "integrationsarbejde" nu bare konfiguration, ikke udvikling [4]. Det samme begynder at ske med A2A-kompatible agenter, efterhånden som flere leverandører leverer dem indbygget i stedet for at kræve skræddersyede adaptere [3][8].

For iværksættere og tekniske ledere, der skal beslutte, hvor de vil bruge ingeniørtid i anden halvdel af 2026: det mest udbytterige træk er ikke at bygge en klogere agent. Det er at bygge koordineringslaget korrekt fra start, ved at bruge de protokoller, resten af branchen allerede har lagt sig fast på — for du kommer til at koble dig på en andens agent eller værktøj før, end din køreplan i øjeblikket antager.

Det større skifte: Dømmekraft rykker længere op i stakken

Her er, hvad der reelt sker under tallene for protokoladoption. Når integration bliver standardiseret — når det at forbinde til et værktøj eller uddelegere til en anden agent bliver et løst, kommercialiseret problem — stopper konkurrencefordelen med at være "vi byggede integrationen" og begynder i stedet at være hvad du fortæller systemet at gøre, og hvordan du begrænser det.

Det er skiftet-efter-kode i miniature. MCP og A2A gjorde ikke AI-agenter klogere. De gjorde VVS'en usynlig, hvilket skubber al den resterende værdi op i de beslutninger, der altid har været menneskelige: hvilke agenter der skal bygges, hvilke grænser de skal have, hvordan "godt" ser ud for en given opgave, og hvornår man skal stole på outputtet i stedet for at gribe ind.

Kode — i dette tilfælde integrationskode — bliver gratis, præcis så kommercialiseret som sloganet antyder. Det, der er tilbage, og det, der bliver sværere at forfalske, er dømmekraft: arkitekturbeslutningerne, beskyttelsesbarriererne, fornemmelsen for, hvornår et hub-and-spoke-system er det rigtige valg, og hvornår det ikke er. De teams, der vinder med multi-agent-systemer i 2026, er ikke dem med de mest snedige prompts. Det er dem, der behandlede orkestrering som det infrastrukturproblem, det er, tog standarderne i brug tidligt og brugte deres resterende tid på de dele af systemet, der faktisk kræver, at et menneske træffer beslutningen.

Det er den grænse, det er værd at holde øje med — ikke om AI-agenter kan koordinere, men hvem der bliver god nok til at styre dem, så det holder op med at være bemærkelsesværdigt.

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