ms-ai-architect/skills/ms-ai-engineering/references/agent-orchestration/multi-agent-orchestration-patterns.md
Kjell Tore Guttormsen 070141f06b chore(ms-ai-architect): refresh KB medium-bucket — 74 files [skip-docs]
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
2026-06-19 14:02:18 +02:00

712 lines
28 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

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