Problemet som inget av protokollen löser på egen hand

Problemet som inget av protokollen löser på egen hand

Före standarderna var varje koppling mellan AI och verktyg, samt mellan AI och agent, ett N×M-problem: N agenter, M verktyg och andra agenter, och en skräddarsydd integration för varje par. Det är samma integrationshelvete som plågat företagsmjukvara i decennier, bara med LLM:er inblandade.

MCP löser den vertikala halvan av detta — att koppla ett enskilt AI-system till den data och de verktyg det behöver: filsystem, databaser, kodförvar, API:er [1][4]. Anthropic lanserade det i november 2024 som en klient-server-arkitektur, och jämförde det uttryckligen med USB-C: en standardkontakt istället för en egen kabel för varje enhet [6]. Det fungerade. Tusentals MCP-servrar finns nu, med SDK:er för alla större språk, och protokollet donerades till den nybildade Agentic AI Foundation i december 2025 för att säkerställa att det förblir leverantörsneutralt [4].

A2A löser den horisontella halvan — hur en agent hittar, kommunicerar med och delegerar arbete till en annan agent, oavsett vem som byggt den eller vilket ramverk den körs på [2][5]. Google presenterade A2A i april 2025 med fler än 50 lanseringspartners, inklusive Atlassian, LangChain, SAP och Salesforce [8]. Budskapet var rakt på sak: agenter byggda av olika leverantörer, på olika teknikstackar, behöver en gemensam handskakning, annars fragmenteras ekosystemet innan det ens kommer igång.

Som en ekosystemanalys uttryckte det, utgör de två protokollen "det tvålagersryggrad av riskhanterade, skalbara agentbaserade ekosystem" [7]. Det är inte marknadsföringssnack — det är en korrekt beskrivning av vad som faktiskt implementeras. MCP ger en agent dess verktyg. A2A ger den agenten ett team.

Hur produktionsdriftsättningar faktiskt ser ut

Hoppa över leksaksexemplen ett tag och titta på vad som faktiskt levereras. A2A har nu dokumenterad användning i produktion i stora företag, inte pilotprogram — Tyson Foods driver agentkoordinering över sina försörjningskedjeverksamheter, och protokollet har fått stöd i AWS, Google Cloud, IBM och Microsofts molnplattformar [3].

Mönstret som ständigt återkommer: en planerings- eller orkestreringsagent sitter i toppen, tar emot ett mål och bryter ner det i delmoment. Den utför inte själva arbetet — den delegerar via A2A till specialiserade agenter (en researchagent, en skrivagent, en dataanalysagent), som var och en använder MCP för att hämta de faktiska verktyg och den kontext den behöver för att utföra sin uppgift [7].

Detta är nav-och-eker-mönstret (hub-and-spoke), och det är den dominerande arkitekturen 2026 av goda skäl: det är enklare att säkra, enklare att felsöka och enklare att resonera kring fel än en helt jämlik (peer-to-peer) väv av agenter som alla kommunicerar direkt med varandra [7]. Hierarkisk delegering speglar dessutom hur riktiga organisationer redan fungerar, vilket sannolikt inte är en tillfällighet.

A2A:s version 0.3 lade till stöd för gRPC och "security cards" — strukturerad metadata som låter en agent redovisa sina förmågor och förtroendegränser innan en annan agent lämnar över en uppgift till den [3]. Det är den föga glamorösa infrastrukturen som gör att företagens jurist- och säkerhetsteam godkänner multiagentsystem istället för att blockera dem.

Varför standarderna vinner över alternativet

Det är värt att vara tydlig med alternativet, eftersom "bygg bara skräddarsydda integrationer" fortfarande är det de flesta team faller tillbaka på som standard — och det är fortfarande ett misstag i större skala.

Utan ett delat protokoll kräver varje koppling mellan agenter egen autentisering, egna scheman och egen felhantering. Lägg till en tredje agent i din pipeline, och din integrationsyta växer inte linjärt — den växer kombinatoriskt. Det är precis det felmönster som MCP och A2A designades för att förhindra [4][7].

Den andra risken är silobildning: team som bygger agentsystem som fungerar utmärkt isolerat men inte kan kommunicera med något utanför den egna teknikstacken. Forbes kallade MCP "ett stort steg i utvecklingen av AI-agenter" redan i slutet av 2024, specifikt eftersom det adresserade just detta — det gav Claude (och senare vilken kompatibel modell som helst) ett standardiserat sätt att nå externa system istället för att kräva en ny skräddarsydd koppling för varje enskild integration [6].

Google formulerade sig på liknande sätt vid lanseringen av A2A: "en ny era av interoperabilitet mellan agenter", uttryckligen designad så att agenter från konkurrerande leverantörer ändå skulle kunna samarbeta [2]. Det är ett genuint ovanligt drag — ett stort AI-labb som gör ett protokoll öppen källkod som medvetet gör det enklare för en Google-agent att fungera tillsammans med en Anthropic-agent eller en egenutvecklad företagsagent. Det hände eftersom alla i branschen insåg att ett fragmenterat agentekosystem inte gynnar någon, inklusive plattformsleverantörerna själva.

Den praktiska slutsatsen: om du funderar på om du ska standardisera nu eller senare, blir senare dyrare. Varje skräddarsydd integration du bygger idag är teknisk skuld du måste avveckla när — inte om — du behöver koppla in en ny agent, ett nytt verktyg eller en ny leverantör.

En byggares ritning: Börja med MCP, lägg till A2A

Om du bygger ett multiagentsystem 2026 är sekvensen som ständigt återkommer i lyckade driftsättningar rakt på sak.

Steg ett: få din verktygsåtkomst rätt med MCP först. Innan du bekymrar dig om flera agenter, se till att en enskild agent tillförlitligt kan läsa dina databaser, anropa dina API:er och interagera med dina filsystem via MCP-servrar. Det är den föga glamorösa grunden — och att hoppa över den för att direkt kasta sig in i "multiagentorkestrering" är det vanligaste misstaget vi ser. En orkestrerare som samordnar fem agenter som var och en har opålitlig verktygsåtkomst innebär fem gånger felytan, inte fem gånger förmågan.

Steg två: definiera din delegeringshierarki innan du skriver orkestreringskod. Bestäm om du behöver nav-och-eker (en planerare, flera specialistagenter) eller en plattare, jämlik struktur. För de flesta affärsflöden — innehållspipelines, dataanalys, kundverksamhet — vinner nav-och-eker eftersom det är granskningsbart. Du kan spåra exakt vilken agent som fattade vilket beslut och varför [7].

Steg tre: lägg till A2A för överlämningarna, och behandla scheman som skyddsräcken, inte pappersarbete. "Security cards" och behörighetsstrukturerna i A2A är inte byråkratisk överbyggnad — de är det som låter dig begränsa vad en delegerad agent faktiskt får göra med uppgiften den tilldelas [3]. Att hoppa över detta steg är hur man hamnar i en situation där en agent tyst överskrider sitt avsedda mandat, vilket är ett mycket svårare problem att felsöka i efterhand än att förebygga från början.

Steg fyra: instrumentera allt. Fel i multiagentsystem är sällan dramatiska — de är oftast tyst kontextförlust mellan överlämningar. En agent sammanfattar för aggressivt, tappar en begränsning, och den efterföljande agenten agerar sedan med full säkerhet på ofullständig information. Att logga varje MCP-anrop och varje A2A-överlämning är inte valfritt om du kör detta i produktion; det är det enda sättet att fånga den här typen av fel innan en kund gör det.

Riktiga team kör redan detta mönster inom finansverksamhet, samordning av försörjningskedjor och innehållsproduktion — Tyson Foods driftsättning är ett av de mer synliga exemplen på A2A som utför riktigt logistikarbete snarare än att svara på demoförfrågningar [3]. Mönstret håller oavsett om du samordnar tre interna agenter eller kopplar in dig i en partners agent över en organisationsgräns.

Vad detta faktiskt kostar (och var värdet finns)

Det ärliga svaret för en byggare här är: standardisering har en initial skatt och en långsiktig rabatt. Att anta MCP och A2A innebär att lära sig specifika protokollskonventioner istället för att skriva vad som helst egen kod som känns snabbast just idag. Det är verklig friktion, särskilt för ett litet team som försöker leverera en MVP på en vecka.

Men matematiken vänder snabbt så fort du behöver lägga till ett andra verktyg, en andra agent, eller en andra teammedlem som ska underhålla systemet efter att du gått vidare. Ett protokollbaserat system är läsbart — någon annan kan titta på din MCP-serverkonfiguration och din A2A-delegeringsgraf och förstå systemet utan att behöva bakåtkonstruera din skräddarsydda orkestreringslogik.

Det finns också en ekosystemutdelning som ackumuleras. Eftersom tusentals MCP-servrar redan finns för vanliga verktyg och databaser är en stor del av ditt "integrationsarbete" nu bara konfiguration, inte utveckling [4]. Samma sak börjar hända med A2A-kompatibla agenter i takt med att fler leverantörer levererar dem nativt istället för att kräva skräddarsydda adaptrar [3][8].

För grundare och tekniska ledare som funderar på var de ska lägga sin ingenjörstid under andra halvan av 2026: det mest lönsamma draget är inte att bygga en smartare agent. Det är att bygga koordineringslagret rätt från början, med de protokoll som resten av branschen redan har enats om — för du kommer att koppla in dig i någon annans agent eller verktyg tidigare än din färdplan just nu förutsätter.

Den större förskjutningen: Omdömet flyttar uppåt i stacken

Så här ser det verkligen ut under siffrorna om protokollanvändning. När integration blir standardiserad — när det är ett löst, kommodifierat problem att koppla till ett verktyg eller delegera till en annan agent — slutar konkurrensfördelen vara "vi byggde integrationen" och blir istället vad du säger åt systemet att göra och hur du begränsar det.

Det är den bortom-kod-förskjutningen i miniatyr. MCP och A2A gjorde inte AI-agenter smartare. De gjorde rörsystemet osynligt, vilket pressar allt återstående värde uppåt till beslut som alltid varit mänskliga: vilka agenter som ska byggas, vilka gränser de ska ges, hur "bra" ser ut för en given uppgift, och när man ska lita på resultatet kontra ingripa.

Kod — i det här fallet integrationskod — håller på att bli gratis, precis lika kommodifierad som slogan antyder. Det som återstår, och det som blir allt svårare att fejka, är omdöme: arkitekturbesluten, skyddsräckena, känslan för när ett nav-och-eker-system är rätt val och när det inte är det. De team som vinner med multiagentsystem 2026 är inte de med de smartaste prompterna. Det är de som behandlade orkestrering som det infrastrukturproblem det faktiskt är, antog standarderna tidigt, och lade sin återstående tid på de delar av systemet som faktiskt kräver att en människa bestämmer.

Det är den frontlinjen som är värd att bevaka — inte om AI-agenter kan samordna sig, utan vem som blir tillräckligt duktig på att styra dem så att det slutar vara anmärkningsvärt.

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