Vad är A2A-protokollet? Agent Cards och Tasks förklarade

A2A-protokollet, förkortning för Agent2Agent Protocol, är en öppen standard för kommunikation mellan oberoende AI-agent-system.

Den meningen låter enkel, men den implicerar något som de flesta AI-agent-demonstrationer helt hoppar över. De flesta demos förutsätter fortfarande en assistent, en körningstid (runtime), en verktygsslinga och en ägare — agenten kan söka, anropa verktyg, skriva kod, fråga API:er, kanske använda MCP-server och returnera ett svar.

A2A är designat för en annan värld, en där agenter kan byggas av olika team, ramverk, leverantörer, språk eller organisationer. Det förutsätter att en agent kan behöva upptäcka en annan agent, förstå vad den kan göra, skicka arbete till den, utbyta meddelanden, ta emot filer eller strukturerade utdata och följa en uppgift tills den är klar — vilket gör det till inte bara ett nytt format för verktygsanrop, utan ett genuint försök att göra AI-agenter interoperabla som jämlikar.

De centrala koncepterna är:

• Agentkort
• Agenter och klienter
• Uppgifter
• Meddelanden
• Delar
• Artefakter
• Uppgiftstillstånd
• Streaming och asynkrona uppdateringar

Den här artikeln förklarar dessa koncept i plaina ingeniörstermer, med tillräckligt med detaljer för att förstå var A2A passar in i verkliga multi-agent-system.

Den korta definitionen

A2A är ett protokoll för agent-till-agent-kommunikation.

Det låter en agent eller klient kommunicera med en annan agent genom en gemensam modell. Den mottagande agenten kan beskriva sina kapaciteter, acceptera arbete, hantera livscykeln för det arbetet, be om mer indata, strömma framsteg och returnera konkreta utdata.

Syftet är inte att standardisera hur en agent tänker internt — det är att standardisera hur agenter kommunicerar vid sina gränser.

En A2A-agent kan internt använda:

• Python
• Go
• JavaScript
• LangGraph
• CrewAI
• Semantic Kernel
• egen kod
• MCP-server
• privata API:er
• vektordatabaser
• arbetsflödesmotorer

Anroparen behöver inte veta något av detta. Det anroparen behöver veta är:

• Vad kan denna agent göra?
• Hur kommunicerar jag med den?
• Vilka indata accepterar den?
• Vilka utdata kan den producera?
• Hur följer jag arbetet?
• Hur tar jag emot resultatet?

Dessa sex frågor definierar protokollgränsen som A2A försöker etablera mellan självständigt opererande agenter.

Varför A2A existerar

AI-system går från ensamma assistenter till nätverk av specialistagenter.

Ett företag kan ha:

• En supportagent
• En faktureringsagent
• En juridisk granskningsagent
• En DevOps-agent
• En dataanalysagent
• En researchagent
• En dokumentationsagent
• En kodgranskningsagent

Varje agent kan ha sina egna verktyg, behörigheter, domänkunskap, prompts, minne, hämtningssystem (retrieval) och revisionsregler.

Utan ett delat protokoll blir varje integration skräddarsydd — supportagenten behöver egen anslutning till faktureringsagenten, faktureringsagenten behöver sin egen till juridikagenten och researchagenten behöver ännu en till dokumentationsagenten. Denna kombinatoriska overhead skalerar inte särskilt bra när agentnätverket växer.

A2A ger dessa agenter ett gemensamt sätt att interagera, vilket minskar N×M-integrationsproblemet till ett enda delat kontrakt. Löftet är inte magisk autonomi; löftet är interoperabilitet.

A2A är inte MCP

A2A jämförs ofta med MCP, men de löser olika problem.

MCP, eller Model Context Protocol, handlar främst om att ansluta en AI-app eller agent till verktyg, resurser och prompts, medan A2A främst handlar om att ansluta agenter till andra agenter.

En användbar mental modell är:

MCP: agent till verktyg
A2A: agent till agent

Till exempel kan en agent använda MCP för att få tillgång till:

• GitHub
• ett filsystem
• en databas
• Slack
• ett system för dokumentationssökning
• ett moln-API

Praktiska guider för att bygga dessa MCP-server finns för Go och Python.

Samma agent kan använda A2A för att delegera arbete till:

• en säkerhetsgranskningsagent
• en researchagent
• en planeringsagent
• en compliance-agent
• en kodningsagent

De två protokollen kan och gör ofta tillsammans. En ren arkitektur är ofta:

A2A utanför agentgränsen.
MCP inuti agentgränsen.

Det betyder att andra agenter kommunicerar med din agent med A2A, medan din agent internt använder MCP för att få tillgång till verktyg — en ren separation av ansvar som håller det externa gränssnittet stabilt oavsett vad som ändras inuti. För en detaljerad jämförelse av hur de två protokollen delar arkitekturellt ansvar och när du faktiskt behöver båda, se A2A vs MCP: Behöver AI-agenter verkligen båda protokollen?

Centrala roller i A2A

A2A använder en enkel rollmodell byggd kring två parter: en agent som exponerar kapaciteter, och en klient som vill använda dem.

Klienten kan vara:

• en annan agent
• en orkestrator
• en assistentapplikation
• ett arbetsflödssystem
• en gateway
• en testmiljö
• en användarvänlig app

Agenten kan vara:

• en specialist AI-tjänst
• en domänassistent
• en agent som äger ett arbetsflöde
• en extern leverantörsagent
• en intern företagsagent

Det viktiga är att agenten inte bara är en funktion. Den äger en viss kapacitet och exponerar den genom ett agentgränssnitt.

Agentkort

Agentkortet är ett av de viktigaste koncepten i A2A.

Ett agentkort beskriver en agent — det är upptäcktsdokumentet som berättar för klienter vad agenten är, vad den kan göra, hur man kommunicerar med den och vilka begränsningar som gäller.

Tänk på ett agentkort som en blandning av:

• tjänstemetadata
• kapacitetsdeklaration
• API-upptäcktsdokument
• agentprofil
• kontraktyta

Ett typiskt agentkort kan beskriva saker som:

• agentnamn
• beskrivning
• tjänstendpoint
• protokollfunktioner som stöds
• in- och utdataformat som stöds
• tillgängliga färdigheter
• autentiseringskrav
• leverantörsinformation
• versionsinformation
• länkar till dokumentation
• valfri metadata

Agentkortet är viktigt eftersom agenter inte behöver ha hårdkodad kunskap om varje annan agent.

En klient kan inspektera kortet och besluta:

• Är detta rätt agent för jobbet?
• Stöder den den innehållstyp jag behöver?
• Stöder den streaming?
• Kräver den autentisering?
• Vilka färdigheter annonserar den?
• Kan den returnera den typ av artefakt jag behöver?

I praktiska system blir agentkorten grunden för agentregister, utvecklarportaler och interna agentkataloger — den maskinläsbara motsvarigheten till en tjänstekatalog där klienter kan slå upp vad som är tillgängligt innan de engagerar sig i en integration.

Agentkort är kapacitetsgränser

Ett agentkort bör inte behandlas som marknadstext — det är en kapacitetsgränse som andra system kommer att förlita sig på vid körning.

Om ditt agentkort säger att din agent kan utföra finansiell analys, kan klienter börja delegera finansiell analysarbete till den. Om det säger att agenten accepterar filer, kan klienter skicka filer. Om det säger att agenten stöder streaming, kan klienter förvänta sig händelser om framsteg.

Dåliga agentkort skapar dåliga system eftersom ruteringsbeslut och kapacitetsantaganden kaskaderar genom hela agentnätverket. Ett användbart agentkort bör vara:

• specifikt
• korrekt
• stabilt
• versionerat
• säkerhetsmedvetet
• ärligt om begränsningar

En vag färdighet som “utför affärsuppgifter” är inte hjälpsam.

En bättre färdighet är:

Analysera SaaS-fakturadata och producera en månadsvis sammanfattning av utgifter.

Ännu bättre, inkludera förväntade in- och utdataformat.

Indata: CSV- eller JSON-fakturaregistreringar.
Utdata: Markdown-sammanfattning och strukturerade JSON-totaler.

Ju mer preciserat agentkortet är, desto lättare är det för andra agenter att ruttar uppgifter korrekt.

Agentupptäckt

Agentupptäckt är processen att hitta ett agentkort.

I enkla deployment kan upptäckten vara statisk. En klient vet redan URL:en till en specifik agent.

I större deployment kan upptäckten involvera:

• ett register
• en utvecklarportal
• en intern katalog
• DNS-baserad upptäckt
• konfigurationshantering
• miljöspecifik ruttning
• tenantmedvetna gateways

Den viktiga designbeslutet är om upptäckten är offentlig, privat eller behörighetsbaserad.

Inte varje agent ska vara upptäckbar av alla — en intern löneagent bör inte exponera samma agentkort för varje anropare, och en partneragent kan bara se partnersäkra färdigheter. Agentupptäckt är inte bara en bekvämlighetsfunktion; det är en del av din säkerhets- och styrmodell, och att avgränsa synlighet är ett förstahandsdesignbeslut.

Uppgifter

En uppgift representerar arbete som utförs av en agent.

Här blir A2A mer intressant än enkla begär-och-svar-API:er.

Vissa agentinteraktioner är snabba. En klient skickar ett meddelande, och agenten returnerar ett direkt svar.

Men många verkliga agentarbetsflöden är inte omedelbara.

En uppgift kan involvera:

• att söka i flera källor
• att be om förtydligande
• att anropa verktyg
• att delegera arbete
• att vänta på godkännande
• att generera en rapport
• att producera filer
• att strömma framsteg
• att hantera försök
• att returnera flera artefakter

A2A modellerar detta slag av arbete som en Uppgift — vilket ger arbetet en identitet och en livscykel, vilket är viktigt eftersom långvarigt agentarbete behöver spåras, inspekteras och potentiellt avbrytas eller försökas igen.

Uppgiftslivscykel

En uppgift kan gå igenom olika tillstånd.

Den exakta tillståndsmodellen beror på protokollversionen och implementationen, men den grundläggande idén är enkel:

• inlämnad
• pågående
• indata krävs
• avslutad
• misslyckad
• avbruten
• avvisad

Den viktiga punkten är att en uppgift inte bara är en svarspayload — det är en pågående enhet av arbete med sitt eget tillstånd som en klient kan fråga vid varje tidpunkt. En klient kan använda uppgiftstillståndet för att förstå vad som händer:

• Har agenten accepterat uppgiften?
• Är den fortfarande pågående?
• Behöver den mer indata?
• Har den avslutats framgångsrikt?
• Misslyckades den?
• Avbröts den?
• Finns det artefakter tillgängliga?

Detta är särskilt användbart för arbetsflöden som tar sekunder, minuter eller längre.

Till exempel kan en researchagent returnera en uppgift omedelbart, och fortsätta arbeta i bakgrunden medan den strömmar händelser om framsteg eller gör resultatet tillgängligt senare.

Stateless-meddelande eller stateful-uppgift

A2A stöder både enkla och komplexa interaktioner.

För en enkel interaktion kan en agent returnera ett direkt Meddelande; för en komplex interaktion kan den returnera en Uppgift. Denna distinktion är viktig eftersom inte allt behöver uppgiftsspårning, och att överingeniera korta interaktioner till fulla uppgiftsarbetsflöden lägger onödig overhead.

Om en klient frågar:

Sammanfatta denna enstaka paragraf.

Kan ett direkt svar räcka.

Om en klient frågar:

Forskning om de fem främsta open source-vektordatabaserna, jämför dem och producera en migrationsrekommendation.

Är en uppgift mer lämplig.

Den praktiska regeln är enkel: använd ett direkt Meddelande för enkla, omedelbara interaktioner, och använd en Uppgift för långvarigt, stateful, revisionsbart eller artefaktproducerande arbete.

Meddelanden

Meddelanden är kommunikationsenheterna som utbyts mellan klient och agent.

Ett meddelande kan innehålla en eller flera delar.

Ett meddelande kan representera:

• en användarbegäran
• ett agentsvar
• en förtydligande fråga
• ytterligare indata
• uppgiftsrelaterad kommunikation
• kontext för framsteg
• strukturerade instruktioner

Meddelanden är inte bara strängar — agentkommunikation behöver ofta bära mycket mer än ren text, och meddelandestrukturen är designad för att ta hävd på det.

Ett meddelande kan inkludera:

• text
• filer
• strukturerad JSON
• bilder
• referenser
• metadata

Meddelandet är kuvertet; delarna är den faktiskt typade innehållet inuti det.

Delar

En Del är en bit innehåll inuti ett meddelande eller en artefakt.

Detta är hur A2A stöder multimodal och strukturerad kommunikation.

En del kan innehålla olika innehållstyper, såsom:

• text
• fildata
• strukturerad data
• binärt innehåll via referens
• JSON-liknande data

En del kan också inkludera metadata som:

• medietyp
• filnamn
• ytterligare kontext

Medietypen är viktig eftersom den berättar för den mottagande agenten hur innehållet ska tolkas.

Till exempel:

text/plain
application/json
text/markdown
image/png
application/pdf
text/csv

Detta är en av de undervärderade delarna av A2A. Agentkommunikation bör inte krossa allt till ren text — om en nedströmsagent behöver ett kalkylblad, en bild, en JSON-payload, en loggfil eller en PDF, bör protokollet bevara det innehållet som innehåll snarare än att förvrida det till en paragraf. Bra agentsystem undviker dessa onödiga textflaskhalsar genom att låta varje del bära sin naturliga medietyp hela vägen till konsumenten.

Artefakter

Artefakter är konkreta utdata som produceras av en agent under uppgiftsbehandling.

Detta skiljer sig från ett generellt meddelande: ett meddelande är kommunikation mellan agenter, medan en artefakt är en konkret leverans som uppgiften har producerat.

Exempel på artefakter inkluderar:

• en markdown-rapport
• ett JSON-analysresultat
• en CSV-export
• en genererad bild
• ett PDF-dokument
• en kodpatch
• en testresultatfil
• en deploymentsplan
• en diagram
• en dataextrakt

Denna distinktion är användbar i praktiken. När en researchagent säger “Jag har funnit svaret”, är det ett meddelande. När den returnerar market-analysis.md, sources.json och risk-summary.csv, är det artefakter — konkreta utdata som gör uppgiftens arbete inspekterbart, återanvändbart och komponerbar. En agents artefakt blir en annan agents indata utan någon förlust av struktur.

Meddelanden vs Artefakter

Ett enkelt sätt att tänka på det:

Meddelanden är samtal.
Artefakter är utdata.

Meddelanden hjälper agenter att koordinera; artefakter är vad uppgiften faktiskt producerade.

Till exempel, i ett software development-arbetsflöde:

• Klienten skickar ett meddelande som ber om en bug-fix.
• Kodningsagenten skickar meddelanden med förtydligande frågor.
• Kodningsagenten arbetar på uppgiften.
• Agenten returnerar artefakter som en patchfil, testutdata och förklaring.

Denna separation är hjälpsam eftersom den undviker att blanda ihop uppgiftscoordination med leveranser, vilket gör det mycket lättare att logga, revidera och passera utdata till nedströmskonsumenter.

Ett praktiskt exempel

Föreställ dig att en primär assistent behöver hjälp från en dokumentationsagent.

Användaren frågar:

Skapa utvecklardokumentation för vår nya billing webhook API.

Den primära assistenten kollar ett agentregister och hittar en dokumentationsagent.

Dokumentationsagenten har ett agentkort som säger att den kan:

• skriva API-dokumentation
• acceptera OpenAPI-specifikationer
• acceptera Markdown-stilguider
• producera Markdown-dokument
• producera exempel på Python och JavaScript
• stödja långvariga uppgifter
• returnera artefakter

Den primära assistenten skickar ett meddelande med:

• en kort instruktion
• en OpenAPI-fil
• en stilguide
• metadata om målgruppen

Dokumentationsagenten skapar en Uppgift.

Uppgiften går in i ett pågående tillstånd.

Dokumentationsagenten kan skicka meddelanden som:

Jag extraherar endpointbeskrivningar.

Då:

Jag behöver förtydligande kring autentiseringsexempel.

Den primära assistenten tillhandahåller den saknade indata.

Uppgiften fortsätter.

Slutligen returnerar dokumentationsagenten artefakter:

billing-webhooks.md
billing-webhook-examples-python.md
billing-webhook-examples-javascript.md

Det är A2A-modellen i aktion: inte bara “anropa denna funktion” utan “delegera denna uppgift till en annan agent, kommunicera vid behov och spåra resultatet genom till avslut.”

Varför uppgifter är viktiga för verkliga system

Uppgifter är det som gör A2A lämplig för seriösa arbetsflöden.

Ett normalt HTTP API-anrop är ofta för tunt för agentarbete. Agentuppgifter kan involvera osäkerhet, flera steg, mellanresultat och följdfrågor.

En Uppgift ger dig en plats att fästa:

• status
• historik
• meddelanden
• artefakter
• fel
• metadata
• framsteg
• avbrott
• revisionsinformation

Detta är användbart för:

• researcharbetsflöden
• kodgenerering
• dataanalys
• compliance-granskning
• dokumentproduktion
• incidentutredning
• flerstegsplanering
• arbetsflöden med mänskligt godkännande

Utan en uppgiftsmodell bygger utvecklare oftast om denna logik själva med skräddarsydda jobb-ID:n, köer, statusendpoints och webhook-återanrop — A2A försöker standardisera den agentspecifika versionen av detta mönster så att du inte behöver uppfinna det om för varje ny agentintegration.

Streaming och asynkront arbete

A2A stöder idén att agentarbete kan vara strömmat eller asynkront.

Streaming är användbart när klienten vill ha live-uppdateringar.

Till exempel:

• händelser om framsteg
• delresultat
• mellanstatus
• genererad text
• steguppdateringar

Asynkrona arbetsflöden är användbara när uppgiften kan ta lång tid eller när klienten inte kan hålla en öppen anslutning.

Till exempel:

• bakgrundsforskning
• generering av stora dokument
• multi-agent-granskning
• databehandling
• mänskligt godkännande
• batchanalys

I praktiken bör ett robust A2A-system designas kring tre lägen: omedelbart svar för enkelt arbete, streaming för interaktivt långvarigt arbete och async för hållbart bakgrundarbete som kan överleva någon enskild anslutning. För SSE, push-webhooks, omregistrering, HITL via input_required, felhantering och produktionschecklistor, se A2A Streaming och asynkrona uppgifter för långvariga agentarbetsflöden.

Agentkort och streamingstöd

Ett agentkort kan annonsera om en agent stöder streaming.

Detta är viktigt eftersom klienter inte kan anta att varje agent stöder streaming — vissa agenter kan bara stödja enkla begär-och-svar, vissa kan stödja uppgiftspolling, och andra kan stödja push-meddelanden eller server-sent events. En bra klient inspekterar agentkortet innan den väljer ett interaktionsmönster, vilket är varför agentkort inte bara är dokumentation: de formar direkt körtidsbeteende.

A2A och multimodala agenter

A2A är designat för att stödja mer än ren text.

Detta är viktigt eftersom verkliga agentsystem alltmer bearbetar blandade in- och utdata:

• text
• bilder
• ljud
• video
• PDF:er
• kalkylblad
• strukturerad JSON
• loggar
• kod
• diagram

Om varje agentgräns konverterar allt till text, kan viktig information gå förlorad.

Till exempel, en visuell felsökningsagent bör ta emot en bild som en bild, inte som en svag textbeskrivning. En finansagent bör ta emot strukturerade kalkylbladsdata, inte en kopierad paragraf. En kodgranskningsagent bör ta emot källfiler eller diffs, inte en vag sammanfattning.

Delar och medietyper är hur A2A bevarar rikare innehåll över agentgränser — och detta är en av de platser där protokollet är viktigare än det först verkar, eftersom informationsförlust vid gränsen komprimeras över varje hopp i en multi-agent-kedja.

A2A är inte ett agent-ramverk

A2A berättar inte för dig hur du bygger en agent.

Det definierar inte:

• resonemangsstrategi
• planeringsalgoritm
• minnesystem
• vektordatabas
• promptmall
• modellleverantör
• verktygsramverk
• orkestreringskörning
• utvärderingsmetod

Det är en funktion, inte en bugg. A2A är ett gränsprotokoll som låter olika agentimplementationer kommunicera utan att kräva att de delar samma interna arkitektur — precis som HTTP inte berättar för dig hur du bygger en webbapplikation, det definierar bara hur system kommunicerar. A2A bör förstås på samma sätt.

A2A är inte en ersättning för API:er

A2A ersätter heller inte varje API.

Om du har en deterministisk tjänst med ett stabilt begär-och-svar-kontrakt, kan ett normalt API vara bättre.

Till exempel:

• valutaomvandling
• adressvalidering
• faktursökning
• bildstorleksändring
• sökendpoint
• feature flag-sökning
• intern CRUD-tjänst

Dessa blir inte automatiskt agenter bara för att de anropas av ett AI-system. A2A är meningsfull när det fjärrsystemet genuint beter sig som en agent:

• den äger en uppgift
• den kan be om mer indata
• den kan använda verktyg internt
• den kan ta tid
• den kan producera artefakter
• den har kapaciteter som är värda att upptäcka
• den kan operera som en jämlik i ett större arbetsflöde

Använd inte A2A bara för att det är modernt — använd det när abstraktionen genuint passar problemet.

Var A2A passar in i AI-systemarkitektur

A2A passar bäst vid gränsen mellan oberoende deploybara agenter.

En användbar arkitektur kan se ut så här:

Användare
  |
  v
Primär assistent
  |
  |-- A2A --> Researchagent
  |-- A2A --> Kodningsagent
  |-- A2A --> Compliance-agent
  |-- A2A --> Dokumentationsagent

Varje specialistagent kan internt använda verktyg:

Researchagent
  |
  |-- MCP --> websökning
  |-- MCP --> dokumentlagring
  |-- MCP --> vektordatabas

Detta ger dig separata lager:

Användargränssnittslager
Agentkoordinationslager
Verktygsintegrationslager
Data- och exekveringslager

A2A finns i agentkoordinationslagret, MCP finns ofta i verktygsintegrationslagret, och normala API:er, köer, databaser och lagringssystem finns under det — varje lager med sin egen abstraktion och sina egna felmoder. För en tvärsnittskarta över hur LLM-inferens, minne, ruttning, verktyg och observabilitet passar ihop inuti produktionsassistenter, se AI-assistentarkitektur: LLM, minne, verktyg, ruttning, observabilitet.

Arkitekturmönster: Orkestrator och specialister

Det vanligaste A2A-mönstret är troligen orkestrator plus specialister.

I detta mönster tar en primär agent emot användarbegäran och delegerar delar av arbetet till specialistagenter.

Exempel:

Primär assistent
  |
  |-- A2A --> Juridisk agent
  |-- A2A --> Finansagent
  |-- A2A --> Researchagent
  |-- A2A --> Skrivagent

Detta mönster är enkelt att förstå: orkestratorn äger det övergripande arbetsflödet, och specialistagenter äger domänspecifikt arbete. Nackdelen är att orkestratorn kan bli en flaskhals, och den behöver en solid ruttstrategi för att delegera effektivt — de underliggande modellvalen och orkestreringsavvägningarna täcks i Multi-modell systemdesign: När en modell inte räcker. Ändå, för de flesta team är detta den bästa första multi-agent-arkitekturen att vända sig till innan man utforskar mer komplexa topologier.

Arkitekturmönster: Peer-agenter

I ett peer-to-peer-mönster kan agenter kommunicera med varandra mer direkt.

Till exempel:

Researchagent --> Dataagent --> Diagramagent --> Skrivagent

Detta kan vara kraftfullt, men det är svårare att kontrollera.

Du behöver starka regler för:

• vem kan ringa vem
• vilken kontext kan delas
• hur loopar förhindras
• vem äger slututdata
• hur kostnad kontrolleras
• hur delegering revideras

Peer-agent-nätverk låter eleganta, men de kan bli kaotiska snabbt — använd dem bara när du har starka styrregler och tydlig ägarskap över varje kant i grafen.

Arkitekturmönster: A2A Gateway

Ett mer produktionsvänligt mönster är en A2A gateway.

Istället för att varje agent direkt anropar varje annan agent, flödar trafiken genom en gateway.

Gatewayen kan hantera:

• autentisering
• auktorisering
• ruttning
• tenantmappning
• loggning
• hastighetsbegränsningar
• policykontroller
• protokollversionshantering
• observabilitet
• revisionsspår

Detta är särskilt användbart i företagsmiljöer, där gatewayen blir kontrollplanet för agentkommunikation — som tillämpar policy på en plats snarare än att återimplementera det över varje agent. I mindre system kan detta vara överdrivet, men i större system med flera team och leverantörer blir det ofta nödvändigt tidigare än förväntat.

Säkerhetsöverväganden

A2A-säkerhet förtjänar seriell uppmärksamhet.

Agent-till-agent-kommunikation kan flytta känslig kontext över gränser. Den kan också delegera arbete till system som kan ha sina egna verktyg och behörigheter.

De centrala säkerhetsfrågorna är:

• Vilka agenter är tillåtna att upptäcka denna agent?
• Vilka agenter är tillåtna att skicka den uppgifter?
• Vilken autentisering krävs?
• Vilka behörigheter är knutna till anroparen?
• Kan en agent delegera användarautorititet till en annan?
• Vilka data kan inkluderas i meddelanden?
• Vilka artefakter kan returneras?
• Hur revideras uppgiften?
• Kan den mottagande agenten anropa verktyg eller andra agenter?
• Hur skyddas hemligheter?

Agentkort bör inte innehålla statiska hemligheter, och känsliga agentkort bör skyddas bakom autentisering snarare än att publiceras öppet. Olika klienter behöver ofta olika vyer av samma agent — en intern anropare kan se fler färdigheter än en extern partner, medan en offentlig klient kan se endast en begränsad uppsättning säkra kapaciteter.

Säkerhet bör inte läggas till efter att agentnätverket är byggt; det bör forma nätverket från start, eftersom att eftermontera auth- och behörighetsgränser över en live agent-topologi är betydligt svårare än att designa dem in. För den fulla behandlingen — hotmodell, identitetslager, gateway-kontrollplan, delegeringsomfång och revisionsspår — se A2A och MCP Agent Säkerhet: Identitet, delegering och revisionsspår.

Observabilitetsöverväganden

A2A-system behöver stark observabilitet.

När en uppgift korsar agentgränser, blir felsökning betydligt svårare eftersom inget enskilt system håller den fulla bilden. Du behöver veta:

• vilken agent skapade uppgiften
• vilken agent accepterade den
• vilka meddelanden utbyttes
• vilka tillståndsändringar inträffade
• vilka artefakter producerades
• vilka fel hände
• hur lång tid varje steg tog
• vilka verktyg användes internt
• om en annan agent anropades
• vem godkännde riskfyllda åtgärder

En användbar spårning bör följa arbetet över hela kedjan.

Till exempel:

användarbegäran
  -> primär assistentuppgift
  -> researchagentuppgift
  -> dokument sökverktygsanrop
  -> sammanfattningsartefakt
  -> slutligt svar

Utan den end-to-end-spårningen blir multi-agent-system mycket svåra att lita på i produktion — du kan inte med säkerhet svara varför systemet producerade ett givet utdata, än mindre identifiera var det gick fel. Observabilitet för LLM-system: Mätningar, spårningar, loggar och testning i produktion täcker instrumentering och verktygssidan av detta problem i djupet.

Vanliga misstag

Misstag 1: Att kalla varje verktyg en agent

Inte varje verktyg är en agent.

En kalkylator är ett verktyg. En filläsare är ett verktyg. En databasfrågeendpoint är ett verktyg.

Om den inte äger en uppgift, ber om indata, producerar artefakter eller beter sig som en oberoende jämlik, behöver den troligen inte A2A.

Misstag 2: Att göra agentkort för vaga

Ett agentkort bör inte säga:

Denna agent hjälper till med affärsuppgifter.

Det är användbart för ingen agent som försöker rutta arbete intelligентt. Ett bra kort bör säga vad agenten faktiskt gör, vad den accepterar, vad den returnerar och vilka begränsningar som gäller.

Misstag 3: Att ignorera uppgiftstillstånd

Om du använder A2A men behandlar varje interaktion som begär-och-svar, missar du mycket av värdet.

Uppgiftsmodellen är en av de främsta anledningarna att använda A2A framför ett vanligt API — att hoppa över det betyder att återbygga samma livscykelhanteringslogik i varje integration.

Misstag 4: Att returnera allt som text

A2A stöder strukturerat och multimodalt innehåll. Använd det.

Om utdatan är en rapport, returnera en rapportartefakt.

Om utdatan är JSON, returnera strukturerad data.

Om utdatan är en fil, returnera en fil.

Platta inte ut allt till ren text om inte ren text är rätt utdata.

Misstag 5: Ingen behörighetsmodell

Agentnätverk utan behörighetsgränser är riskabla.

Inte varje agent ska få anropa varje annan agent med varje typ av data — använd autentisering, auktorisering och revisionsspår för att tillämpa principen om minsta privilegium över agentnätverket.

När ska du använda A2A?

Använd A2A när du har verkliga agentgränser.

Goda skäl inkluderar:

• agenter ägs av olika team
• agenter deployas som separata tjänster
• agenter byggs med olika ramverk
• agenter behöver upptäcka varandra
• agenter behöver delegera uppgifter
• uppgifter kan vara långvariga
• resultat kan inkludera artefakter
• klienter inte bör känna till interna verktyg
• agentkapacitetsmetadata är viktig

Svaga skäl inkluderar:

• det låter modernt
• du vill anropa en funktion
• du har en single-agent-app
• ett normalt API skulle fungera
• MCP redan löser ditt verktygsintegrationsproblem

A2A är kraftfullt när systemet faktiskt är multi-agent; det är onödig ceremoni när systemet inte är det, och kostnaden för den ceremonin — tillagda koncept, infrastruktur, felsökningsyta och säkerhetskrav — är verklig.

En minimal mental modell

Om du minns bara en sak, kom ihåg detta:

Agentkort: vad agenten kan göra.
Meddelande: vad agenter säger till varandra.
Del: typat innehåll inuti ett meddelande eller en artefakt.
Uppgift: arbete som agenten äger.
Artefakt: utdata som uppgiften producerade.

Det är kärnan i A2A — resten handlar mest om att göra dessa fem koncept tillförlitliga, observerbara och säkra nog att använda i verkliga produktionssystem.

Sluttankar

A2A är inte bara en ny AI-förkortning — det är en del av en större förskjutning från isolerade assistenter till interoperabla agentsystem. Den förskjutningen kommer inte att hända överallt på en gång, och många applikationer kommer att förbli single-agent-system med bra verktygsåtkomst där MCP och normala API:er är helt tillräckliga.

Men när agenter blir separat deployade jämlikar, behöver du starkare gränser: upptäckt, uppgiftsägarskap, meddelanden som bär mer än text, artefakter som förstaklassutdata, och säkerhet, tillstånd och observabilitet som sträcker sig över agentgränser. Det är det utrymme A2A försöker uppta, och det är ett genuint annat problem från verktygsintegrationsproblemet MCP löser.

För en praktisk syn på var A2A faktiskt har produktionsfotfäste 2026 — inklusive adoptionstrupper, säkerhetsbekymmer, företagsanvändningsfallet och ett beslutsramverk — se Google A2A-protokollet 2026: Adoption, hype och verklighet.

Min åsikt: börja inte med A2A för små projekt. Börja med en användbar agent, bra verktyg och tydlig arkitektur — AI Systems-klustret täcker self-hosted assistenter, MCP-server och agentminne som en sammanhängande uppsättning om du vill ha den bredare kontexten. Men när din “verktyg” börjar se ut som en annan autonom specialist med sin egen uppgiftslivscykel, är det troligen inte bara ett verktyg längre — och det är när A2A blir intressant.

Källor

• A2A Protocol Specification: https://a2a-protocol.org/latest/specification/
• A2A Key Concepts: https://a2a-protocol.org/latest/topics/key-concepts/
• A2A Life of a Task: https://a2a-protocol.org/latest/topics/life-of-a-task/
• A2A Agent Discovery: https://a2a-protocol.org/latest/topics/agent-discovery/
• A2A Streaming and Async Operations: https://a2a-protocol.org/latest/topics/streaming-and-async/
• A2A and MCP: https://a2a-protocol.org/latest/topics/a2a-and-mcp/