ms-ai-architect/skills/ms-ai-engineering/references/agent-orchestration/semantic-kernel-agents-implementation.md

Semantic Kernel and Microsoft Agent Framework - Implementation Patterns

Last updated: 2026-04 | Verified: MCP 2026-04 Status: GA (Agent Orchestration: Experimental) Category: Agent Orchestration & Automation

---

Introduksjon

Semantic Kernel Agent Framework og Microsoft Agent Framework representerer neste generasjon av agentic AI-utvikling på Microsoft-stacken. Semantic Kernel Agent Framework bygger på det etablerte Semantic Kernel-økosystemet og utvider det med multi-agent orchestration patterns, mens Microsoft Agent Framework forener kapabilitetene fra Semantic Kernel og AutoGen i ett unified framework.

Begge frameworks deler samme grunnleggende filosofi: agenter er autonome enheter som kan resonnere, kalle funksjoner, samarbeide med andre agenter, og tilpasse seg dynamisk til komplekse scenarier. De bruker function calling som primær planleggingsmekanisme, der moderne LLM-modeller iterativt velger og utfører funksjoner for å løse oppgaver.

Semantic Kernel Agent Framework gir fem hovedagent-typer (ChatCompletionAgent, OpenAIAssistantAgent, AzureAIAgent, OpenAIResponsesAgent, CopilotStudioAgent) og fem orchestration patterns (Concurrent, Sequential, Handoff, Group Chat, Magentic). Microsoft Agent Framework bygger videre på dette og legger til enterprise-grade features som OpenTelemetry observability, Microsoft Entra-integrasjon, og standarder som Agent-to-Agent (A2A) protocol og Model Context Protocol (MCP).

Nøkkelforskjellen: Semantic Kernel bruker Kernel-objektet som sentral orkestreringsenhet, mens Microsoft Agent Framework bruker IChatClient wrapped av ChatClientAgent for mer fleksibel provider-integrasjon.

Kjernekomponenter

Agent-typer i Semantic Kernel

Agent Type	Use Case	State Management	Function Calling
ChatCompletionAgent	Generell-purpose conversational agents	Lokal (ChatHistory)	Må aktiveres eksplisitt (FunctionChoiceBehavior.Auto())
OpenAIAssistantAgent	OpenAI Assistants API-baserte agenter	Serverside (OpenAI)	Alltid aktivert
AzureAIAgent	Azure AI Agent Service-baserte agenter	Serverside (Azure)	Matcher AzureAIAgentThread
OpenAIResponsesAgent	Structured responses via Responses API	Lokal/Serverside	Konfigurerbar
CopilotStudioAgent	Copilot Studio agent-integrasjon	Copilot Studio	Via Copilot Studio

Plugins og Function Calling

Plugins er grunnlaget for agent-kapabiliteter. De defineres med [KernelFunction]-attributtet og registreres på Kernel-objektet:

public class OrderPlugin {
    [KernelFunction("check_order_status")]
    [Description("Gets the current status of an order")]
    public string CheckOrderStatus(string orderId)
        => $"Order {orderId} is shipped.";
}

// Registrer plugin på agenten
ChatCompletionAgent agent = new() {
    Name = "OrderAgent",
    Instructions = "You help customers with order inquiries.",
    Kernel = kernel,
    Arguments = new KernelArguments(
        new OpenAIPromptExecutionSettings() {
            FunctionChoiceBehavior = FunctionChoiceBehavior.Auto()
        })
};
agent.Kernel.Plugins.AddFromType<OrderPlugin>();

Function calling loop:

1. LLM får chat history + function schemas
2. LLM bestemmer om den skal svare eller kalle en funksjon
3. Hvis funksjonskall: parse funksjonsnavn og parametere
4. Utfør funksjonen
5. Returner resultatet til LLM
6. Repeter til oppgaven er løst eller brukeren trengs

Semantic Kernel automatiserer hele denne loopen når FunctionChoiceBehavior.Auto() er aktivert.

Agent Thread og Conversation State

AgentThread abstraherer conversation state management:

• Stateful agents (AzureAIAgent, OpenAIAssistantAgent): State lagres i tjenesten, tilgang via ID
• Stateless agents (ChatCompletionAgent): Chat history sendes med hver invokasjon
• Type matching: Stateful agents krever matching thread-type (f.eks. AzureAIAgent + AzureAIAgentThread)

# ChatCompletionAgent med lokal state
from semantic_kernel.agents import ChatCompletionAgent, ChatHistoryAgentThread

agent = ChatCompletionAgent(
    service=AzureChatCompletion(),
    instructions="You are a helpful assistant.",
    plugins=[MyPlugin()]
)

thread = ChatHistoryAgentThread()  # Lokal state
async for message in agent.invoke(user_message, thread):
    print(message.content)

Orchestration Patterns (Semantic Kernel)

Pattern	Koordinering	Typisk bruk	Status
Concurrent	Broadcast til alle, samle resultater uavhengig	Parallell analyse, ensemble decision making	Experimental
Sequential	Pass resultat fra én agent til neste i sekvens	Pipelines, multi-stage processing	Experimental
Handoff	Dynamisk overføring basert på kontekst/regler	Escalation, expert handoff	Experimental
Group Chat	Alle agenter i gruppe, koordinert av manager	Collaborative problem solving, brainstorming	Experimental
Magentic	Planner-based manager koordinerer team	Komplekse, generalist multi-agent tasks	Experimental

Unified interface: Alle orchestration patterns har samme konstruksjons- og invokasjonsmønster.

Microsoft Agent Framework Additions

Microsoft Agent Framework bygger på Semantic Kernel og tilbyr:

• Multi-agent orchestration: Sequential, Concurrent, Group Chat, Handoff, Magentic
• Cloud/provider flexibility: Cloud-agnostisk (containers, on-prem, multi-cloud) og provider-agnostisk (OpenAI, Azure AI Foundry)
• Enterprise features: OpenTelemetry, Microsoft Entra, Responsible AI (prompt injection protection, task adherence monitoring)
• Standards-based interoperability: A2A protocol, Model Context Protocol (MCP)

Hovedforskjell fra Semantic Kernel: Bruker IChatClient (Microsoft.Extensions.AI) i stedet for Kernel-objektet.

// Microsoft Agent Framework approach
var chatClient = new AzureOpenAIClient(endpoint, credential).AsChatClient(modelId);
var chatClientAgent = new ChatClientAgent(chatClient, name: "Assistant");

// Semantic Kernel approach
var kernel = Kernel.CreateBuilder()
    .AddAzureOpenAIChatCompletion(modelId, endpoint, apiKey)
    .Build();
var agent = new ChatCompletionAgent() { Kernel = kernel };

Arkitekturmønstre

1. Single Agent med Function Calling

Bruk når: Oppgaven kan løses av én spesialisert agent med tilgang til plugins.

Fordeler:

• Enkel arkitektur
• Lav latency (ingen koordinering mellom agenter)
• Lett å debugge

Ulemper:

• Begrenset til én agents kompetanseområde
• Kan ikke håndtere komplekse, multi-domene oppgaver

from semantic_kernel.agents import ChatCompletionAgent
from semantic_kernel.connectors.ai import FunctionChoiceBehavior

agent = ChatCompletionAgent(
    service=AzureChatCompletion(),
    instructions="You are a GitHub repository assistant.",
    plugins=[GitHubPlugin()],
    function_choice_behavior=FunctionChoiceBehavior.Auto()
)

thread = ChatHistoryAgentThread()
async for message in agent.invoke("What issues are open?", thread):
    print(message.content)

2. Sequential Orchestration

Bruk når: Oppgaven er en tydelig pipeline der hver agent bygger på resultatet fra forrige.

Fordeler:

• Forutsigbar flyt
• Lett å resonnere om
• God for step-by-step workflows

Ulemper:

• Blokkerende (agent 2 venter på agent 1)
• Kan ikke håndtere sideveier eller branching

Eksempel: Document processing pipeline (Extract → Analyze → Summarize → Translate)

3. Group Chat med Magentic Manager

Bruk når: Oppgaven er kompleks, åpen, og krever dynamisk samarbeid mellom spesialiserte agenter.

Fordeler:

• Fleksibel koordinering
• Manager kan re-plane basert på fremgang
• Human-in-the-loop plan review støttes

Ulemper:

• Høyere latency (planning overhead)
• Manager må være kraftig modell (gpt-4o, o1)
• Kan stall hvis agenter ikke gjør fremgang

from agent_framework import MagenticBuilder

workflow = (
    MagenticBuilder()
    .participants([researcher_agent, coder_agent, reviewer_agent])
    .with_manager(
        agent=manager_agent,
        max_round_count=10,
        max_stall_count=3,
        max_reset_count=2
    )
    .with_plan_review()  # Enable HITL
    .build()
)

async for event in workflow.run(task="Research and implement feature X"):
    if event.type == "RequestInfoEvent":
        # Handle plan review request
        response = await get_human_approval(event.data)
        await workflow.respond(response)

4. Handoff Pattern

Bruk når: Agenter er organisert i mesh-topologi og kan dynamisk overføre kontroll uten sentral manager.

Fordeler:

• Desentralisert (ingen single point of failure)
• Agenter bestemmer selv når de hander off
• God for escalation-scenarier

Ulemper:

• Kan være vanskeligere å resonnere om flyt
• Krever tydelige handoff-regler i agent instructions

Eksempel: Customer support (TriageAgent → OrderStatusAgent | ReturnAgent | RefundAgent)

Beslutningsveiledning

Velg Agent Type

Trenger du OpenAI Assistants API features (code interpreter, retrieval)?
├─ Ja → OpenAIAssistantAgent
└─ Nei → Trenger du Azure AI Agent Service (persistent threads, storage)?
    ├─ Ja → AzureAIAgent
    └─ Nei → Trenger du Copilot Studio integrasjon?
        ├─ Ja → CopilotStudioAgent
        └─ Nei → ChatCompletionAgent (mest fleksibel)

Velg Orchestration Pattern

Foer du velger multi-agent pattern: Evaluer om scenariet faktisk krever det. Hvert kompleksitetsnivaa introduserer koordinerings-overhead, latens og kostnad. Bruk laveste kompleksitetsnivaa som tilfredsstillende loser problemet:

1. Direct model call — klassifisering, oppsummering, oversettelse (ingen agent)
2. Single agent med tools — varierte spoerringsmaal innen ett domene (ofte riktig default)
3. Multi-agent orchestration — cross-domain, ulike sikkerhetsbegrensninger, eller oppgaver som drar nytte av parallell spesialisering

Scenario	Anbefalt Pattern	Hvorfor
Uavhengige subtasks	Concurrent	Parallell utførelse, redusert total tid
Lineær pipeline	Sequential	Forutsigbar, enkel flyt
Ukjent løsningsvei	Magentic	Dynamisk planning, iterativ refinement
Samarbeid uten planning	Group Chat	Enklere enn Magentic, fortsatt fleksibel
Triage/escalation	Handoff	Desentralisert, agent-drevet routing

Vanlige feil

Feil	Konsekvens	Fix
Glemmer å aktivere FunctionChoiceBehavior.Auto()	Agent kaller aldri plugins	Legg til i Arguments ved agent-opprettelse
Bruker feil thread-type med stateful agent	Runtime exception	Match thread-type til agent-type (AzureAIAgent + AzureAIAgentThread)
For mange plugins på én agent	Token overflow, dårlig function selection	Split agenter etter domene, bruk orchestration
Mangler [Description] på functions	LLM velger feil funksjon	Alltid beskriv funksjonens formål tydelig
Bruker Group Chat når Sequential ville fungert	Unødvendig overhead	Vurder om oppgaven faktisk trenger dynamisk koordinering

Røde flagg

• Agent kaller samme funksjon i loop: Manglende progress tracking eller dårlig instruction prompt
• Manager i Magentic staller umiddelbart: Agenter mangler capabilities til oppgaven, eller task er for vag
• Function calling returnerer "Unable to find function": Plugin ikke registrert på Kernel, eller function name mismatch
• Chat history vokser uhåndterlig: Mangler conversation summarization eller token management

Integrasjon med Microsoft-stacken

Azure AI Foundry

Semantic Kernel-agenter kan bruke Azure AI Foundry-deployments via Azure OpenAI connector:

builder.AddAzureOpenAIChatCompletion(
    deploymentName: "gpt-4o",
    endpoint: "https://<resource>.openai.azure.com",
    credentials: new AzureCliCredential()
);

AzureAIAgent integrerer direkte med Azure AI Agent Service for persistent threads og storage.

Copilot Studio

CopilotStudioAgent lar Semantic Kernel-kode kommunisere med Copilot Studio-bygde agenter:

var copilotAgent = new CopilotStudioAgent() {
    Name = "CopilotStudioBot",
    CopilotStudioEndpoint = "https://<endpoint>",
    // State management via Copilot Studio
};

Use case: Wrap Copilot Studio-agent i større multi-agent workflow.

Microsoft 365 Agents SDK

Microsoft 365 Agents SDK bruker Semantic Kernel eller Agent Framework som orchestrator:

• Agents SDK gir TurnContext og TurnState for channel-integrasjon (Teams, M365 Copilot)
• Semantic Kernel Kernel-objekt registreres som singleton i Program.cs
• Agent Framework bruker IChatClient wrapper i stedet

Deployment: Agents kan deployes til Microsoft Teams, M365 Copilot, eller egne channels.

Power Platform

Semantic Kernel kan integreres med Power Platform via:

• Power Automate: Custom connectors som kaller Semantic Kernel-backends
• AI Builder: Prompt-baserte modeller kan wrappes som Semantic Kernel plugins
• Dataverse: Lagre agent conversation state i Dataverse

Offentlig sektor (Norge)

GDPR og Datasuverenitet

Utfordring: Chat history og function call logs inneholder ofte persondata.

Mitigering:

• ChatCompletionAgent: Chat history lagres lokalt — full kontroll over data residency
• OpenAIAssistantAgent/AzureAIAgent: State lagres i tjenesten — verifiser at Azure-region er EU (West Europe, North Europe)
• Logging: Bruk Azure Monitor i norsk region, aktiver data residency-garantier
• PII filtering: Implementer pre-processing hooks som anonymiserer/pseudonymiserer PII før sending til LLM

AI Act Compliance

Høyrisiko AI-systemer (f.eks. helse, politi): Krever human oversight, logging, bias-testing.

Semantic Kernel-tilpasninger:

• Human-in-the-loop: Bruk with_plan_review() i Magentic for å kreve menneskelig godkjenning av planer
• Audit logging: Log alle function calls og agent decisions til tamper-proof storage (Azure Immutable Storage)
• Bias testing: Test agenter mot representative datasett fra norsk kontekst

Forvaltningsloven og Utredningsinstruksen

Krav: Beslutninger må kunne etterprøves og begrunnes.

Semantic Kernel-tilpasninger:

• Explainability: Logg hele ChatHistory med function calls for full transparency
• Decision tracing: Bruk metadata-felter i ChatMessageContent for å tagge beslutningspunkter
• Versjonering: Versjonshåndter agent instructions og plugin code for å kunne gjenskape beslutninger

Schrems II og Cloud Act

Risiko: Data lagret i US-baserte cloud-tjenester kan potensielt tilgjengeliggjøres for amerikanske myndigheter.

Mitigering:

• Azure EU regions: Bruk West Europe/North Europe for alle Semantic Kernel-relaterte ressurser
• ChatCompletionAgent over stateful agents: Reduserer avhengighet av US-baserte tjenester (OpenAI Assistants API)
• On-prem LLMs: For ekstremt sensitive data, kjør open-source modeller (Phi, Llama) on-prem med Semantic Kernel

Kostnad og Lisensiering

Prismodell

Komponent	Kostnad	Enhet
Azure OpenAI (GPT-4o)	~0.60 USD per 1M input tokens, ~1.80 USD per 1M output tokens	Token
Azure AI Agent Service	~0.002 USD per agent session + storage	Session + GB
OpenAI Assistants API	~0.03 USD per assistant/day + token costs	Day + Token
Semantic Kernel SDK	Gratis (open source)	-
Microsoft Agent Framework	Gratis (open source)	-

Kostnadsoptimalisering

1. Token management:

// Bruk smaller context window når mulig
var settings = new OpenAIPromptExecutionSettings() {
    MaxTokens = 500,  // Begrens output
    FunctionChoiceBehavior = FunctionChoiceBehavior.Auto(
        autoInvoke: true,
        options: new() {
            AllowConcurrentInvocation = true  // Parallel function calling → fewer turns
        }
    )
};

2. Velg billigere modeller for enkle agenter:

• Manager i Magentic: GPT-4o (trenger reasoning)
• Specialist agents: GPT-4o-mini (40% billigere, ofte tilstrekkelig)

3. Caching (Azure OpenAI):

• Bruk system message caching for agent instructions (redusert input token cost)

4. Kernel cloning (Semantic Kernel):

// IKKE opprett ny Kernel for hver agent
Kernel agentKernel = sharedKernel.Clone();  // Rebruk AI service connections

5. Batch processing:

• Grupper uavhengige oppgaver og bruk Concurrent orchestration (fewer total LLM calls)

Lisensiering

Semantic Kernel: MIT License (ingen restriksjon på kommersiell bruk) Microsoft Agent Framework: MIT License Azure OpenAI: Krever Azure-abonnement, ingen per-agent lisensavgift OpenAI API: Per-token pricing, ingen agent-lisens

Offentlig sektor: Ingen spesielle lisensbegrensninger, men vurder data residency-krav ved valg av AI service (Azure OpenAI vs. OpenAI).

For arkitekten (Cosmo)

Spørsmål å stille kunden

1. Kompleksitetsnivå: Er oppgaven løsbar av én agent, eller kreves samarbeid mellom spesialiserte agenter?
2. State management: Trenger dere persistent conversation state på tvers av sesjoner, eller er in-memory tilstrekkelig?
3. Data residency: Har dere krav om at chat history og agent state må lagres i EU?
4. Human oversight: Må menneskelige beslutningstagere godkjenne agent-planer før utførelse?
5. Integrasjon: Skal agentene integreres med eksisterende Microsoft 365-kanaler (Teams, Copilot)?
6. Volum: Hvor mange samtidige agentsesjoner forventer dere? (påvirker valg av Azure-tier og caching-strategi)
7. Compliance: Er dette et høyrisiko AI-system som faller under AI Act? Krever dere full audit trail?
8. Existing plugins: Har dere eksisterende Semantic Kernel plugins, eller starter dere fra scratch?

Fallgruver

Fallgruve	Konsekvens	Forebygging
Over-engineering med orchestration	Høy latency, kostnad	Start med single agent, utvid til orchestration kun hvis nødvendig
Under-engineering agent instructions	Agent kaller feil funksjoner	Bruk templates, test med few-shot examples
Manglende error handling i plugins	Agent får "function failed" uten context	Wrap plugin methods med try-catch, returner descriptive error messages
Ikke versjonshåndtere agent definitions	Kan ikke gjenskape historiske beslutninger	Versjonshåndter instructions og plugin code i git
Blande stateful og stateless agents	Thread type mismatch, runtime errors	Cluster agenter etter state management pattern

Anbefalinger per modenhetsnivå

Beginner (aldri brukt Semantic Kernel):

• Start med ChatCompletionAgent og én enkel plugin
• Bruk automatic function calling (FunctionChoiceBehavior.Auto())
• Unngå orchestration inntil du mestrer single-agent patterns
• Bruk OpenAI Playground for å teste function calling-prompts før implementasjon

Intermediate (erfaring med Semantic Kernel, nye på agenter):

• Eksperimenter med Sequential orchestration for pipelines
• Implementer ChatHistoryAgentThread for conversation management
• Utforsk AzureAIAgent for persistent threads
• Legg til OpenTelemetry for å spore function calls og agent decisions

Advanced (building production multi-agent systems):

• Bruk Magentic orchestration med human-in-the-loop for komplekse workflows
• Implementer Microsoft Agent Framework for enterprise features (Entra, observability)
• Bygg custom managers for spesialiserte orchestration patterns
• Integrer med Azure AI Foundry evaluations for kvalitetstesting av agenter

Enterprise (large-scale deployment):

• Vurder Microsoft Agent Framework over Semantic Kernel for standardized observability
• Implementer multi-region deployment for data residency compliance
• Bygg internal plugin marketplace for å dele reusable capabilities
• Etabler governance-prosess for agent instruction review (AI Act compliance)

Kilder og verifisering

Microsoft Learn-dokumentasjon (Verified via MCP)

1. Semantic Kernel Agent Orchestration — Confidence: Verified (2026-02)
2. Agent Architecture Overview — Confidence: Verified (2026-02)
3. Configuring Agents with Plugins — Confidence: Verified (2026-02)
4. Planning and Function Calling — Confidence: Verified (2026-02)
5. Microsoft Agent Framework Overview — Confidence: Verified (2026-02)
6. Magentic Orchestration Pattern — Confidence: Verified (2026-02)
7. Microsoft 365 Agents SDK - Semantic Kernel Integration — Confidence: Verified (2026-02)
8. AI Agent Orchestration Patterns (Azure Architecture) — Confidence: Verified (oppdatert 2026-04: start med riktig kompleksitetsnivaa — direct model call, single agent med tools, multi-agent; guidance om naar multi-agent er hensiktsmessig)

Kodeeksempler (Verified via MCP Code Search)

9. ChatCompletionAgent with GitHub Plugin — C# sample, Confidence: Verified (2026-02)
10. Function Calling Loop Implementation — Multi-language samples, Confidence: Verified (2026-02)
11. Handoff Pattern Example — Customer support scenario, Confidence: Verified (2026-02)

Konfidensgradering per seksjon

Seksjon	Konfidensnivå	Kilde
Agent-typer	Verified	Microsoft Learn API reference
Orchestration patterns	Verified	Semantic Kernel docs + Agent Framework docs
Function calling loop	Verified	Planning docs + code samples
Microsoft Agent Framework additions	Verified	Agent Framework docs
Kostnadsmodell	Baseline	Azure pricing calculator (feb 2026)
Offentlig sektor compliance	Baseline	Generell AI Act/GDPR-kunnskap + Azure compliance docs
Integration patterns	Verified	Microsoft 365 Agents SDK docs

Totalt: 11 unike kilder fra Microsoft Learn, 10/11 verifisert via MCP (feb 2026).