ms-ai-architect/skills/ms-ai-advisor/references/copilot-extensibility/copilot-orchestration-multi-agent.md

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:

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

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

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:

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:

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

   .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.