feat(ultraplan-local): v1.6.0 — /ultraresearch-local deep research command
Add /ultraresearch-local for structured research combining local codebase analysis with external knowledge via parallel agent swarms. Produces research briefs with triangulation, confidence ratings, and source quality assessment. New command: /ultraresearch-local with modes --quick, --local, --external, --fg. New agents: research-orchestrator (opus), docs-researcher, community-researcher, security-researcher, contrarian-researcher, gemini-bridge (all sonnet). New template: research-brief-template.md. Integration: --research flag in /ultraplan-local accepts pre-built research briefs (up to 3), enriches the interview and exploration phases. Planning orchestrator cross-references brief findings during synthesis. Design principle: Context Engineering — right information to right agent at right time. Research briefs are structured artifacts in the pipeline: ultraresearch → brief → ultraplan --research → plan → ultraexecute. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
Kjell Tore Guttormsen
commit
baa2d0220b
488 changed files with 213221 additions and 0 deletions
|
|
@ -0,0 +1,699 @@
|
|||
# Multi-Agent Orchestration Patterns and Topologies
|
||||
|
||||
**Last updated:** 2026-02
|
||||
**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 Agent Service):**
|
||||
- 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
|
||||
2. Use MCP for tool/data access (M365 services)
|
||||
3. Use A2A for cross-platform messaging
|
||||
4. Integrate mature agents via MCP or A2A
|
||||
5. Enforce policy/auditing via Agent 365 control plane
|
||||
|
||||
### 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: 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
|
||||
|
||||
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
|
||||
|
||||
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)
|
||||
Loading…
Add table
Add a link
Reference in a new issue