Verifisert mot offisiell MS-doc (juni 2026): «Microsoft Foundry» er det gjeldende produkt-/portalnavnet; «Foundry (classic)» = gamle «Azure AI Foundry» (/azure/foundry/ vs /azure/foundry-classic/). Premiss bekreftet før sveip. Multi-regel, IKKE naiv s/Azure AI Foundry/Microsoft Foundry/ — MS dropper «Azure AI» (legger IKKE til «Microsoft») for to produktvarianter: - «Azure AI Foundry Agent[ Service|s]» → «Foundry Agent Service/Agents» (MS-form) - «Azure AI Foundry Models» → «Foundry Models» (i «Azure OpenAI in Foundry Models») - «Azure AI Foundry SDK» → «Microsoft Foundry SDK» (operatør-valg) - «Azure AI Foundry portal/project» + generisk → «Microsoft Foundry» - Pre-eksisterende «Microsoft Foundry Models» (4) normalisert → «Foundry Models» Bevart: «Azure OpenAI», «Azure AI Inference SDK», «Azure AI Search», «Azure AI Services», kode-IDer. Historisk ref «(tidligere Azure AI Foundry)» i model-catalog-2026.md beskyttet via lookbehind. URL /azure/ai-foundry/→ /azure/foundry/ kun i owasp-llm-top10 (KB-ref); docs/-filer deferred. Scope: skills (inkl. 3 SKILL.md) + commands + agents + README + CLAUDE. Ekskludert: docs/ (interne), playground/+tests/ fixtures (testdata), CHANGELOG.md (historisk logg), STATE.md (gitignored). 3 SKILL.md endret (advisor/engineering/security) → judge-cache teknisk invalidert for disse, men scorer uendret: advisor 91, eng/gov/infra/sec 96 (alle ≥90). validate 239/0. 0 «Azure AI Foundry» igjen (utenom bevart ref). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
466 lines
19 KiB
Markdown
466 lines
19 KiB
Markdown
# Multi-Agent Orchestration in Copilot
|
|
|
|
**Last updated:** 2026-06-19 | Verified: MCP 2026-06-19
|
|
**Status:** Generally Available (GA)
|
|
**Category:** Copilot Extensibility & Integration
|
|
|
|
---
|
|
|
|
## Introduksjon
|
|
|
|
Multi-agent orchestration i Microsoft-økosystemet handler om å bygge komplekse AI-systemer ved å komponere flere spesialiserte agenter som samarbeider for å løse brukeroppgaver. Denne tilnærmingen erstatter monolittiske chatbots med modulære, skalerbare arkitekturer hvor hver agent har sitt eget domene, verktøy og kunnskapskilder.
|
|
|
|
Microsofts tilnærming til multi-agent orchestration støttes på tvers av tre hovedplattformer: **Copilot Studio** (low-code), **Microsoft Agent Framework** (pro-code), og **Microsoft 365 Copilot** (enterprise integration). Alle bruker generative orchestration powered by large language models for å automatisk koble sammen agenter, topics, tools og knowledge sources uten å kreve forhåndsdefinerte trigger phrases.
|
|
|
|
Multi-agent systemer gir fordeler som bedre modularity, domene-separasjon, enklere vedlikehold, og mulighet til å gjenbruke spesialiserte agenter på tvers av flere hovedagenter. De muliggjør også granulær governance og access control per agent, noe som er kritisk for enterprise-scenarier.
|
|
|
|
## Kjernekomponenter
|
|
|
|
### Agent-typer i Copilot Studio
|
|
|
|
| Type | Beskrivelse | Context Sharing | Brukstilfeller |
|
|
|------|-------------|-----------------|----------------|
|
|
| **Inline agents** (child agents) | Små, gjenbrukbare workflows innenfor samme agent. Ofte implementert som topics. | Deler context med hovedagent | Enkle sub-tasks, hjelpefunksjoner (f.eks. tekstoversettelse) |
|
|
| **Connected agents** | Separate agenter med egen orchestration, tools og knowledge | Konversasjonshistorikk sendes automatisk (kan deaktiveres) | Komplekse domener, ulike tilgangskontroller, gjenbruk på tvers av hovedagenter |
|
|
|
|
### Generative Orchestration (Copilot Studio)
|
|
|
|
Når generative orchestration er aktivert, bruker agenten store språkmodeller til å:
|
|
|
|
1. **Automatisk velge ressurser**: Identifiserer hvilke topics, tools, agenter og knowledge sources som skal brukes basert på beskrivelser (ikke trigger phrases)
|
|
2. **Multi-intent håndtering**: Kan håndtere forespørsler med flere intensjoner i én user message
|
|
3. **Automatisk parameter-utfylling**: Ekstraher kontekst fra samtalen for å fylle inn manglende input-parametere
|
|
4. **Chaining**: Kaller flere agenter/tools i sekvens og sammenstiller svar automatisk
|
|
|
|
**Nøkkelfaktorer for agent-seleksjon:**
|
|
- Description (viktigst)
|
|
- Navn på agent/topic/tool
|
|
- Input/output parametere og deres beskrivelser
|
|
|
|
**Avanserte kontrollmuligheter (generativ modus):**
|
|
- **Avbryte plan**: Bruk **"End all topics"**-node i et topic for å kansellere gjenværende steg i orchestratorens plan
|
|
- **Samtalehistorikk**: Agenter bruker nylig samtalehistorikk som kontekst. For å nullstille: bruk **"Clear variable values"**-node med alternativet "Conversation history for the current session"
|
|
- **Topic-triggere**: `AI response generated` (agenten genererer svar) og `Plan complete` (alle planlagte steg utført) gir finkornet kontroll
|
|
|
|
### Agent-komponenter (Microsoft Agent Framework)
|
|
|
|
For pro-code utvikling tilbyr Agent Framework:
|
|
|
|
| Komponent | Beskrivelse |
|
|
|-----------|-------------|
|
|
| **HandoffBuilder** | Bygger workflows hvor agenter kan overføre samtaler til hverandre med eksplisitte routing rules |
|
|
| **GroupChatBuilder** | Koordinerer multi-agent samarbeid gjennom group chat med orchestrator-agent |
|
|
| **ConcurrentBuilder** | Kjører flere agenter parallelt (fan-out/fan-in pattern) |
|
|
| **SequentialPipeline** | Chain av agenter som kjører i sekvens |
|
|
|
|
### Agent Connectivity (Copilot Studio)
|
|
|
|
Copilot Studio støtter forbindelse til eksterne agenter via:
|
|
|
|
- Copilot Studio agents (samme environment)
|
|
- Microsoft Foundry agents
|
|
- Microsoft Fabric Data agents
|
|
- Microsoft 365 Agents SDK agents
|
|
- Agent2Agent (A2A) protocol (cross-platform)
|
|
|
|
## Arkitekturmønstre
|
|
|
|
### Mønster 1: Triage + Specialist (Handoff)
|
|
|
|
**Beskrivelse:** En hovedagent (triage) router brukerforespørsler til spesialiserte agenter basert på domene.
|
|
|
|
```
|
|
User → Triage Agent → [Math Tutor | History Tutor | Billing Agent]
|
|
↓
|
|
(kan returnere til Triage)
|
|
```
|
|
|
|
**Fordeler:**
|
|
- Tydelig domene-separasjon
|
|
- Spesialistene kan ha egne verktøy og kunnskapskilder
|
|
- Enklere å vedlikeholde og teste hver spesialist
|
|
|
|
**Ulemper:**
|
|
- Overhead ved context switching
|
|
- Krever nøye beskrivelser for at triage kan route korrekt
|
|
- Lengre responstid sammenlignet med inline-løsning
|
|
|
|
**Når bruke:**
|
|
- Subtasken er kompleks nok til å ha egen suite av tools/knowledge
|
|
- Krever ulike governance rules eller tilgangskontroller
|
|
- Agenten skal gjenbrukes i mange hovedagenter
|
|
|
|
**Copilot Studio implementering:**
|
|
```yaml
|
|
# Parent agent configuration
|
|
- Add connected agent: "Billing Specialist"
|
|
Description: "Handles all billing inquiries including invoices,
|
|
payments, refunds, and subscription management."
|
|
Pass conversation history: Yes
|
|
```
|
|
|
|
### Mønster 2: Concurrent Fan-Out/Fan-In
|
|
|
|
**Beskrivelse:** Flere agenter kjører parallelt på samme input, resultatene aggregeres.
|
|
|
|
```
|
|
User Input → [Researcher | Marketer | Legal Reviewer] → Aggregation → Output
|
|
```
|
|
|
|
**Fordeler:**
|
|
- Raskere responstid (parallell prosessering)
|
|
- Hver agent gir sitt perspektiv på samme data
|
|
- Godt egnet for review-workflows
|
|
|
|
**Ulemper:**
|
|
- Kompleksitet i aggregering av resultater
|
|
- Alle agenter må kunne jobbe med samme input
|
|
- Ressurskrevende (flere LLM-kall samtidig)
|
|
|
|
**Når bruke:**
|
|
- Content review fra ulike perspektiver (legal, marketing, technical)
|
|
- Multi-language translation
|
|
- Data analysis fra ulike vinkler
|
|
|
|
**Microsoft Agent Framework (Python):**
|
|
```python
|
|
from agent_framework import ConcurrentBuilder
|
|
|
|
workflow = ConcurrentBuilder().participants([
|
|
researcher,
|
|
marketer,
|
|
legal_reviewer
|
|
]).build()
|
|
|
|
result = await workflow.run("Analyze this product launch plan")
|
|
```
|
|
|
|
### Mønster 3: Sequential Pipeline
|
|
|
|
**Beskrivelse:** Agenter kjører i sekvens, hvor output fra én agent blir input til neste.
|
|
|
|
```
|
|
User → Research Agent → Writer Agent → Review Agent → Final Output
|
|
```
|
|
|
|
**Fordeler:**
|
|
- Strukturert, forutsigbar flyt
|
|
- Enkel debugging (kan inspisere output mellom steg)
|
|
- Hver agent bygger på forrige agents arbeid
|
|
|
|
**Ulemper:**
|
|
- Lengre total responstid
|
|
- Feil tidlig i pipeline kan spre seg nedover
|
|
- Vanskeligere å håndtere branching logic
|
|
|
|
**Når bruke:**
|
|
- Content creation pipelines
|
|
- Data processing med validering mellom steg
|
|
- Multi-stage approval workflows
|
|
|
|
**Microsoft Agent Framework (C#):**
|
|
```csharp
|
|
var workflow = AgentWorkflowBuilder
|
|
.CreateSequentialPipeline(researchAgent, writerAgent, reviewerAgent)
|
|
.Build();
|
|
|
|
var result = await workflow.RunAsync("Write an article about AI safety");
|
|
```
|
|
|
|
## Beslutningsveiledning
|
|
|
|
### Når skal du splitte til separate agenter?
|
|
|
|
| Kriterium | Inline (topic) | Connected Agent |
|
|
|-----------|----------------|-----------------|
|
|
| Kompleksitet | Enkel sub-task | Egen suite av tools/knowledge |
|
|
| Governance | Same tilgangskontroller | Ulike access controls |
|
|
| Gjenbruk | Brukes kun av én hovedagent | Gjenbrukes i mange hovedagenter |
|
|
| Domene | Del av samme domene | Forskjellig domene |
|
|
| Vedlikehold | Kan vedlikeholdes inline | Krever separat lifecycle |
|
|
|
|
**Tommelfingerregel:** Start med én agent og topics. Splitt kun når du ser et klart behov for modularity eller governance-grense.
|
|
|
|
### Vanlige feil
|
|
|
|
| Feil | Konsekvens | Løsning |
|
|
|------|-----------|---------|
|
|
| **Over-segmentering** | Mange små agenter gir overhead | Konsolider agenter som ikke har tydelig governance/domene-grense |
|
|
| **Vage beskrivelser** | Orchestrator velger feil agent | Skriv spesifikke, unike beskrivelser med nøkkelord |
|
|
| **Manglende data handoff-planlegging** | Connected agent mangler kontekst | Definer eksplisitt hvilke parametere som skal sendes |
|
|
| **Glemt audit logging** | Vanskelig å tracke hva connected agents gjør | Korreler parent/child sessions via telemetri identifiers |
|
|
| **Overlappende agent-beskrivelser** | Orchestrator kaller flere agenter unødvendig | Test grundig og revider overlappende beskrivelser |
|
|
|
|
### Røde flagg
|
|
|
|
⚠️ **Security:** Connected agent har tilgang hovedagent ikke har (f.eks. slette records) → Krev eksplisitt user consent eller approval workflow
|
|
|
|
⚠️ **Context limit:** Konversasjonshistorikk er begrenset → Viktig informasjon må inkluderes i transcript ved jevne intervaller
|
|
|
|
⚠️ **Disambiguation:** Med generative orchestration disambigueres ikke automatisk mellom lignende topics → Test grundig eller deaktiver "Multiple Topics Matched" system topic
|
|
|
|
⚠️ **Custom entities:** Tools/topics støtter ikke custom entities (closed lists, regex) som input → Bruk Question node i topic
|
|
|
|
## Integrasjon med Microsoft-stakken
|
|
|
|
### Copilot Studio ↔ Microsoft 365 Copilot
|
|
|
|
**Scenario:** Utvid M365 Copilot med organisasjonens egne agenter.
|
|
|
|
- Agenter bygget i Copilot Studio kan publiseres som **declarative agents** i M365 Copilot
|
|
- M365 Copilot bruker sin egen orchestrator, men agent kan ha egne instructions, knowledge og actions
|
|
- Governance håndteres via **Microsoft 365 admin center** (enable/disable/assign/block agents) under **Agents**-seksjonen i Copilot Control System
|
|
- Agent pinning: Microsoft-pinned, admin-pinned, user-pinned
|
|
- **AI Admin**-rollen gir dedikert, lavprivilegert administratortilgang for agent-styring (anbefalt fremfor Global Admin)
|
|
|
|
**Agent-typer som kan administreres (Verified):**
|
|
- **Publisert av org**: Predefinerte instruksjoner og actions — må gjennom admin approval
|
|
- **Delt av bruker**: Opprettet via Copilot Studio eller Agent Builder
|
|
- **Microsoft-agenter**: Innebygd i M365-tjenester (Researcher, Analyst etc.)
|
|
- **Eksterne partner-agenter**: Fra ISV-er
|
|
- **Frontier agents** (eksperimentelle):
|
|
- **App Builder agent**: Kan bygge Power Apps via Copilot
|
|
- **Workflows agent**: Lager flows i Copilot — lagres i default environment
|
|
|
|
**Microsoft Agent 365** er den nye kontrollplanen for alle AI-agenter (uavhengig av hvor de er bygd), tilgjengelig via M365 admin center.
|
|
|
|
**Nøkkel-policy:**
|
|
- Agents arver M365 Copilots security, privacy og compliance
|
|
- Data forblir innenfor Microsoft 365 service boundary
|
|
- Conditional Access og MFA via Microsoft Entra ID
|
|
|
|
### Agent Framework ↔ Semantic Kernel
|
|
|
|
**Integrasjon:**
|
|
- Agent Framework agents kan wrappas som Semantic Kernel plugins
|
|
- Workflows kan konverteres til `AIAgent` med `.AsAgent()` extension method
|
|
- Semantic Kernel kan orkestrere Agent Framework workflows via `CopilotStudioAgent` client
|
|
|
|
**Use case:**
|
|
```python
|
|
from semantic_kernel.agents import CopilotStudioAgent
|
|
|
|
agent = CopilotStudioAgent(
|
|
client=client,
|
|
name="CustomAgent",
|
|
instructions="You help answer custom questions."
|
|
)
|
|
```
|
|
|
|
### Power Platform Integration
|
|
|
|
- **Agent flows** (Copilot Studio) vs. **cloud flows** (Power Automate):
|
|
- Agent flows: Optimalisert for business processes, AI-driven automation
|
|
- Cloud flows: Generelle automation-scenarier, kan kombineres med agent flows
|
|
- **Connectors:** Agent flows kan bruke Power Automate connector library
|
|
- **Environment governance:** DLP, role-based access, auditing på environment-nivå
|
|
|
|
### Foundry Agents
|
|
|
|
Connected agents kan koble til Microsoft Foundry agents, som gir:
|
|
- Custom language models
|
|
- Advanced RAG capabilities
|
|
- Prompt flow orchestration
|
|
|
|
## Offentlig sektor (Norge)
|
|
|
|
### GDPR & Datasuverenitet
|
|
|
|
**Vurderingspunkter:**
|
|
- **Data residency:** Hvor lagres agent-konversasjoner? (Microsoft 365 tenant-region)
|
|
- **Cross-border data transfer:** Connected agents på tvers av environments → sjekk at begge er i EU-region
|
|
- **Treatyansvar:** Definer data processing agreements for hver connected agent som håndterer persondata
|
|
|
|
**Praksis:**
|
|
- Dokumenter dataflyt mellom agenter i DPIA
|
|
- Bruk Microsoft Purview for å oppdage, beskytte og governe data i agent-interaksjoner
|
|
- Aktiver audit logging for alle connected agent-kall
|
|
|
|
### AI Act & Transparency
|
|
|
|
**Krav:**
|
|
- Brukere skal informeres om at de interagerer med AI
|
|
- Brukere skal forstå når én agent delegerer til en annen
|
|
|
|
**Implementering i Copilot Studio:**
|
|
```yaml
|
|
# Conversation Start system topic
|
|
- Message: "Hei! Jeg er en AI-assistent som kan koble deg til
|
|
spesialiserte agenter for fakturering, teknisk support
|
|
og ordrehåndtering."
|
|
```
|
|
|
|
**Audit:**
|
|
- Log alle agent handoffs med timestamps og user consent
|
|
- Separate transcripts per connected agent (korreler via session ID)
|
|
|
|
### Forvaltningsloven § 11 (veiledningsplikt)
|
|
|
|
**Relevans:** Offentlige virksomheter har plikt til å veilede brukere.
|
|
|
|
**Multi-agent implementering:**
|
|
- **Triage agent:** Hjelper bruker å finne riktig spesialist-agent
|
|
- **Fallback til human:** Hvis ingen agent kan hjelpe, eskaler til saksbehandler
|
|
- **Transparent routing:** Vis bruker hvilken agent de snakker med
|
|
|
|
**Eksempel:**
|
|
```
|
|
Triage: "Jeg ser du har spørsmål om barnetrygd.
|
|
Jeg kobler deg til vår spesialist for dette. [Barnetrygd-agent aktiveres]"
|
|
```
|
|
|
|
## Kostnad og lisensiering
|
|
|
|
### Kostnadsmodeller
|
|
|
|
| Plattform | Prismodell | Kostnadsdrivere |
|
|
|-----------|-----------|-----------------|
|
|
| **Copilot Studio** | Consumption-based (messages) | Antall meldinger, generative actions |
|
|
| **M365 Copilot** | Per-user license | M365 Copilot license (ca. $30/user/month) |
|
|
| **Agent Framework** | Azure consumption | Azure OpenAI API calls, Azure Functions runtime |
|
|
|
|
### Multi-agent kostnadshensyn
|
|
|
|
**Connected agents øker kostnad:**
|
|
- Hver agent-call = separate LLM-kall
|
|
- Konversasjonshistorikk sendes ved hver handoff (større context window)
|
|
- Parallelle agenter (concurrent) = multiple LLM-kall samtidig
|
|
|
|
**Optimaliseringsstrategier:**
|
|
1. **Deaktiver conversation history** når connected agent ikke trenger det:
|
|
```
|
|
Pass conversation history: No
|
|
```
|
|
2. **Bruk inline agents** (topics) for enkle sub-tasks → ingen ekstra LLM-kall
|
|
3. **Limit autonomous turns** (Agent Framework):
|
|
```python
|
|
.with_autonomous_mode(
|
|
agents=[triage_agent],
|
|
turn_limits={triage_agent.name: 3}
|
|
)
|
|
```
|
|
4. **Cache knowledge sources** → redusert re-indexing cost
|
|
5. **Monitor telemetry** → identifiser agenter som kalles unødvendig
|
|
|
|
### Lisenskrav (M365 Copilot agents)
|
|
|
|
| Funksjon | Lisenskrav |
|
|
|----------|-----------|
|
|
| Bruke M365 Copilot med agenter | M365 Copilot license |
|
|
| Bygge declarative agents | Copilot Studio eller Teams Toolkit (dev) |
|
|
| Administrere agents | M365 admin (gratis med tenant) |
|
|
| Custom engine agents | Azure subscription for hosting |
|
|
|
|
## For arkitekten (Cosmo)
|
|
|
|
### Spørsmål å stille kunden
|
|
|
|
1. **Domene-separasjon:**
|
|
- Hvilke forretningsdomener skal agenten dekke? (f.eks. HR, IT, salg)
|
|
- Har disse domenene ulike datakilder eller tilgangskontroller?
|
|
|
|
2. **Gjenbruk:**
|
|
- Skal noen av disse funksjonene brukes av flere hovedagenter?
|
|
- Planlegger dere flere agent-prosjekter fremover?
|
|
|
|
3. **Governance:**
|
|
- Trenger ulike deler av systemet ulike godkjenningsprosesser?
|
|
- Har dere behov for separate audit logs per domene?
|
|
|
|
4. **Performance:**
|
|
- Hva er akseptabel responstid? (sequential vs. concurrent)
|
|
- Hvor kritisk er kostnadskontroll? (inline vs. connected)
|
|
|
|
5. **Brukeropplevelse:**
|
|
- Skal brukere informeres når de "flyttes" til en annen agent?
|
|
- Trenger dere transparent routing for compliance?
|
|
|
|
6. **Lifecycle:**
|
|
- Hvem eier vedlikehold av ulike agenter? (samme team vs. separate teams)
|
|
- Har dere etablert CI/CD for agent deployment?
|
|
|
|
7. **Security:**
|
|
- Skal connected agents ha høyere privilegier enn hovedagent?
|
|
- Kreves user consent før sensitive operasjoner?
|
|
|
|
8. **Datahåndtering:**
|
|
- Hvor sensitiv er konteksten som sendes mellom agenter?
|
|
- Må dere logge eller anonymisere data ved agent handoffs?
|
|
|
|
### Fallgruber å unngå
|
|
|
|
| Fallgruve | Impact | Forebygging |
|
|
|-----------|--------|------------|
|
|
| **Premature decomposition** | Overhead uten gevinst | Start med én agent, splitt når behov oppstår |
|
|
| **Poor description quality** | Feil agent-seleksjon | Bruk nøkkelord, spesifiser hva agent *ikke* gjør |
|
|
| **Security bypass via handoff** | Uautoriserte operasjoner | Audit alle connected agent-kall, krev consent for sensitive actions |
|
|
| **Context loss** | Connected agent mangler info | Test conversation history handoff, vurder explicit parameter passing |
|
|
| **Insufficient testing** | Orchestrator kaller feil agenter | Test med realistiske multi-intent queries |
|
|
| **No correlation in telemetry** | Vanskelig debugging | Korreler parent/child sessions med identifiers |
|
|
|
|
### Anbefalinger per modenhetsnivå
|
|
|
|
#### Nivå 1: Starter (proof-of-concept)
|
|
- **Bruk:** Inline agents (topics) kun
|
|
- **Plattform:** Copilot Studio low-code
|
|
- **Fokus:** Lær generative orchestration med topics først
|
|
- **Unngå:** Connected agents (for tidlig kompleksitet)
|
|
|
|
#### Nivå 2: Voksende (pilot i produksjon)
|
|
- **Bruk:** 1-2 connected agents for tydelige domener
|
|
- **Plattform:** Copilot Studio + Power Automate
|
|
- **Fokus:** Etabler governance for agent handoffs, audit logging
|
|
- **Best practice:** Dokumenter beskrivelser i versjonskontroll
|
|
|
|
#### Nivå 3: Moden (enterprise-scale)
|
|
- **Bruk:** Multi-agent arkitektur med triage + spesialist-agenter
|
|
- **Plattform:** Agent Framework (pro-code) + Microsoft Foundry
|
|
- **Fokus:** CI/CD for agents, telemetri-korrelering, cost optimization
|
|
- **Advanced patterns:** Concurrent workflows, approval workflows, A2A protocol for cross-platform
|
|
|
|
#### Nivå 4: Innovativ (cutting-edge)
|
|
- **Bruk:** Autonomous multi-agent systems med self-coordination
|
|
- **Plattform:** Agent Framework + custom orchestrators
|
|
- **Fokus:** Agent-to-agent protocols, dynamic agent composition
|
|
- **Research:** Agent swarms, emergent collaboration
|
|
|
|
## Kilder og verifisering
|
|
|
|
### Microsoft Learn URLs (MCP-verifisert)
|
|
|
|
1. **Multi-agent patterns:**
|
|
https://learn.microsoft.com/en-us/microsoft-copilot-studio/guidance/multi-agent-patterns
|
|
(Verified: 2026-06-19)
|
|
|
|
2. **Generative orchestration:**
|
|
https://learn.microsoft.com/en-us/microsoft-copilot-studio/advanced-generative-actions
|
|
(Verified: 2026-04)
|
|
|
|
3. **Agents for M365 Copilot:**
|
|
https://learn.microsoft.com/en-us/microsoft-365-copilot/extensibility/agents-overview
|
|
(Verified: 2026-04)
|
|
|
|
4. **Agent Framework Handoff:**
|
|
https://learn.microsoft.com/en-us/agent-framework/user-guide/workflows/orchestrations/handoff
|
|
(Verified: 2026-04)
|
|
|
|
5. **Agent governance (M365 admin):**
|
|
https://learn.microsoft.com/en-us/microsoft-365/admin/manage/manage-copilot-agents-integrated-apps
|
|
(Verified: 2026-06-19)
|
|
|
|
6. **Agent security & compliance:**
|
|
https://learn.microsoft.com/en-us/copilot/microsoft-365/agent-essentials/agent-essentials-overview
|
|
(Verified: 2026-04)
|
|
|
|
### Konfidensnivå per seksjon
|
|
|
|
| Seksjon | Konfidens | Kilde |
|
|
|---------|-----------|-------|
|
|
| Kjernekomponenter | **Verified** | MCP: microsoft_docs_fetch (multi-agent-patterns, generative-actions) |
|
|
| Arkitekturmønstre | **Verified** | MCP: microsoft_code_sample_search (handoff, concurrent patterns) |
|
|
| Integrasjon M365 | **Verified** | MCP: microsoft_docs_search (agents-overview, admin-guide) |
|
|
| Kostnad | **Baseline** | Modellkunnskap (prismodeller kan endre seg) |
|
|
| Offentlig sektor (Norge) | **Baseline** | Generell compliance-kunnskap (verifiser lokale regler) |
|
|
| Best practices | **Verified** | MCP: microsoft_docs_fetch (multi-agent-patterns guidance) |
|
|
|
|
**Anbefaling:** For produksjonsbeslutninger, verifiser alltid kostnad og compliance mot siste Microsoft-dokumentasjon og lokale juridiske rådgivere.
|