Hvad er Agent2Agent (A2A)? Sådan kommunikerer og samarbejder AI‑agenter

Agent2Agent (A2A) er en åben protokol, der gør det muligt for AI‑agenter at opdage hinanden, udveksle beskeder, delegere opgaver, rapportere fremskridt og returnere resultater på tværs af systemgrænser. Den er designet til situationer, hvor en agent har brug for hjælp fra en anden uden at kræve, at nogen af parterne afslører sin interne resonering, hukommelse eller implementering.

Når organisationer implementerer specialiserede agenter, bliver kommunikation et infrastrukturproblem. En indkøbsagent kan have brug for information fra en compliance‑agent; en kundeservice‑agent kan have brug for en logistik‑agent til at undersøge en forsendelse. A2A giver en fælles måde at koordinere dette arbejde på, selv når agenterne bruger forskellige rammer, leverandører eller modeller.

Hvorfor agenter har brug for en kommunikationsstandard

Traditionelle API’er eksponerer funktioner og data, men en agent‑til‑agent‑interaktion kan være mere åben. Den modtagende agent kan have brug for at fortolke et mål, beslutte, hvordan det skal løses, stille opfølgende spørgsmål, arbejde i minutter eller timer, streame opdateringer og returnere flere artefakter.

Uden en fælles protokol ville hver platform definere sine egne formater for identitet, opdagelse af evner, opgaver, beskeder, status og fejl. Denne fragmentering gør tværplatforms‑delegation vanskelig og låser nyttige agenter inde i enkelte produkter.

A2A standardiserer kommunikationslaget, samtidig med at hver agent kan forblive en sort boks. Den aktuelle A2A‑specifikationen definerer protokollens kerneobjekter og interaktioner.

De vigtigste roller i A2A

Denne adskillelse er det, der gør A2A anderledes end et simpelt funktionskald. Den fjernstående deltager kan håndtere en langvarig opgave, anmode om yderligere information, forhandle understøttede indholdstyper og returnere én eller flere artefakter. Klient‑agenten sporer den opgave, mens den bevarer identiteten og autoriteten for den bruger eller applikation, der initierede den.

En A2A‑interaktion involverer typisk to logiske roller:

• Client agent: agenten eller applikationen, der anmoder om arbejde.
• Remote agent: agenten, der modtager anmodningen og udfører eller koordinerer arbejdet.

Ordene “klient” og “fjern” beskriver den aktuelle interaktion, ikke en permanent hierarki. Den samme agent kan anmode om arbejde i én kontekst og betjene en anden agent i en anden kontekst.

Agentkort: Opdagelse af evner

Før en opgave kan delegeres, skal en klient vide, hvad en fjernagent kan gøre, og hvordan man kommunikerer med den. A2A bruger et agentkort til at offentliggøre beskrivende og operationel metadata.

Et agentkort kan beskrive en agents navn, endpoint, understøttede protokolfunktioner, autentificeringsforventninger, færdigheder og accepterede indholdstyper. En færdighed er et erklæret område af kapabilitet, såsom at oversætte et dokument, gennemgå en kontrakt eller undersøge et marked.

Opdagelse beviser ikke kvalitet eller pålidelighed. Et agentkort er et krav om kapabilitet, ikke en uafhængig certificering. Produktionssystemer har stadig brug for identitet, autorisation, politik‑kontroller, omdømme og evaluering.

Beskeder, Opgaver og Artefakter

A2A repræsenterer samarbejde gennem flere kerneobjekter.

Beskeder

Beskeder overfører kommunikation mellem agenter. De kan indeholde tekst og andre strukturerede dele, så agenterne kan udveksle instruktioner, afklaringer eller kontekstuelt materiale.

Opgaver

En opgave repræsenterer en arbejdsenhed, hvis tilstand kan ændre sig over tid. En fjernagent kan acceptere arbejdet, fortsætte behandlingen, anmode om yderligere input, fuldføre det, fejle eller annullere det. En vedvarende opgaveidentitet er nyttig for langvarige operationer, fordi klienten kan referere til den samme job på tværs af opdateringer.

Artefakter

Artefakter er de output, der produceres af arbejdet, såsom en rapport, datasæt, billede, kode‑patch eller struktureret anbefaling. At adskille artefakter fra konverserende beskeder gør det lettere for klienten at identificere og forbruge de endelige leverancer.

Hvordan en A2A‑interaktion fungerer

Antag, at en rejseplanlægningsagent har brug for en specialist til at verificere indrejsekrav.

1. Klienten opdager en fjernagent og læser dens Agent Card.
2. Den tjekker, at agenten annoncerer den relevante funktionalitet og en kompatibel interaktionsmetode.
3. Klienten autentificerer og sender en besked, der beskriver opgaven, rejsende, datoer og påkrævet output.
4. Den fjernagent opretter eller opdaterer en opgave og påbegynder arbejdet.
5. Den fjernagent kan streame fremskridt eller anmode om en manglende detalje.
6. Klienten leverer afklaringen, mens opgavekonteksten bevares.
7. Den fjernagent fuldfører opgaven og returnerer et struktureret artefakt med sit resultat.
8. Klienten evaluerer resultatet, før det bruges i den overordnede rejseplan.

Den fjernagent beslutter, hvordan den skal udføre sin opgave. Den kan kalde sine egne værktøjer, konsultere private data eller koordinere yderligere agenter. A2A kræver ikke, at disse interne trin afsløres.

A2A vs. MCP

Protokollerne kan placeres på forskellige lag af den samme arkitektur. En rejseplanlægningsagent kan delegere en specialistopgave for visumforskning via A2A. Den specialistagent kan derefter bruge MCP-forbindelser til at søge i godkendte databaser og hente politikdokumenter. A2A koordinerer ansvar mellem agenter; MCP standardiserer adgang mellem en AI-vært og funktioner.

A2A og Model Context Protocol løser forskellige integrationsproblemer.

• MCP forbinder en AI-applikation med værktøjer og kontekst. En klient opdager kapaciteter såsom funktioner, ressourcer og prompts fra en MCP-server.
• A2A forbinder agenter med agenter. En klient kan delegere en målorienteret opgave til en fjernagent, som kan håndtere sin egen proces og returnere et resultat.

Forskellen svarer til at bruge et værktøj versus at hyre en specialist. En lommeregner afslører en operation; en analytiker accepterer et mål og beslutter, hvilke operationer der er nødvendige. I reelle systemer kan en fjern A2A-agent bruge MCP internt til at nå sine egne værktøjer og data.

A2A vs. Almindelige API’er

Et konventionelt API er ideelt, når kaldet kender den præcise operation og inputformat: hente en post, beregne et tilbud eller opdatere et felt. A2A er nyttigt, når anmodningen er samtalebaseret, tilstandsfuld, asynkron eller resultatorienteret.

A2A erstatter ikke alle API’er. Fjernagenter kalder ofte almindelige API’er for at udføre deres arbejde, og organisationer kan eksponere deterministiske tjenester direkte, når agentens skøn ikke tilføjer værdi.

Hvorfor interoperabilitet er vigtigt

Agent-økosystemer vil være heterogene. Forskellige teams vil optimere for forskellige domæner, modeller, sikkerhedsgrænser og implementeringsmiljøer. En fælles protokol giver organisationer mulighed for at bevare denne specialisering, samtidig med at samarbejde muliggøres.

Interoperabilitet kan også reducere integrationskoblingen. En klient kan stole på en erklæret færdighed og protokoladfærd i stedet for at importere den fjernede agents framework eller duplikere dens interne logik. A2A-projektets oversigt beskriver dette mål som at gøre det muligt for agenter bygget på forskellige stakke at kommunikere som jævnaldrende; projektets opdatering i 2026 om at tilslutte Agentic AI Foundation afspejler presset mod neutral, tværindustriel styring.

Sikkerheds- og tillidsudfordringer

Delegation skaber en ansvarskæde. Klienten skal verificere den fjernede agents identitet og annoncerede kapacitet, minimere den kontekst den deler, og bevare den initierende brugers autorisation. Den fjernede agent bør ikke arve brede rettigheder blot fordi en anden agent har anmodet om opgaven. Hvert hop kræver autentificering, afgrænsede legitimationsoplysninger, sporbarhed og en klar regel for, hvad der sker, når krav konflikterer eller tilliden er lav.

Agent-til-agent-delegation skaber en autoritetkæde. En klient kan ved et uheld dele følsom kontekst, give en fjern agent mere skøn end tilsigtet, eller handle på et upålideligt artefakt. Den fjernede agent kan også modtage ondsindede instruktioner eller filer fra en ikke‑betroet klient.

Stærke implementeringer kræver kontrol på flere lag:

• Identitet og autentificering: verificer hvilken agent og organisation der deltager.
• Autorisation: begræns de færdigheder, data, handlinger og opgavescope, der er tilgængelige for hver opkalder.
• Dataminimering: del kun den kontekst, den fjernede agent har brug for.
• Oprindelse: registrer hvem der anmodede om arbejdet, hvilken agent der producerede det, og hvilke kilder der understøtter det.
• Outputvalidering: betragt fjernartefakter som upålidelige, indtil de bestå relevante kontroller.
• Delegationsgrænser: styr om en fjern agent må involvere yderligere agenter eller tjenester.
• Menneskelig godkendelse: pause før finansielle, juridiske, eksterne, destruktive eller på anden måde konsekvensfulde handlinger.

Protokolkompatibilitet indebærer ikke organisatorisk tillid. En agent kan tale A2A korrekt og stadig være upassende for en bestemt opgave.

Hvornår bør teams bruge A2A?

A2A er mest overbevisende, når uafhængige agenter skal samarbejde på tværs af produkt-, leverandør- eller organisationsgrænser; når arbejdet er langvarigt; eller når det modtagende system skal bevare friheden til, hvordan det producerer resultatet.

Det kan være unødvendigt for en simpel funktion, en fast intern arbejdsproces eller tæt koblede komponenter inden for én applikation. I sådanne tilfælde kan en almindelig API, en event‑bus eller et direkte værktøjs‑kald være lettere at operere og evaluere.

Hvad man skal huske om, hvad Agent2Agent (A2A) er

A2A leverer et fælles sprog, så agenter kan opdage kapaciteter og koordinere målrettet arbejde uden at dele deres interne maskineri. Dens kerneværdi er ikke, at flere agenter automatisk er bedre end én, men at uafhængigt byggede specialister kan samarbejde gennem en stabil grænse.

Den grænse skal bære mere end beskeder. Den kræver identitet, opgavetilstand, artefakter, tilladelser, oprindelse og fejlhåndtering. A2A leverer protokolfundamentet; organisationer leverer stadig tillidsmodellen.