
MCP och A2A löser olika problem – en agent kan behöva båda

Välj MCP när en AI-agent behöver läsa data eller utföra en avgränsad åtgärd via ett verktyg, till exempel ett internt API. A2A passar när agenten ska lämna ett uppdrag till en annan självständig agent och fortsätta utbyta information om arbetet. MCP:s introduktion beskriver hur AI-applikationer ansluts till datakällor, verktyg och arbetsflöden.
I en lösning med flera självständiga agenter kan båda protokollen behövas: A2A bär uppdraget mellan agenterna, medan MCP ger dem åtkomst till de verktyg de använder var för sig. A2A-projektets jämförelse beskriver den uppdelningen. Den avgörande frågan är om mottagaren ska utföra ett bestämt anrop eller ta ansvar för en uppgift som kan kräva egna beslut.
Gränsen går vid vem som äger nästa steg
Ett verktyg har en beskriven funktion samt indata och utdata. Agenten väljer när det ska anropas och tolkar svaret. Om ett ekonomisystem returnerar status för en faktura är det fortfarande agenten som avgör hur statusen besvarar användarens fråga; API:t tar inte över hela ärendet.
En självständig agent kan däremot få ett mål och själv avgöra hur den ska arbeta inom sitt uppdrag. Den kan använda egna verktyg, begära mer information eller återkomma med ett resultat senare. A2A är relevant när sådant samarbete ska fungera mellan agenter med skilda gränssnitt eller ansvarsområden. Ett API som anropas genom MCP blir inte därmed en självständig agent.
Antalet inkopplade system avgör inte valet. En agent kan använda många MCP-verktyg utan att behöva A2A. Om flera funktioner styrs inom samma applikation kan dess vanliga interna anrop räcka; A2A blir ett möjligt val när funktionerna uppträder som självständiga agenter med egna uppgifter.
Ett internt API: ett avgränsat verktygsanrop
Anta att en svensk kommun vill låta en intern agent svara en handläggare på om ett ärende har fått en viss status. Flödet är handläggarens fråga, agentens uppslag i ärendesystemet och ett svar tillbaka till handläggaren. Om systemets API exponeras som ett MCP-verktyg kan agenten använda en beskriven funktion för uppslagningen. Exemplet är hypotetiskt.
Förtroendegränsen går mellan agenten och ärendesystemet. Systemet ska bara lämna ut uppgifter som anropet och den bakomliggande behörigheten medger; möjligheten att formulera fler frågor ger inte agenten bredare åtkomst. Kommunen ansvarar i detta tänkta upplägg för vilka funktioner som exponeras, vilken identitet anropen använder och hur svaret får användas. Ingen annan agent tar över uppgiften, så A2A tillför inget till just detta flöde.
Om handläggaren senare behöver en separat expertagents bedömning ändras relationen. Experagenten kan då få ett avgränsat uppdrag, begära ytterligare underlag och lämna tillbaka en bedömning. Det är överlämningen till en självständig mottagare, snarare än uppslaget i API:t, som kan motivera A2A.
Flera interna agenter: skilda uppgifter inom samma bolag
Tänk i stället på ett svenskt energibolag med en kundserviceagent och en separat driftagent. Kundserviceagenten tar emot en fråga om ett planerat arbete och ber driftagenten utreda läget. Driftagenten hämtar information ur sitt driftssystem och återkommer med en bedömning som kundserviceagenten kan använda i svaret. Även detta är ett hypotetiskt verksamhetsexempel.
Data passerar två olika gränser. Uppdraget och svaret går mellan agenterna, där A2A kan passa om de drivs som självständiga tjänster. Driftagentens uppslag i driftssystemet är ett verktygsanrop där MCP kan passa. Kundserviceagenten behöver då inte direkt åtkomst till driftssystemets funktioner för att kunna be om en bedömning.
Bolaget behöver bestämma vilka uppgifter från kundärendet som får skickas vidare och vilka driftuppgifter mottagaren får använda. Kundserviceagenten ansvarar för kontakten med användaren och för innehållet i slutsvaret; driftagenten ansvarar för sin deluppgift och sina verktygsanrop. Om de två delarna i praktiken är funktioner under samma applikations styrning kan ett enklare internt anrop räcka, även om båda kallas agenter.
En extern parts agent: uppdraget passerar organisationsgränsen
I ett tredje tänkt fall behöver en svensk nätbutiks agent besked från ett fraktbolags agent om en leveransavvikelse. Butikens agent kan använda MCP för att läsa den egna orderstatusen och sedan be fraktbolagets agent utreda transporten. Med A2A kan de självständiga parterna utbyta uppdrag, följdfrågor och resultat utan att butiken får direkt åtkomst till fraktbolagets interna system.
Här lämnar orderuppgifter butiken och ett svar kommer från en annan organisation. A2A-specifikationen beskriver en Agent Card som anger bland annat förmågor och autentiseringskrav, medan varje agents åtkomstmodell bestämmer vilka resurser en anropare får använda. Att hitta en agent ger alltså inte i sig rätt att dela orderuppgifter med den. Butiken måste avgöra vad den får lämna ut och kontrollera vem den kontaktar; fraktbolaget måste avgöra vad dess agent får se och besvara.
Ansvarsfördelningen behöver också täcka ett uppdrag som kräver mer information eller inte kan slutföras. Butikens agent äger kunddialogen och kan inte tolka uteblivet svar som ett leveransbesked. Fraktbolagets agent äger sin utredning men får inte automatiskt tillgång till butikens övriga kunddata. Protokollet förmedlar uppdraget; parterna sätter gränserna för data och beslut.
Så avgörs valet i arkitekturen
Utgå från mottagarens roll. Ska den utföra en definierad funktion medan den anropande agenten behåller ansvaret för uppgiften, pekar valet mot MCP. Ska mottagaren själv kunna driva en deluppgift, begära mer sammanhang och återkomma med ett resultat, kan A2A passa. Den mottagande agenten kan samtidigt använda MCP för sina egna API:er och datakällor.
Gränserna visar också vem som måste fatta besluten om behörighet: mellan agent och verktyg, mellan interna agenter och mellan organisationer. För varje gräns behöver det vara tydligt vilken part som får välja verktyg, dela data och använda resultatet. När en uppgift både delegeras till en självständig agent och kräver åtkomst till den agentens verktyg fyller protokollen var sin funktion.
Relaterade artiklar


Shopify Canvas bygger hela butiken med AI – men bara i tidig åtkomst

Azure OpenAI eller direkt API: dataplaceringen kan kosta 10 procent

Ett lyckat agenttest räcker inte – mät utfallet och upprepningen

GitHub eller GitLab: gratis CI-minuter säger inte hela kostnaden

Cloudflare R2 eller Amazon S3: gratis uttrafik löser inte allt
Prenumerera på vårt nyhetsbrev
Få de senaste nyheterna om Web3, AI och krypto direkt i din inkorg.