ms-ai-architect/skills/ms-ai-engineering/references/agent-orchestration/agent-to-agent-a2a-protocol.md

Agent2Agent (A2A) Protocol — Åpen Standard for Agent-Interoperabilitet

Last updated: 2026-06-18 | Verified: 2026-06-18 Status: Stabil (protokollspesifikasjon v1.0) / Preview (Microsofts A2A-SDK + Agent Framework A2A-pakker) Category: Agent Orchestration & Automation

---

Introduksjon

Agent2Agent (A2A) er en åpen standardprotokoll for kommunikasjon og samarbeid mellom autonome AI-agenter på tvers av rammeverk, leverandører og organisasjonsgrenser. Protokollen ble lansert av Google i april 2025 og donert til Linux Foundation i juni 2025, der den nå forvaltes som et nøytralt open source-prosjekt.

Kjerneproblemet A2A løser: Agenter er typisk siloer — en agent bygget med Semantic Kernel, en annen med LangChain, en tredje hos en ekstern partner. Uten en felles protokoll kan de ikke kommunisere. A2A gir dem et felles språk: standardisert discovery, meldingsformat, oppgavelivssyklus og sikkerhet — uavhengig av plattform.

Microsoft har implementert A2A-støtte i Foundry Agent Service, Copilot Studio, Semantic Kernel og Teams AI Library. Azure API Management kan frontes som A2A-gateway med governance og observability.

Historikk og governance

Milepæl	Dato
Lansert av Google Cloud	April 2025
50+ partnere (Accenture, Atlassian, Cohere, Salesforce, Microsoft m.fl.)	April 2025
Donert til Linux Foundation	Juni 2025
Protokollversjon v0.3	2025
Protokollversjon v1.0 (første stabile, produksjonsklare versjon)	2026
Microsoft Foundry A2A-støtte (preview)	2025–2026

A2A v1.0 (stabil): Den første stabile, produksjonsklare versjonen av protokollen. Fire hovednyheter: Signed Agent Cards (kryptografisk verifisering av agentidentitet/metadata før interaksjon på tvers av organisasjonsgrenser), multi-tenancy (ett endepunkt kan trygt hoste flere agenter — relevant for SaaS), multi-protocol bindings (samme logiske agent eksponert over både JSON-RPC og gRPC), og versjonsforhandling (spec-nivå-garanti for bakoverkompatibel migrering fra v0.3 til v1.0). v0.3 er fortsatt støttet — agenter kan annonsere både v0.3 og v1.0 samtidig for gradvis migrering.

Viktig nyanse (juni 2026): Selve A2A-protokollen er v1-stabil, men Microsofts A2A-SDK og Agent Framework A2A-pakkene (agent-framework-a2a, Microsoft.Agents.AI.Hosting.A2A/.AspNetCore) er fortsatt i preview. Bygg på den stabile v1-protokollen for langsiktig garanti, men behandle .NET-/Python-verktøyet rundt den som experimental — IKKE «GA i MAF».

---

Protokolldesign

A2A er bygget på eksisterende webstandarder:

• Transport: HTTP(S) med JSON-RPC 2.0 som primært meldingsformat
• Streaming: Server-Sent Events (SSE) for sanntidsoppdateringer
• Push-notifikasjoner: Webhook-callbacks for langtidsoppgaver (asynkron prosessering)
• Discovery: /.well-known/agent.json (noen implementasjoner: /.well-known/agent-card.json)

JSON-RPC Meldingsformat

Innkommende melding (client → agent):

{
  "jsonrpc": "2.0",
  "method": "message/send",
  "params": {
    "message": {
      "kind": "message",
      "role": "user",
      "parts": [
        {
          "kind": "text",
          "text": "Hva er status på sak 2024-1234?",
          "metadata": {}
        }
      ],
      "messageId": "msg-uuid-123",
      "contextId": "conversation-context-id"
    }
  },
  "id": "request-id"
}

Svar (agent → client):

{
  "jsonrpc": "2.0",
  "result": {
    "kind": "message",
    "role": "agent",
    "parts": [
      {
        "kind": "text",
        "text": "Sak 2024-1234 er under behandling. Estimert ferdigdato: 15. mars 2026."
      }
    ],
    "messageId": "resp-uuid-456",
    "contextId": "conversation-context-id"
  },
  "id": "request-id"
}

Standard JSON-RPC-metoder

Metode	Formål
message/send	Send melding og vent på svar (synkron)
message/stream	Send melding og motta strømmede svar (SSE)
tasks/get	Hent status på en langtidsoppgave
tasks/cancel	Kanseller en pågående oppgave

---

Agent Cards — Discovery og Kapabilitetsannonsering

En Agent Card er et JSON-manifest som agenten eksponerer på /.well-known/agent.json. Det fungerer som et digitalt visittkort: andre agenter og orkestratorer bruker det til å oppdage hva agenten kan gjøre og hvordan den skal nås.

{
  "name": "NAV Saksbehandler-agent",
  "description": "Håndterer spørsmål om dagpenger, uføretrygd og sykepenger",
  "version": "1.2.0",
  "url": "https://agents.nav.no/saksbehandler/a2a",
  "capabilities": {
    "streaming": true,
    "pushNotifications": true,
    "stateTransitionHistory": false
  },
  "skills": [
    {
      "id": "dagpenger-oppslag",
      "name": "Dagpenger-oppslag",
      "description": "Slår opp dagpengekrav og beregner stønadssats",
      "inputModes": ["text"],
      "outputModes": ["text", "data"]
    }
  ],
  "securitySchemes": {
    "bearerAuth": {
      "type": "http",
      "scheme": "bearer"
    }
  },
  "security": [{"bearerAuth": []}]
}

Nøkkelfelt i Agent Card:

Felt	Formål
name / description	Agentens identitet — brukes av orkestratorer til å vurdere om agenten passer oppgaven
url	Base-URL for A2A-kommunikasjon (ikke URL for agent card)
capabilities.streaming	Støtter SSE-strømming?
capabilities.pushNotifications	Støtter webhook-callbacks for asynkrone tasks?
skills	Liste over hva agenten kan gjøre, med input/output-modaliteter
securitySchemes	Hvilke autentiseringsmetoder støttes

Copilot Studio henter automatisk navn og beskrivelse fra Agent Card når man kobler til en ekstern A2A-agent, forutsatt at kortet er tilgjengelig på standard .well-known-URL.

---

Task-livssyklus

A2A skiller mellom meldinger (messages) for rask, synkron kommunikasjon, og tasks for langtidsoperasjoner.

[submitted] → [working] → [completed]
                 ↓              ↓
             [input-required]  [failed]
                 ↓
             [working]   (etter at klienten har svart)
                              ↓
                         [canceled]

Tilstandsbeskrivelser:

Tilstand	Beskrivelse
submitted	Task mottatt, ikke startet
working	Agent prosesserer aktivt
input-required	Agent venter på tilleggsinformasjon fra klienten (tilsvarer MCP elicitations)
completed	Task fullført med artefakter
failed	Feil oppstod
canceled	Kansellert av klienten

Python-eksempel — streaming og langtidsoppgave:

import asyncio
import httpx
from a2a.client import A2ACardResolver
from agent_framework.a2a import A2AAgent

async def main():
    a2a_host = "https://agents.nav.no/saksbehandler/a2a"

    # Discover remote agent capabilities via AgentCard
    async with httpx.AsyncClient(timeout=60.0) as http_client:
        resolver = A2ACardResolver(httpx_client=http_client, base_url=a2a_host)
        agent_card = await resolver.get_agent_card()  # Verified MCP 2026-04

    # Koble til ekstern A2A-agent
    async with A2AAgent(name=agent_card.name, agent_card=agent_card, url=a2a_host) as agent:

        # Synkron streaming
        async with agent.run("Hva er min dagpengesats?", stream=True) as stream:
            async for update in stream:
                for content in update.contents:
                    if content.text:
                        print(content.text, end="", flush=True)
            final = await stream.get_final_response()

        # Langtidsoppgave (background=True)
        response = await agent.run("Generer årsrapport for 2025", background=True)
        if response.continuation_token:
            result = await agent.poll_task(response.continuation_token)
            print(result)

---

A2A vs MCP — Komplementære Protokoller

A2A og MCP (Model Context Protocol) løser forskjellige problemer og er komplementære, ikke konkurrerende.

Dimensjon	A2A	MCP
Hva det er	Agent-til-agent kommunikasjon	Agent-til-verktøy tilkobling
Deltakere	Agenter som samarbeider som likeverdige parter	En orkestrator + passive verktøy/datakilder
Orchestration	Den invokerte agenten bruker sin egen chain-of-thought	MCP-host orkestrerer hvilke verktøy som kalles
Modaliteter	Annonserer støttede medietyper (tekst, filer, strukturert data, lyd, video)	Krever at MCP-host støtter modaliteten
Multi-turn	contextId håndterer kontekst på tvers av agenter og tasks	Kontekststyring forblir hos host
Forhandling	Dynamisk — agenten kan tilpasse seg uten klientoppdatering	Krever klientoppdatering ved nye modaliteter
Transparens	Intern logikk er ugjennomsiktig for kallende agent	Orkestrator ser og kontrollerer all verktøybruk
Beste for	Agenter eid av forskjellige team/org, kompleks delegering	Enkelt, kontrollert tilgang til APIer og data

A2A-melding inkluderer rik metadata: Hver A2A-melding inneholder et unikt contextId, messageId, locale-info, full chat-historikk (ikke bare siste melding), og content parts (tekst, tool calls, etc.). Downstream agenter kan bruke denne metadata til routing, kontekst og kontinuitet.

Typisk kombinert bruk:

Bruker → [Orkestrerings-agent]
              │
              ├─ MCP → [Database-verktøy] (henter data)
              ├─ MCP → [API-kall] (sjekker status)
              └─ A2A → [Ekstern spesialist-agent] (NAV, Skatteetaten)
                           └─ MCP → [Interne verktøy hos ekstern agent]

Valg av protokoll:

• A2A: Når agenten på den andre siden er en selvstendig aktør med sin egen resonnering, eller tilhører en annen organisasjon
• MCP: Når du vil ha full kontroll over hvilke verktøy som brukes og syntetisere svaret selv

---

Microsoft-implementasjoner

Foundry Agent Service

Foundry støtter A2A som et "tool" agenten kan bruke for å kalle eksterne A2A-endepunkter.

Forskjell: A2A-tool vs multi-agent workflow:

• A2A-tool: Agent A kaller Agent B, svaret returneres til Agent A som bruker det i sitt endelige svar. Agent A beholder kontroll.
• Multi-agent workflow: Agent A delegerer til Agent B, som tar over hele ansvaret for å svare brukeren.

from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import PromptAgentDefinition, A2ATool
from azure.identity import DefaultAzureCredential

with AIProjectClient(endpoint=endpoint, credential=DefaultAzureCredential()) as project_client:
    a2a_connection = project_client.connections.get("min-a2a-connection")

    tool = A2ATool(project_connection_id=a2a_connection.id)

    agent = project_client.agents.create_version(
        agent_name="MinAgent",
        definition=PromptAgentDefinition(
            model="gpt-4o",
            instructions="Du er en hjelpsom assistent.",
            tools=[tool],
        ),
    )

Støttede SDK-er i Foundry: Python, C#, TypeScript, REST API (Java ikke støttet per februar 2026)

Copilot Studio

Copilot Studio kan konsumere A2A-agenter direkte:

1. Gå til Agents-siden → Add an agent → Connect to an external agent → velg Agent2Agent
2. Angi endepunkt-URL (kommunikasjonsendepunktet, IKKE URL for agent card)
3. Copilot Studio henter automatisk navn og beskrivelse fra /.well-known/agent.json (standard well-known-URL). Hvis automatisk populering feiler, angi navn og beskrivelse manuelt
4. Velg autentiseringsmetode: None, API key, eller OAuth 2.0
5. Velg eller opprett connection, deretter Add and configure

A2A vs HTTP connector — valg av integrasjonstype:

Behov	Anbefalt
Agenter som er bygget på eksterne rammeverk	A2A
Agenter hostet utenfor Copilot Studio	A2A
Multi-turn interaksjoner med domenespesifikk resonnering	A2A
Enkle API-kall eller HTTP-tjenester	Custom connectors
MCP-verktøy og ressurser	MCP-servere
Microsoft 365 Agents SDK-agenter	Activity Protocol

Viktig: Tilkobling til A2A-agenter utenfor Copilot Studio gir brukeransvar for datadeling, sikkerhet, compliance og kvalitetssikring.

Semantic Kernel

// Bruk A2A-agent i Semantic Kernel orchestration
using Microsoft.SemanticKernel.Agents;

A2ACardResolver resolver = new(new Uri("https://ekstern-agent.example.com"));
AIAgent a2aAgent = await resolver.GetAIAgentAsync();

// Integrér i SK orchestration-mønstre (Concurrent, Sequential, Handoff, Group Chat)
GroupChatOrchestration orchestration = new([internAgent, a2aAgent]);
await orchestration.InvokeAsync("Samarbeid om denne oppgaven");

SK orchestration-mønstre som støtter A2A:

Mønster	Beskrivelse	Egnet for A2A
Concurrent	Alle agenter jobber parallelt	Ja — parallell delegering
Sequential	En agent om gangen i definert rekkefølge	Ja — pipeline med ekstern agent
Handoff	Dynamisk overføring basert på kontekst	Ja — eskalering til spesialist
Group Chat	Alle deltar i gruppekonversasjon	Ja — med ekstern part
Magentic	Inspirert av MagenticOne, generalist	Ja — kompleks samarbeid

Azure API Management

APIM kan fungere som A2A-gateway med:

• Mediering av JSON-RPC-operasjoner til A2A-backend
• Governance og trafikkstyring via policies
• OpenTelemetry GenAI-samsvar (genai.agent.id, genai.agent.name)
• Agent Card-transformasjon (bytter hostname med APIM-instansens hostname)

Teams AI Library

# Python
pip install microsoft-teams-a2a

# TypeScript
npm install @microsoft/teams.a2a

Teams-agenten kan fungere som både A2A-server (eksponerer /a2a-endpoint) og A2A-klient (kaller andre A2A-agenter).

---

Sikkerhet

Autentiseringsmetoder i Foundry

Metode	Brukes når	Bruker-kontekst bevares
Ingen autentisering	Offentlige/testendepunkter	Nei
Nøkkelbasert (API key)	Enkle token-baserte endepunkter	Nei
Microsoft Entra ID — agent identity	Azure-tjenester med managed identity	Nei
Microsoft Entra ID — project managed identity	Alle agenter i prosjektet deler identitet	Nei
OAuth identity passthrough	Per-bruker-tilgang med egne rettigheter	Ja

Agent Identity-livssyklus (Foundry)

• Før publisering: Alle agenter i prosjektet deler én felles identitet (enklere utvikling)
• Etter publisering: Hver agent får unik identitet — gir isolasjon og granulær tilgangskontroll

Sikkerhetsarkitekturprinsipper

1. Minste privileg: Agent Card bør deklarere nøyaktig hvilke operasjoner som støttes — ikke gi bredere tilgang enn nødvendig
2. Secrets i project connections: Lagre API-nøkler i Foundry project connections, ikke i kode eller prompts
3. Roter tokens regelmessig: Sett opp påminnelser for tokengenerering
4. Audit alle agent-interaksjoner: Bruk contextId og traceId for full sporbarhet
5. TLS påkrevd: Alle A2A-endepunkter må bruke HTTPS i produksjon
6. Verifiser Agent Cards: Stol kun på agent cards fra kjente, betrodde endepunkter

OAuth Identity Passthrough — flyt

1. Bruker sender forespørsel til agent
2. Agent Service genererer samtykkelenke
3. Bruker logger inn og godkjenner tilgang
4. Agent Service lagrer access token + refresh token per bruker/agent-kombinasjon
5. Påfølgende kall: Agent Service inkluderer brukerens token automatisk
6. Token utløpt: Agent Service bruker refresh token for å hente nytt access token

---

Multi-vendor Interoperabilitet

A2A er designet for at agenter bygget av forskjellige leverandører og med forskjellige rammeverk skal kunne kommunisere uten forhåndskunnskap om hverandres interne arkitektur.

Nøkkelegenskaper for interoperabilitet:

Egenskap	Beskrivelse
Ugjennomsiktighet	Klienten trenger ikke vite noe om serveragentens interne logikk, LLM-modell eller datakilder
Dynamisk forhandling	Agenter kan tilpasse kommunikasjonsmodalitet uten at klienten må oppdateres
Versjonering	Semantic versioning i endepunktpaths (v1, v2) for bakoverkompatibilitet
Agent Card-basert discovery	Ingen hardkodede capabiliteter — agenten annonserer selv hva den kan

Praktisk eksempel på multi-vendor samarbeid:

[Microsoft Foundry-agent] → A2A → [Google Vertex AI-agent]
[Copilot Studio-agent]    → A2A → [Amazon Bedrock-agent]
[Semantic Kernel-agent]   → A2A → [Custom Python-agent]

Så lenge alle implementerer A2A-protokollen korrekt, er rammeverk og cloud-leverandør irrelevant.

---

Norsk Offentlig Sektor

Interoperabilitet mellom offentlige systemer

A2A er spesielt relevant for offentlig sektor fordi norske myndigheter opererer med mange separate fagsystemer og etater:

Typiske bruks-scenarioer:

Scenario	Aktører	A2A-kobling
Innbygger-henvendelse (NAV + Skatteetaten)	NAV-agent, Skatteetaten-agent	NAV-agent delegerer skatteoppslag via A2A
Direktoratet for digital tjenesteutvikling + Politiet	Kjøretøy-agent, Trafikk-agent	Felles trafikkanalyse via A2A
Helseforetak på tvers	Sykehus A-agent, Fastlege-agent	Pasienthistorikk-utveksling (med samtykke)
DigDir-tjenester	eID-agent, Altinn-agent	Autentisert datautveksling

GDPR og datasuverenitet

Krav	A2A-implementasjon
Personvern by design	Agent Card deklarerer hvilke datatyper som prosesseres
Behandlingsgrunnlag	contextId + traceId sporer samtykke og behandlingsgrunnlag
Dataportabilitet	Eksporter conversation history fra agent sessions via tasks/get
Rett til sletting	Implementer DELETE /sessions/{contextId} endpoint
Dataresidens	Krev at Agent Card deklarerer dataLocation (f.eks. "Norway East")

Agent Card med GDPR-utvidelse (norsk offentlig sektor):

{
  "name": "Direktoratet Kjøretøy-agent",
  "version": "2.0.0",
  "capabilities": {
    "streaming": false,
    "pushNotifications": true
  },
  "extensions": {
    "gdpr": {
      "personalData": true,
      "dataCategories": ["kjøretøydata", "eierskap"],
      "retentionDays": 90,
      "dataLocation": "Norway East",
      "legalBasis": "offentlig myndighetsutøvelse"
    }
  }
}

AI Act (EU 2024)

Krav (høyrisikosystem)	A2A-mapping
Transparens	Agent Card deklarerer AI-modell og kapabiliteter
Human oversight	input-required-tilstand i task-livssyklus for human-in-the-loop
Sporbarhet	traceId i alle A2A-meldinger → audit log
Risikovurdering	DPIA for agenter som håndterer persondata (se /architect:dpia)

Forvaltningsloven og automatiserte vedtak

Agenter som deltar i vedtaksprosesser via A2A må:

1. Logge hvert agent-til-agent-kall med contextId, traceId, avsender-agent og mottaker-agent
2. Implementere human-in-the-loop via input-required-tilstand i kritiske beslutningspunkter
3. Bevare samtalehistorikk som dokumentasjon i vedtakssaken

// Logging for audit (forvaltningsloven)
logger.LogInformation(
    "A2A-kall: {CallerAgent} → {RemoteAgent} for sak {CaseId}. " +
    "ContextId: {ContextId}, TraceId: {TraceId}, Status: {TaskStatus}",
    callerAgentId, remoteAgentId, caseId, contextId, traceId, taskStatus);

Schrems II

• Unngå US-baserte A2A-agenter uten Data Privacy Framework-sertifisering
• Krev dataresidensdeklarasjon i Agent Card for alle agenter som behandler personopplysninger
• Bruk Azure Norway East/West for hosting av norske offentlige agenter

---

For Cosmo — Beslutningsveiledning

Når skal du anbefale A2A?

Bruk A2A når:

• To eller flere agenter tilhører forskjellige organisasjoner, team eller teknologiplattformer
• Den kallede agenten er en selvstendig aktør med sin egen LLM, logikk og state
• Du trenger dynamisk forhandling om kapabiliteter uten å endre klientkode
• Det kreves opak grense mellom agenter (intern logikk skal ikke eksponeres)
• Cross-platform eller cross-vendor integrasjon er et krav

Bruk direkte integrasjon (ikke A2A) når:

• Agentene er innenfor samme applikasjon og rammeverk
• Du trenger full kontroll over chain-of-thought og verktøybruk (→ velg MCP i stedet)
• Enkle, synkrone API-kall er tilstrekkelig (overhead fra A2A er unødvendig)

Beslutningstabell

Scenario	Anbefaling	Begrunnelse
POC — én agent kaller én annen internt	A2A Direct (hardkodet URL)	Minimal oppsett
Pilot — 3-5 agenter, kjente endpoints	A2A Direct + enkel auth	Lav kompleksitet
Produksjon — mange agenter, audit-krav	A2A + Agent Registry + audit logging	Enterprise-grade
Offentlig sektor (GDPR, AI Act)	A2A + Entra ID + audit logging	Compliance-krav
Cross-org agent-samarbeid	A2A + OAuth/Entra + Agent Card-verifisering	Sikkerhet, discovery
Agent trenger å kalle et API/verktøy	MCP, ikke A2A	A2A er for agenter, MCP for verktøy

Spørsmål å stille kunden

1. Er agenten på den andre siden en selvstendig aktør, eller et passivt verktøy?

   • Selvstendig aktør → A2A
   • Passivt verktøy → MCP

2. Tilhører agentene samme team/org, eller er det cross-org?

   • Cross-org → A2A er nødvendig
   • Samme team → vurder om A2A-overhead er verdt det

3. Er det compliance-krav (GDPR, AI Act, Forvaltningsloven)?

   • Ja → A2A + audit logging + Entra ID
   • Nei → A2A Direct med enklere auth

4. Hvor lang tid tar oppgavene?

   • <15 sek: message/send (synkron)
   • 15 sek – 5 min: A2A tasks (polling/streaming)

   • 5 min: A2A push notifications + webhook

5. Trenger du per-bruker-kontekst?

   • Ja → OAuth identity passthrough
   • Nei → shared auth (API key, Managed Identity)

Vanlige fallgruver

Fallgruve	Konsekvens	Mitigering
Bruke A2A for verktøy/API-kall	Unødvendig kompleksitet	Bruk MCP i stedet
Ingen versjonering i Agent Card	Breaking changes	Semantic versioning (v1, v2) i URL-paths
Stole blindt på eksterne Agent Cards	Sikkerheitsrisiko	Verifiser endepunkt, bruk APIM som gateway
Synkron kall-kjede (A→B→C→D)	Latens akkumulerer, timeout	Bruk async tasks eller parallell orkestrering
Manglende logging av A2A-kall	Compliance-brudd i offentlig sektor	Logg contextId + traceId for alle kall
Hardkode base URL i kode	Brittle, ingen failover	Bruk Agent Card discovery eller registry

Decision Tree

Er agenten på den andre siden selvstendig med egne beslutninger?
├─ Nei → Bruk MCP (verktøy/API-integrasjon)
└─ Ja → Bruk A2A
    └─ Er det cross-org eller cross-platform?
        ├─ Nei → A2A Direct (enkel oppsett)
        └─ Ja → A2A + Agent Card discovery
            └─ Er det compliance-krav (offentlig sektor)?
                ├─ Nei → Basic auth (API key)
                └─ Ja → Entra ID + audit logging + APIM-gateway

---

Arkitekturmønster

1. Enkelt A2A-kall (POC/Pilot)

[Klienten] → HTTP POST → [/.well-known/agent.json] → henter capabilities
           → HTTP POST → [/a2a/message/send] → svar

Ingen sentral koordinering, hardkodede endpoints, minimal overhead.

2. A2A med APIM-gateway (Enterprise)

[Klient-agent]
      ↓
[Azure API Management] — governance, policies, observability
      ↓
[A2A-agent] — intern logikk ugjennomsiktig for klienten

3. Multi-agent mesh (Cross-org offentlig sektor)

[Borger] → [Felles inngangsagent (DigDir)]
                ├─ A2A → [NAV-agent]
                ├─ A2A → [Skatteetaten-agent]
                └─ A2A → [Direktoratet-agent]

Hver etat eier og drifter sin egen agent. Felles inngangsagent orkestrerer via A2A.

---

Installasjon og SDK-er

# Autentisert A2A-kall (AuthInterceptor-mønster) — Verified MCP 2026-04
from a2a.client.auth.interceptor import AuthInterceptor

class BearerAuth(AuthInterceptor):
    def __init__(self, token: str):
        self.token = token
    async def intercept(self, request):
        request.headers["Authorization"] = f"Bearer {self.token}"
        return request

async with A2AAgent(
    name="secure-agent",
    url="https://secure-a2a-agent.example.com",
    auth_interceptor=BearerAuth("your-token"),
) as agent:
    response = await agent.run("Hello!")

# Python — Agent Framework
pip install agent-framework-a2a --pre

# Python — Azure AI Projects med A2A-støtte
pip install azure-ai-projects[agents]

# TypeScript — Teams AI Library
npm install @microsoft/teams.a2a

# Python — Teams AI Library
pip install microsoft-teams-a2a

.NET (Semantic Kernel):

// Agent card tilgjengelig på: GET /a2a/my-agent/v1/card
// Message endpoint:          POST /a2a/my-agent/v1/message:stream
app.MapA2A(agent, "/a2a/my-agent", agentCard: new()
{
    Name = "Min Agent",
    Description = "Hjelpsom assistent for norsk offentlig sektor",
    Version = "1.0",
    Capabilities = new() { Streaming = true }
});  // Verified MCP 2026-04

---

Kilder og verifisering

Microsoft Learn (Verified)

1. Foundry Agent Service — A2A Tool

   • https://learn.microsoft.com/azure/foundry/agents/how-to/tools/agent-to-agent
   • Confidence: Verified (offisiell guide, preview, februar 2026)

2. A2A Authentication in Foundry

   • https://learn.microsoft.com/azure/foundry/agents/concepts/agent-to-agent-authentication
   • Confidence: Verified (offisiell auth-guide, februar 2026)

3. Copilot Studio — Connect A2A Agent

   • https://learn.microsoft.com/microsoft-copilot-studio/add-agent-agent-to-agent
   • Confidence: Verified (offisiell guide, oppdatert 2026-04: oppsettstrinn, autentiseringsalternativer, A2A vs HTTP connector-tabell)

4. Multi-agent Patterns — MCP vs A2A

   • https://learn.microsoft.com/microsoft-copilot-studio/guidance/architecture/multi-agent-patterns
   • Confidence: Verified (Copilot Studio arkitekturguide, oppdatert 2026-04: MCP vs A2A capability-matrise, hybrid workflow-anbefalinger, Agent 365 control plane)

5. Azure API Management — A2A Agent API

   • https://learn.microsoft.com/azure/api-management/agent-to-agent-api
   • Confidence: Verified (APIM preview-støtte, februar 2026)

6. Agent Framework — A2A Integration (Python og C#)

   • https://learn.microsoft.com/agent-framework/integrations/a2a
   • Confidence: Verified (MCP 2026-04) — A2ACardResolver-pattern (Python), A2AAgent med agent_card-parameter, AuthInterceptor for sikret kall, MapA2A /v1/card og /v1/message:stream endepunkt-paths (.NET), NuGet-pakker Microsoft.Agents.AI.Hosting.A2A og .AspNetCore

7. Semantic Kernel Agent Orchestration

   • https://learn.microsoft.com/semantic-kernel/frameworks/agent/agent-orchestration/
   • Confidence: Verified (SK orchestration-mønstre, februar 2026)

Ekstern Standard (Verified)

8. A2A Protocol Specification (offisiell)

   • https://a2a-protocol.org/latest/specification/
   • https://a2a-protocol.org/latest/announcing-1.0/ (v1.0-kunngjøring)
   • Confidence: Verified (2026-06-18) (Linux Foundation-prosjekt; v1.0 er gjeldende stabile versjon, v0.3 fortsatt støttet via versjonsforhandling)

9. Linux Foundation — A2A Project lansering

   • https://www.linuxfoundation.org/press/linux-foundation-launches-the-agent2agent-protocol-project
   • Confidence: Verified (pressemeldinger, juni 2025)

10. Google Developer Blog — A2A-lansering

    • https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/
    • Confidence: Verified (offisiell kunngjøring, april 2025)

Confidence per seksjon

Seksjon	Confidence	Kilde
Protokolldesign (JSON-RPC, SSE)	Verified	a2a-protocol.org spec + MS Learn
Agent Card-format	Verified	a2a-protocol.org spec
Task-livssyklus	Verified	a2a-protocol.org + MS Learn
A2A vs MCP	Verified	MS Learn multi-agent patterns
Foundry-implementasjon	Verified	MS Learn Foundry docs
Copilot Studio-integrasjon	Verified	MS Learn Copilot Studio
Semantic Kernel-integrasjon	Verified	MS Learn SK docs
Auth-metoder	Verified	MS Learn Foundry auth-konsepter
GDPR/AI Act-mapping	Baseline	LLM kunnskap + norsk compliance-praksis
Norsk offentlig sektor-scenarioer	Baseline	LLM kunnskap + norsk kontekst

Total sources cited: 10 unike URLer fra MCP-research + tavily-research MCP calls: 4 (3x search, 2x fetch)