Agent-Framework | The .NET Blog

Microsoft Foundry Avril 2026 : Foundry Local GA, GPT-5.5, CodeAct avec Hyperlight

Emiliano Montesdeoca — Tue, 02 Jun 2026 00:00:00 +0000

Un mois chargé pour Microsoft Foundry. Voici les annonces les plus importantes.

Foundry Local est Généralement Disponible

Foundry Local — le runtime d’IA local multiplateforme de Microsoft — passe de la préversion à la GA sur Windows, macOS (Apple Silicon) et Linux x64. Inférence de modèles locaux prête pour la production avec un SDK convivial pour les développeurs. La version 1.1 ajoute la transcription, les embeddings et la prise en charge de l’API Responses.

GPT-5.5

Le dernier modèle de la famille GPT-5 est maintenant disponible dans Foundry. Quota par défaut pour les abonnements Tier 5 et Tier 6. Si vous avez travaillé avec des variantes antérieures de GPT-5, cela vaut la peine d’être évalué pour vos cas d’utilisation.

Traçage d’Agent Framework dans Foundry

Deux fonctionnalités de traçage sont disponibles en préversion ce mois-ci :

Traçage de Microsoft Agent Framework — Les agents MAF peuvent maintenant émettre des traces OpenTelemetry dans Foundry. Déboguez le comportement des agents, tracez l’exécution en plusieurs étapes, exposez la latence et les erreurs dans les appels d’outils. Cela comble un vrai manque : savoir ce que votre agent a réellement fait en production, pas seulement ce qu’il a retourné.

Traçage des agents hébergés — Les sessions, appels d’outils et étapes d’exécution des agents hébergés apparaissent également dans les traces Foundry. La même histoire d’observabilité étendue au niveau hébergé.

CodeAct avec Hyperlight (Alpha)

C’est l’ajout techniquement le plus intéressant : Agent Framework peut désormais exécuter du code Python dans des micro-machines virtuelles Hyperlight.

CodeAct est le modèle où un agent génère et exécute du code Python comme outil. La préoccupation évidente est la sécurité — vous exécutez du code généré par le modèle. Les micro-VMs d’Hyperlight fournissent une isolation au niveau du processus avec un temps de démarrage proche du natif, rendant l’exécution de code en sandbox pratique sans la surcharge de conteneurs ou de VMs complets.

Pour les flux de travail agentiques où l’exécution de code est nécessaire, c’est une amélioration de sécurité significative par rapport à l’exécution de code dans le processus hôte.

Tableau de Bord de Surveillance des Agents (Préversion)

Un tableau de bord d’opérations unifié combinant l’utilisation des tokens, la latence, le taux de succès des exécutions et les scores des évaluateurs en une seule vue. La distinction par rapport aux tableaux de bord d’observabilité classiques : il inclut les résultats d’évaluation aux côtés des métriques opérationnelles, vous permettant de corréler « l’agent est plus lent » avec « les scores de l’évaluateur ont chuté » — ou de confirmer qu’ils ne sont pas liés.

Évaluateurs Personnalisés d’Évaluation Continue (Préversion)

Vous pouvez maintenant apporter vos propres évaluateurs basés sur du code ou des prompts dans les pipelines d’évaluation continue. Auparavant, l’évaluation continue était limitée aux évaluateurs intégrés. Les évaluateurs personnalisés vous permettent d’appliquer des critères de qualité spécifiques à votre équipe dans votre boucle de surveillance en production.

Inventaire des Agents dans le Plan de Contrôle

La vue Operate du Plan de Contrôle Foundry affiche désormais tous les agents pris en charge dans un abonnement : agents Foundry, Azure SRE Agent, boucles d’agents Logic Apps et agents personnalisés enregistrés. Une vue pour comprendre ce qui est déployé et où.

Publication originale : What’s new in Microsoft Foundry | April 2026

Le Modèle Handoff : Quand Un Agent Ne Suffit Pas

Emiliano Montesdeoca — Mon, 01 Jun 2026 00:00:00 +0000

À un moment donné, tout système multi-agents dépasse un simple routeur. Le premier signe apparaît généralement quand un agent spécialiste doit poser une question de suivi, ou réalise en milieu de tour qu’un autre agent devrait continuer. Un pipeline fixe échoue là. Un routeur à passage unique échoue là.

C’est exactement le problème que le modèle d’orchestration Handoff dans Microsoft Agent Framework est conçu pour résoudre.

Comment Fonctionne Handoff

Le développeur déclare un graphe : voici les agents, voici les arêtes entre eux. Le framework fait le reste — il synthétise un outil handoff par arête sortante et l’injecte dans chaque agent. Quand un agent décide de passer le contrôle, il appelle l’outil. Le framework applique la topologie.

Trois choses rendent cela différent du fait d’avoir simplement des agents qui s’appellent mutuellement :

Une transcription partagée — l’agent récepteur voit l’intégralité de l’historique de conversation. Pas de recommencement à zéro.
Application de la topologie — un agent ne peut faire handoff qu’à des cibles déclarées. Vous détectez les bugs de routage au moment de l’authoring, pas en production.
Terminaison naturelle — quand l’agent actif termine son tour sans appeler un outil handoff, le workflow cède à l’utilisateur. Pas de polling, pas de conditions de sortie explicites.

Un Exemple Minimal

En .NET, construire un workflow handoff ressemble à ceci :

using Microsoft.Agents.AI;
using Microsoft.Agents.AI.Workflows;

AIAgent triage = chatClient.AsAIAgent(
 instructions: "Route to the right specialist.",
 name: "Triage");

AIAgent billing = chatClient.AsAIAgent(
 instructions: "Handle billing questions.",
 name: "Billing");

AIAgent tech = chatClient.AsAIAgent(
 instructions: "Handle technical support.",
 name: "Tech");

var workflow = HandoffWorkflow.Create()
 .Add(triage, targets: [billing, tech])
 .Add(billing, targets: [triage])
 .Add(tech, targets: [triage, billing]);

Triage peut envoyer à l’un ou l’autre spécialiste. Les deux spécialistes peuvent renvoyer vers triage. Le graphe est compatible avec l’acyclique mais prend en charge les arêtes arrière quand vous en avez besoin (“j’ai besoin de plus d’informations” → retour à la recherche).

Quand Utiliser Handoff (et Quand Ne Pas Le Faire)

Handoff est un bon choix quand :

La propriété peut changer en cours de conversation — un agent peut réaliser qu’il est le mauvais spécialiste
Les arêtes arrière comptent — vous pourriez avoir besoin de revisiter une étape antérieure sans repartir à zéro
Les décisions de routage sont floues — la décision de faire un handoff est contextuelle et mieux prise par le modèle que par des prédicats typés

Ce n’est pas le bon choix quand :

Votre pipeline est fixe et séquentiel — utilisez le workflow Sequential pour cela
Chaque étape est indépendante — des agents partageant une transcription où seul l’un d’eux en avait besoin n’est que du bruit
Vous avez besoin de garanties strictes de traitement — le non-déterminisme du routage piloté par modèle n’est pas ce que vous voulez

Arêtes Arrière et Humain-dans-la-Boucle

L’une des formes les plus intéressantes qu’Handoff permet est les vraies arêtes arrière. Un agent peut décider “je n’ai pas assez d’informations” et revenir à une étape de recherche, pas avec une boucle codée en dur, mais parce que le modèle décide que c’est la bonne décision.

Les interactions humain-dans-la-boucle se composent également naturellement. Quand un spécialiste a besoin d’une entrée de l’utilisateur, le workflow cède à l’utilisateur via la boucle de tour par défaut, recueille la réponse et reprend avec le contexte complet. L’agent n’a jamais perdu la conversation.

Conclusion

Handoff est l’un de ces modèles qui semble simple mais permet beaucoup une fois intégré : routage décentralisé, contexte partagé, topologie appliquée, terminaison naturelle. C’est la prochaine étape appropriée quand vos agents commencent à dire “en fait, quelqu’un d’autre devrait gérer ça.”

Lisez le guide complet dans le post original : A Tour of the Handoff Orchestration Pattern

Workflows Durables dans Microsoft Agent Framework : De In-Memory à Azure Functions

Emiliano Montesdeoca — Sun, 31 May 2026 00:00:00 +0000

L’un des points douloureux avec les premiers workflows d’agents IA : ils sont fragiles. Un workflow multi-étapes de longue durée lié à un seul processus signifie que le redémarrage du processus = état perdu. Pour des démos simples, c’est acceptable. Pour des charges de travail en production, ce ne l’est pas.

Le modèle de programmation de workflows de Microsoft Agent Framework prend désormais en charge l’exécution durable, basée sur le framework Durable Task, avec hébergement Azure Functions. Voici comment fonctionne le modèle de programmation et pourquoi l’histoire de la durabilité compte.

Les Blocs de Construction Fondamentaux

Les Executors sont l’unité fondamentale de travail. Chacun est typé — il prend une entrée spécifique et produit une sortie spécifique :

using Microsoft.Agents.AI.Workflows;

internal sealed class OrderLookup()
 : Executor<OrderCancelRequest, Order>("OrderLookup")
{
 public override async ValueTask<Order> HandleAsync(
 OrderCancelRequest message,
 IWorkflowContext context,
 CancellationToken cancellationToken = default)
 {
 // rechercher la commande, la retourner
 return new Order(Id: message.OrderId, ...);
 }
}

Les Workflows relient les executors en graphes dirigés en utilisant un constructeur fluide. Le framework gère l’exécution, le flux de données entre les étapes et la propagation des erreurs.

Vous pouvez modéliser :

Des chaînes séquentielles (étape A → étape B → étape C)
Fan-out/fan-in parallèle (exécuter les agents A, B, C en parallèle, agréger les résultats)
Branchement conditionnel
Approbations humain-dans-la-boucle (suspendre le workflow, attendre un signal externe)

Le Runner In-Memory pour le Développement Local

Démarrer est rapide :

dotnet add package Microsoft.Agents.AI
dotnet add package Microsoft.Agents.AI.Workflows

Le package principal inclut un runner léger en cours de processus. Pas de dépendances externes, pas de base de données, pas de ressources Azure. Fonctionne très bien pour le développement local et les tests unitaires.

Ajouter la Durabilité avec Durable Task

Quand un workflow doit survivre aux redémarrages de processus — parce qu’il est de longue durée, parce qu’il a des étapes humain-dans-la-boucle, parce qu’il se distribue sur de nombreux appels d’agents en parallèle — le runner in-memory n’est pas suffisant.

L’intégration Durable Task de MAF stocke l’état du workflow dans Azure Storage. Si le processus redémarre, le workflow reprend là où il s’était arrêté. Le modèle de programmation reste le même ; vous remplacez simplement le runner.

dotnet add package Microsoft.Agents.AI.Workflows.DurableTask

Les mêmes executors, le même graphe de workflow — basé sur un état durable.

Hébergement Azure Functions

La troisième couche est l’hébergement Azure Functions. Votre workflow devient une application Function : déclenchez le workflow via un endpoint HTTP, et le runtime durable gère la mise à l’échelle, l’état et la fiabilité.

Cela signifie qu’un workflow multi-agents avec des appels parallèles, des branches conditionnelles et des approbations humaines peut s’adapter à un environnement Functions serverless sans gestion d’état personnalisée.

Pourquoi C’est Important

La combinaison est significative pour les vrais systèmes IA :

Appels d’agents en parallèle — distribuer vers plusieurs agents spécialisés simultanément sans blocage, agréger les résultats quand tous terminent
Processus de longue durée — les workflows qui impliquent une approbation humaine ou des événements externes peuvent se suspendre et reprendre sur des heures ou des jours
Mise à l’échelle — Azure Functions fait évoluer l’exécution horizontalement ; le framework Durable Task gère la coordination de l’état parallèle

Si vous construisez des workflows MAF au-delà de simples démos locaux, c’est le chemin vers l’exécution de qualité production.

Publication originale : Durable Workflows in the Microsoft Agent Framework

Votre Agent MAF Local Vient d'Obtenir une Maison en Production

Emiliano Montesdeoca — Sat, 30 May 2026 00:00:00 +0000

Faire fonctionner un agent localement est la partie amusante. La partie délicate est tout ce qui vient après : le déployer sans perdre la tête, gérer les sessions, configurer l’identité, câbler l’observabilité. Cela signifie généralement beaucoup d’infrastructure personnalisée.

Foundry Hosted Agents vient de supprimer la majeure partie de cette infrastructure pour les utilisateurs de Microsoft Agent Framework (MAF).

Ce que Foundry Hosted Agents Fait Vraiment

Lorsque vous déployez un agent MAF dans Foundry Hosted Agents, la plateforme gère une liste étonnamment longue de choses que vous auriez autrement à construire vous-même :

Mise à l’échelle à zéro — votre agent ne coûte rien en idle et redémarre automatiquement
Sandboxes isolés par VM par session — chaque session utilisateur obtient son propre sandbox avec persistance du système de fichiers qui survit aux événements de réduction d’échelle
Entra ID intégré — chaque agent obtient sa propre identité pour appeler les modèles Foundry, Toolbox et les services Azure sans secrets dans l’image
Déploiements versionnés — chaque déploiement est un instantané immuable, avec support de déploiement blue/green et canary
Observabilité sans configuration — APPLICATIONINSIGHTS_CONNECTION_STRING est injecté au runtime pour que les traces OpenTelemetry de MAF s’écoulent automatiquement dans App Insights

Ce dernier point est vraiment appréciable. Pas de câblage supplémentaire, pas de configuration additionnelle. Les traces apparaissent simplement.

La Différence de Code Est Minime

C’est ce que j’apprécie le plus dans cette intégration. Vous ne réécrivez pas votre agent. Vous l’encapsulez simplement :

En .NET :

using Microsoft.Agents.AI.Foundry.Hosting;

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddFoundryResponses(agent);

var app = builder.Build();
app.MapFoundryResponses();

app.Run();

En Python :

server = ResponsesHostServer(agent)
server.run()

C’est tout. La même logique que vous avez testée localement est ce qui s’exécute en production. La plateforme l’encapsule dans l’infrastructure de gestion de sessions, d’identité et de scaling.

Deux Protocoles, Un Agent

Les Hosted Agents supportent deux styles d’endpoints :

Responses (/responses) — compatible OpenAI, gère l’historique des conversations et le streaming. Bon défaut pour les agents de type chat.
Invocations (/invocations) — vous définissez le schéma requête/réponse. Bon pour les workflows non conversationnels.

Si vous construisez quelque chose qui ressemble à une conversation, commencez avec Responses. Si vous construisez un agent de type API qui prend une entrée structurée et retourne une sortie structurée, Invocations vous donne la flexibilité.

Le Flux de Déploiement avec `azd`

Lorsque vous exécutez azd up avec un agent MAF :

Crée optionnellement un projet Foundry et déploie un modèle
Empaquette votre code et pousse une image vers Azure Container Registry
Provisionne du calcul depuis l’image ACR
Attribue un Entra ID dédié à l’agent
Expose un endpoint stable (https://{project_endpoint}/agents/{agent_name})
Gère tout le reste à partir de ce point

Les sessions persistent jusqu’à 30 jours. Le calcul inactif est déprovisionné après 15 minutes et restauré transparemment sur la prochaine requête. Du point de vue de l’agent, rien n’a changé.

Conclusion

La distance entre “fonctionnant localement” et “s’exécutant en production” a toujours été longue et douloureuse pour les agents IA. Foundry Hosted Agents + MAF réduit considérablement cet écart. Si vous avez déjà un agent local construit avec Agent Framework, cela vaut la peine d’essayer aujourd’hui.

L’équipe annonce que GA arrive bientôt — c’est actuellement en preview. Consultez les docs d’intégration MAF Hosted Agent et les exemples .NET pour démarrer.

Article original : From Local to Production: Deploy Your Microsoft Agent Framework Agent with Foundry Hosted Agents

Créer des Agents, C'est la Partie Facile — Les Exécuter en Toute Sécurité, C'est la Partie Difficile

Emiliano Montesdeoca — Fri, 29 May 2026 00:00:00 +0000

Il existe un modèle dans le développement d’agents IA que j’ai commencé à appeler le « regret de démo ». L’agent fonctionne très bien dans les démos. Ensuite, quelqu’un demande : que se passe-t-il s’il appelle le mauvais outil ? Et s’il accède à des données auxquelles il ne devrait pas ? Qui a audité ça ?

Microsoft Agent Framework vous soutient pour la construction et l’orchestration. Agent Governance Toolkit (AGT) couvre la partie après — gouvernance, application des politiques et auditabilité à l’exécution.

Ce Que Chaque Projet Fait Vraiment

Microsoft Agent Framework (MAF) vous offre le modèle de programmation : workflows multi-agents, interopérabilité du protocole A2A, hooks de middleware, mémoire et hébergement géré via Foundry Agent Service. Il gère la sécurité du contenu au niveau de l’entrée/sortie du modèle.

Agent Governance Toolkit (AGT) se connecte à ce même pipeline de middleware pour gouverner les actions. Chaque appel d’outil, accès aux ressources et message inter-agents est évalué par rapport à la politique avant l’exécution. Surcharge inférieure à la milliseconde. Pas de sidecars, pas de proxies, pas de prompts modifiés.

Action Agent --> Vérification Politique --> Autoriser / Refuser --> Journal Audit (< 0.1 ms)

Des couches différentes, une couverture complète, un pipeline.

S’intégrer, C’est Juste Ajouter un Middleware

En Python, AGT s’ajoute au même paramètre middleware que vous utiliseriez pour la journalisation ou les filtres de contenu :

agent = Agent(
 client=OpenAIChatClient(model="gpt-5.3"),
 name="Contoso Loan Officer",
 instructions="You are a governed loan assistant.",
 tools=[check_credit_score, get_loan_rates, approve_small_loan],
 middleware=[
 AuditTrailMiddleware(audit_log=audit_log, agent_did="loan-agent"),
 GovernancePolicyMiddleware(evaluator=evaluator, audit_log=audit_log),
 CapabilityGuardMiddleware(allowed_tools=["check_credit_score", "get_loan_rates"]),
 RogueDetectionMiddleware(detector=detector, agent_id="loan-agent"),
 ],
)

En .NET, même modèle via .Use() :

var agent = builder.BuildAIAgent(model: "gpt-5.3")
 .Use(new GovernancePolicyMiddleware(evaluator))
 .Use(new CapabilityGuardMiddleware(allowedTools))
 .Use(new AuditTrailMiddleware(auditLog));

Même agent, même orchestration, mêmes outils. AGT ajoute des capacités de gouvernance sans toucher à la logique de l’agent.

Ce Que Vous Obtenez

GovernancePolicyMiddleware — évalue chaque action par rapport aux règles de politique déclaratives
CapabilityGuardMiddleware — liste blanche des outils qu’un agent est autorisé à appeler (l’outil approve_small_loan n’est pas dans la liste autorisée ci-dessus — délibérément)
RogueDetectionMiddleware — détecte les modèles de comportement anormaux à l’exécution
AuditTrailMiddleware — journal d’audit chaîné par Merkle pour que chaque action soit cryptographiquement inviolable

Ce dernier point compte pour la conformité. Une chaîne Merkle signifie que si quelqu’un modifie le journal, la chaîne se rompt. L’audit est la preuve.

Cinq Scénarios Industriels

Le dépôt AGT comprend cinq scénarios complets de bout en bout : services financiers (agent de crédit), santé (données patient), juridique (examen de contrat), gouvernement (services aux citoyens) et fabrication (contrôle qualité). Chacun associe de vrais agents MAF avec un vrai middleware de gouvernance AGT.

Ce ne sont pas des démos jouets. Ce sont le type de scénarios où vous auriez vraiment besoin d’une gouvernance en production.

Conclusion

Si vous construisez des agents qui touchent des données réelles, prennent des décisions avec des conséquences, ou s’exécutent sans surveillance en production — la gouvernance n’est pas optionnelle. La combinaison MAF + AGT vous donne la pile complète : construisez-le avec Agent Framework, gouvernez-le avec AGT.

Les deux projets sont open source. L’article original contient des liens vers les exemples de code complets.

Publication originale : Governance at the Speed of Agents: Microsoft Agent Framework and Agent Governance Toolkit, Better Together

A2A v1 Est Là : Communication Inter-Agents Cross-Platform dans Microsoft Agent Framework pour .NET

Emiliano Montesdeoca — Mon, 04 May 2026 00:00:00 +0000

Ce post a été traduit automatiquement. Pour la version originale, cliquez ici.

A2A v1 Est Là : Communication Inter-Agents Cross-Platform dans Microsoft Agent Framework pour .NET — le Protocole A2A vient d’atteindre v1.0, et les paquets A2A Agent (client) et A2A Hosting (serveur) pour .NET ont été mis à jour.

Ce qu’est réellement A2A v1

A2A est un protocole d’interopérabilité ouvert pour les agents IA soutenu par un comité de direction technique avec des représentants d’AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP et ServiceNow. L’étiquette v1 signifie que c’est maintenant un standard stable et prêt pour la production. Les paquets SDK et Agent Framework qui l’implémentent sont toujours en preview, mais le protocole lui-même est figé.

v1 améliore v0.3 avec le support multi-tenant, des Agent Cards signées pour l’identité cryptographique, des flux de sécurité améliorés et une architecture alignée sur le web.

Se connecter à un agent A2A distant

Un agent A2A distant est simplement un AIAgent dans votre code — même RunAsync, même streaming, même gestion de sessions :

// Découverte via URI well-known
A2ACardResolver resolver = new(new Uri("https://a2a-agent.example.com"));
AIAgent agent = await resolver.GetAIAgentAsync();
Console.WriteLine(await agent.RunAsync("What's the weather in Seattle?"));

// Configuration directe
A2AClient a2aClient = new(new Uri("https://a2a-agent.example.com"));
AIAgent agent = a2aClient.AsAIAgent(name: "my-agent", description: "A helpful assistant.");

// Le streaming fonctionne de la même façon
await foreach (var update in agent.RunStreamingAsync("Write a short summary..."))
 Console.Write(update.Text);

Exposer votre agent comme endpoint A2A

N’importe quel AIAgent que vous avez construit — sur Microsoft Foundry, Azure OpenAI, OpenAI, Anthropic ou AWS Bedrock — peut être exposé comme endpoint A2A avec deux lignes dans ASP.NET Core :

builder.Services.AddKeyedSingleton<AIAgent>("weather-agent", (sp, _) => ...);
builder.AddA2AServer("weather-agent");

La carte de l’agent est servie automatiquement à /.well-known/agent-card.json.

Ce que cela signifie en pratique

Le protocole stable v1 signifie que vous pouvez connecter vos agents .NET à des agents construits en Python, Java ou tout autre langage sans vous soucier des changements cassants. L’identité cryptographique dans les Agent Cards signées vous fournit également une base pour la vérification de confiance entre agents.

Consultez le post complet pour le journal des modifications complet et les notes de migration depuis v0.3.

CodeAct dans Agent Framework : Comment Réduire la Latence de votre Agent de Moitié

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

Ce post a été traduit automatiquement. Pour la version originale, cliquez ici.

Il y a ce moment dans tout projet d’agents où vous regardez la trace et pensez : « pourquoi est-ce que ça prend autant de temps ? » Le modèle est bien. Les outils fonctionnent. Mais il y a sept allers-retours pour obtenir un résultat qu’on pourrait calculer en une seule fois.

C’est exactement le problème que CodeAct résout — et l’équipe Agent Framework vient de publier un support alpha via le nouveau paquet agent-framework-hyperlight.

Qu’est-ce que CodeAct ?

Le pattern CodeAct est élégamment simple : au lieu de donner au modèle une liste d’outils à appeler un par un, vous lui donnez un seul outil execute_code et le laissez exprimer le plan complet comme un court programme Python. L’agent écrit le code une fois, le sandbox l’exécute, et vous récupérez un seul résultat consolidé.

Câblage	Temps	Tokens
Traditionnel	27,81s	6 890
CodeAct	13,23s	2 489
Amélioration	52,4%	63,9%

Sécurité : Micro-VMs Hyperlight

Le paquet agent-framework-hyperlight utilise des micro-VMs Hyperlight. Chaque appel execute_code obtient sa propre micro-VM fraîchement créée. Le démarrage se mesure en millisecondes. L’isolation est pratiquement gratuite.

Vos outils continuent de s’exécuter sur l’hôte. Le code de collage généré par le modèle s’exécute dans le sandbox. C’est le bon découpage.

Configuration minimale

from agent_framework import Agent, tool
from agent_framework_hyperlight import HyperlightCodeActProvider

@tool
def get_weather(city: str) -> dict[str, float | str]:
 """Return the current weather for a city."""
 return {"city": city, "temperature_c": 21.5, "conditions": "partly cloudy"}

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

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

Quand utiliser CodeAct (et quand ne pas l’utiliser)

Utilisez CodeAct quand :

La tâche enchaîne de nombreux petits appels d’outils (lookups, jointures, calculs)
La latence et le coût en tokens comptent
Vous voulez une isolation forte par appel pour le code généré par le modèle

Restez avec le tool-calling traditionnel quand :

L’agent ne fait qu’un ou deux appels d’outils par tour
Chaque appel a des effets secondaires à approuver individuellement
Les descriptions d’outils sont peu détaillées

Essayez maintenant

pip install agent-framework-hyperlight --pre

Consultez le post complet sur le blog Agent Framework pour une couverture approfondie.

GPT-5.5 Est Là et Arrive dans Azure Foundry — Ce que les Développeurs .NET Doivent Savoir

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

Ce post a été traduit automatiquement. Pour la version originale, cliquez ici.

Microsoft vient d’annoncer que GPT-5.5 est généralement disponible dans Microsoft Foundry. Si vous avez été en train de créer des agents sur Azure, c’est la mise à jour que vous attendiez.

La progression de GPT-5

GPT-5 : a unifié le raisonnement et la vitesse en un seul système
GPT-5.4 : raisonnement multi-étapes plus solide, capacités agentiques pour l’entreprise
GPT-5.5 : raisonnement en contexte long plus profond, exécution agentique plus fiable, meilleure efficacité des tokens

Ce qui a vraiment changé

Codage agentique amélioré : GPT-5.5 maintient le contexte sur de grandes bases de code, diagnostique les défaillances architecturales et anticipe les exigences de tests. Le modèle raisonne sur ce que d’autre une correction affecte avant d’agir.

Efficacité des tokens : Des sorties de meilleure qualité avec moins de tokens et moins de tentatives. Coût et latence directement réduits en production.

Analyse en contexte long : Gère de vastes documents et des historiques multi-sessions sans perdre le fil.

Tarification

Modèle	Entrée ($/M tokens)	Entrée en cache	Sortie ($/M tokens)
GPT-5.5	5,00 $	0,50 $	30,00 $
GPT-5.5 Pro	30,00 $	3,00 $	180,00 $

Pourquoi Foundry est important

Foundry Agent Service vous permet de définir des agents en YAML ou de les connecter avec Microsoft Agent Framework, GitHub Copilot SDK, LangGraph ou OpenAI Agents SDK — et de les exécuter comme agents hébergés isolés avec un système de fichiers persistant, une identité Microsoft Entra distincte et une tarification à l’échelle zéro.

AIAgent agent = aiProjectClient
 .AsAIAgent("gpt-5.5", instructions: "Vous êtes un assistant utile.", name: "MonAgent");

Consultez l’annonce complète pour tous les détails.

Où votre Agent se Souvient-il des Choses ? Guide Pratique sur le Stockage de l'Historique de Chat

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

Ce post a été traduit automatiquement. Pour la version originale, cliquez ici.

Lors de la création d’un agent IA, vous consacrez la majeure partie de votre énergie au modèle, aux outils et aux prompts. La question de l’endroit où vit l’historique des conversations semble être un détail d’implémentation — mais c’est l’une des décisions architecturales les plus importantes que vous prendrez.

Elle détermine si les utilisateurs peuvent bifurquer des conversations, annuler des réponses, reprendre des sessions après un redémarrage, et si vos données quittent jamais votre infrastructure. L’équipe Agent Framework a publié une analyse approfondie.

Deux modèles fondamentaux

Géré par le service : le service IA stocke l’état de la conversation. Votre application tient une référence et le service inclut automatiquement l’historique pertinent dans chaque requête.

Géré par le client : votre application maintient l’historique complet et envoie les messages pertinents avec chaque requête. Le service est sans état. Vous contrôlez tout.

Comment Agent Framework abstrait cela

// C# — fonctionne pareil quel que soit le fournisseur
AgentSession session = await agent.CreateSessionAsync();
var first = await agent.RunAsync("Je m'appelle Alice.", session);
var second = await agent.RunAsync("Quel est mon nom ?", session);

# Python
session = agent.create_session()
first = await agent.run("Je m'appelle Alice.", session=session)
second = await agent.run("Quel est mon nom ?", session=session)

Référence rapide des fournisseurs

Fournisseur	Stockage	Modèle	Compaction
OpenAI/Azure Chat Completions	Client	N/A	Vous
Foundry Agent Service	Service	Linéaire	Service
Responses API (défaut)	Service	Bifurquant	Service
Anthropic Claude, Ollama	Client	N/A	Vous

Comment choisir

Besoin de bifurcation ou « annuler » ? → Responses API géré par service
Besoin de souveraineté des données ? → Géré par client avec fournisseur base de données
Simple chatbot ? → Géré par service linéaire suffit

Lisez le post complet pour l’arbre de décision complet.

Les Agent Skills en .NET deviennent vraiment flexibles

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

Cet article a été traduit automatiquement. Pour la version originale, cliquez ici.

Si vous construisez des agents avec le Microsoft Agent Framework, vous connaissez le principe : vous définissez des skills, vous les connectez à un provider et vous laissez l’agent décider lequel invoquer. Ce qui est nouveau, c’est comment vous créez ces skills — et le gain en flexibilité est significatif.

La dernière mise à jour introduit trois patterns d’authoring pour les agent skills : basées sur des fichiers, basées sur des classes et définies en code inline. Les trois se branchent sur un seul AgentSkillsProviderBuilder, ce qui veut dire que vous pouvez les mixer sans logique de routage ni code spécial. Je vous présente chacune et quand l’utiliser.

Skills basées sur des fichiers : le point de départ

Les skills basées sur des fichiers sont exactement ce que leur nom suggère — un répertoire sur disque avec un fichier SKILL.md, des scripts optionnels et des documents de référence. La façon la plus directe de donner de nouvelles capacités à votre agent :

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

Le frontmatter du SKILL.md déclare le nom et la description, et la section d’instructions dit à l’agent comment utiliser les scripts et les références :

---
name: onboarding-guide
description: >-
 Walk new hires through their first-week setup checklist.
---

## Instructions

1. Ask for the employee's name and start date.
2. Run `scripts/check-provisioning.py` to verify accounts.
3. Walk through `references/onboarding-checklist.md`.
4. Follow up on incomplete items.

Ensuite vous le connectez avec SubprocessScriptRunner.RunAsync pour l’exécution des scripts :

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

AIAgent agent = new AzureOpenAIClient(new Uri(endpoint), new DefaultAzureCredential())
 .GetResponsesClient()
 .AsAIAgent(new ChatClientAgentOptions
 {
 Name = "HRAgent",
 ChatOptions = new() { Instructions = "You are a helpful HR assistant." },
 AIContextProviders = [skillsProvider],
 },
 model: deploymentName);

L’agent découvre la skill automatiquement et invoque le script de provisioning quand il doit vérifier le statut des comptes. Propre et simple.

Skills basées sur des classes : distribuer via NuGet

C’est là que ça devient intéressant pour les équipes. Les skills basées sur des classes dérivent de AgentClassSkill<T> et utilisent des attributs comme [AgentSkillResource] et [AgentSkillScript] pour que le framework découvre tout par réflexion :

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

 protected override string Instructions => """
 1. Read the available-plans resource.
 2. Confirm the plan the employee wants.
 3. Use the enroll script to complete enrollment.
 """;

 [AgentSkillResource("available-plans")]
 [Description("Plan options with monthly pricing.")]
 public string AvailablePlans => """
 ## Available Plans (2026)
 - Health: Basic HMO ($0/month), Premium PPO ($45/month)
 - Dental: Standard ($12/month), Enhanced ($25/month)
 - Vision: Basic ($8/month)
 """;

 [AgentSkillScript("enroll")]
 [Description("Enrolls employee in the specified benefit plan.")]
 private static string Enroll(string employeeId, string planCode)
 {
 bool success = HrClient.EnrollInPlan(employeeId, planCode);
 return JsonSerializer.Serialize(new { success, employeeId, planCode });
 }
}

Le beau ici, c’est qu’une équipe peut packager ça en paquet NuGet. Vous l’ajoutez à votre projet, vous le mettez dans le builder, et ça fonctionne à côté de vos skills fichier sans coordination :

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

Les deux skills apparaissent dans le system prompt de l’agent. L’agent décide laquelle utiliser en fonction de la conversation — pas de code de routage nécessaire.

Skills inline : le pont rapide

Vous connaissez ce moment où une autre équipe construit exactement la skill dont vous avez besoin, mais elle ne sera pas prête avant le prochain sprint ? AgentInlineSkill est votre pont :

var timeOffSkill = new AgentInlineSkill(
 name: "time-off-balance",
 description: "Calculate remaining vacation and sick days.",
 instructions: """
 1. Ask for the employee ID if not provided.
 2. Use calculate-balance to get the remaining balance.
 3. Present used and remaining days clearly.
 """)
 .AddScript("calculate-balance", (string employeeId, string leaveType) =>
 {
 int totalDays = HrDatabase.GetAnnualAllowance(employeeId, leaveType);
 int daysUsed = HrDatabase.GetDaysUsed(employeeId, leaveType);
 int remaining = totalDays - daysUsed;
 return JsonSerializer.Serialize(new { employeeId, leaveType, totalDays, daysUsed, remaining });
 });

Ajoutez-la au builder comme les autres :

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

Quand le paquet NuGet sort enfin, vous échangez la skill inline contre la version classe. L’agent ne voit pas la différence.

Les skills inline ne sont pas que pour les ponts. Elles sont aussi le bon choix quand vous devez générer des skills dynamiquement à l’exécution — pensez à une skill par unité métier chargée depuis la config — ou quand un script doit capturer un état local qui n’a pas sa place dans un conteneur DI.

Approbation de scripts : l’humain dans la boucle

Pour nous développeurs .NET qui construisons des agents de production, c’est la partie qui débloque vraiment les discussions de déploiement. Certains scripts ont des conséquences réelles — inscrire quelqu’un à des avantages, interroger l’infrastructure de production. Activez UseScriptApproval et l’agent se met en pause avant d’exécuter tout script :

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

Quand l’agent veut exécuter un script, il retourne une demande d’approbation à la place. Votre app collecte la décision — approuver ou rejeter — et l’agent continue en conséquence. Dans les environnements réglementés, c’est la différence entre “on peut déployer ça” et “le juridique dit non.”

Pourquoi cette combinaison compte

Le vrai pouvoir n’est pas dans un pattern individuel — c’est dans la composition. Vous pouvez :

Commencer petit avec une skill fichier, itérer sur les instructions et la publier sans écrire de C#
Distribuer des skills réutilisables comme paquets NuGet que d’autres équipes ajoutent en une ligne
Combler les lacunes avec des skills inline quand vous avez besoin de quelque chose maintenant
Filtrer les répertoires partagés avec des prédicats pour que votre agent ne charge que ce qu’il doit
Ajouter une supervision humaine pour les scripts qui touchent les systèmes de production

Tout cela se compose via AgentSkillsProviderBuilder. Pas de routage spécial, pas de logique conditionnelle, pas de vérifications de type de skill.

Pour conclure

Les agent skills en .NET ont maintenant un modèle d’authoring véritablement flexible. Que vous soyez un développeur solo qui prototype avec des skills fichier ou une équipe enterprise qui distribue des capacités packagées via NuGet, les patterns s’adaptent. Et le mécanisme d’approbation de scripts le rend prêt pour la production dans les environnements où vous avez besoin de ce checkpoint humain.

Consultez l’annonce originale, la documentation Agent Skills sur Microsoft Learn et les exemples .NET sur GitHub pour vous lancer.

Construire des UIs Multi-Agents en Temps Réel Qui Ne Ressemblent Pas à une Boîte Noire

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

Cet article a été traduit automatiquement. Pour la version originale, cliquez ici.

Voilà le truc avec les systèmes multi-agents : ils sont incroyables en démo. Trois agents qui se passent le travail, résolvent des problèmes, prennent des décisions. Puis tu essaies de le mettre devant de vrais utilisateurs et… silence. Un indicateur qui tourne. Aucune idée de quel agent fait quoi ni pourquoi le système est en pause. Ce n’est pas un produit — c’est un problème de confiance.

L’équipe Microsoft Agent Framework vient de publier un excellent tutoriel sur le couplage des workflows MAF avec AG-UI, un protocole ouvert pour streamer les événements d’exécution des agents vers un frontend via les Server-Sent Events. Et franchement ? C’est exactement le pont qui nous manquait.

Pourquoi c’est important pour les développeurs .NET

Si tu construis des applications alimentées par l’IA, tu as probablement déjà heurté ce mur. Ton orchestration backend fonctionne parfaitement — les agents se passent le relais, les outils se déclenchent, les décisions sont prises. Mais le frontend n’a aucune idée de ce qui se passe en coulisses. AG-UI résout ça en définissant un protocole standard pour streamer les événements d’agents (pense à RUN_STARTED, STEP_STARTED, TOOL_CALL_*, TEXT_MESSAGE_*) directement vers ta couche UI via SSE.

La démo est un workflow de support client avec trois agents : un agent de triage qui route les demandes, un agent de remboursement qui gère les questions d’argent, et un agent de commandes qui gère les remplacements. Chaque agent a ses propres outils, et la topologie de handoff est définie explicitement — pas de « devine à partir du prompt ».

La topologie de handoff est la vraie star

Ce qui m’a marqué, c’est comment HandoffBuilder te permet de déclarer un graphe de routage dirigé entre les agents :

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

Chaque add_handoff crée une arête dirigée avec une description en langage naturel. Le framework génère des outils de handoff pour chaque agent en se basant sur cette topologie. Les décisions de routage reposent donc sur ta structure d’orchestration, pas juste sur ce que le LLM a envie de faire. C’est un gain énorme pour la fiabilité en production.

Le human-in-the-loop qui fonctionne vraiment

La démo présente deux patterns d’interruption dont toute app d’agents réelle a besoin :

Interruptions d’approbation d’outils — quand un agent appelle un outil marqué avec approval_mode="always_require", le workflow se met en pause et émet un événement. Le frontend affiche un modal d’approbation avec le nom de l’outil et ses arguments. Pas de boucles de retry qui brûlent des tokens — juste un flux propre pause-approbation-reprise.

Interruptions de demande d’information — quand un agent a besoin de plus de contexte de la part de l’utilisateur (comme un ID de commande), il se met en pause et pose la question. Le frontend affiche la question, l’utilisateur répond, et l’exécution reprend exactement là où elle s’était arrêtée.

Les deux patterns sont streamés en tant qu’événements AG-UI standard, donc ton frontend n’a pas besoin de logique personnalisée par agent — il affiche simplement chaque événement qui arrive via la connexion SSE.

L’intégration est étonnamment simple

L’intégration entre MAF et AG-UI se résume à un seul appel de fonction :

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",
)

La workflow_factory crée un workflow frais par thread, pour que chaque conversation ait son propre état isolé. L’endpoint gère toute la plomberie SSE automatiquement. Si tu utilises déjà FastAPI (ou que tu peux l’ajouter comme couche légère), c’est quasiment zéro friction.

Mon avis

Pour nous développeurs .NET, la question immédiate est : « Est-ce que je peux faire ça en C# ? » L’Agent Framework est disponible pour .NET et Python, et le protocole AG-UI est agnostique au langage (c’est juste du SSE). Donc même si cette démo spécifique utilise Python et FastAPI, le pattern se transpose directement. Tu pourrais câbler une API minimale ASP.NET Core avec des endpoints SSE suivant le même schéma d’événements AG-UI.

Le point plus important est que les UIs multi-agents deviennent une préoccupation de premier plan, pas un ajout après coup. Si tu construis quoi que ce soit où des agents interagissent avec des humains — support client, workflows d’approbation, traitement de documents — cette combinaison d’orchestration MAF et de transparence AG-UI est le pattern à suivre.

Pour conclure

AG-UI + Microsoft Agent Framework te donne le meilleur des deux mondes : une orchestration multi-agents robuste côté backend et une visibilité en temps réel côté frontend. Fini les interactions d’agents en boîte noire.

Consulte le tutoriel complet et le dépôt du protocole AG-UI pour aller plus loin.

Microsoft Agent Framework Atteint la 1.0 — Voici Ce Qui Compte Vraiment pour les Développeurs .NET

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

Cet article a été traduit automatiquement. Pour la version originale, cliquez ici.

Si vous avez suivi le parcours d’Agent Framework depuis les premiers jours de Semantic Kernel et AutoGen, celui-ci est significatif. Microsoft Agent Framework vient d’atteindre la version 1.0 — prêt pour la production, APIs stables, engagement de support à long terme. Il est disponible pour .NET et Python, et il est véritablement prêt pour les charges de travail réelles.

Laissez-moi couper à travers le bruit de l’annonce et me concentrer sur ce qui compte si vous construisez des applications alimentées par l’IA avec .NET.

La version courte

Agent Framework 1.0 unifie ce qui était auparavant Semantic Kernel et AutoGen en un seul SDK open source. Une abstraction d’agent. Un moteur d’orchestration. Plusieurs fournisseurs d’IA. Si vous avez jonglé entre Semantic Kernel pour les patterns entreprise et AutoGen pour les workflows multi-agent de niveau recherche, vous pouvez arrêter. C’est le seul SDK maintenant.

Démarrer est presque injustement simple

Voici un agent fonctionnel en .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."));

C’est tout. Une poignée de lignes et vous avez un agent IA qui tourne contre Azure Foundry. L’équivalent Python est tout aussi concis. Ajoutez des outils de fonctions, des conversations multi-tours et du streaming au fur et à mesure — la surface de l’API monte en puissance sans devenir bizarre.

Orchestration multi-agent — c’est du sérieux

Les agents individuels sont bien pour les démos, mais les scénarios de production nécessitent généralement de la coordination. Agent Framework 1.0 est livré avec des patterns d’orchestration éprouvés au combat directement de Microsoft Research et AutoGen :

Séquentiel — les agents traitent dans l’ordre (rédacteur → réviseur → éditeur)
Concurrent — distribue vers plusieurs agents en parallèle, converge les résultats
Handoff — un agent délègue à un autre basé sur l’intention
Chat de groupe — plusieurs agents discutent et convergent vers une solution
Magentic-One — le pattern multi-agent de niveau recherche de MSR

Tous supportent le streaming, le checkpointing, les approbations humain-dans-la-boucle, et la pause/reprise. La partie checkpointing est cruciale — les workflows de longue durée survivent aux redémarrages de processus. Pour nous, développeurs .NET qui avons construit des workflows durables avec Azure Functions, ça nous parle.

Les fonctionnalités qui comptent le plus

Voici ma liste de ce qui vaut la peine d’être connu :

Hooks middleware. Vous savez comment ASP.NET Core a des pipelines middleware ? Même concept, mais pour l’exécution des agents. Interceptez chaque étape — ajoutez la sécurité du contenu, le logging, les politiques de conformité — sans toucher aux prompts de l’agent. C’est comme ça que vous rendez les agents prêts pour l’entreprise.

Mémoire pluggable. Historique conversationnel, état persistant clé-valeur, récupération basée sur les vecteurs. Choisissez votre backend : Foundry Agent Service, Mem0, Redis, Neo4j, ou créez le vôtre. La mémoire est ce qui transforme un appel LLM sans état en un agent qui se souvient réellement du contexte.

Agents YAML déclaratifs. Définissez les instructions de votre agent, ses outils, sa mémoire et sa topologie d’orchestration dans des fichiers YAML versionnés. Chargez et exécutez avec un seul appel API. C’est un changement de donne pour les équipes qui veulent itérer sur le comportement de l’agent sans redéployer du code.

Support A2A et MCP. MCP (Model Context Protocol) permet aux agents de découvrir et d’invoquer des outils externes dynamiquement. A2A (protocole Agent-to-Agent) permet la collaboration inter-runtime — vos agents .NET peuvent se coordonner avec des agents s’exécutant dans d’autres frameworks. Le support A2A 1.0 arrive bientôt.

Les fonctionnalités en preview à surveiller

Certaines fonctionnalités ont été livrées en preview dans la 1.0 — fonctionnelles mais les APIs peuvent évoluer :

DevUI — un débogueur local basé navigateur pour visualiser l’exécution de l’agent, les flux de messages et les appels d’outils en temps réel. Pensez Application Insights, mais pour le raisonnement de l’agent.
GitHub Copilot SDK et Claude Code SDK — utilisez Copilot ou Claude comme harness d’agent directement depuis votre code d’orchestration. Composez un agent capable de coder aux côtés de vos autres agents dans le même workflow.
Agent Harness — un runtime local personnalisable donnant aux agents l’accès au shell, au système de fichiers et aux boucles de messagerie. Pensez agents de codage et patterns d’automatisation.
Skills — des packages de capacités de domaine réutilisables qui donnent aux agents des capacités structurées prêtes à l’emploi.

Migration depuis Semantic Kernel ou AutoGen

Si vous avez du code Semantic Kernel ou AutoGen existant, il existe des assistants de migration dédiés qui analysent votre code et génèrent des plans de migration étape par étape. Le guide de migration Semantic Kernel et le guide de migration AutoGen vous accompagnent à travers tout.

Si vous étiez sur les packages RC, la mise à niveau vers 1.0 est juste un changement de version.

Pour conclure

Agent Framework 1.0 est le jalon de production que les équipes entreprise attendaient. APIs stables, support multi-fournisseur, patterns d’orchestration qui fonctionnent réellement à l’échelle, et des chemins de migration depuis Semantic Kernel et AutoGen.

Le framework est entièrement open source sur GitHub, et vous pouvez commencer dès aujourd’hui avec dotnet add package Microsoft.Agents.AI. Consultez le guide de démarrage rapide et les exemples pour mettre les mains dans le cambouis.

Si vous attendiez le signal « utilisable en production en toute sécurité » — c’est celui-ci.

Les réponses en arrière-plan dans Microsoft Agent Framework : fini l'angoisse des timeouts

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

Si vous avez construit quoi que ce soit avec des modèles de raisonnement comme o3 ou GPT-5.2, vous connaissez la douleur. Votre agent commence à réfléchir à une tâche complexe, le client attend, et quelque part entre “ça va” et “est-ce que ça a planté ?” votre connexion expire. Tout ce travail ? Perdu.

Microsoft Agent Framework vient de livrer les réponses en arrière-plan — et honnêtement, c’est une de ces fonctionnalités qui auraient dû exister depuis le premier jour.

Le problème avec les appels bloquants

Dans un schéma requête-réponse traditionnel, votre client bloque jusqu’à ce que l’agent termine. Ça marche bien pour les tâches rapides. Mais quand vous demandez à un modèle de raisonnement de faire une recherche approfondie, une analyse en plusieurs étapes, ou de générer un rapport de 20 pages ? Vous regardez des minutes de temps réel. Pendant cette fenêtre :

Les connexions HTTP peuvent expirer
Les coupures réseau tuent toute l’opération
Votre utilisateur fixe un spinner en se demandant s’il se passe quelque chose

Les réponses en arrière-plan inversent la donne.

Comment fonctionnent les tokens de continuation

Au lieu de bloquer, vous lancez la tâche de l’agent et récupérez un token de continuation. Pensez-y comme un ticket de retrait dans un atelier de réparation — vous ne restez pas debout au comptoir à attendre, vous revenez quand c’est prêt.

Le flux est direct :

Envoyez votre requête avec AllowBackgroundResponses = true
Si l’agent supporte le traitement en arrière-plan, vous recevez un token de continuation
Interrogez à votre rythme jusqu’à ce que le token retourne null — ça signifie que le résultat est prêt

Voici la version .NET :

AIAgent agent = new AzureOpenAIClient(
 new Uri("https://<myresource>.openai.azure.com"),
 new DefaultAzureCredential())
 .GetResponsesClient("<deployment-name>")
 .AsAIAgent();

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);

// Interroger jusqu'à complétion
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);

Si l’agent finit immédiatement (tâches simples, modèles qui n’ont pas besoin de traitement en arrière-plan), aucun token de continuation n’est renvoyé. Votre code fonctionne simplement — aucun traitement spécial nécessaire.

Streaming avec reprise : la vraie magie

Le polling convient pour les scénarios fire-and-forget, mais que faire quand vous voulez un progrès en temps réel ? Les réponses en arrière-plan supportent aussi le streaming avec reprise intégrée.

Chaque mise à jour streamée porte son propre token de continuation. Si votre connexion tombe en plein stream, vous reprenez exactement là où vous en étiez :

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

AgentSession session = await agent.CreateSessionAsync();
AgentResponseUpdate? latestUpdate = null;

await foreach (var update in agent.RunStreamingAsync(
 "Write a detailed market analysis for the Q4 product launch.", session, options))
{
 Console.Write(update.Text);
 latestUpdate = update;
 break; // Simuler une interruption réseau
}

// Reprendre exactement là où nous en étions
options.ContinuationToken = latestUpdate?.ContinuationToken;
await foreach (var update in agent.RunStreamingAsync(session, options))
{
 Console.Write(update.Text);
}

L’agent continue le traitement côté serveur indépendamment de ce qui se passe avec votre client. C’est de la tolérance aux pannes intégrée sans que vous écriviez de la logique de retry ou des circuit breakers.

Quand utiliser ça concrètement

Tous les appels d’agent n’ont pas besoin de réponses en arrière-plan. Pour les completions rapides, vous ajoutez de la complexité pour rien. Mais voici où elles brillent :

Tâches de raisonnement complexe — analyse en plusieurs étapes, recherche approfondie, tout ce qui fait vraiment réfléchir un modèle de raisonnement
Génération de contenu long — rapports détaillés, documents en plusieurs parties, analyses approfondies
Réseaux peu fiables — clients mobiles, déploiements edge, VPN d’entreprise instables
Patterns UX asynchrones — soumettez une tâche, allez faire autre chose, revenez pour les résultats

Pour nous développeurs .NET qui construisons des apps enterprise, ce dernier point est particulièrement intéressant. Pensez à une app Blazor où un utilisateur demande un rapport complexe — vous lancez la tâche de l’agent, affichez un indicateur de progression, et le laissez continuer à travailler. Pas d’acrobaties WebSocket, pas d’infrastructure de file d’attente personnalisée, juste un token et une boucle de polling.

Pour conclure

Les réponses en arrière-plan sont disponibles maintenant en .NET et Python via Microsoft Agent Framework. Si vous construisez des agents qui font plus que du simple Q&A, ça vaut le coup de l’ajouter à votre boîte à outils. Le pattern du token de continuation garde les choses simples tout en résolvant un vrai problème de production.

Consultez la documentation complète pour la référence API complète et plus d’exemples.

Agent-Framework | The .NET Blog

Microsoft Foundry Avril 2026 : Foundry Local GA, GPT-5.5, CodeAct avec Hyperlight

Foundry Local est Généralement Disponible

GPT-5.5

Traçage d’Agent Framework dans Foundry

CodeAct avec Hyperlight (Alpha)

Tableau de Bord de Surveillance des Agents (Préversion)

Évaluateurs Personnalisés d’Évaluation Continue (Préversion)

Inventaire des Agents dans le Plan de Contrôle

Le Modèle Handoff : Quand Un Agent Ne Suffit Pas

Comment Fonctionne Handoff

Un Exemple Minimal

Quand Utiliser Handoff (et Quand Ne Pas Le Faire)

Arêtes Arrière et Humain-dans-la-Boucle

Conclusion

Workflows Durables dans Microsoft Agent Framework : De In-Memory à Azure Functions

Les Blocs de Construction Fondamentaux

Le Runner In-Memory pour le Développement Local

Ajouter la Durabilité avec Durable Task

Hébergement Azure Functions

Pourquoi C’est Important

Votre Agent MAF Local Vient d'Obtenir une Maison en Production

Ce que Foundry Hosted Agents Fait Vraiment

La Différence de Code Est Minime

Deux Protocoles, Un Agent

Le Flux de Déploiement avec azd

Conclusion

Créer des Agents, C'est la Partie Facile — Les Exécuter en Toute Sécurité, C'est la Partie Difficile

Ce Que Chaque Projet Fait Vraiment

S’intégrer, C’est Juste Ajouter un Middleware

Ce Que Vous Obtenez

Cinq Scénarios Industriels

Conclusion

A2A v1 Est Là : Communication Inter-Agents Cross-Platform dans Microsoft Agent Framework pour .NET

Ce qu’est réellement A2A v1

Se connecter à un agent A2A distant

Exposer votre agent comme endpoint A2A

Ce que cela signifie en pratique

CodeAct dans Agent Framework : Comment Réduire la Latence de votre Agent de Moitié

Qu’est-ce que CodeAct ?

Sécurité : Micro-VMs Hyperlight

Configuration minimale

Quand utiliser CodeAct (et quand ne pas l’utiliser)

Essayez maintenant

GPT-5.5 Est Là et Arrive dans Azure Foundry — Ce que les Développeurs .NET Doivent Savoir

La progression de GPT-5

Ce qui a vraiment changé

Tarification

Pourquoi Foundry est important

Où votre Agent se Souvient-il des Choses ? Guide Pratique sur le Stockage de l'Historique de Chat

Deux modèles fondamentaux

Comment Agent Framework abstrait cela

Référence rapide des fournisseurs

Comment choisir

Les Agent Skills en .NET deviennent vraiment flexibles

Skills basées sur des fichiers : le point de départ

Skills basées sur des classes : distribuer via NuGet

Skills inline : le pont rapide

Approbation de scripts : l’humain dans la boucle

Pourquoi cette combinaison compte

Pour conclure

Construire des UIs Multi-Agents en Temps Réel Qui Ne Ressemblent Pas à une Boîte Noire

Pourquoi c’est important pour les développeurs .NET

La topologie de handoff est la vraie star

Le human-in-the-loop qui fonctionne vraiment

L’intégration est étonnamment simple

Mon avis

Pour conclure

Microsoft Agent Framework Atteint la 1.0 — Voici Ce Qui Compte Vraiment pour les Développeurs .NET

La version courte

Démarrer est presque injustement simple

Orchestration multi-agent — c’est du sérieux

Les fonctionnalités qui comptent le plus

Les fonctionnalités en preview à surveiller

Migration depuis Semantic Kernel ou AutoGen

Pour conclure

Les réponses en arrière-plan dans Microsoft Agent Framework : fini l'angoisse des timeouts

Le problème avec les appels bloquants

Comment fonctionnent les tokens de continuation

Streaming avec reprise : la vraie magie

Le Flux de Déploiement avec `azd`