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
**Type:** reference
**Source:** https://learn.microsoft.com/azure/foundry/agents/concepts/agent-to-agent-authentication

---

## Innhold

- [Introduksjon](#introduksjon)
- [Protokolldesign](#protokolldesign)
- [Agent Cards — Discovery og Kapabilitetsannonsering](#agent-cards--discovery-og-kapabilitetsannonsering)
- [Task-livssyklus](#task-livssyklus)
- [A2A vs MCP — Komplementære Protokoller](#a2a-vs-mcp--komplementære-protokoller)
- [Microsoft-implementasjoner](#microsoft-implementasjoner)
- [Sikkerhet](#sikkerhet)
- [Multi-vendor Interoperabilitet](#multi-vendor-interoperabilitet)
- [Norsk Offentlig Sektor](#norsk-offentlig-sektor)
- [For Cosmo — Beslutningsveiledning](#for-cosmo--beslutningsveiledning)
- [Arkitekturmønster](#arkitekturmønster)
- [Installasjon og SDK-er](#installasjon-og-sdk-er)
- [Kilder og verifisering](#kilder-og-verifisering)

## 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):**

```json
{
  "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):**

```json
{
  "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.

```json
{
  "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:**

```python
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.

```python
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

```csharp
// 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

```bash
# 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):**

```json
{
  "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

```csharp
// 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

```python
# 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!")
```

```bash
# 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):**

```csharp
// 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)