feat(ultraplan-local): v1.6.0 — /ultraresearch-local deep research command
Add /ultraresearch-local for structured research combining local codebase analysis with external knowledge via parallel agent swarms. Produces research briefs with triangulation, confidence ratings, and source quality assessment. New command: /ultraresearch-local with modes --quick, --local, --external, --fg. New agents: research-orchestrator (opus), docs-researcher, community-researcher, security-researcher, contrarian-researcher, gemini-bridge (all sonnet). New template: research-brief-template.md. Integration: --research flag in /ultraplan-local accepts pre-built research briefs (up to 3), enriches the interview and exploration phases. Planning orchestrator cross-references brief findings during synthesis. Design principle: Context Engineering — right information to right agent at right time. Research briefs are structured artifacts in the pipeline: ultraresearch → brief → ultraplan --research → plan → ultraexecute. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
Kjell Tore Guttormsen
commit
baa2d0220b
488 changed files with 213221 additions and 0 deletions
|
|
@ -0,0 +1,665 @@
|
|||
# Agent2Agent (A2A) Protocol — Åpen Standard for Agent-Interoperabilitet
|
||||
|
||||
**Last updated:** 2026-02
|
||||
**Status:** Preview (Microsoft-implementasjoner) / GA (protokollspesifikasjon v0.3)
|
||||
**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 **Azure AI 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 |
|
||||
| Microsoft Foundry A2A-støtte (preview) | 2025 |
|
||||
|
||||
---
|
||||
|
||||
## 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
|
||||
from agent_framework.a2a import A2AAgent
|
||||
|
||||
async def main():
|
||||
# Koble til ekstern A2A-agent
|
||||
async with A2AAgent(name="saksbehandler", url="https://agents.nav.no/saksbehandler/a2a") 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 |
|
||||
|
||||
**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
|
||||
|
||||
### Azure AI 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** → **Add an agent** → **Connect to an external agent** → velg **Agent2Agent**
|
||||
2. Angi endepunkt-URL (ikke URL for agent card, men kommunikasjonsendepunktet)
|
||||
3. Copilot Studio henter automatisk navn og beskrivelse fra `/.well-known/agent.json`
|
||||
4. Velg autentiseringsmetode
|
||||
|
||||
**Viktig:** Copilot Studio er ansvarlig for å vurdere datadeling, sikkerhet og compliance for tilkoblede eksterne agenter.
|
||||
|
||||
### 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 |
|
||||
| Statens vegvesen + 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": "Vegvesen 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 → [Vegvesen-agent]
|
||||
```
|
||||
|
||||
Hver etat eier og drifter sin egen agent. Felles inngangsagent orkestrerer via A2A.
|
||||
|
||||
---
|
||||
|
||||
## Installasjon og SDK-er
|
||||
|
||||
```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
|
||||
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 }
|
||||
});
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Kilder og verifisering
|
||||
|
||||
### Microsoft Learn (Verified)
|
||||
|
||||
1. **Foundry Agent Service — A2A Tool**
|
||||
- https://learn.microsoft.com/azure/ai-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/ai-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, februar 2026)
|
||||
|
||||
4. **Multi-agent Patterns — MCP vs A2A**
|
||||
- https://learn.microsoft.com/microsoft-copilot-studio/guidance/architecture/multi-agent-patterns
|
||||
- Confidence: **Verified** (Copilot Studio arkitekturguide, februar 2026)
|
||||
|
||||
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)**
|
||||
- https://learn.microsoft.com/agent-framework/integrations/a2a
|
||||
- Confidence: **Verified** (offisiell SDK-dokumentasjon, februar 2026)
|
||||
|
||||
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/
|
||||
- Confidence: **Verified** (Linux Foundation-prosjekt, v0.3, 2025)
|
||||
|
||||
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)
|
||||
Loading…
Add table
Add a link
Reference in a new issue