Microsoft Agent Framework évolue vite. Très vite même.Lors de ses premières versions, il était assez naturel de le regarder essentiellement comme le successeur conjoint de Semantic Kernel et d’AutoGen : une nouvelle API Microsoft pour construire des agents, leur fournir des tools et orchestrer plusieurs agents. Cette description devient aujourd’hui trop réductrice.

Microsoft Agent Framework — MAF pour les intimes — commence à proposer les briques d’une véritable plateforme d’exécution agentique :

• agents classiques pilotés par un LLM ;

• workflows déterministes ou semi-déterministes ;

• workflows déclaratifs en YAML ;

• agents eux-mêmes déclarables en YAML ou JSON ;

• orchestration multi-agent ;

• état et checkpointing ;

• humain dans la boucle ;

• exposition des agents à travers le protocole AG-UI ;

• Agent Skills chargeables à la demande ;

• ressources et scripts associés aux skills ;

• MCP ;

• middleware ;

• observabilité ;

• intégration avec plusieurs fournisseurs de modèles, y compris Ollama.

Ce changement est important parce qu’il marque aussi une clarification architecturale.

Un agent ne doit pas devenir un workflow bricolé à coups de prompts.

Et un workflow ne doit pas être remplacé par un LLM auquel on demande gentiment de respecter dix-sept étapes dans le bon ordre.

Microsoft formalise désormais explicitement cette distinction dans Agent Framework. Un agent prend dynamiquement ses décisions à partir d’un modèle et des tools auxquels il a accès. Un workflow définit au contraire un chemin d’exécution contrôlé comportant éventuellement des agents.

Et c’est probablement l’évolution la plus intéressante de MAF depuis son apparition.

1. Agent Framework n’est plus simplement une API d’agents

La documentation actuelle de Microsoft Agent Framework distingue trois grandes familles de fonctionnalités :

1. Agents

2. Harness

3. Workflows

Les agents restent les composants pilotés par un LLM. Ils traitent des entrées, utilisent éventuellement des tools, des serveurs MCP et des providers de contexte, puis produisent une réponse.

Le Harness est une couche plus prescriptive destinée aux tâches agentiques longues : planification, suivi des tâches, compactage du contexte, fichiers, mémoire, approbation des tools et observabilité.

Enfin viennent les Workflows, qui connectent agents et code dans un graphe d’exécution contrôlé, avec routage typé, checkpointing et human-in-the-loop.

Cette séparation répond à un problème que l’on rencontre très vite dès que l’on construit de vrais systèmes agentiques.

Prenons un processus de traitement de facture :

1. extraire les informations du document ;

2. contrôler le fournisseur ;

3. vérifier les montants ;

4. demander une validation humaine au-dessus d’un certain seuil ;

5. enregistrer la facture ;

6. notifier la comptabilité.

On peut donner l’ensemble de ces instructions à un agent :

Tu dois d'abord extraire la facture.
Ensuite vérifier le fournisseur.
Ensuite contrôler les montants.
Si le montant dépasse 10 000 €, demander une validation.
Puis enregistrer...

Cela fonctionne jusqu’au jour où cela ne fonctionne plus.

Le modèle reste celui qui interprète les instructions et décide implicitement de l’enchaînement.

Pour un chatbot, c’est acceptable.

Pour un processus métier, cela ne l’est souvent pas.

Le workflow remet donc du code déterministe autour de l’intelligence probabiliste.

C’est une distinction essentielle.

2. Un workflow MAF est un graphe d’exécution

En .NET, l’API fondamentale reste WorkflowBuilder.

Le workflow connecte des executors à travers des edges.

Un exemple conceptuellement minimal ressemble à ceci :

using Microsoft.Agents.AI.Workflows;

var processor = new DataProcessor();
var validator = new Validator();
var formatter = new Formatter();

WorkflowBuilder builder = new(processor);

builder.AddEdge(processor, validator);
builder.AddEdge(validator, formatter);

var workflow = builder.Build();

C’est exactement le modèle présenté aujourd’hui dans la documentation Microsoft.

Le graphe obtenu est ici trivial :

DataProcessor
     |
     v
 Validator
     |
     v
 Formatter

Mais MAF permet naturellement d’aller beaucoup plus loin :

                       +--> Agent technique --+
                       |                      |
Entrée --> Classifier -+--> Agent juridique --+--> Synthèse --> Validation
                       |                      |
                       +--> Agent financier --+

Les edges peuvent être conditionnels et le runtime sait gérer des scénarios de fan-out, fan-in et exécution parallèle.

3. Executor et Agent ne sont pas synonymes

C’est une nuance assez importante.

Un executor représente une unité d’exécution du workflow.

Il peut encapsuler :

• du code .NET traditionnel ;

• une transformation ;

• une validation ;

• un appel de service ;

• un agent IA ;

• une demande d’information externe ;

• une intervention humaine.

Autrement dit, utiliser Agent Framework Workflows ne signifie absolument pas :

« tout transformer en agent ».

Et heureusement.

Imaginez que nous devions vérifier si un montant est supérieur à 10 000 €.

La mauvaise solution agentique consisterait à demander à un LLM :

Le montant est 14500.
Est-il supérieur à 10000 ?

C’est absurde.

Le bon workflow utilise du code :

bool RequiresApproval(decimal amount)
    => amount >= 10_000m;

Le LLM n’intervient que là où l’on a réellement besoin de capacités de compréhension, d’interprétation, de génération ou de raisonnement.

C’est précisément ce que permet le modèle Agent Framework.

4. Les supersteps : comprendre le modèle d’exécution

Le runtime des workflows MAF utilise un modèle par supersteps.

Cela devient particulièrement important lorsqu’un executor alimente plusieurs branches parallèles.

Schématiquement :

           ┌── Executor B ──┐
Executor A ┤                ├── Executor D
           └── Executor C ──┘

B et C peuvent appartenir au même superstep.

Le runtime peut donc exécuter les opérations activées pendant cette phase avant de passer au niveau suivant du graphe.

Ce modèle intervient aussi dans le checkpointing : pour les workflows graphes, les checkpoints se placent aux frontières des supersteps.

Pour une application métier longue, c’est loin d’être anecdotique.

Cela permet d’envisager :

• reprise après interruption ;

• processus nécessitant plusieurs interactions humaines ;

• traitements longs ;

• workflows distribués ;

• audit de l’avancement.

Nous sortons clairement du modèle :

await agent.RunAsync(prompt);

5. Workflow ou agent : une question de contrôle

Microsoft donne maintenant une recommandation assez raisonnable : ne pas utiliser un workflow lorsque quelque chose de plus simple suffit.

Un agent unique est souvent préférable lorsque le déroulement doit rester libre.

Le workflow devient pertinent lorsqu’on a besoin de garantir certaines propriétés :

• ordre des étapes ;

• embranchements contrôlés ;

• validation ;

• parallélisme explicite ;

• intervention humaine ;

• état ;

• reprise ;

• audit.

Microsoft formule d’ailleurs la distinction ainsi : l’agent détermine dynamiquement ses étapes à partir du contexte alors que le workflow définit explicitement le chemin d’exécution.

On pourrait résumer cela ainsi :

Agent
    "Que dois-je faire maintenant ?"

Workflow
    "Voici ce qui doit arriver maintenant.
     L'agent peut éventuellement décider comment traiter cette étape."

Cette inversion est fondamentale.

6. Puis arrivent les workflows déclaratifs

C’est ici que les choses deviennent particulièrement intéressantes.

Agent Framework permet désormais de décrire des workflows en YAML, sans construire explicitement le graphe dans du code C#.

Microsoft appelle cela les Declarative Workflows.

L’idée n’est pas simplement esthétique.

Au lieu d’avoir :

builder.AddEdge(...);
builder.AddEdge(...);
builder.AddEdge(...);

la structure du processus devient une donnée de configuration.

Pour .NET, un workflow YAML commence typiquement ainsi :

kind: Workflow

trigger:
  kind: OnConversationStart
  id: my_workflow

  actions:
    - kind: SetVariable
      id: initialize
      displayName: Initialisation

La structure C# des workflows déclaratifs utilise donc un trigger avec une collection d’actions.

Microsoft fournit actuellement pour .NET les packages :

dotnet add package Microsoft.Agents.AI.Workflows.Declarative --prerelease
dotnet add package Microsoft.Agents.AI.Workflows.Declarative.AzureAI --prerelease

Et, pour MCP :

dotnet add package Microsoft.Agents.AI.Workflows.Declarative.Mcp --prerelease

Le --prerelease n’est pas décoratif : au moment où j’écris ces lignes, il faut considérer cette partie de l’API comme encore susceptible d’évoluer.

7. Un premier workflow YAML

Prenons un cas extrêmement simple.

Nous récupérons le dernier message de l’utilisateur puis générons un message.

kind: Workflow

trigger:
  kind: OnConversationStart
  id: welcome_workflow

  actions:

    - kind: SetVariable
      id: capture_name
      displayName: Capture du nom
      variable: Local.userName
      value: =System.LastMessage.Text

    - kind: SendActivity
      id: welcome
      displayName: Message de bienvenue
      activity:
        text: =Concat("Bonjour ", Local.userName)

Un élément essentiel apparaît immédiatement :

value: =System.LastMessage.Text

Le préfixe = indique une expression évaluée à l’exécution.

Dans la documentation Microsoft, on retrouve notamment des fonctions telles que :

Concat(...)
If(...)
IsBlank(...)

et des espaces de variables comme System.* ou des variables locales au workflow.

Nous ne sommes donc pas devant un simple fichier de configuration statique.

Le YAML décrit réellement un petit programme d’orchestration.

8. Ce que le YAML sait faire

La première version qu’on imagine d’un workflow déclaratif est souvent :

action A
action B
action C

Ce serait utile, mais limité.

L’offre actuelle va nettement plus loin.

Microsoft documente notamment les catégories d’actions suivantes :

Ce point change considérablement la portée du système.

On peut avoir un fichier YAML qui décrit réellement un processus métier agentique.

9. Exemple : pipeline multi-agent déclaratif

Voici par exemple le principe d’un pipeline de production de contenu.

kind: Workflow

trigger:
  kind: OnConversationStart
  id: content_workflow

  actions:

    - kind: InvokeAzureAgent
      id: research
      displayName: Recherche
      conversationId: =System.ConversationId
      agent:
        name: ResearcherAgent

    - kind: InvokeAzureAgent
      id: write
      displayName: Rédaction
      conversationId: =System.ConversationId
      agent:
        name: WriterAgent

    - kind: InvokeAzureAgent
      id: review
      displayName: Relecture
      conversationId: =System.ConversationId
      agent:
        name: ReviewerAgent

Microsoft documente explicitement ce modèle de pipeline séquentiel multi-agent.

L’intérêt n’est pas d’économiser quelques lignes de C#.

Il est ailleurs.

Le processus n’est plus compilé dans l’application.

On peut :

• le versionner indépendamment ;

• le inspecter facilement ;

• le comparer dans Git ;

• générer une représentation ;

• l’adapter sans reconstruire toute l’architecture ;

• éventuellement permettre à d’autres profils que les développeurs de modifier certaines parties du processus.

10. Mais attention : YAML n’est pas automatiquement meilleur que C#

Il serait tentant de conclure :

« puisque MAF supporte maintenant le YAML, tous les workflows devraient devenir déclaratifs ».

Ce serait une mauvaise conclusion.

Microsoft recommande elle-même l’approche programmatique lorsque la logique devient très spécifique ou lorsque l’on recherche le maximum de flexibilité.

Une logique comme :

if (invoice.Country == Country.France &&
    customer.Type == CustomerType.PublicAdministration &&
    invoice.Total > policy.GetThreshold(customer))
{
    ...
}

n’a pas nécessairement intérêt à devenir un cauchemar YAML.

Le déclaratif fonctionne particulièrement bien lorsque la topologie métier est importante et relativement stable, alors que le code reste supérieur pour les algorithmes et règles complexes.

Une architecture réaliste combinera probablement :

YAML
  |
  +--> orchestration
  |
  +--> fonctions C#
  |
  +--> agents
  |
  +--> MCP
  |
  +--> services métier

C’est beaucoup plus sain que de tenter de transformer YAML en nouveau langage de programmation généraliste.

11. Les agents eux-mêmes deviennent déclaratifs

La logique déclarative ne s’arrête pas aux workflows.

Agent Framework permet également de créer des Declarative Agents.

Un agent peut ainsi être défini en YAML ou JSON plutôt que construit entièrement en C#.

En .NET, le package correspondant est actuellement :

dotnet add package Microsoft.Agents.AI.Declarative --prerelease

Prenons un exemple directement inspiré du modèle Microsoft :

kind: Prompt

name: TechnicalReviewer

description: Agent de revue technique

instructions: |
  Tu es architecte logiciel spécialisé en .NET.
  Analyse le texte fourni.
  Identifie les problèmes techniques.
  Ne propose aucune correction qui ne soit justifiée.

model:
  options:
    temperature: 0.2

outputSchema:
  properties:

    score:
      type: integer
      required: true

    analysis:
      type: string
      required: true

On le transforme ensuite en AIAgent.

using Azure.AI.OpenAI;
using Azure.Identity;
using Microsoft.Agents.AI;
using Microsoft.Extensions.AI;

IChatClient chatClient =
    new AzureOpenAIClient(
        new Uri(endpoint),
        new DefaultAzureCredential())
    .GetChatClient(deploymentName)
    .AsIChatClient();

var factory = new ChatClientPromptAgentFactory(chatClient);

AIAgent? agent =
    await factory.CreateFromYamlAsync(yamlDefinition);

Console.WriteLine(
    await agent!.RunAsync(
        "Analyse cette proposition d'architecture."));

C’est exactement le genre de séparation que j’attendais depuis longtemps dans les frameworks agentiques.

Les instructions de production n’ont aucune raison d’être systématiquement noyées dans :

const string SystemPrompt = """
    ...
    """;

Une configuration d’agent est une configuration.

Elle peut donc devenir un artefact indépendant.

12. Déclaratif ne veut cependant pas dire absence de gouvernance

Sortir les prompts du C# n’est utile que si l’on traite ensuite correctement ces fichiers.

Un YAML agentique de production devrait être considéré presque comme du code :

agents/
    technical-review.yaml

workflows/
    invoice-validation.yaml

skills/
    dotnet-architecture/
        SKILL.md

Avec :

• versioning ;

• revue de code ;

• tests ;

• validation syntaxique ;

• validation comportementale ;

• promotion DEV → TEST → PROD ;

• audit des changements.

Changer :

temperature: 0.1

en :

temperature: 1.0

est un changement de comportement applicatif.

Modifier une instruction système est également un changement de comportement applicatif.

Le fait que cela soit du YAML ne le rend pas moins important qu’une modification de code.

13. Et maintenant les Agent Skills

Les Skills sont probablement l’autre évolution majeure de MAF.

Microsoft définit les Agent Skills comme des packages portables contenant :

• instructions ;

• ressources ;

• scripts.

Ils donnent à l’agent une expertise spécialisée sans nécessiter que toute cette information soit présente en permanence dans son contexte.

Une skill basée sur des fichiers ressemble à ceci :

dotnet-migration/
│
├── SKILL.md
│
├── references/
│   ├── migration-rules.md
│   └── compatibility.md
│
└── scripts/
    └── analyze-project.ps1

Le fichier central est :

SKILL.md

Il comporte un frontmatter YAML suivi d’instructions Markdown.

Par exemple :

---
name: dotnet-migration
description: Analyse un projet .NET Framework et prépare sa migration vers .NET moderne.
---

# Migration .NET

Lorsque tu analyses une migration :

1. Identifier le Target Framework.
2. Lister les dépendances.
3. Repérer les dépendances Windows-only.
4. Identifier les API obsolètes.
5. Évaluer la possibilité de migration incrémentale.
6. Produire un rapport structuré.

Consulte `references/compatibility.md` lorsque des problèmes
de compatibilité apparaissent.

Les détails volumineux restent dans les ressources.

Et des scripts peuvent fournir des actions déterministes.

14. La vraie bonne idée des Skills : progressive disclosure

Il ne faudrait surtout pas comprendre les skills comme :

« un nouveau moyen de coller davantage de texte dans le system prompt ».

C’est presque l’inverse.

MAF utilise un mécanisme de progressive disclosure.

Microsoft décrit quatre niveaux.

Niveau 1 — Advertise

Au départ, seuls le nom et la description de la skill sont exposés.

Environ une centaine de tokens par skill selon les recommandations Microsoft.

Par exemple :

dotnet-migration
Analyse les migrations .NET Framework vers .NET moderne.

Pas les 4 000 tokens de documentation.

Niveau 2 — Load

Si l’agent estime que la skill est pertinente, il utilise :

load_skill

Le contenu détaillé du SKILL.md est alors injecté dans le contexte.

Niveau 3 — Resources

Si l’agent a besoin d’une référence particulière, il peut appeler :

read_skill_resource

Une documentation de plusieurs dizaines de pages peut donc rester hors contexte tant qu’elle n’est pas utile.

Niveau 4 — Scripts

Enfin, lorsqu’une skill fournit du code exécutable :

run_skill_script

peut être utilisé.

Le modèle Microsoft est donc :

Description
    ↓ si nécessaire
Instructions
    ↓ si nécessaire
Ressource
    ↓ si nécessaire
Script

plutôt que :

METTONS TOUT DANS LE PROMPT !!!

C’est un énorme progrès conceptuel.

15. AgentSkillsProvider : l’architecture .NET

En C#, les skills passent par :

AgentSkillsProvider

Ce détail est important.

AgentSkillsProvider est un AIContextProvider.

Il ne s’agit donc pas d’une liste de tools collée arbitrairement à l’agent.

Le provider :

1. découvre les skills ;

2. annonce leur existence à l’agent ;

3. expose les outils nécessaires ;

4. charge leur contenu à la demande.

Pour des skills présentes sur disque :

using Microsoft.Agents.AI;

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

Puis ce provider est associé aux providers de contexte de l’agent.

La documentation actuelle insiste sur ce modèle. Il n’existe notamment pas à ce niveau une API magique WithSkills() qui transformerait simplement des skills en tools statiques.

16. Plusieurs répertoires de Skills

On peut rechercher dans plusieurs racines :

var skillsProvider =
    new AgentSkillsProvider(
        [
            Path.Combine(
                AppContext.BaseDirectory,
                "company-skills"),

            Path.Combine(
                AppContext.BaseDirectory,
                "team-skills")
        ]);

Le provider sait parcourir les répertoires et découvrir les SKILL.md.

Les options permettent également de contrôler :

• profondeur de recherche ;

• extensions des resources ;

• extensions de scripts ;

• filtrage.

La documentation actuelle mentionne par défaut des ressources comme :

.md
.json
.yaml
.yml
.csv
.xml
.txt

et des scripts :

.py
.js
.sh
.ps1
.cs
.csx

17. Les Skills ne sont pas obligatoirement des fichiers

Là encore, Microsoft ne s’est pas arrêté au cas SKILL.md.

Une skill peut provenir de plusieurs sources :

File-based
Code-defined
Class-based
MCP-based
Custom source

Côté .NET, on trouve notamment :

AgentInlineSkill
AgentClassSkill<T>
AgentFileSkillsSource
AgentInMemorySkillsSource

ainsi que la possibilité d’écrire ses propres sources.

C’est particulièrement intéressant pour une application d’entreprise.

Imaginez que les skills autorisées dépendent :

• de l’utilisateur ;

• du tenant ;

• de son rôle ;

• du client ;

• de son abonnement ;

• de l’environnement.

Une source custom peut décider dynamiquement quelles skills sont accessibles.

18. Composer plusieurs sources avec AgentSkillsProviderBuilder

Microsoft fournit également :

AgentSkillsProviderBuilder

pour agréger différentes origines.

Le principe est :

var skillsProvider =
    new AgentSkillsProviderBuilder()

        .UseFileSkill(
            Path.Combine(
                AppContext.BaseDirectory,
                "skills"))

        .UseSkill(volumeConverterSkill)

        .UseSkill(temperatureConverter)

        .Build();

Le builder permet d’appliquer des comportements comme :

• agrégation ;

• déduplication ;

• cache ;

• filtrage.

On voit ici apparaître quelque chose qui manque souvent aux premières implémentations de « skills » : une architecture de catalogue de capacités, et non simplement une collection de prompts.

19. Les Skills peuvent aussi provenir de MCP

MAF sait également découvrir des skills à travers MCP.

C’est intéressant parce que cela rapproche deux concepts différents :

MCP

Comment accéder à des outils ou ressources externes ?

Skill

Comment expliquer à l’agent quand et comment utiliser une expertise spécialisée ?

Les deux ne sont pas interchangeables.

Un serveur MCP peut exposer :

get_customer
create_invoice
search_document

Une skill peut expliquer :

Lorsque tu prépares une facture :
1. vérifie le client ;
2. récupère les conditions commerciales ;
3. applique les règles suivantes ;
4. n'émet jamais la facture sans validation...

On peut alors construire :

Skill
   |
   +--> instructions
   +--> ressources
   +--> scripts
   +--> MCP tools

C’est bien plus expressif qu’une simple liste de functions.

20. Skills et tools : ne pas confondre

Une function tool expose une capacité technique :

GetWeather("Paris")

Une skill décrit une compétence.

Elle peut dire :

Lorsque tu réalises une analyse météorologique agricole :

1. récupère température et hygrométrie ;
2. compare-les aux seuils agronomiques ;
3. applique les règles du document X ;
4. génère le résultat au format Y.

La différence est donc essentiellement :

Tool  = opération

Skill = savoir-faire

Un agent sans skill mais avec 80 tools possède 80 boutons sans forcément savoir précisément comment les combiner.

Une skill fournit la procédure, les références et éventuellement les opérations nécessaires.

21. Skills ou workflows ?

La question suivante arrive naturellement :

Si une skill contient une procédure, pourquoi créer encore un workflow ?

Parce que leur niveau de garantie n’est pas identique.

Une skill guide l’agent.

Un workflow contrôle l’exécution.

Exemple de skill :

Pour traiter une demande de remboursement :

1. vérifier la commande ;
2. vérifier la date ;
3. vérifier les conditions ;
4. demander validation au-delà de 500 € ;
5. rembourser.

Le LLM reste chargé d’appliquer ces instructions.

Dans un workflow :

CheckOrder
   |
CheckDate
   |
CheckPolicy
   |
 amount > 500 ?
   |       |
  oui     non
   |       |
Approval   |
   +-------+
      |
   Refund

la structure elle-même impose l’enchaînement.

Pour un processus réglementé, financier ou destructif, je préfère largement la seconde approche.

La documentation Microsoft distingue d’ailleurs explicitement les cas d’usage des skills et des workflows.

22. Et les deux peuvent évidemment être combinés

C’est là que l’architecture devient vraiment puissante.

Imaginons :

Workflow
   |
   +--> Analyse technique
   |       |
   |       +--> Agent
   |              |
   |              +--> Skill .NET Migration
   |
   +--> Analyse sécurité
   |       |
   |       +--> Agent
   |              |
   |              +--> Skill Secure Coding
   |
   +--> Validation humaine
   |
   +--> Rapport final

Le workflow contrôle :

• ordre ;

• branches ;

• checkpointing ;

• approbations.

Les agents effectuent les opérations nécessitant de l’intelligence.

Les skills leur fournissent l’expertise.

Les tools et MCP donnent accès au monde extérieur.

On commence à obtenir une architecture très lisible :

               PROCESSUS
              Workflow
                  |
       +----------+----------+
       |                     |
    Agent                  Code
       |
    Skills
       |
 +-----+------+
 |            |
Tools        Resources
 |
MCP / APIs

23. Arrive ensuite AG-UI

Une fois que nous savons créer un agent sophistiqué, une autre question apparaît :

Comment l’exposer proprement à une application cliente ?

Une API REST traditionnelle peut évidemment fonctionner.

Mais un agent moderne ne renvoie pas nécessairement seulement :

{
  "answer": "Bonjour"
}

Il peut produire :

• streaming de texte ;

• appels de tools ;

• progression ;

• demandes d’approbation ;

• état ;

• événements ;

• UI générative.

C’est précisément le problème auquel répond AG-UI.

Agent Framework dispose désormais d’une intégration documentée avec ce protocole.

24. AG-UI n’est pas une bibliothèque graphique

Le nom peut prêter à confusion.

AG-UI est avant tout un protocole standardisé de communication entre un agent et une interface utilisateur.

La documentation Microsoft mentionne notamment :

• hébergement distant ;

• streaming temps réel ;

• communication standardisée ;

• gestion des sessions ;

• human-in-the-loop ;

• synchronisation d’état ;

• rendu de composants interactifs.

L’architecture devient :

┌─────────────────┐
│ Web / App       │
│ Client AG-UI    │
└────────┬────────┘
         │
       HTTP
       + SSE
         │
┌────────▼────────┐
│ Endpoint AG-UI  │
└────────┬────────┘
         │
┌────────▼────────┐
│ AIAgent / MAF   │
└────────┬────────┘
         │
      LLM / tools

25. Héberger un agent AG-UI en ASP.NET Core

Au 14 août 2026, la documentation Microsoft fournit pour .NET un exemple particulièrement compact.

Installation :

dotnet add package \
    Microsoft.Agents.AI.Hosting.AGUI.AspNetCore \
    --prerelease

Puis :

using Microsoft.Agents.AI;
using Microsoft.Agents.AI.Hosting.AGUI.AspNetCore;

WebApplicationBuilder builder =
    WebApplication.CreateBuilder(args);

builder.Services.AddAGUIServer();

AIAgent agent = CreateAgent();

WebApplication app = builder.Build();

app.MapAGUIServer("/", agent);

await app.RunAsync();

Oui, l’essentiel tient presque dans :

builder.Services.AddAGUIServer();

app.MapAGUIServer("/", agent);

L’endpoint reçoit les requêtes AG-UI et diffuse les réponses de l’agent sous forme d’événements SSE.

26. Client .NET AG-UI

Le SDK propose également un client :

dotnet add package AGUI.Client --prerelease
dotnet add package Microsoft.Agents.AI --prerelease

Puis :

using AGUI.Abstractions;
using AGUI.Client;
using Microsoft.Agents.AI;
using Microsoft.Extensions.AI;

using HttpClient httpClient = new()
{
    BaseAddress =
        new Uri("http://localhost:8888")
};

AGUIChatClient chatClient =
    new(
        new AGUIChatClientOptions(
            httpClient,
            "/"));

AIAgent remoteAgent =
    chatClient.AsAIAgent();

AgentSession session =
    await remoteAgent.CreateSessionAsync();

await foreach (
    AgentResponseUpdate update in
    remoteAgent.RunStreamingAsync(
        "Bonjour",
        session))
{
    foreach (
        TextContent text in
        update.Contents.OfType<TextContent>())
    {
        Console.Write(text.Text);
    }
}

Le détail architectural remarquable est celui-ci :

chatClient.AsAIAgent();

L’agent distant redevient localement une abstraction AIAgent.

On peut donc écrire du code qui manipule un agent sans nécessairement savoir qu’il s’exécute dans un autre processus.

27. Que transporte AG-UI ?

AG-UI utilise notamment :

HTTP POST
+
Server-Sent Events
+
JSON

Microsoft documente entre autres des événements tels que :

RUN_STARTED
TEXT_MESSAGE_START
TEXT_MESSAGE_CONTENT
TEXT_MESSAGE_END
RUN_FINISHED
RUN_ERROR

Le streaming ressemble conceptuellement à :

data: {
  "type": "RUN_STARTED",
  "threadId": "...",
  "runId": "..."
}

data: {
  "type": "TEXT_MESSAGE_CONTENT",
  "messageId": "...",
  "delta": "Bonjour"
}

data: {
  "type": "RUN_FINISHED",
  "threadId": "...",
  "runId": "..."
}

On dispose donc d’un protocole événementiel bien plus approprié à un agent qu’un simple endpoint :

POST /ask

qui bloquerait trente secondes avant de retourner une chaîne de caractères.

28. AG-UI supporte beaucoup plus que le texte

La documentation MAF actuelle indique que l’intégration couvre les principales capacités d’AG-UI :

• agentic chat ;

• tools exécutés côté backend ;

• human-in-the-loop ;

• agentic generative UI ;

• tool-based generative UI ;

• shared state ;

• predictive state updates.

Autrement dit, le protocole sert également à représenter ce qui se passe pendant l’exécution.

C’est particulièrement pertinent pour un workflow :

Analyse du document       OK
Vérification fournisseur  OK
Contrôle financier        EN COURS
Validation humaine        EN ATTENTE

Une application agentique sérieuse a besoin de ce genre de visibilité.

Afficher uniquement :

L'agent réfléchit...

pendant quarante secondes devient rapidement insuffisant.

29. Attention néanmoins : AG-UI reste en évolution

Il faut ici éviter tout enthousiasme excessif.

La documentation Microsoft classe actuellement AG-UI dans les intégrations Preview.

Microsoft avertit également que le protocole continue d’évoluer.

Et il existe encore des différences de disponibilité entre Python et .NET.

La page consacrée à Workflows with AG-UI indique notamment que le support complet des workflows dans l’intégration AG-UI .NET est encore annoncé comme « coming soon » sur cette partie spécifique de la documentation.

Il faut donc distinguer :

AIAgent + AG-UI en .NET
    → documenté et disponible en preview

Toutes les fonctions avancées
Workflow + AG-UI
    → encore inégalement disponibles selon le SDK

C’est exactement le genre de détail à vérifier avant de bâtir une architecture de production.

30. Sessions : threadId n’est pas un mécanisme de sécurité

Autre détail intéressant de la documentation récente.

AG-UI utilise notamment :

threadId
parentRunId

pour représenter la continuité des conversations.

Mais Microsoft précise explicitement que ces identifiants sont des données de protocole, pas des credentials d’autorisation.

C’est important.

Ne construisez jamais un système du genre :

if (threadId == knownThread)
{
    AllowAccess();
}

Le contrôle d’identité, de tenant et d’autorisation doit rester indépendant de l’identifiant conversationnel.

31. Sécurité des Skills : le sujet que l’on ne doit surtout pas ignorer

Les skills peuvent charger des instructions.

Mais elles peuvent également charger des fichiers et exécuter des scripts.

Dès que l’on voit :

run_skill_script

il faut immédiatement arrêter de penser uniquement à l’IA et revenir aux fondamentaux de la sécurité informatique.

Une skill provenant d’une source non maîtrisée peut constituer une surface d’attaque.

Microsoft recommande notamment pour l’exécution de scripts en production :

• sandbox ;

• limitation CPU ;

• limitation mémoire ;

• timeout ;

• validation des entrées ;

• allow-list ;

• journalisation ;

• audit.

En d’autres termes :

SKILL.md téléchargé sur Internet
+
script PowerShell
+
droits du processus serveur

n’est pas une architecture.

C’est un incident de sécurité en attente de son heure.

32. L’approbation des tools est activée par défaut pour les Skills

MAF adopte d’ailleurs une attitude prudente.

Les tools associés au provider de skills :

load_skill
read_skill_resource
run_skill_script

nécessitent par défaut une approbation.

L’application peut ensuite définir des règles d’auto-approbation pour les opérations considérées comme sûres.

C’est une excellente décision.

On peut par exemple considérer que :

load_skill
read_skill_resource

sont autorisés automatiquement,

mais conserver :

run_skill_script

derrière une politique plus stricte.

33. Le système complet commence à devenir très intéressant

En combinant les briques actuelles, on peut envisager une application ayant cette architecture :

                         ┌───────────────┐
                         │  Application  │
                         │    Web UI     │
                         └───────┬───────┘
                                 │
                              AG-UI
                                 │
                     ┌───────────▼───────────┐
                     │ ASP.NET Core Hosting  │
                     └───────────┬───────────┘
                                 │
                         ┌───────▼───────┐
                         │   Workflow    │
                         │ YAML / Graph  │
                         └───────┬───────┘
                                 │
                ┌────────────────┼────────────────┐
                │                │                │
             Agent A          Code C#          Agent B
                │                                 │
           SkillsProvider                    SkillsProvider
                │                                 │
       ┌────────┼────────┐               ┌────────┼────────┐
       │        │        │               │        │        │
     Skill    Skill     MCP             Skill    Skill     MCP
       │
  ┌────┴─────┐
  │          │
Resources Scripts

Chaque niveau a alors une responsabilité identifiable.

AG-UI

Communication avec le frontend.

Workflow

Contrôle du processus.

Agent

Raisonnement dynamique.

Skill

Expertise spécialisée.

Tool

Opération atomique.

MCP

Interopérabilité avec capacités externes.

Code C#

Logique déterministe.

C’est probablement la meilleure manière de comprendre la direction prise par Microsoft Agent Framework.

34. Ce que cela change pour l’architecture d’une application .NET

Pendant quelque temps, les applications agentiques ont eu tendance à ressembler à :

var prompt = """
    Tu es un agent qui...
    Premièrement...
    Deuxièmement...
    Troisièmement...
    Si jamais...
    N'oublie jamais...
    Tu disposes des fonctions suivantes...
    """;

puis :

await agent.RunAsync(prompt);

Cette période doit se terminer.

Nous disposons maintenant de mécanismes dédiés.

Les responsabilités peuvent être réparties ainsi :

Cette séparation rend les applications agentiques beaucoup plus raisonnables à maintenir.

35. Ce que je continuerais de laisser en C#

Tout n’a évidemment pas vocation à devenir YAML, skill ou agent.

Je conserverais sans hésitation en C# :

• règles métier déterministes ;

• calculs ;

• validation ;

• sécurité ;

• autorisation ;

• transformations ;

• contrats de données ;

• orchestration très algorithmique ;

• accès aux systèmes internes ;

• contrôle transactionnel.

Par exemple :

public bool CanRefund(
    Order order,
    User user)
{
    return
        order.Status == OrderStatus.Paid &&
        order.PaymentDate >= DateTime.UtcNow.AddDays(-30) &&
        user.Permissions.Contains(
            Permission.Refund);
}

Ce code ne gagnerait absolument rien à devenir :

"Demande à un LLM si le remboursement semble approprié."

L’IA doit être utilisée là où l’incertitude est utile.

Pas là où elle détruit les garanties que nous possédions déjà.

36. Ce que je placerais dans une Skill

Une skill est idéale pour encoder une expertise comme :

Comment auditer une application .NET Framework avant migration ?

Elle pourrait contenir :

SKILL.md

references/
    framework-compatibility.md
    migration-strategies.md
    known-blockers.md

scripts/
    analyze-project.ps1

L’agent charge la skill uniquement lorsqu’il détecte une mission de migration.

Il peut ensuite lire :

known-blockers.md

uniquement si nécessaire.

Enfin il peut utiliser :

analyze-project.ps1

pour obtenir des informations factuelles plutôt que d’essayer de deviner le contenu du projet.

Cette architecture est infiniment supérieure à un system prompt de 25 000 tokens contenant tout ce que l’organisation sait sur .NET.

37. Ce que je placerais dans un Workflow

Continuons avec cette mission de migration.

Le workflow pourrait imposer :

1. Inventaire solution
2. Analyse dépendances
3. Analyse projets
4. Classification des risques
5. Analyse IA
6. Validation architecte
7. Génération du rapport

Certains executors seraient déterministes.

D’autres appelleraient un agent spécialisé.

Par exemple :

InventoryExecutor        -> C#
DependencyExecutor       -> C#
ArchitectureAgent        -> IA + Skill
SecurityAgent            -> IA + Skill
HumanApprovalExecutor    -> humain
ReportAgent              -> IA

Le LLM reste extrêmement utile.

Il n’est simplement plus responsable de décider si l’étape 3 doit se produire avant l’étape 6.

38. Ce que je placerais dans le YAML

Le YAML convient particulièrement bien aux éléments que l’on souhaite pouvoir faire évoluer indépendamment du code :

ordre des étapes ;
agent à appeler ;
routage ;
conditions simples ;
paramètres ;
instructions ;
modèle ;
température ;
output schema.

Cela permet d’imaginer une CI/CD où :

Code
+
Agents YAML
+
Workflows YAML
+
Skills

constituent ensemble la version du système agentique.

C’est un changement de perspective important.

L’application agentique n’est plus seulement son assembly.

39. Des prompts aux artefacts agentiques

Je pense que c’est finalement ce que montrent toutes ces évolutions.

Nous avons commencé avec :

un prompt

Puis :

prompt + tools

Puis :

agent + tools

Puis :

agents + orchestration

Et nous arrivons maintenant à :

agents
workflows
skills
resources
tools
MCP
protocoles UI
état
approbations
télémétrie

Le prompt reste essentiel.

Mais il n’est plus l’architecture.

40. Conclusion

Microsoft Agent Framework commence à atteindre un niveau de maturité conceptuelle particulièrement intéressant.

Pas nécessairement une maturité complète des API — plusieurs packages et intégrations restent explicitement en preview — mais une maturité architecturale.

La distinction devient beaucoup plus nette :

Agent
    = intelligence dynamique

Workflow
    = orchestration contrôlée

YAML
    = description déclarative

Skill
    = expertise chargeable

Tool
    = capacité opérationnelle

MCP
    = protocole d'intégration des capacités

AG-UI
    = protocole d'interaction avec l'interface

Et cette séparation est saine.

Elle réduit l’un des principaux travers de l’agentique actuel : essayer de résoudre tous les problèmes avec davantage de prompt.

Un système de production ne devrait pas demander au LLM de mémoriser la totalité des règles métier, de déterminer seul l’ordre des opérations, de découvrir les outils, de gérer les autorisations, d’orchestrer plusieurs spécialistes et d’expliquer son état à l’interface utilisateur.

Nous savons depuis des décennies construire des logiciels en séparant les responsabilités.

L’arrivée des LLM ne constitue pas une raison valable pour oublier ces principes.

Au contraire.

Agent Framework devient intéressant précisément parce qu’il commence à remettre une architecture logicielle autour du modèle.

Et pour un développeur .NET, c’est probablement beaucoup plus important que l’arrivée d’une énième méthode RunAsync().

C'était un peu long aujourd'hui mais cela en valait la peine ! Les annonces sont très techniques et seront à prendre en compte dès que ces nouveautés auront eu un peu le temps de dévenir stables. Mais ça avance, et vite ! Raison de plus pour...

Stay Tuned !

Références Microsoft

Les informations techniques de cet article ont été vérifiées sur la documentation Microsoft Agent Framework disponible au 24 août 2026.

Microsoft Agent Framework — Overview
Présentation actuelle des agents, harness et workflows et positionnement de MAF comme successeur de Semantic Kernel et AutoGen.

Microsoft Agent Framework — Workflows
Concepts fondamentaux, différence agent/workflow, executors, edges, checkpointing et orchestration multi-agent.

Workflow Builder & Execution
API .NET WorkflowBuilder, graphes, exécution et supersteps.

Declarative Workflows
Syntaxe YAML, actions, expressions, agents, tools, MCP, human-in-the-loop et packages .NET déclaratifs.

Declarative Agents
Définition d’un AIAgent en YAML ou JSON avec Microsoft.Agents.AI.Declarative et CreateFromYamlAsync.

Agent Skills
Architecture des skills, SKILL.md, progressive disclosure, resources, scripts, sources, AgentSkillsProvider, sécurité et approbations.

AG-UI Integration with Agent Framework
Architecture AG-UI, streaming, state, human-in-the-loop et fonctionnalités supportées.

Getting Started with AG-UI
Exemple ASP.NET Core actuel avec AddAGUIServer, MapAGUIServer, client .NET et AGUIChatClient. Page mise à jour le 14 août 2026.

Workflows with AG-UI
Intégration workflow/AG-UI et état actuel du support selon les SDK.