Vad är A2A-protokollet? Agentkort och uppgifter förklaras

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

Den meningen låter enkel, men den innebär något som de flesta AI-agent-demonstrationer helt hoppar över. De flesta demonstrationer utgår fortfarande från en assistent, en körning, ett verktygslöpp och en ägare – agenten kan söka, anropa verktyg, skriva kod, fråga API:er, kanske använda MCP-servrar och returnera ett svar.

A2A är designat för en annan värld, där agenter kan ha byggts av olika team, ramverk, leverantörer, språk eller organisationer. Det utgår från att en agent kanske behöver upptäcka en annan agent, förstå vad den kan göra, skicka arbete till den, utbyta meddelanden, motta filer eller strukturerade utdata och spåra en uppgift tills den är avslutad – vilket gör det till mer än bara ett annat format för verktygsanrop, utan ett genuint försök att göra AI-agenter interoperabla som jämlikar.

De centrala koncepten är:

• Agent Cards (Agentkort)
• Agenter och klienter
• Uppgifter (Tasks)
• Meddelanden
• Delar (Parts)
• Artefakter
• Uppgiftstillstånd (Task states)
• Streaming och asynkrona uppdateringar

Denna artikel förklarar dessa koncept i klara tekniska termer, 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 kommunikation mellan agenter.

Det låter en agent eller klient kommunicera med en annan agent genom en gemensam modell. Den mottagande agenten kan beskriva sina kapaciteter, ta emot arbete, hantera livscykeln för det arbetet, begära mer indata, streama framsteg och returnera konkreta utdata.

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

En A2A-agent kan internt använda:

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

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

• Vad kan denna agent göra?
• Hur pratar jag med den?
• Vilka indata accepterar den?
• Vilka utdata kan den producera?
• Hur spårar jag arbetet?
• Hur mottar jag resultatet?

Dessa sex frågor definierar protokollgränsen som A2A försöker etablera mellan oberoende agenter.

Varför A2A finns

AI-system går från enskilda assistenter till nätverk av specialiserade agenter.

Ett företag kan ha:

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

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

Utan en delad protokoll blir varje integration unik – supportagenten behöver skräddarsydd koppling till faktureringsagenten, faktureringsagenten behöver sin egen till juridikagenten, och forskningsagenten behöver ännu en till dokumentationsagenten. Denna kombinatoriska overhead skalar inte bra när agentnätverket växer.

A2A ger dessa agenter ett gemensamt sätt att interagera, och reducerar N×M-integrationsproblemet till ett enda delat avtal. 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 dokumentationssökningssystem
• ett moln-API

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

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

• en säkerhetsgranskningsagent
• en forskningsagent
• en planeringsagent
• en efterlevnadsagent
• en kodningsagent

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

A2A utanför agentgränsen.
MCP inom 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 intressen som håller det externa gränssnittet stabilt oavsett vad som ändras internt. För en detaljerad jämförelse av hur de två protokollen delar upp arkitekturens ansvar och när du faktiskt behöver båda, se A2A vs MCP: Do AI Agents Really Need Both Protocols?

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
• ett testharness
• en app med användargränssnitt

Agenten kan vara:

• en specialiserad 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.

Agent Cards (Agentkort)

Agentkortet är ett av de viktigaste koncepten i A2A.

Ett Agentkort beskriver en agent – det är upptäcksdokumentet 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äcksdokument
• agentprofil
• avtalsyta

Ett typiskt Agentkort kan beskriva saker som:

• agentnamn
• beskrivning
• tjänstendpoint
• understödda protokollfunktioner
• understödda in- och utmattningslägen
• tillgängliga färdigheter
• autentiseringskrav
• leverantörsinformation
• versionsinformation
• dokumentationslänkar
• valfri metadata

Agentkortet är viktigt eftersom agenter inte behöver hårdkodad kunskap om var och en annan agent.

En klient kan inspektera kortet och besluta:

• Är detta rätt agent för jobbet?
• Stödjer den innehållstypen jag behöver?
• Stödjer 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 Agentkort grunden för agentregister, developer-portaler och interna agentkataloger – det maskinläsbara motsvarigheten till en tjänstdirectory där klienter kan slå upp vad som är tillgängligt innan de begår sig på en integration.

Agentkort är kapacitetsgränser

Ett Agentkort bör inte behandlas som marketingtext – det är en kapacitetsgränser som andra system kommer att lita 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ödjer streaming, kan klienter förvänta sig händelser om framsteg.

Dåliga Agentkort skapar dåliga system eftersom rutteringsbeslut 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 “gör affärssaker” är inte hjälpsam.

En bättre färdighet är:

Analysera SaaS-faktura-data och producera en månadsvis kostnadssammanfattning.

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

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

Ju mer precist Agentkortet är, desto lättare är det för andra agenter att rätta uppgifter korrekt.

Agentupptäckt

Agentupptäckt är processen att hitta ett Agentkort.

I enkla distributioner kan upptäckten vara statisk. En klient känner redan till URL:en för en specifik agent.

I större distributioner kan upptäckten involvera:

• ett register
• en developer-portal
• en intern katalog
• DNS-baserad upptäckt
• konfigurationshantering
• miljöspecifik ruttering
• tenantmedvetna gateways

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

Inte alla agenter bör vara upptäckbara 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 omfatta synlighet är ett förstaklass-designval.

Uppgifter (Tasks)

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 streama 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 röra sig genom olika tillstånd.

Den exakta tillståndsmodellen beror på protokollversionen och implementeringen, 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 arbetsenhet 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?
• Har den misslyckats?
• Har den avbrutits?
• 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 forskningsagent returnera en uppgift omedelbart, och sedan fortsätta arbeta i bakgrunden medan den streamar händelser om framsteg eller gör resultatet tillgängligt senare.

Tillståndsloset meddelande eller tillståndsbunden uppgift

A2A stödjer 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 överdesigna korta interaktioner till fulla uppgiftsflöden lägger onödig overhead.

Om en klient frågar:

Sammanfatta denna ena stycke.

Kan ett direkt svar räcka.

Om en klient frågar:

Forska om de fem främsta open source-vektordatabaserna, jämför dem och producera ett migrationsförslag.

Ä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, tillståndsbundet, granskningsbart 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
• sammanhang om 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ärd om detta.

Ett meddelande kan inkludera:

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

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

Delar (Parts)

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

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

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

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

En del kan också inkludera metadata såsom:

• mediatyp
• filnamn
• ytterligare sammanhang

Mediatypen ä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 kollapsa allt till ren text – om en nedströmsagent behöver ett kalkylark, en bild, en JSON-payload, en loggfil eller en PDF, bör protokollet bevara det innehållet som innehåll snarare än att vränga det till ett stycke. Bra agentsystem undviker dessa onödiga textflaskhalsar genom att låta varje del bära sin naturliga mediatyp hela vägen till konsumenten.

Artefakter

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

Detta är annorlunda ä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 forskningsagent säger “Jag hittade 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 sammansättbart. 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 konversation.
Artefakter är utdata.

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

Till exempel, i ett softwareutvecklingsarbetsflöde:

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

Denna separation är hjälpsam eftersom den undviker att blanda ihop uppgifts koordinering med leveranser, vilket gör det mycket lättare att logga, granska 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 utvecklar dokumentation för vår nya fakturerings webhook API.

Den primära assistenten kontrollerar 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 i 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ålpubliken

Dokumentationsagenten skapar en Uppgift.

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

Dokumentationsagenten kan skicka meddelanden såsom:

Jag extraherar endpoint-beskrivningar.

Sedan:

Jag behöver förtydligande om 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 vanligt HTTP API-anrop är ofta för tunt för agentarbete. Agentuppgifter kan involvera osäkerhet, flera steg, mellanresultat och uppföljningsfrå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:

• forskningsarbetsflöden
• kodgenerering
• dataanalys
• efterlevnadsgranskning
• dokumentproduktion
• incidentutredning
• flerstegsplanering
• arbetsflöden för mänskligt godkännande

Utan en upgiftsmodell brukar utvecklare bygga om denna logik själva med anpassade job-ID:n, köer, statusendpoints och webhook-återanrop – A2A försöker standardisera den agentspecifika versionen av det mönstret så att du inte behöver uppfinna det om för varje ny agentintegration.

Streaming och asynkront arbete

A2A stödjer idén att agentarbete kan vara streaming eller asynkront.

Streaming är användbart när klienten vill ha liveuppdateringar.

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
• granskning av flera agenter
• databearbetning
• mänskligt godkännande
• batchanalys

I praktiken bör ett robust A2A-system designas runt tre lägen: omedelbart svar för enkelt arbete, streaming för interaktivt långvarigt arbete och asynkront för hållbart bakgrundarbete som kan överleva någon enskild anslutning.

Agentkort och streamingstöd

Ett Agentkort kan annonsera om en agent stödjer streaming.

Detta är viktigt eftersom klienter inte kan anta att alla agenter stödjer streaming – vissa agenter kan bara stödja enkel begäran och svar, vissa kan stödja uppgifts polling, 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örningsbeteende.

A2A och multimodala agenter

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

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

• text
• bilder
• ljud
• video
• PDF:er
• kalkylark
• 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 motta en bild som en bild, inte som en svag textbeskrivning. En finansagent bör motta strukturerad kalkylarkdata, inte ett kopierat stycke. En kodgranskningsagent bör motta källfiler eller diffar, inte en vag sammanfattning.

Delar och mediatyper ä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 kaskaderar ö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:

• resonemangstrategi
• planeringsalgoritm
• minnessystem
• 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 agentimplementeringar 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-avtal, kan ett vanligt API vara bättre.

Till exempel:

• valutoräkningsomvandling
• adressvalidering
• fakturansökning
• bildstorleksjustering
• 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 gör mening när det externa systemet verkligen beter sig som en agent:

• det äger en uppgift
• det kan be om mer indata
• det kan använda verktyg internt
• det kan ta tid
• det kan producera artefakter
• det har kapaciteter som är värda att upptäcka
• det 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 distribuerbara agenter.

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

Användare
  |
  v
Primär assistent
  |
  |-- A2A --> Forskningsagent
  |-- A2A --> Kodningsagent
  |-- A2A --> Efterlevnadsagent
  |-- A2A --> Dokumentationsagent

Varje specialagent kan internt använda verktyg:

Forskningsagent
  |
  |-- MCP --> websökning
  |-- MCP --> dokumentlager
  |-- MCP --> vektordatabas

Detta ger dig separata lager:

Användargränssnittslager
Agentkoordineringlager
Verktygsintegrationslager
Data- och exekveringslager

A2A finns i agentkoordineringslaget, MCP finns ofta i verktygsintegrationslaget, och vanliga API:er, köer, databaser och lagersystem finns under det – varje lager med sin egen abstraktion och sina egna felmoder. För en tvärsnittskarta över hur LLM-inferens, minne, ruttering, verktyg och observabilitet passar ihop inom produktionsassistenter, se AI Assistant Architecture: LLM, Memory, Tools, Routing, Observability.

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 bitar av arbete till specialagenter.

Exempel:

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

Detta mönster är enkelt att förstå: orkestratorn äger det övergripande arbetsflödet, och specialagenter äger domänspecifikt arbete. Nackdelen är att orkestratorn kan bli en flaskhals, och den behöver en solid rutteringsstrategi för att delegera effektivt – de underliggande modellvalen och orkestreringsavvägningarna täcks i Multi-Model System Design: When One Model Isn’t Enough. Ändå, för de flesta team är detta den bästa första multi-agent-arkitekturen att nå för 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:

Forskningsagent --> Dataagent --> Diagramagent --> Skrivagent

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

Du behöver starka regler för:

• vem som kan anropa vem
• vilket sammanhang som kan delas
• hur looper förhindras
• vem som äger slututdata
• hur kostnad kontrolleras
• hur delegering granskas

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 trafik genom en gateway.

Gatewayen kan hantera:

• autentisering
• auktorisering
• ruttering
• tenantmappning
• loggning
• hastighetsgränser
• policykontroller
• protokollversionshantering
• observabilitet
• revisionsspår

Detta är särskilt användbart i företagsmiljöer, där gatewayen blir kontrollplanet för agentkommunikation – som genomför policy på en plats snarare än att implementera det om över varje agent. I mindre system kan detta vara överkill, 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 seriös uppmärksamhet.

Agent-til-agent-kommunikation kan flytta känsligt sammanhang över gränser. Det 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 bifogade till anroparen?
• Kan en agent delegera användarbehörighet till en annan?
• Vilka data kan inkluderas i meddelanden?
• Vilka artefakter kan returneras?
• Hur granskas 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 publiceras öppet. Olika klienter behöver ofta olika vy av samma agent – en intern anropare kan se fler färdigheter än en extern partner, medan en offentlig klient kan se bara 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 agenttopologi är betydligt svårare än att designa dem in.

Observabilitetsöverväganden

A2A-system behöver stark observabilitet.

När en uppgift korsar agentgränser, blir felsökning avsevärt 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 förekom
• 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ände riskabla åtgärder

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

Till exempel:

användarbegäran
  -> primär assistent uppgift
  -> forskningsagent uppgift
  -> dokument sökverktygsanrop
  -> sammanfattningsartefakt
  -> slutlig 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 resultat, än mindre identifiera var det gick fel. Observability for LLM Systems: Metrics, Traces, Logs, and Testing in Production täcker instrumenteringen och verktygssidan av detta problem i djupet.

Vanliga misstag

Misstag 1: Att kalla varje verktyg för 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ärssaker.

Det är användbart för ingen agent som försöker rätta arbete intelligently. 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äran 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 bygga om samma livscykel-spårningslogik i varje integration.

Misstag 4: Att returnera allt som text

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

Om utdata är en rapport, returnera en rapportartefakt.

Om utdata är JSON, returnera strukturerade data.

Om utdata ä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 bör få anropa varje annan agent med varje typ av data – använd autentisering, auktorisering och revisionsspår för att genomföra principen om minsta behörighet över agentnätverket.

När ska du använda A2A?

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

Godta skäl inkluderar:

• agenter ägs av olika team
• agenter distribueras 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 ska 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 vanligt 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 bara kommer ihåg 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 av A2A – resten handlar mest om att göra dessa fem koncept tillförlitliga, observerbara och säkra nog att använda i verkliga produktionssystem.

Sista tankar

A2A är inte bara ett nytt AI-akronym – det är en del av en större förskjutning från isolerade assistenter till interoperabla agentsystem. Den förskjutningen kommer inte 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 vanliga API:er är helt tillräckliga.

Men när agenter blir separat distribuerade jämlikar, behöver du starkare gränser: upptäckt, uppgiftsägarskap, meddelanden som bär mer än text, artefakter som förstaklass-utdata, och säkerhet, tillstånd och observabilitet som spänner över agentgränser. Det är det utrymme A2A försöker upptäcka, och det är ett genuint annorlunda problem från verktygsintegrationsproblemet MCP löser.

För en praktisk syn på var A2A faktiskt har produktionsfäste 2026 – inklusive adaptionstrappar, säkerhetsbekymmer, företagsfallet och ett beslutsramverk – se Google A2A Protocol in 2026: Adoption, Hype, and Reality.

Min åsikt: börja inte med A2A för små projekt. Börja med en användbar agent, bra verktyg och klar arkitektur – AI Systems cluster täcker självhostade assistenter, MCP-servrar och agentminne som en sammanhängande uppsättning om du vill ha bredare sammanhang. Men när ditt “verktyg” börjar se ut som en annan autonom specialist med sin egen uppgiftslivscykel, är det troligen inte längre bara ett verktyg – och det är då 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/