# Multi-Agent Orchestration Patterns and Topologies

**Last updated:** 2026-06-19 | Verified: MCP 2026-06-19
**Status:** GA
**Category:** Agent Orchestration & Automation
**Type:** reference
**Source:** https://learn.microsoft.com/agent-framework/user-guide/workflows/orchestrations/overview

---

## Innhold

- [Introduksjon](#introduksjon)
- [Kjernekomponenter](#kjernekomponenter)
- [Arkitekturmønstre](#arkitekturmønstre)
- [Beslutningsveiledning](#beslutningsveiledning)
- [Integrasjon med Microsoft-stakken](#integrasjon-med-microsoft-stakken)
- [Offentlig sektor (Norge)](#offentlig-sektor-norge)
- [Kostnad og lisensiering](#kostnad-og-lisensiering)
- [For arkitekten (Cosmo)](#for-arkitekten-cosmo)
- [Kilder og verifisering](#kilder-og-verifisering)

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