KB-currency refresh (medium priority, 2026-06-19) via /architect:kb-update. 74 medium-prioritets filer re-verifisert mot Microsoft Learn (MCP) — delegert til 15 parallelle Opus-subagenter (3 bølger) gruppert etter delt kilde, med disjunkte fil-sett. Verifisert i hovedkontekst (scope-sjekk + diff-review av de faktatunge gruppene + tester). Hovedendringer (faktuelle korreksjoner + currency): - Azure AI Search semantic ranker: TILGJENGELIG PÅ ALLE TIERS (også Free/Basic m/ gratis månedlig kvote) — gammel KB sa feilaktig "kun S1+". Korrigert i tier-tabell, anti-patterns og beslutningstabell (azure-ai-search-setup). - APIM score-threshold = DISTANSE (lavere = strengere): tuning-tabellen i rag-caching-optimization hadde retningen baklengs — invertert til korrekt. - Agentic retrieval GA/preview-nyanse presisert (hovedkontekst-korreksjon mot agentic-retrieval-how-to-migrate): GA via REST 2026-04-01 returnerer EKSTRAKTIV grounding (references + activity), IKKE syntetiserte svar. Answer synthesis, ikke-minimal reasoning effort (LLM query planning) og multi-turn messages forblir preview (2026-05-01-preview). Subagent hadde overforenklet til "hele kjernepipelinen GA"; rettet i agentic-rag-patterns + citation-tracking. - Copilot Studio modell-tabeller (platforms/copilot-studio): fjernet Claude Opus 4.5 + GPT-5.2 (borte fra kilde), lagt til Claude Sonnet 4.6/Opus 4.6 (GA), Opus 4.7 + Mistral Medium 3.5 (experimental); GPT-5 Reasoning/Auto = preview; A2A GA (apr 2026). - Computer Use (CUA): Copilot Studio GA 2026-05-07; 4 modeller m/ tier/status (OpenAI CUA + Sonnet 4.5 GA, Sonnet 4.6 + Opus 4.6 experimental); 5 credits/ steg standard, 15 premium; US-only region-krav FJERNET i GA-dok; Cloud PC pool + Hosted browser + bring-your-own-machine. - Azure AI Search REST API-versjoner bumpet: 2025-09-01 -> 2026-04-01 (stabil), 2025-11-01-preview -> 2026-05-01-preview (hybrid-search, rag-security-rbac, chunking). - Power Automate-integrasjon: trigger "Run a flow from Copilot" -> "When an agent calls the flow"; App Service innebygd MCP (preview) lagt til. - M365 Copilot-manifest v1.26 -> v1.28 (GA, mai) / v1.29 dokumentert (juni); "Tenant graph grounding" -> "Work IQ". - Speech fast transcription 2t/300MB -> 5t/500MB; multilingual 14 -> 15 locales (+ pt-BR). Content Understanding reasoning preview -> GA (v1.0, 2025-11-01). - Security Copilot E5 -> E5+E7. Død Databricks-URL ci-cd/best-practices -> ci-cd/flows. Prompt Flow retirement (2027-04-20 -> MAF) notert der den presenteres som go-forward. Gateway-topologi-tabell-feil rettet. - Alle 74 Last updated -> 2026-06-19. Discovery ikke kjørt (historisk kun Databricks-støy) -> 389-telling uendret, ingen resync. validate 239 PASS, kb-integrity 115/115 (262 orphan-warnings uendret), gitleaks clean. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01REiKFhP4w6xGXXqWKpPCJJ
712 lines
28 KiB
Markdown
712 lines
28 KiB
Markdown
# Multi-Agent Orchestration Patterns and Topologies
|
||
|
||
**Last updated:** 2026-06-19 | Verified: MCP 2026-06-19
|
||
**Status:** GA
|
||
**Category:** Agent Orchestration & Automation
|
||
|
||
---
|
||
|
||
## Introduksjon
|
||
|
||
Multi-agent orchestration representerer en fundamental arkitektonisk tilnærming for å håndtere komplekse AI-oppgaver gjennom koordinering av flere spesialiserte agenter. I stedet for å bygge én monolittisk agent med mange verktøy og kunnskapsbaser, deler multi-agent-systemer problemet i mindre, spesialiserte enheter som kan samarbeide, parallellisere eller sekvensielt prosessere oppgaver.
|
||
|
||
Microsoft tilbyr fem kjerne-orkestreringsmønstre gjennom Microsoft Agent Framework og Semantic Kernel: **Sequential**, **Concurrent**, **Group Chat**, **Handoff** og **Magentic**. Hvert mønster adresserer ulike koordineringsbehov, fra lineære pipelines til dynamisk, planbasert samarbeid. Valg av riktig mønster påvirker ytelse, vedlikeholdbarhet, feilhåndtering og evnen til å skalere løsningen over tid.
|
||
|
||
Disse mønstrene implementeres som **workflow orchestrations** i Microsoft Agent Framework, og som **orchestration patterns** i Semantic Kernel. De er plattform-agnostiske designmønstre som utfyller tradisjonelle cloud design patterns ved å adressere unike utfordringer ved koordinering av autonome, LLM-drevne komponenter.
|
||
|
||
## Kjernekomponenter
|
||
|
||
### Fem orkestreringsmønstre
|
||
|
||
| Mønster | Topologi | Koordinering | Beste bruk |
|
||
|---------|----------|--------------|------------|
|
||
| **Sequential** | Pipeline (lineær kjede) | Deterministisk rekkefølge | Steg-for-steg workflows, progressive refinement |
|
||
| **Concurrent** | Fan-out/Fan-in (stjerne) | Parallell broadcast | Uavhengige analyser, ensemble decision-making |
|
||
| **Group Chat** | Star med sentral manager | Manager-styrt turbasert dialog | Iterativ refinement, maker-checker loops |
|
||
| **Handoff** | Mesh (dynamisk routing) | Agent-til-agent delegering | Eskalering, spesialist-routing, fallback |
|
||
| **Magentic** | Manager-led med task ledger | Planbasert med dynamic task breakdown | Åpne problemer uten forhåndsdefinert løsning |
|
||
|
||
### Workflow vs. Agent
|
||
|
||
| Aspekt | Workflow | Agent |
|
||
|--------|----------|-------|
|
||
| **Definisjon** | Predefinert sekvens av operasjoner | LLM-drevet autonomi med verktøy |
|
||
| **Flow** | Eksplisitt definert av utvikler | Dynamisk bestemt av modellen |
|
||
| **Komponenter** | Kan inkludere agenter, API-kall, timers | Har instruksjoner, verktøy, kunnskapsbaser |
|
||
| **Kontrollfløyt** | Deterministisk eller hybrid | Ikke-deterministisk (LLM-styrt) |
|
||
|
||
### SDK-implementasjoner
|
||
|
||
**Microsoft Agent Framework:**
|
||
- Workflow-fokusert: `AgentWorkflowBuilder`
|
||
- Støtter Sequential, Concurrent, Group Chat, Handoff, Magentic
|
||
- Integrasjon med Durable Functions for state persistence
|
||
- GitHub: [agent-framework/workflow-samples](https://github.com/microsoft/agent-framework/tree/main/workflow-samples)
|
||
|
||
**Semantic Kernel:**
|
||
- Agent-fokusert: `SequentialOrchestration`, `ConcurrentOrchestration`, etc.
|
||
- Unified interface for alle mønstre
|
||
- Experimental stage (aktiv utvikling)
|
||
- GitHub: [semantic-kernel/agent samples](https://github.com/microsoft/semantic-kernel/tree/main/python/samples/getting_started_with_agents)
|
||
|
||
**AutoGen:**
|
||
- Open source multi-agent framework fra Microsoft Research
|
||
- Magentic-One implementasjon (kilde til Magentic-mønster)
|
||
|
||
## Arkitekturmønstre
|
||
|
||
### 1. Sequential Orchestration
|
||
|
||
**Topologi:** Lineær pipeline (Agent 1 → Agent 2 → ... → Agent N)
|
||
|
||
**Karakteristika:**
|
||
- Deterministisk rekkefølge
|
||
- Hver agent mottar output fra forrige
|
||
- Shared state akkumuleres gjennom pipelinjen
|
||
- Ligner Pipes and Filters cloud pattern
|
||
|
||
**Når bruke:**
|
||
```
|
||
✅ Multistage prosesser med klare avhengigheter
|
||
✅ Data transformation pipelines
|
||
✅ Progressive refinement (draft → review → polish)
|
||
✅ Stages kan IKKE paralleliseres
|
||
```
|
||
|
||
**Når unngå:**
|
||
```
|
||
❌ Stages er embarrassingly parallel
|
||
❌ Få stages som en agent kan håndtere
|
||
❌ Tidlige stages kan feile uten graceful degradation
|
||
❌ Workflow krever backtracking eller iterasjon
|
||
```
|
||
|
||
**Eksempel (juridisk kontrakt):**
|
||
```
|
||
Template Selection Agent
|
||
↓ (selected template)
|
||
Clause Customization Agent
|
||
↓ (customized contract)
|
||
Regulatory Compliance Agent
|
||
↓ (compliance-checked)
|
||
Risk Assessment Agent
|
||
↓ (final document with risk ratings)
|
||
```
|
||
|
||
**Kodeeksempel (Agent Framework C#):**
|
||
```csharp
|
||
var workflow = AgentWorkflowBuilder
|
||
.CreateSequentialPipeline(templateAgent, clauseAgent, complianceAgent, riskAgent)
|
||
.Build();
|
||
|
||
var result = await workflow.InvokeAsync(documentRequest);
|
||
```
|
||
|
||
---
|
||
|
||
### 2. Concurrent Orchestration
|
||
|
||
**Topologi:** Fan-out/Fan-in (Initiator → [Agent 1, Agent 2, ..., Agent N] → Aggregator)
|
||
|
||
**Karakteristika:**
|
||
- Parallell broadcast av samme task til alle agenter
|
||
- Uavhengige resultater aggregeres
|
||
- Redusert latency ved parallellisering
|
||
- Ikke-deterministische resultater (modellvariasjon)
|
||
|
||
**Når bruke:**
|
||
```
|
||
✅ Tasks som kan kjøres parallelt
|
||
✅ Multiple perspectives (teknisk, business, kreativ)
|
||
✅ Ensemble reasoning, voting-baserte beslutninger
|
||
✅ Tidssensitive scenarios
|
||
```
|
||
|
||
**Når unngå:**
|
||
```
|
||
❌ Agents må bygge på hverandres arbeid
|
||
❌ Krever spesifikk rekkefølge for determinisme
|
||
❌ Resource constraints (model quota)
|
||
❌ Shared state-konflikter ved parallellitet
|
||
❌ Kompleks konfliktløsningslogikk
|
||
```
|
||
|
||
**Eksempel (aksjeanalyse):**
|
||
```
|
||
Ticker Symbol
|
||
├─→ Fundamental Analysis Agent ──→ Intermediate result
|
||
├─→ Technical Analysis Agent ──→ Intermediate result
|
||
├─→ Sentiment Analysis Agent ──→ Intermediate result
|
||
└─→ ESG Agent ──→ Intermediate result
|
||
↓
|
||
Stock Analysis Agent (aggregerer)
|
||
↓
|
||
Investment Recommendation
|
||
```
|
||
|
||
**Kodeeksempel (Semantic Kernel C#):**
|
||
```csharp
|
||
ConcurrentOrchestration<string, Analysis> orchestration =
|
||
new(fundamentalAgent, technicalAgent, sentimentAgent, esgAgent);
|
||
|
||
OrchestrationResult<Analysis> result = await orchestration.InvokeAsync(tickerSymbol, runtime);
|
||
Analysis decision = await result.GetValueAsync(TimeSpan.FromSeconds(60));
|
||
```
|
||
|
||
---
|
||
|
||
### 3. Group Chat Orchestration
|
||
|
||
**Topologi:** Star med sentral manager (Manager ↔ [Agent 1, Agent 2, ..., Agent N])
|
||
|
||
**Karakteristika:**
|
||
- Akkumulerende chat thread alle agenter ser
|
||
- Manager bestemmer hvem som snakker neste (round-robin, prompt-based, custom)
|
||
- Iterativ refinement gjennom diskusjon
|
||
- Read-only mode for agenter (ingen tool execution i live systems)
|
||
|
||
**Når bruke:**
|
||
```
|
||
✅ Collaborative brainstorming
|
||
✅ Maker-checker loops (iterativ review)
|
||
✅ Quality assurance workflows
|
||
✅ Multi-disciplinary problemer
|
||
✅ Human-in-the-loop scenarios
|
||
```
|
||
|
||
**Når unngå:**
|
||
```
|
||
❌ Basic task delegation holder
|
||
❌ Real-time processing (diskusjon overhead)
|
||
❌ Deterministiske workflows
|
||
❌ Manager kan ikke bestemme når task er ferdig
|
||
❌ >3 agenter (kontrollproblemer)
|
||
```
|
||
|
||
**Maker-Checker Variant:**
|
||
- Maker-agent: oppretter/foreslår
|
||
- Checker-agent: kritiserer/gir feedback
|
||
- Turn-based sekvens drevet av manager
|
||
- Itererer til akseptabel kvalitet
|
||
|
||
**Eksempel (park development):**
|
||
```
|
||
Park Proposal
|
||
↓
|
||
Group Chat Manager
|
||
├─→ Community Engagement Agent
|
||
├─→ Environmental Planning Agent
|
||
└─→ Budget & Operations Agent
|
||
↓ (iterativ diskusjon)
|
||
Parks Department Employee (human-in-the-loop)
|
||
↓
|
||
Consensus Recommendation
|
||
```
|
||
|
||
**Kodeeksempel (Agent Framework C#):**
|
||
```csharp
|
||
var workflow = AgentWorkflowBuilder
|
||
.CreateGroupChatBuilderWith(agents =>
|
||
new RoundRobinGroupChatManager(agents)
|
||
{
|
||
MaximumIterationCount = 5
|
||
})
|
||
.AddParticipants(writerAgent, reviewerAgent)
|
||
.Build();
|
||
```
|
||
|
||
---
|
||
|
||
### 4. Handoff Orchestration
|
||
|
||
**Topologi:** Mesh (agents kan overføre kontroll peer-to-peer)
|
||
|
||
**Karakteristika:**
|
||
- Dynamisk routing basert på agent-vurdering
|
||
- Ingen sentral manager
|
||
- Full kontroll overføres (ikke parallelt)
|
||
- Agents kan eskalere til mennesker eller andre spesialister
|
||
|
||
**Når bruke:**
|
||
```
|
||
✅ Spesialistkunnskap trengs, men rekkefølge ukjent
|
||
✅ Ekspertise-behov emerges under prosessering
|
||
✅ Multi-domain problemer med uforutsigbar flow
|
||
✅ Eskalering og fallback-patterns
|
||
```
|
||
|
||
**Når unngå:**
|
||
```
|
||
❌ Rekkefølge alltid kjent upfront
|
||
❌ Deterministisk routing holder
|
||
❌ Suboptimal routing gir dårlig brukeropplevelse
|
||
❌ Multiple operasjoner bør kjøre samtidig
|
||
❌ Infinite handoff loops vanskelig å unngå
|
||
```
|
||
|
||
**Eksempel (telco customer support):**
|
||
```
|
||
Customer Query
|
||
↓
|
||
Triage Support Agent
|
||
├─→ Technical Infrastructure Agent
|
||
│ ↓ (discovers billing issue)
|
||
│ Financial Resolution Agent
|
||
│ ↓ (discovers account problem)
|
||
│ Account Access Agent
|
||
│ ↓ (cannot solve)
|
||
│ Human Customer Support Employee
|
||
│
|
||
├─→ Billing Agent
|
||
└─→ Human Escalation
|
||
```
|
||
|
||
**Kodeeksempel (Agent Framework C#):**
|
||
```csharp
|
||
var workflow = AgentWorkflowBuilder.StartHandoffWith(triageAgent)
|
||
.WithHandoffs(triageAgent, [mathTutor, historyTutor])
|
||
.WithHandoff(mathTutor, triageAgent)
|
||
.WithHandoff(historyTutor, triageAgent)
|
||
.Build();
|
||
```
|
||
|
||
---
|
||
|
||
### 5. Magentic Orchestration
|
||
|
||
**Topologi:** Manager-led med task ledger (Manager + Task Ledger + [Tool-enabled Agents])
|
||
|
||
**Karakteristika:**
|
||
- Focus på **plan building** før execution
|
||
- Task ledger (task breakdown, dependencies, status)
|
||
- Agents har tools for å endre eksterne systemer
|
||
- Manager itererer, backtracks, delegerer
|
||
- Evaluerer kontinuerlig om målet er nådd eller stalled
|
||
|
||
**Når bruke:**
|
||
```
|
||
✅ Komplekse, åpne problemer uten kjent løsning
|
||
✅ Krever multiple specialist inputs for å utvikle plan
|
||
✅ Behov for å generere reviewable plan før execution
|
||
✅ Tool-equipped agents som kan endre live systems
|
||
```
|
||
|
||
**Når unngå:**
|
||
```
|
||
❌ Løsningen er deterministisk/kjent
|
||
❌ Ingen behov for task ledger
|
||
❌ Lav kompleksitet
|
||
❌ Time-sensitive (mønsteret prioriterer planning)
|
||
❌ Frequent stalls eller infinite loops
|
||
```
|
||
|
||
**Eksempel (SRE automation):**
|
||
```
|
||
Live-site Incident
|
||
↓
|
||
SRE Automation Manager Agent
|
||
├─→ creates/refines Task Ledger
|
||
│ (resolution approach plan + task statuses)
|
||
│
|
||
├─→ consults Diagnostics Agent (log/metrics knowledge)
|
||
├─→ consults Infrastructure Agent (graph + CLI tools)
|
||
├─→ consults Communication Agent (notify stakeholders)
|
||
└─→ invokes Rollback Agent (Git access, CLI tools)
|
||
↓
|
||
Evaluates: Issue resolved?
|
||
├─→ Yes: Result
|
||
└─→ No: Refine plan, continue
|
||
```
|
||
|
||
**Kodeeksempel (Semantic Kernel C#):**
|
||
```csharp
|
||
MagenticOrchestration orchestration = new(
|
||
manager: new MagenticManager(kernel),
|
||
diagnosticsAgent,
|
||
infrastructureAgent,
|
||
rollbackAgent,
|
||
communicationAgent
|
||
);
|
||
|
||
OrchestrationResult<string> result = await orchestration.InvokeAsync(incidentReport, runtime);
|
||
```
|
||
|
||
**Magentic vs. Group Chat:**
|
||
- Group Chat: fokus på diskusjon/iterativ refinement (read-only)
|
||
- Magentic: fokus på planlegging + tool execution (write-enabled)
|
||
|
||
## Beslutningsveiledning
|
||
|
||
### Beslutningstabell
|
||
|
||
| Hvis... | Vurder mønster |
|
||
|---------|----------------|
|
||
| Steg må kjøres i rekkefølge | Sequential |
|
||
| Steg kan kjøres uavhengig samtidig | Concurrent |
|
||
| Agents må diskutere/iterere | Group Chat |
|
||
| Routing basert på kontekst, ikke plan | Handoff |
|
||
| Åpent problem som krever planlegging | Magentic |
|
||
| Hybrid behov (ulike stages) | **Kombiner mønstre** |
|
||
|
||
### Hybrid Design
|
||
|
||
**Anbefalt:** Kombiner mønstre per workflow-stage når ulike deler har ulike karakteristika.
|
||
|
||
**Eksempel:**
|
||
```
|
||
Sequential for datainnsamling
|
||
↓
|
||
Concurrent for parallell analyse
|
||
↓
|
||
Group Chat for consensus building
|
||
↓
|
||
Handoff til human approval
|
||
```
|
||
|
||
### Vanlige feil
|
||
|
||
| Anti-pattern | Konsekvens |
|
||
|--------------|------------|
|
||
| Bruke komplekst mønster når sequential/concurrent holder | Unødvendig overhead |
|
||
| Agents uten meningsfull spesialisering | Waste of compute/tokens |
|
||
| Ignorere latency ved multi-hop communication | Dårlig brukeropplevelse |
|
||
| Shared mutable state i concurrent agents | Data inkonsistens |
|
||
| Deterministic pattern for non-deterministic workflow | Ustabil oppførsel |
|
||
| Non-deterministic pattern for deterministic workflow | Unødvendig variasjon |
|
||
| Voksende context window uten trunkering | Token exhaustion |
|
||
|
||
### Røde flagg
|
||
|
||
🚩 **Single agent, multitool:** Hvis én agent kan løse problemet pålitelig med mange tools, bruk det i stedet.
|
||
🚩 **Context window growth:** Akkumulert context kan sluke token-budsjett — implementer context summarization.
|
||
🚩 **Infinite loops:** Særlig i Handoff og Magentic — implementer max iterations og stall detection.
|
||
🚩 **Cascading failures:** Distribuerte systemer-problemer (network partitions, message loss) — implementer retry, circuit breakers.
|
||
|
||
## Integrasjon med Microsoft-stakken
|
||
|
||
### Azure-tjenester for orchestration
|
||
|
||
| Tjeneste | Bruk i orchestration |
|
||
|----------|----------------------|
|
||
| **Azure Functions** | Stateless compute nodes for reasoning/task flows |
|
||
| **Durable Functions** | Long-running orchestrations, multi-step workflows, state persistence |
|
||
| **Azure Service Bus** | Reliable, ordered message delivery mellom agents |
|
||
| **Azure Cosmos DB** | State persistence, conversation history |
|
||
| **Azure Managed Redis** | Short-term memory, session caching |
|
||
| **Azure Application Insights** | Tracing av reasoning steps, model calls, API execution |
|
||
| **Azure Monitor Logs** | Per-tenant performance tracking |
|
||
|
||
### Durable Agents (Agent Framework + Durable Functions)
|
||
|
||
**Deterministic Multi-Agent Orchestrations:**
|
||
- Deterministisk replay etter failure
|
||
- Automatic conversation state management
|
||
- Checkpoint mellom agent calls
|
||
- Human-in-the-loop patterns med venting (dager/uker uten compute cost)
|
||
|
||
**Kodeeksempel (parallel execution):**
|
||
```csharp
|
||
DurableAIAgent agentA = context.GetAgent("AgentA");
|
||
DurableAIAgent agentB = context.GetAgent("AgentB");
|
||
|
||
Task<AgentResponse<TextResponse>> taskA = agentA.RunAsync<TextResponse>(input);
|
||
Task<AgentResponse<TextResponse>> taskB = agentB.RunAsync<TextResponse>(input);
|
||
|
||
await Task.WhenAll(taskA, taskB); // Checkpoint ensures no replay
|
||
```
|
||
|
||
### Copilot Studio og M365 Copilot
|
||
|
||
**Connected Agents (Foundry classic — DEPRECATED, pensjoneres 2027-03-31; i ny Foundry Agent Service: Workflows `2025-11-15-preview` + A2A):**
|
||
- Nondeterministic workflows (primært)
|
||
- No-code/low-code environment
|
||
- Begrenset pattern-support (primært simple routing)
|
||
|
||
**Agent-to-Agent (A2A) protocol:**
|
||
- Cross-platform agent-to-agent messaging
|
||
- Capability discovery, task contracts
|
||
- Published SDKs for standard integrations
|
||
- Anbefales for inter-platform orchestration
|
||
|
||
**Multi-Agent Pattern Recommendations (Microsoft Copilot Studio):**
|
||
1. Prefer platform-native orchestration for internal flows with subagents
|
||
2. Use MCP for tool and data access (M365 services) — enterprise-grade security, authentication, auditing
|
||
3. Use A2A for cross-platform agent-to-agent messaging — design for capability discovery and task contracts
|
||
4. Integrate mature or abstracted agents via MCP or A2A for reuse and end-to-end traceability
|
||
5. Enforce policy and auditing at control-plane layer with Agent 365
|
||
6. Use least-privileged scope when calling MCP-hosted tools
|
||
7. Design for parallelism, limit inter-agent context to strictly necessary, use short-term memory
|
||
8. Include users in workflow — require human approvals for high-impact cross-agent actions
|
||
|
||
**MCP vs A2A — nar bruke hva (oppdatert fra Copilot Studio multi-agent-patterns):**
|
||
|
||
| Kapabilitet | MCP | A2A |
|
||
|-------------|-----|-----|
|
||
| Multimodalitet | Krever at MCP host stoetter det | Annonserer stoettede medietyper |
|
||
| Multi-turn interaksjoner | Valgfri elicitation. Kontekst hos host | contextId haandterer kontekst paa tvers av agenter |
|
||
| Orkestrering | Host orkestrerer hvilke tools som kalles | Invokert agent bruker sin egen chain-of-thought |
|
||
| Forhandling | Krever klientoppdatering | Dynamisk forhandling, robust mot serviceoppdateringer |
|
||
| Beste for | Full kontroll over resonnering, kontrollerte scenarios | Opake agenter, cross-org, ekstern agent |
|
||
|
||
### Semantic Kernel + Agent Framework
|
||
|
||
| Aspekt | Semantic Kernel | Agent Framework |
|
||
|--------|-----------------|-----------------|
|
||
| **Fokus** | Agent-centric, unified interface | Workflow-centric, builder pattern |
|
||
| **Status** | Experimental (active development) | GA |
|
||
| **Patterns** | Sequential, Concurrent, Group Chat, Handoff, Magentic | Sequential, Concurrent, Group Chat, Handoff, Magentic |
|
||
| **Runtime** | `InProcessRuntime` | Durable Functions integration |
|
||
| **Callbacks** | Input/output transforms, callbacks | Builder-konfigurert |
|
||
|
||
### Agent 365 (Observability & Control Plane)
|
||
|
||
**Compliance & Policy:**
|
||
- Enforce policy/auditing at control-plane layer
|
||
- Tracing av InvokeAgentScope for per-agent observability
|
||
- Tenant-specific tracking
|
||
|
||
**Eksempel:**
|
||
```csharp
|
||
using var scope = InvokeAgentScope.Start(
|
||
invokeAgentDetails: invokeAgentDetails,
|
||
tenantDetails: tenantDetails,
|
||
request: request,
|
||
conversationId: conversationId
|
||
);
|
||
|
||
scope.RecordInputMessages(new[] { userInput });
|
||
// ... agent logic ...
|
||
scope.RecordOutputMessages(new[] { output });
|
||
```
|
||
|
||
## Offentlig sektor (Norge)
|
||
|
||
### GDPR og datasuverenitet
|
||
|
||
**Orchestration-spesifikke vurderinger:**
|
||
- **Multi-tenant state:** Sørg for tenant isolation i shared state stores (Cosmos DB, Redis)
|
||
- **Cross-agent data flows:** Implementer security trimming i hver agent (data tilgjengelig for agent ≠ tilgjengelig for sluttbruker)
|
||
- **Logging av agent-interaksjoner:** Persondata i chat threads må logges i henhold til personvernforordningen
|
||
- **A2A cross-border:** Hvis orchestration krysser Azure-regioner, evaluer datasuverenitet (Schrems II)
|
||
|
||
### Forvaltningsloven
|
||
|
||
**Dokumentasjonsplikter:**
|
||
- **Task ledger i Magentic:** Genererer audit trail av plan + execution (§ 11 vedtaksdokumentasjon)
|
||
- **Sequential workflows:** Log hver stage-output for etterprøvbarhet
|
||
- **Group Chat:** Akkumulerende chat thread gir transparent beslutningsprosess
|
||
- **Handoff chains:** Dokumenter routing-beslutninger (hvorfor agent X ga til agent Y)
|
||
|
||
### AI Act (EU AI-forordningen)
|
||
|
||
**High-risk AI systems:**
|
||
- Multi-agent systems i kritisk infrastruktur eller offentlig tjenesteyting kan klassifiseres som høyrisiko
|
||
- **Krav:** Technical documentation, human oversight, accuracy/robustness testing
|
||
- **Orchestration-implikasjon:** Implementer deterministic patterns der mulig for higher reliability
|
||
|
||
**Ansvar og ansvarlighet:**
|
||
- **Magentic task ledger:** Gir sporbarhet av agent-beslutninger
|
||
- **Human-in-the-loop (Group Chat, Handoff):** Oppfyller human oversight-krav
|
||
- **Red flags for infinite loops:** Implementer fail-safes for å unngå ukontrollert agent-atferd
|
||
|
||
### Norske krav (Digdir, NSM)
|
||
|
||
**Zero Trust (NSM):**
|
||
- Agents skal autentiseres med Managed Identities
|
||
- Tool invocation via least-privilege scoping
|
||
- Network isolation mellom agents (Service Bus, API Management)
|
||
|
||
**Tilgjengelighetserklæring (WCAG):**
|
||
- Human-in-the-loop workflows må ha tilgjengelige grensesnitt
|
||
- Agent-outputs må kunne presenteres i skjermleser-vennlig format
|
||
|
||
## Kostnad og lisensiering
|
||
|
||
### Kostnadsmodell
|
||
|
||
| Kostnadsfaktor | Påvirkning av orchestration |
|
||
|----------------|----------------------------|
|
||
| **Model API calls** | ↑ i multi-agent patterns (N agents = N calls minimum) |
|
||
| **Context window** | ↑ i Group Chat og Magentic (akkumulerende threads) |
|
||
| **Compute (Azure Functions)** | ↑ i long-running Durable Orchestrations (men serverless = pay-per-execution) |
|
||
| **State storage** | ↑ hvis conversation history lagres (Cosmos DB, Redis) |
|
||
| **Tool execution** | Varierer (API-kostnader for hver tool call) |
|
||
|
||
### Optimaliserings-tips
|
||
|
||
**Token-optimalisering:**
|
||
- **Concurrent:** Parallell execution reduserer wall-clock time, men øker total tokens (N agent calls)
|
||
- **Sequential:** Hvis context kan trunkes mellom stages, implementer summarization
|
||
- **Group Chat:** Begrens max iterations, bruk round-robin i stedet for LLM-based speaker selection
|
||
- **Magentic:** Task ledger kan vokse — implementer checkpointing og ledger pruning
|
||
|
||
**Compute-optimalisering:**
|
||
- **Durable Functions:** Serverless billing = ingen cost under human-wait i HITL
|
||
- **PTU (Provisioned Throughput Units):** Hvis concurrent orchestration har forutsigbar throughput, vurder PTU
|
||
- **Batching:** Kombiner concurrent agents i batch API calls hvis modell-provider støtter det
|
||
|
||
### Lisensiering (Microsoft 365)
|
||
|
||
**Agent-kjøring:**
|
||
- Microsoft Agent Framework: Gratis SDK (men pay for model API calls)
|
||
- Semantic Kernel: Gratis SDK (open source)
|
||
- Copilot Studio Agents: Included in Power Apps per-user plan, Microsoft 365 Copilot (messages/day limits)
|
||
|
||
**Foundry Agent Service:**
|
||
- Azure AI Foundry: Pay-per-use pricing (model API calls + hosting)
|
||
- Connected Agents (classic, deprecated 2027-03-31 → Workflows + A2A): Workflow orchestration, pay-per-invocation
|
||
|
||
**Estimat (eksempel):**
|
||
- Sequential (4 agenter × 1000 tokens/agent × $0.01/1K tokens) ≈ **$0.04 per run**
|
||
- Concurrent (4 agenter parallelt) ≈ **$0.04 per run** (samme, men raskere wall-clock)
|
||
- Group Chat (5 iterations × 3 agenter × 1000 tokens) ≈ **$0.15 per run**
|
||
|
||
## For arkitekten (Cosmo)
|
||
|
||
### Spørsmål å stille
|
||
|
||
1. **Workflow-karakteristika:**
|
||
- Kan stegene i prosessen kjøres parallelt eller må de gå sekvensielt?
|
||
- Er rekkefølgen deterministisk eller dynamisk basert på kontekst?
|
||
- Hvor mange agents/steg er involvert? (<3 = simple patterns holder, >5 = vurder hybrid)
|
||
|
||
2. **State og context:**
|
||
- Trenger hver agent full context fra forrige, eller kan det trunkes/summarizes?
|
||
- Må state persisteres ved failures (Durable Functions)?
|
||
- Er conversation history sensitiv (GDPR)?
|
||
|
||
3. **Tool og system-interaksjon:**
|
||
- Skal agents kun resonnere eller også gjøre endringer i live systems?
|
||
- Hvis tool execution: Kreves human approval? (→ Group Chat HITL eller Magentic med approval gates)
|
||
|
||
4. **Reliability og observability:**
|
||
- Hva skjer hvis én agent feiler midt i workflow? (Circuit breakers, graceful degradation)
|
||
- Må orchestration være deterministisk for compliance/audit? (→ Sequential eller Durable Orchestrations)
|
||
- Hvordan trackes hver agent-beslutning? (Application Insights, Agent 365)
|
||
|
||
5. **Kostnadsbudsjett:**
|
||
- Hva er token-budsjett per run? (Group Chat og Magentic kan vokse raskt)
|
||
- Er latency viktigere enn kostnad? (→ Concurrent hvis ja, Sequential hvis nei)
|
||
- Skal vi bruke PTU for forutsigbar kostnad?
|
||
|
||
6. **Organisasjonens modenhetsnivå:**
|
||
- Har teamet erfaring med multi-agent debugging? (Start enkelt hvis nei)
|
||
- Er det kompetanse på distributed systems? (Orchestration ≈ distributed system)
|
||
- Finnes det existing agents som kan gjenbrukes? (Vurder Handoff eller A2A)
|
||
|
||
7. **Regulatoriske krav:**
|
||
- Klassifiseres løsningen som høyrisiko AI (AI Act)?
|
||
- Kreves human-in-the-loop? (→ Group Chat, Magentic med approval)
|
||
- Må beslutningsprosessen dokumenteres (Forvaltningsloven)? (→ task ledger i Magentic)
|
||
|
||
8. **Integrasjonsbehov:**
|
||
- Skal orchestration integreres med Copilot Studio eller M365 Copilot? (→ A2A protocol)
|
||
- Finnes det existing workflows i Power Automate som kan orkestrere? (Hybrid low-code/code)
|
||
|
||
### Fallgruver
|
||
|
||
| Fallgruve | Hvordan unngå |
|
||
|-----------|---------------|
|
||
| **Over-engineering** | Start med Sequential eller Concurrent, komplisér kun når nødvendig |
|
||
| **Context explosion** | Implementer context summarization mellom stages |
|
||
| **Infinite loops** | Hardcode max iterations, implementer stall detection |
|
||
| **Security over-privilege** | Bruk Managed Identities, least-privilege per agent |
|
||
| **Ignoring latency** | Måle wall-clock time, ikke kun token-kostnad |
|
||
| **Shared state conflicts** | Isoler state per agent eller bruk coordinator pattern |
|
||
| **Tool execution uten approval** | Implementer FunctionApprovalRequestContent i HITL workflows |
|
||
| **Determinism når ikke nødvendig** | Vurder om non-deterministic patterns gir mer value |
|
||
|
||
### Anbefalinger per modenhetsnivå
|
||
|
||
**Level 1: Single-Agent (baseline):**
|
||
- Én agent med mange tools
|
||
- Før du går multi-agent: sikre at én agent virkelig ikke holder
|
||
|
||
**Level 2: Simple Multi-Agent:**
|
||
- Sequential (lineær pipeline) eller Concurrent (parallel analyse)
|
||
- Deterministiske workflows
|
||
- Begrenset state sharing
|
||
|
||
**Level 3: Collaborative Multi-Agent:**
|
||
- Group Chat (iterativ refinement)
|
||
- Handoff (specialist routing)
|
||
- Human-in-the-loop integration
|
||
- State persistence med Durable Functions
|
||
|
||
**Level 4: Autonomous Multi-Agent:**
|
||
- Magentic (dynamic planning)
|
||
- Tool-enabled agents med external system changes
|
||
- Task ledger-basert execution
|
||
- Comprehensive observability (Application Insights, Agent 365)
|
||
|
||
**Level 5: Enterprise Multi-Agent Platform:**
|
||
- Hybrid patterns per workflow stage
|
||
- Cross-platform orchestration (A2A protocol)
|
||
- Policy enforcement (Agent 365 control plane)
|
||
- Multi-tenant isolation, Zero Trust architecture
|
||
|
||
## Kilder og verifisering
|
||
|
||
### Microsoft Learn (Verified via MCP)
|
||
|
||
1. **AI agent orchestration patterns** (Azure Architecture Center)
|
||
https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/ai-agent-design-patterns
|
||
*Confidence: Verified* — Definitive guide til alle 5 patterns, spektrum av kompleksitet (direct model call → single agent → multi-agent), oppdatert 2026-04
|
||
|
||
2. **Microsoft Agent Framework Workflows Orchestrations**
|
||
https://learn.microsoft.com/en-us/agent-framework/user-guide/workflows/orchestrations/overview
|
||
*Confidence: Verified* — Implementation guide med C#/Python samples
|
||
|
||
3. **Semantic Kernel Agent Orchestration**
|
||
https://learn.microsoft.com/en-us/semantic-kernel/frameworks/agent/agent-orchestration/
|
||
*Confidence: Verified* — Unified interface for orchestration patterns
|
||
|
||
4. **Durable Agent Features**
|
||
https://learn.microsoft.com/en-us/agent-framework/user-guide/agents/agent-types/durable-agent/features
|
||
*Confidence: Verified* — Deterministic orchestrations, checkpointing
|
||
|
||
5. **Application design for AI workloads on Azure**
|
||
https://learn.microsoft.com/en-us/azure/well-architected/ai/application-design
|
||
*Confidence: Verified* — When to use orchestration vs. agents
|
||
|
||
6. **Multi-agent patterns (Copilot Studio)**
|
||
https://learn.microsoft.com/en-us/microsoft-copilot-studio/guidance/architecture/multi-agent-patterns
|
||
*Confidence: Verified* — A2A protocol, MCP integration, capability matrise, hybrid workflow diagram, oppdatert 2026-04
|
||
|
||
7. **Build agent platforms on Azure** (Microsoft for Startups)
|
||
https://learn.microsoft.com/en-us/microsoft-for-startups/build/build-agent
|
||
*Confidence: Verified* — Orchestration layer architecture
|
||
|
||
8. **Multiple-agent workflow automation solution**
|
||
https://learn.microsoft.com/en-us/azure/architecture/ai-ml/idea/multiple-agent-workflow-automation
|
||
*Confidence: Verified* — Use cases per industry
|
||
|
||
### GitHub Code Samples (Verified via MCP)
|
||
|
||
9. **Agent Framework workflow samples**
|
||
https://github.com/microsoft/agent-framework/tree/main/workflow-samples
|
||
*Confidence: Verified* — C# code examples for all patterns
|
||
|
||
10. **Semantic Kernel multi-agent samples**
|
||
https://github.com/microsoft/semantic-kernel/tree/main/python/samples/getting_started_with_agents
|
||
*Confidence: Verified* — Python orchestration examples
|
||
|
||
### Research Papers (Baseline Knowledge)
|
||
|
||
11. **Magentic-One: A Generalist Multi-Agent System**
|
||
https://www.microsoft.com/en-us/research/articles/magentic-one-a-generalist-multi-agent-system-for-solving-complex-tasks/
|
||
*Confidence: Baseline* — Original Magentic research from Microsoft Research
|
||
|
||
12. **AutoGen Multi-Agent Framework**
|
||
https://microsoft.github.io/autogen/stable/user-guide/core-user-guide/design-patterns/intro.html
|
||
*Confidence: Baseline* — Open source multi-agent patterns
|
||
|
||
---
|
||
|
||
**Total MCP calls:** 6 (3 microsoft_docs_search + 2 microsoft_docs_fetch + 1 microsoft_code_sample_search)
|
||
**Total unique URLs:** 12
|
||
**Confidence per section:**
|
||
- Introduksjon, Kjernekomponenter, Arkitekturmønstre: **Verified**
|
||
- Beslutningsveiledning, Integrasjon med Microsoft-stakken: **Verified**
|
||
- Offentlig sektor, Kostnad og lisensiering: **Baseline** (applied Azure/M365 pricing knowledge + Norwegian regulatory context)
|
||
- For arkitekten: **Baseline** (architectural synthesis from Verified sources)
|