Agent Framework | The .NET Blog

CodeAct in Agent Framework: Hoe je de latentie van je agent halveert

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

Dit bericht is automatisch vertaald. Voor de originele versie, klik hier.

In elk agentproject is er dat moment waarop je naar de trace kijkt en denkt: “waarom duurt dit zo lang?” Het model werkt goed. De tools doen wat ze moeten doen. Maar er zijn zeven rondes nodig voor een resultaat dat je in één keer kunt berekenen.

Dat is precies het probleem dat CodeAct oplost — en het Agent Framework team heeft zojuist alpha-ondersteuning uitgebracht via het nieuwe pakket agent-framework-hyperlight.

Wat is CodeAct?

Het CodeAct-patroon is elegant eenvoudig: in plaats van het model een lijst tools te geven om één voor één aan te roepen, geef je het één execute_code-tool en laat je het het hele plan uitdrukken als een kort Python-programma.

Aanpak	Tijd	Tokens
Traditioneel	27,81s	6.890
CodeAct	13,23s	2.489
Verbetering	52,4%	63,9%

Beveiliging: Hyperlight Micro-VM’s

Het pakket agent-framework-hyperlight gebruikt Hyperlight micro-VM’s. Elke execute_code-aanroep krijgt zijn eigen verse micro-VM. Opstarten duurt milliseconden. De isolatie is vrijwel gratis.

Je tools blijven op de host draaien. De door het model gegenereerde lijmcode draait in de sandbox. Dat is de juiste verdeling.

Minimale configuratie

from agent_framework import Agent, tool
from agent_framework_hyperlight import HyperlightCodeActProvider

codeact = HyperlightCodeActProvider(
 tools=[get_weather],
 approval_mode="never_require",
)

agent = Agent(
 client=client,
 name="CodeActAgent",
 instructions="You are a helpful assistant.",
 context_providers=[codeact],
)

Wanneer CodeAct gebruiken (en wanneer niet)

Gebruik CodeAct wanneer:

De taak veel kleine tool-aanroepen aan elkaar koppelt (lookups, joins, berekeningen)
Latentie en tokenkosten tellen
Je sterke isolatie wil voor door het model gegenereerde code

Blijf bij traditionele tool-calling wanneer:

De agent slechts één of twee tool-aanroepen per beurt maakt
Elke aanroep bijwerkingen heeft die individueel goedgekeurd moeten worden

Probeer het nu

pip install agent-framework-hyperlight --pre

Lees het volledige bericht op de Agent Framework blog.

GPT-5.5 Is Er en Komt naar Azure Foundry — Wat .NET-Ontwikkelaars Moeten Weten

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

Dit bericht is automatisch vertaald. Klik hier voor de originele versie.

Microsoft heeft zojuist aangekondigd dat GPT-5.5 algemeen beschikbaar is in Microsoft Foundry. Als u agents op Azure bouwt, is dit de update waarop u wachtte.

De GPT-5 progressie

GPT-5: combineerde redenering en snelheid in één systeem
GPT-5.4: sterkere meerstaps-redenering, vroege agentische mogelijkheden voor enterprise
GPT-5.5: diepere langecontextredenering, betrouwbaardere agentische uitvoering, betere tokenefficiëntie

Wat er echt veranderd is

Verbeterde agentische codering: GPT-5.5 behoudt context over grote codebases, diagnosticeert architectuurfouten en anticipeert op testvereisten. Het model redeneert over wat anders een oplossing beïnvloedt voordat het actie onderneemt.

Tokenefficiëntie: Hogere kwaliteitsoutputs met minder tokens en minder pogingen. Direkt lagere kosten en latency voor productie-deployments.

Prijzen

Model	Invoer ($/M tokens)	Gecachte invoer	Uitvoer ($/M tokens)
GPT-5.5	$5,00	$0,50	$30,00
GPT-5.5 Pro	$30,00	$3,00	$180,00

Waarom Foundry belangrijk is

Foundry Agent Service stelt u in staat agents in YAML te definiëren of ze te verbinden met Microsoft Agent Framework, GitHub Copilot SDK, LangGraph of OpenAI Agents SDK — en ze uit te voeren als geïsoleerde gehoste agents met een persistent bestandssysteem, een eigen Microsoft Entra-identiteit en scale-to-zero prijsstelling.

AIAgent agent = aiProjectClient
 .AsAIAgent("gpt-5.5", instructions: "U bent een behulpzame assistent.", name: "MijnAgent");

Bekijk de volledige aankondiging voor alle details.

Waar Onthoudt uw Agent Dingen? Een Praktische Gids voor Chat-geschiedenis Opslag

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

Dit bericht is automatisch vertaald. Klik hier voor de originele versie.

Wanneer u een AI-agent bouwt, besteedt u het grootste deel van uw energie aan het model, de tools en de prompts. De vraag waar de conversatiegeschiedenis leeft lijkt een implementatiedetail — maar het is een van de belangrijkste architectuurbeslissingen die u zult nemen.

Het bepaalt of gebruikers gesprekken kunnen vertakken, antwoorden ongedaan kunnen maken, sessies na een herstart kunnen hervatten en of uw gegevens ooit uw infrastructuur verlaten. Het Agent Framework-team heeft een diepgaande analyse gepubliceerd.

Twee fundamentele patronen

Door de service beheerd: de AI-service slaat de conversatiestatus op. Uw app bewaart een referentie en de service voegt automatisch de relevante geschiedenis toe aan elk verzoek.

Door de client beheerd: uw app behoudt de volledige geschiedenis en stuurt relevante berichten met elk verzoek. De service is stateless. U beheert alles.

Hoe Agent Framework dit abstraheert

AgentSession session = await agent.CreateSessionAsync();
var first = await agent.RunAsync("Mijn naam is Alice.", session);
var second = await agent.RunAsync("Wat is mijn naam?", session);

session = agent.create_session()
first = await agent.run("Mijn naam is Alice.", session=session)
second = await agent.run("Wat is mijn naam?", session=session)

Snelle referentie van providers

Provider	Opslag	Model	Comprimering
OpenAI/Azure Chat Completions	Client	N/A	U
Foundry Agent Service	Service	Lineair	Service
Responses API (standaard)	Service	Vertakkend	Service
Anthropic Claude, Ollama	Client	N/A	U

Hoe te kiezen

Vertakking of “ongedaan maken” nodig? → Responses API door service beheerd
Gegevenssouvereiniteit nodig? → Door client beheerd met database-backend
Eenvoudige chatbot? → Lineair door service beheerd is prima

Lees het volledige bericht voor de volledige beslissingsboom.

Agent Skills in .NET Zijn Nu Serieus Flexibel

Emiliano Montesdeoca — Tue, 14 Apr 2026 00:00:00 +0000

Dit bericht is automatisch vertaald. Voor het origineel, klik hier.

Als je agents bouwt met Microsoft Agent Framework, ken je de werkwijze: je definieert skills, koppelt ze aan een provider en laat de agent bepalen welke hij aanroept. Nieuw is hoe je die skills schrijft — en de sprong in flexibiliteit is aanzienlijk.

De nieuwste update introduceert drie verschillende patronen voor het schrijven van agent skills: bestand-gebaseerd, klasse-gebaseerd en inline code-gedefinieerd. Alle drie koppelen aan één AgentSkillsProviderBuilder, wat betekent dat je ze kunt mixen zonder routeringslogica.

Bestand-gebaseerde skills: het startpunt

Bestand-gebaseerde skills zijn precies wat ze klinken — een map op schijf met een SKILL.md-bestand, optionele scripts en referentiedocumenten:

skills/
└── onboarding-guide/
├── SKILL.md
├── scripts/
│ └── check-provisioning.py
└── references/
└── onboarding-checklist.md

De frontmatter van SKILL.md declareert de skillnaam en beschrijving, en de instructiesectie vertelt de agent hoe scripts en referenties te gebruiken.

Je koppelt het met SubprocessScriptRunner.RunAsync:

var skillsProvider = new AgentSkillsProvider(
 Path.Combine(AppContext.BaseDirectory, "skills"),
 SubprocessScriptRunner.RunAsync);

Klasse-gebaseerde skills: leveren via NuGet

Hier wordt het interessant voor teams. Klasse-gebaseerde skills leiden af van AgentClassSkill<T> en gebruiken attributen zoals [AgentSkillResource] en [AgentSkillScript]:

public sealed class BenefitsEnrollmentSkill : AgentClassSkill<BenefitsEnrollmentSkill>
{
 public override AgentSkillFrontmatter Frontmatter { get; } = new(
 "benefits-enrollment",
 "Enroll an employee in health, dental, or vision plans.");

 [AgentSkillScript("enroll")]
 private static string Enroll(string employeeId, string planCode)
 {
 bool success = HrClient.EnrollInPlan(employeeId, planCode);
 return JsonSerializer.Serialize(new { success, employeeId, planCode });
 }
}

Een team kan dit als NuGet-pakket verpakken. Voeg het toe aan je project, stop het in de builder en het werkt naast je bestand-gebaseerde skills.

Inline skills: de snelle brug

Dat moment wanneer een ander team precies de skill bouwt die je nodig hebt, maar deze pas over een sprint beschikbaar is? AgentInlineSkill is je brug:

var timeOffSkill = new AgentInlineSkill(
 name: "time-off-balance",
 description: "Calculate remaining vacation and sick days.",
 instructions: "1. Vraag om medewerker-ID. 2. Gebruik calculate-balance. 3. Presenteer resultaten.")
 .AddScript("calculate-balance", (string employeeId, string leaveType) =>
 {
 int remaining = HrDatabase.GetAnnualAllowance(employeeId, leaveType)
 - HrDatabase.GetDaysUsed(employeeId, leaveType);
 return JsonSerializer.Serialize(new { employeeId, leaveType, remaining });
 });

Wanneer het NuGet-pakket verschijnt, vervang je de inline skill door de klasse-gebaseerde. De agent merkt het verschil niet.

Scriptgoedkeuring: human-in-the-loop

Voor .NET-ontwikkelaars die productie-agents bouwen, is dit het deel dat implementatiegesprekken daadwerkelijk deblokkert. Zet UseScriptApproval aan en de agent pauzeert voor het uitvoeren van elk script:

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseSkill(timeOffSkill)
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .UseScriptApproval(true)
 .Build();

Samenvatting

Agent skills in .NET hebben nu een echt flexibel schrijfmodel. Of je nu een prototype bouwt met bestand-gebaseerde skills of verpakte mogelijkheden via NuGet levert — alle patronen stellen samen via AgentSkillsProviderBuilder.

Bekijk de originele aankondiging en GitHub-voorbeelden.

Real-Time Multi-Agent UI's Bouwen Die Niet Aanvoelen als een Black Box

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Dit bericht is automatisch vertaald. Voor het origineel, klik hier.

Dit is de werkelijkheid over multi-agent systemen: ze zien er geweldig uit in demo’s. Drie agents die werk aan elkaar doorgeven, problemen oplossen, beslissingen nemen. Dan probeer je het aan echte gebruikers te tonen en… stilte. Een draaiende indicator. Geen idee welke agent wat doet of waarom het systeem gepauzeerd is. Dat is geen product — dat is een vertrouwensprobleem.

Het Microsoft Agent Framework-team heeft zojuist een fantastisch overzicht gepubliceerd over het koppelen van MAF-workflows aan AG-UI, een open protocol voor het streamen van agent-uitvoeringsgebeurtenissen naar een frontend via Server-Sent Events. En eerlijk gezegd? Dit is precies de brug die we misten.

Waarom dit belangrijk is voor .NET-ontwikkelaars

Als je AI-aangedreven apps bouwt, ben je waarschijnlijk al tegen deze muur opgelopen. Je backend-orkestratie werkt prima — agents geven werk aan elkaar door, tools worden uitgevoerd, beslissingen worden genomen. Maar de frontend heeft geen idee wat er achter de schermen gebeurt. AG-UI lost dit op door een standaardprotocol te definiëren voor het streamen van agentgebeurtenissen (RUN_STARTED, STEP_STARTED, TOOL_CALL_*, TEXT_MESSAGE_*) rechtstreeks naar je UI-laag via SSE.

De demo die ze bouwden is een klantenserviceworkflow met drie agents: een triageagent die verzoeken routeert, een terugbetalingsagent die financiële zaken afhandelt, en een orderagent die vervangingen beheert. Elke agent heeft zijn eigen tools, en de handoff-topologie is expliciet gedefinieerd — geen “bedenk het maar uit de prompt”-sfeer.

De handoff-topologie is de echte ster

Wat mij opviel is hoe HandoffBuilder je in staat stelt een gerichte routeringsgraf tussen agents te declareren:

builder = HandoffBuilder(
 name="ag_ui_handoff_workflow_demo",
 participants=[triage, refund, order],
 termination_condition=termination_condition,
)

(
 builder
 .add_handoff(triage, [refund], description="Refunds, damaged-item claims...")
 .add_handoff(triage, [order], description="Replacement, exchange...")
 .add_handoff(refund, [order], description="Replacement logistics needed after refund.")
 .add_handoff(order, [triage], description="After replacement/shipping tasks complete.")
)

Elke add_handoff maakt een gerichte koppeling met een beschrijving in natuurlijke taal. Het framework genereert handoff-tools voor elke agent op basis van deze topologie. Routeringsbeslissingen zijn daardoor gegrond in jouw orkestratiestucture, niet in wat het LLM toevallig wil doen. Dat is enorm belangrijk voor betrouwbaarheid in productie.

Human-in-the-loop die echt werkt

De demo toont twee onderbrekingspatronen die elke echte agentapp nodig heeft:

Tool-goedkeuringsonderbrekingen — wanneer een agent een tool aanroept die is gemarkeerd met approval_mode="always_require", pauzeert de workflow en stuurt een gebeurtenis. De frontend toont een goedkeuringsmodal met de toolnaam en argumenten. Geen token-verspillende herhalingsloops — gewoon een nette pauze-goedkeur-hervat-stroom.

Informatieverzoekonderbrekingen — wanneer een agent meer context van de gebruiker nodig heeft (zoals een order-ID), pauzeert het en vraagt. De frontend toont de vraag, de gebruiker antwoordt, en de uitvoering gaat verder precies waar het gestopt was.

Beide patronen worden gestreamd als standaard AG-UI-gebeurtenissen, zodat je frontend geen aangepaste logica per agent nodig heeft — het rendert gewoon wat er via de SSE-verbinding binnenkomt.

Het aansluiten is verrassend eenvoudig

De integratie tussen MAF en AG-UI is één functieaanroep:

from agent_framework.ag_ui import (
 AgentFrameworkWorkflow,
 add_agent_framework_fastapi_endpoint,
)

app = FastAPI()

demo_workflow = AgentFrameworkWorkflow(
 workflow_factory=lambda _thread_id: create_handoff_workflow(),
 name="ag_ui_handoff_workflow_demo",
)

add_agent_framework_fastapi_endpoint(
 app=app, agent=demo_workflow, path="/handoff_demo",
)

De workflow_factory maakt een nieuwe workflow per thread, zodat elke conversatie geïsoleerde toestand heeft. Het endpoint regelt alle SSE-infrastructuur automatisch. Als je FastAPI al gebruikt (of het als lichte laag kunt toevoegen), is dit vrijwel nul wrijving.

Mijn kijk

Voor ons als .NET-ontwikkelaars is de directe vraag: “Kan ik dit in C# doen?” Agent Framework is beschikbaar voor zowel .NET als Python, en het AG-UI-protocol is taalonafhankelijk (het is gewoon SSE). Dus hoewel deze specifieke demo Python en FastAPI gebruikt, is het patroon direct overdraagbaar. Je kunt een ASP.NET Core minimal API aansluiten met SSE-endpoints die hetzelfde AG-UI-gebeurtenisschema volgen.

De grotere les is dat multi-agent UI’s een prioriteit worden, geen bijzaak. Als je iets bouwt waarbij agents met mensen interageren — klantenservice, goedkeuringsworkflows, documentverwerking — is deze combinatie van MAF-orkestratie en AG-UI-transparantie het te volgen patroon.

Samenvatting

AG-UI + Microsoft Agent Framework geeft je het beste van beide werelden: robuuste multi-agent orkestratie op de backend en real-time zichtbaarheid op de frontend. Geen black-box agentinteracties meer.

Bekijk de volledige walkthrough en de AG-UI protocol repository om dieper te gaan.

Microsoft Agent Framework Bereikt 1.0 — Dit Is Wat Er Echt Toe Doet voor .NET-Ontwikkelaars

Emiliano Montesdeoca — Fri, 03 Apr 2026 00:00:00 +0000

Dit bericht is automatisch vertaald. Voor het origineel, klik hier.

Als je de Agent Framework-reis hebt gevolgd vanaf de vroege dagen van Semantic Kernel en AutoGen, dan is dit significant. Microsoft Agent Framework heeft zojuist versie 1.0 bereikt — productieklaar, stabiele API’s, toezegging voor langetermijnondersteuning. Beschikbaar voor .NET en Python, en echt klaar voor echte workloads.

Laten we door het aankondigingslawaai heen snijden en ons richten op wat ertoe doet als je AI-aangedreven apps bouwt met .NET.

De korte versie

Agent Framework 1.0 verenigt wat vroeger Semantic Kernel en AutoGen was in één open-source SDK. Één agent-abstractie. Één orkestratieengine. Meerdere AI-providers. Als je heen en weer ging tussen Semantic Kernel voor enterprise-patronen en AutoGen voor research-grade multi-agent workflows, kun je stoppen. Dit is nu de ene SDK.

Beginnen is bijna oneerlijk eenvoudig

Hier is een werkende agent in .NET:

// dotnet add package Microsoft.Agents.AI.OpenAI --prerelease
using Microsoft.Agents.AI;
using Microsoft.Agents.AI.Foundry;
using Azure.Identity;

var agent = new AIProjectClient(endpoint: "https://your-project.services.ai.azure.com")
 .GetResponsesClient("gpt-5.3")
 .AsAIAgent(
 name: "HaikuBot",
 instructions: "You are an upbeat assistant that writes beautifully."
 );

Console.WriteLine(await agent.RunAsync("Write a haiku about shipping 1.0."));

Dat is het. Een handvol regels en je hebt een AI-agent die op Azure Foundry draait. Het Python-equivalent is even beknopt. Voeg functietools, meerturnsgesprekken en streaming toe naarmate je verder gaat — het API-oppervlak schaalt op zonder vreemd te worden.

Multi-agent-orkestratie — dit is het echte werk

Enkele agents zijn prima voor demo’s, maar productiescenario’s vereisen meestal coördinatie. Agent Framework 1.0 wordt geleverd met in de strijd geteste orkestratiepatronen rechtstreeks uit Microsoft Research en AutoGen:

Sequential — agents verwerken op volgorde (schrijver → reviewer → editor)
Concurrent — fan out naar meerdere agents in parallel, resultaten samenvoegen
Handoff — één agent delegeert naar een andere op basis van intentie
Group chat — meerdere agents bespreken en convergeren naar een oplossing
Magentic-One — het research-grade multi-agent patroon van MSR

Ze ondersteunen allemaal streaming, checkpointing, human-in-the-loop goedkeuringen en pauzeren/hervatten. Het checkpointing-deel is cruciaal — langlopende workflows overleven procesrestarts.

De meest belangrijke functies

Middleware-hooks. Ken je de middleware-pipelines in ASP.NET Core? Hetzelfde concept, maar voor agentuitvoering. Onderschep elke fase — voeg inhoudsbeveiliging, logging, nalevingsbeleid toe — zonder agentvragen aan te raken.

Pluggable geheugen. Gespreksgeschiedenis, persistente sleutel-waardestatus, vectorgebaseerd ophalen. Kies je backend: Foundry Agent Service, Mem0, Redis, Neo4j of eigen implementatie.

Declaratieve YAML-agents. Definieer de instructies, tools, geheugen en orkestratietopologie van je agent in versiegecontroleerde YAML-bestanden. Laad en voer uit met één API-aanroep.

A2A- en MCP-ondersteuning. MCP (Model Context Protocol) stelt agents in staat externe tools dynamisch te ontdekken en aan te roepen. A2A (Agent-to-Agent protocol) maakt samenwerking tussen runtimes mogelijk.

Preview-functies die de moeite waard zijn

DevUI — een op browser gebaseerde lokale debugger voor het visualiseren van agentuitvoering, berichtstromen en toolaanroepen in real-time.
GitHub Copilot SDK en Claude Code SDK — gebruik Copilot of Claude als agentharnas rechtstreeks vanuit je orkestatiecode.
Agent Harness — aanpasbare lokale runtime die agents toegang geeft tot shell, bestandssysteem en berichtlussen.
Skills — herbruikbare domeinvermogenspakketten.

Migreren van Semantic Kernel of AutoGen

Als je bestaande Semantic Kernel- of AutoGen-code hebt, zijn er speciale migratieassistenten die je code analyseren en stap-voor-stap migratieplannen genereren.

Samenvatting

Agent Framework 1.0 is de productiemijlpaal waar enterprise-teams op hebben gewacht. Stabiele API’s, multi-providerondersteuning en orkestratiepatronen die echt op schaal werken.

Het framework is volledig open source op GitHub. Als je wachtte op het “veilig om in productie te gebruiken”-signaal — dit is het.

Achtergrondreacties in Microsoft Agent Framework: Geen Timeout-angst Meer

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

Dit bericht is automatisch vertaald. Voor het origineel, klik hier.

Als je ooit iets hebt gebouwd met redeneermodellen zoals o3 of GPT-5.2, ken je de pijn. Je agent begint een complexe taak te verwerken, de client zit te wachten en ergens treedt een verbindingstime-out op.

Microsoft Agent Framework heeft zojuist achtergrondreacties uitgebracht — en eerlijk gezegd is dit een van die functies die er vanaf dag één had moeten zijn.

Hoe vervolgingstokens werken

In plaats van te blokkeren start je de agenttaak en krijg je een vervolgingstoken terug. Denk eraan als een klaim-ticket bij een reparatiewinkel:

Stuur je verzoek met AllowBackgroundResponses = true
Als de agent achtergrondverwerking ondersteunt, krijg je een vervolgingstoken
Poll op je planning totdat het token null terugkeert

AgentRunOptions options = new()
{
 AllowBackgroundResponses = true
};

AgentSession session = await agent.CreateSessionAsync();
AgentResponse response = await agent.RunAsync(
 "Write a detailed market analysis for the Q4 product launch.", session, options);

while (response.ContinuationToken is not null)
{
 await Task.Delay(TimeSpan.FromSeconds(2));
 options.ContinuationToken = response.ContinuationToken;
 response = await agent.RunAsync(session, options);
}

Console.WriteLine(response.Text);

Wanneer dit te gebruiken

Complexe redeneer taken — meerstapsanalyse, diepgaand onderzoek
Lange contentgeneratie — gedetailleerde rapporten, meerdelige documenten
Onbetrouwbare netwerken — mobiele clients, edge-implementaties
Asynchrone UX-patronen — taak indienen, iets anders doen, terugkomen voor resultaten

Bekijk de volledige documentatie.