LLM + Action = Agent
An agent is an LLM that can call tools. Then a reasoning loop, YAML to instantiate agents, and a UI so the client can create them.
Les agents sont devenus un incontournable du monde logiciel. Ils sont partout ( presque trop ).
A l'exception faite que vous auriez potentiellement élu domicile au centre de la terre avec un accès a la civilisation extrêmement limité, vous devriez savoir ce qu'est un agent. Dans le doute, on est jamais trop prudent on va repasser sur quelques explications histoire d'être alignés.
LLM + Action = Agent
Je considère que pour qu'un bout de logiciel puisse être un agent il n'a pas beaucoup de critères à respecter.
Il vous faut un LLM qui puisse être capable d'appeler les outils adéquats depuis une phrase en langage naturel. Pas besoin de sophistication supplémentaire ou de boucle de raisonnement, à partir d'ici vous avez déjà un agent, simple certes mais tout commence à partir de là.
L'évolution de notre agent se dirige naturellement vers une boucle de raisonnement.
La plupart des agents que vous verrez reposent sur cette brique fondamentale, de chatGPT à claude code, la boucle de raisonnement est ce qui apporte toute la puissance et à ce qu'on pourrait appeler de "l'intelligence" à l'agent.
Le principe est simple, à chaque itération de boucle le LLM va se demander s'il peut répondre à la demande ou bien s'il doit appeler un outil pour obtenir l'info. Si la réponse est possible alors il va la fournir à l'appelant.
Retenez bien ça car c'est vraiment le fondamental de ce que fait un agent aujourd'hui.
Vous reprendrez bien un peu de RAG ?
J'ai été contacté par un client qui avait mis en place un RAG pour faire de l'analyse de dossiers crowdfunding immobiliers.
Le RAG mis en place ne donnait pas entière satisfaction et loupait des informations.
J'ai donc été mandaté pour améliorer ce qui est en place. En faisant quelques tests, je me suis rendu compte que je n'allais pas réussir à obtenir de bien meilleurs résultats.
Ma première reflexion c'est que le RAG est finalement assez peu adapté à mon cas d'usage, il faut pouvoir croiser des informations dans plusieurs documents et produire une réponse.
Un RAG peut louper ce genre d'informations car la réponse ne se trouve pas forcément dans un passage sémantiquement similaire. Le nombre de documents qui remontent au LLM est également limité.
J'ai estimé que ca ne valait pas le coup de continuer avec le RAG, et que je devais tester d'autres solutions.
Un YAML pour les gouverner tous
J'avais besoin de pouvoir tester rapidement plusieurs agents qui utilisaient différentes méthodes. Au même moment je regardais pas mal Deep agents, c'est une abstraction fournie par Langchain pour créer de agents autonomes.
La boucle ReAct étant déja encapsulé par langchain.
mcp = MultiServerMCPClient({
"github": {
"transport": "http",
"url": "https://mcp-anything/real-estate/mcp"
}
})
agent = create_deep_agent(
model="openai:gpt-5.5",
tools=mcp.get_tools(),
subagents=[
{
"name": "researcher",
"model": "anthropic:claude-haiku-4-5-20251001",
"description": "Recherche web",
"system_prompt": "Tu cherches."
}
],
system_prompt="Tu codes. Délègue à researcher.",
interrupt_on={"file_write": True},
)Avec quelques lignes de code, on obtient déjà un agent capable d'utiliser des outils via MCP, de déléguer à un sous-agent et de demander une validation humaine avant certaines actions.
En y regardant de plus près, on voit surtout que les éléments qui définissent notre agent sont finalement des paramètres. Il devient donc possible d'externaliser cette définition dans du YAML et d'instancier dynamiquement différents agents à partir de celle-ci.
J'ai donc fait une brique autour pour parser du YAML et instancier dynamiquement un agent.
name: haiku-rag-formation
model: openai:anthropic/claude-haiku-4.5:nitro
system_prompt: |
## Objectif
Tu es un assistant analyste immobilier...
mcp_servers:
- name: raganything
transport: http
url: https://mcp-anything/real-estate/mcp
headers:
Authorization: "Bearer ${USER_JWT}"
X-API-Key: "${USER_API_KEY}"Le bénéfice pour moi est assez clair, cela me permet d'avoir une petite usine à agents à réutiliser pour d'autres cas clients.
Et finalement..... Si le client pouvait créer ses agents lui même ?
Vous voulez une interface avec votre backend ?
Il ne manquait plus qu'une seule chose pour avoir un système complet et réutilisable, une interface utilisable par tout à chacun.
On peut finalement généraliser ce que j'avais construit pour mon client en trois briques :
┌──────────────────┐
│ Composable UI │
│ créer / utiliser│
│ les agents │
└────────┬─────────┘
│
▼
┌──────────────────┐
│ Composable Agents│
│ │
│ runtime agents │
│ subagents / HITL │
└────────┬─────────┘
│ MCP
┌────────┴─────────┐
▼ ▼
┌──────────────────┐ ┌──────────────────┐
│ MCP-RAGAnything │ │ autres MCP │
│ │ │ servers │
│ fichiers + RAG │ │ │
└──────────────────┘ └──────────────────┘Les trois briques sont indépendantes et peuvent être utilisées séparément. Ensemble, elles permettent cependant de construire une plateforme complète : une UI pour créer les agents, un runtime pour les exécuter et des services MCP pour leur fournir des capacités, notamment l'accès aux documents et au RAG.
Je pense que les agents vont progressivement devenir une nouvelle unité logicielle packagée. Pour une grande partie des cas d'usage, il n'y aura plus nécessairement besoin de réécrire leur implémentation de zéro : on pourra partir d'un agent existant, lui donner de nouvelles capacités, modifier son comportement et le composer avec d'autres.
Il restera évidemment des cas particuliers pour lesquels le code sur mesure sera nécessaire, mais ils pourraient progressivement devenir l'exception plutôt que la règle.
Créer un agent depuis une UI
N'importe quel client est désormais capable de se créer lui même des agents sans dépendre d'un provider en particulier.
Le mot de la fin
Je ne pense pas avoir anticipé l'avenir des agents.
J'ai simplement appliqué à ce problème les principes d'architecture que j'utilise déjà sur mes projets : découpler les responsabilités, rendre les composants indépendants, définir des interfaces claires et éviter de coupler l'application à une implémentation particulière.
Et finalement, quelques mois après avoir commencé ce projet, je constate que plusieurs acteurs majeurs de l'écosystème arrivent à des abstractions assez similaires.
Je ne vais évidemment pas en conclure que j'ai trouvé la bonne architecture. Mais c'est quand même une observation assez rassurante : une manière de concevoir le logiciel qui m'a semblé naturelle m'a amené vers une direction qui semble également émerger à l'échelle de l'industrie.
Liens/Références
Cette convergence n'est d'ailleurs pas uniquement une impression de ma part. LangChain décrit lui-même Deep Agents comme une abstraction permettant de construire des agents autonomes, et pousse également aujourd'hui l'idée d'agents managés.
Les repos dont il est question dans cet article :
Une version en ligne, inscription non libre il faudra me contacter : composables.soludev.tech