Hva er Agent2Agent (A2A)? Hvordan AI‑agenter kommuniserer og samarbeider

Agent2Agent (A2A) er en åpen protokoll som gjør det mulig for AI‑agenter å oppdage hverandre, utveksle meldinger, delegere oppgaver, rapportere fremdrift og returnere resultater på tvers av systemgrenser. Den er designet for situasjoner hvor en agent trenger hjelp fra en annen uten at noen av partene må eksponere sin interne resonnering, minne eller implementasjon.

Etter hvert som organisasjoner distribuerer spesialiserte agenter, blir kommunikasjon et infrastrukturelt problem. En innkjøpsagent kan trenge informasjon fra en samsvarsagent; en kundeservice‑agent kan trenge en logistikkagent for å undersøke en forsendelse. A2A gir en felles måte å koordinere dette arbeidet på, selv når agentene bruker ulike rammeverk, leverandører eller modeller.

Hvorfor agenter trenger en kommunikasjonsstandard

Tradisjonelle API‑er eksponerer funksjoner og data, men en agent‑til‑agent‑interaksjon kan være mer åpen. Den mottakende agenten kan måtte tolke et mål, bestemme hvordan det skal løses, stille oppfølgingsspørsmål, arbeide i minutter eller timer, strømme oppdateringer og returnere flere artefakter.

Uten en felles protokoll vil hver plattform definere sine egne formater for identitet, oppdagelse av evner, oppgaver, meldinger, status og feil. Denne fragmenteringen gjør tverrplattform‑delegasjon vanskelig og låser nyttige agenter inne i enkeltprodukter.

A2A standardiserer kommunikasjonslaget samtidig som hver agent kan forbli en sort boks. Den nåværende A2A spesifikasjon definerer protokollens kjerneobjekter og interaksjoner.

De viktigste rollene i A2A

Denne separasjonen er det som gjør A2A forskjellig fra et enkelt funksjonskall. Den eksterne deltakeren kan håndtere en langvarig oppgave, be om tilleggsinformasjon, forhandle om støttede innholdstyper og returnere ett eller flere artefakter. Klientagenten følger oppgaven mens den bevarer identiteten og autoriteten til brukeren eller applikasjonen som initierte den.

En A2A‑interaksjon involverer vanligvis to logiske roller:

• Klientagent: agenten eller applikasjonen som ber om arbeid.
• Fjernagent: agenten som mottar forespørselen og utfører eller koordinerer arbeidet.

Ordene «klient» og «fjern» beskriver den aktuelle interaksjonen, ikke et permanent hierarki. Den samme agenten kan be om arbeid i én kontekst og betjene en annen agent i en annen kontekst.

Agentkort: Oppdage evner

Før en oppgave delegere, trenger en klient å vite hva en fjernagent kan gjøre og hvordan man kommuniserer med den. A2A bruker et agentkort for å publisere beskrivende og operative metadata.

Et agentkort kan beskrive en agents navn, endepunkt, støttede protokollfunksjoner, autentiseringsforventninger, ferdigheter og aksepterte innholdstyper. En ferdighet er et deklarert kompetanseområde, som å oversette et dokument, sjekke en kontrakt eller undersøke et marked.

Oppdagelse beviser ikke kvalitet eller pålitelighet. Et agentkort er et påstand om evne, ikke en uavhengig sertifisering. Produksjonssystemer trenger fortsatt identitet, autorisasjon, policy‑kontroller, omdømme og evaluering.

Meldinger, oppgaver og artefakter

A2A representerer samarbeid gjennom flere kjerneobjekter.

Meldinger

Meldinger bærer kommunikasjon mellom agenter. De kan inneholde tekst og andre strukturerte deler, som gjør det mulig for agentene å utveksle instruksjoner, presiseringer eller kontekstuelt materiale.

Oppgaver

En oppgave representerer en arbeidsenhet hvis tilstand kan endre seg over tid. En fjernagent kan akseptere arbeidet, fortsette behandlingen, be om mer input, fullføre det, feile eller avbryte det. Vedvarende oppgaveidentitet er nyttig for langvarige operasjoner fordi klienten kan referere til samme jobb på tvers av oppdateringer.

Artefakter

Artefakter er resultatene som produseres av arbeidet, som en rapport, datasett, bilde, kodepatch eller strukturert anbefaling. Å skille artefakter fra konversasjonsmeldinger gjør det enklere for klienten å identifisere og bruke de endelige leveransene.

Hvordan en A2A‑interaksjon fungerer

Anta at en reiseplanleggingsagent trenger en spesialist for å verifisere innreisekrav.

1. Klienten oppdager en ekstern agent og leser dens Agentkort.
2. Den sjekker at agenten annonserer den relevante funksjonen og en kompatibel interaksjonsmetode.
3. Klienten autentiserer og sender en melding som beskriver oppgaven, reisende, datoer og ønsket resultat.
4. Den eksterne agenten oppretter eller oppdaterer en oppgave og begynner arbeidet.
5. Den eksterne agenten kan strømme fremdrift eller be om en manglende detalj.
6. Klienten leverer avklaringen mens oppgavekonteksten bevares.
7. Den eksterne agenten fullfører oppgaven og returnerer et strukturert artefakt med resultatet.
8. Klienten evaluerer resultatet før det brukes i den overordnede reiseplanen.

Den eksterne agenten bestemmer hvordan oppdraget skal utføres. Den kan kalle sine egne verktøy, konsultere private data eller koordinere ytterligere agenter. A2A krever ikke at disse interne trinnene avsløres.

A2A vs. MCP

Protokollene kan ligge på ulike lag i samme arkitektur. En reiseplanleggingsagent kan delegere en spesialistoppgave for visumforskning via A2A. Den spesialisteagenten kan deretter bruke MCP-tilkoblinger til å søke i godkjente databaser og hente policy-dokumenter. A2A koordinerer ansvar mellom agenter; MCP standardiserer tilgangen mellom en AI-vert og funksjoner.

A2A og Model Context Protocol løser ulike integrasjonsproblemer.

• MCP kobler en AI-applikasjon til verktøy og kontekst. En klient oppdager evner som funksjoner, ressurser og forespørsler fra en MCP-server.
• A2A kobler agenter til agenter. En klient delegere en målrettet oppgave til en ekstern agent som kan håndtere sin egen prosess og returnere et resultat.

Forskjellen ligner på å bruke et verktøy versus å ansette en spesialist. En kalkulator eksponerer en operasjon; en analytiker aksepterer et mål og bestemmer hvilke operasjoner som trengs. I virkelige systemer kan en ekstern A2A-agent bruke MCP internt for å nå sine egne verktøy og data.

A2A vs. Vanlige API-er

Et konvensjonelt API er ideelt når den som kaller kjenner den eksakte operasjonen og inndataformatet: hente en post, beregne et tilbud eller oppdatere et felt. A2A er nyttig når forespørselen er samtalebasert, tilstandsfølsom, asynkron eller resultatorientert.

A2A erstatter ikke alle API-er. Eksterne agenter kaller ofte vanlige API-er for å utføre arbeidet sitt, og organisasjoner kan eksponere deterministiske tjenester direkte når agentens skjønn ikke tilfører verdi.

Hvorfor interoperabilitet er viktig

Agent-økosystemer vil være heterogene. Ulike team vil optimalisere for ulike domener, modeller, sikkerhetsgrenser og distribusjonsmiljøer. En felles protokoll lar organisasjoner bevare den spesialiseringen samtidig som den muliggjør samarbeid.

Interoperabilitet kan også redusere integrasjonskoblingen. En klient kan stole på en deklarert ferdighet og protokollatferd i stedet for å importere den eksterne agentens rammeverk eller duplisere sin interne logikk. A2A-prosjektets oversikt beskriver dette målet som å gjøre det mulig for agenter bygget på ulike stakker å kommunisere som jevnaldrende; prosjektets oppdatering for 2026 om å bli med i Agentic AI Foundation reflekterer presset mot nøytral, tverrindustriell styring.

Sikkerhets- og tillitsutfordringer

Delegasjon skaper en ansvarskjede. Klienten må verifisere den eksterne agentens identitet og annonserte evne, minimere konteksten den deler, og bevare den initierende brukerens autorisasjon. Den eksterne agenten bør ikke arve brede privilegier bare fordi en annen agent har forespurt oppgaven. Hvert hopp krever autentisering, avgrensede legitimasjoner, sporbarhet og en klar regel for hva som skjer når krav er i konflikt eller tilliten er lav.

Agent-til-agent-delegasjon skaper en autoritetskjed. En klient kan ved et uhell dele sensitiv kontekst, gi en ekstern agent mer skjønn enn tiltenkt, eller handle på et upålitelig artefakt. Den eksterne agenten kan også motta ondsinnede instruksjoner eller filer fra en uklar klient.

Robuste distribusjoner krever kontroller på flere lag:

• Identity and authentication: verifiser hvilken agent og organisasjon som deltar.
• Authorization: begrens ferdighetene, dataene, handlingene og oppgaveskopet som er tilgjengelige for hver påkaller.
• Data minimization: del kun den konteksten den eksterne agenten trenger.
• Provenance: registrer hvem som ba om arbeidet, hvilken agent som produserte det, og hvilke kilder som støtter det.
• Output validation: behandle eksterne artefakter som upålitelige til de har bestått relevante kontroller.
• Delegation limits: kontroller om en ekstern agent kan involvere ytterligere agenter eller tjenester.
• Human approval: pause før finansielle, juridiske, eksterne, destruktive eller på annen måte konsekvensfulle handlinger.

Protokollkompatibilitet innebærer ikke organisatorisk tillit. En agent kan snakke A2A korrekt og likevel være upassende for en bestemt oppgave.

Når bør team bruke A2A?

A2A er mest overbevisende når uavhengige agenter må samarbeide på tvers av produkt-, leverandør- eller organisasjonsgrenser; når arbeidet er langvarig; eller når mottakssystemet skal beholde friheten til hvordan det produserer resultatet.

Det kan være unødvendig for en enkel funksjon, en fast intern arbeidsflyt eller tett koblede komponenter innen én applikasjon. I slike tilfeller kan et vanlig API, en hendelsesbuss eller et direkte verktøykall være enklere å håndtere og evaluere.

Hva du bør huske om hva Agent2Agent (A2A) er

A2A gir et felles språk for agenter til å oppdage evner og koordinere målrettet arbeid uten å dele sin interne maskinering. Dens kjerneverdi er ikke at flere agenter automatisk er bedre enn én, men at uavhengig bygde spesialister kan samarbeide gjennom en stabil grense.

Den grensen må bære mer enn meldinger. Den trenger identitet, oppgavestatus, artefakter, tillatelser, proveniens og feilbehandling. A2A leverer protokollfundamentet; organisasjoner leverer fortsatt tillitsmodellen.