Steg 9 (R4): unified migrate-corpus.mjs --write over engineering/governance/ infrastructure/security. 327 filer mutert, verified=null, prosa byte-identisk (fra første ## seksjon), advisor urørt (0 endringer). To applier-fixes oppdaget under kjøring (TDD, RED→GREEN): - insertHeaderFields: anker faller nå tilbake når en meta-linje selv passerer 500B (2 filer pakket et avsnitt i **Status:** → Type/Source landet utenfor scan-vinduet, applierens post-write-assertion fanget + restaurerte). - normalizeStaleVerified: fjerner nå ALLE stale non-date **Verified:** i 500B-vinduet, inkl. stray body-dup rett under --- (9 mlops-genaiops-filer var ellers falskt "verified"/fresh, droppet fra worklist). Operatør-godkjent utvidelse av carve-out; kun stray metadata-linjer, aldri prosa. test-transform-criterion: precondition oppdatert til post-migrasjons-sannhet (fila bærer nå Source). Suite 728/728 grønn.
24 KiB
Semantic Kernel and Microsoft Agent Framework - Implementation Patterns
Last updated: 2026-06-18 | Verified: 2026-06-18 Status: GA — Microsoft Agent Framework 1.0 (3. apr 2026), orchestration patterns GA Category: Agent Orchestration & Automation Type: reference Source: https://learn.microsoft.com/agent-framework/overview/agent-framework-overview
Produksjonsklart rammeverk (juni 2026): Microsoft Agent Framework (MAF) 1.0 nådde GA 3. april 2026 og er det produksjonsklare, open-source rammeverket (.NET + Python) som Semantic Kernel og AutoGen har konvergert inn i. SK og AutoGen er nå i vedlikeholds-/migrasjonsmodus (migration guides finnes); ny utvikling bør bygge på MAF. De fem orkestreringsmønstrene — Sequential, Concurrent, Handoff, Group Chat og Magentic — er stabile (GA) i MAF 1.0 med streaming, checkpointing, human-in-the-loop og pause/resume.
Innhold
- Introduksjon
- Kjernekomponenter
- Arkitekturmønstre
- Beslutningsveiledning
- Integrasjon med Microsoft-stacken
- Offentlig sektor (Norge)
- Kostnad og Lisensiering
- For arkitekten (Cosmo)
- Kilder og verifisering
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:
- LLM får chat history + function schemas
- LLM bestemmer om den skal svare eller kalle en funksjon
- Hvis funksjonskall: parse funksjonsnavn og parametere
- Utfør funksjonen
- Returner resultatet til LLM
- 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 | GA i MAF 1.0 (3. apr 2026) |
| Sequential | Pass resultat fra én agent til neste i sekvens | Pipelines, multi-stage processing | GA i MAF 1.0 (3. apr 2026) |
| Handoff | Dynamisk overføring basert på kontekst/regler | Escalation, expert handoff | GA i MAF 1.0 (3. apr 2026) |
| Group Chat | Alle agenter i gruppe, koordinert av manager | Collaborative problem solving, brainstorming | GA i MAF 1.0 (3. apr 2026) |
| Magentic | Planner-based manager koordinerer team | Komplekse, generalist multi-agent tasks | GA i MAF 1.0 (3. apr 2026) |
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, Microsoft 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:
- Direct model call — klassifisering, oppsummering, oversettelse (ingen agent)
- Single agent med tools — varierte spoerringsmaal innen ett domene (ofte riktig default)
- 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
Microsoft Foundry
Semantic Kernel-agenter kan bruke Microsoft 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
TurnContextogTurnStatefor channel-integrasjon (Teams, M365 Copilot) - Semantic Kernel
Kernel-objekt registreres som singleton iProgram.cs - Agent Framework bruker
IChatClientwrapper 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
ChatMessageContentfor å 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
- Kompleksitetsnivå: Er oppgaven løsbar av én agent, eller kreves samarbeid mellom spesialiserte agenter?
- State management: Trenger dere persistent conversation state på tvers av sesjoner, eller er in-memory tilstrekkelig?
- Data residency: Har dere krav om at chat history og agent state må lagres i EU?
- Human oversight: Må menneskelige beslutningstagere godkjenne agent-planer før utførelse?
- Integrasjon: Skal agentene integreres med eksisterende Microsoft 365-kanaler (Teams, Copilot)?
- Volum: Hvor mange samtidige agentsesjoner forventer dere? (påvirker valg av Azure-tier og caching-strategi)
- Compliance: Er dette et høyrisiko AI-system som faller under AI Act? Krever dere full audit trail?
- 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 Microsoft 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)
- Semantic Kernel Agent Orchestration — Confidence: Verified (2026-02)
- Agent Architecture Overview — Confidence: Verified (2026-02)
- Configuring Agents with Plugins — Confidence: Verified (2026-02)
- Planning and Function Calling — Confidence: Verified (2026-02)
- Microsoft Agent Framework Overview — Confidence: Verified (2026-02)
- Magentic Orchestration Pattern — Confidence: Verified (2026-02)
- Microsoft 365 Agents SDK - Semantic Kernel Integration — Confidence: Verified (2026-02)
- 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)
- ChatCompletionAgent with GitHub Plugin — C# sample, Confidence: Verified (2026-02)
- Function Calling Loop Implementation — Multi-language samples, Confidence: Verified (2026-02)
- 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).