J'ai construit un agent pour la 4ème fois la semaine dernière

J'ai construit un agent pour la 4ème fois la semaine dernière.

Même schéma : tools, MCP, HITL, sub-agents, observabilité, persistance de threads. 400 lignes de glue code que j'avais déjà écrites 3 fois avant.

C'est à ce moment-là que j'ai compris que le problème c'était pas l'agent. C'était moi qui réinventais la roue.

Les archis ont convergées

Les archis d'agents ont convergées. Quel que soit le use case (extracteur de données immo, code reviewer, assistant RAG, agent commercial), tu retrouves le même squelette.

Model + system prompt + tools + MCP servers + sous-agents + interrupt rules + middleware d'observabilité.

Toujours. La seule chose qui change, c'est la config.

Je devais tester plusieurs hypothèses pour un client, j'ai donc encapsulé tout ça dans un framework maison.

L'idée : tu déclares ton agent dans un YAML de 20 lignes, le framework s'occupe du reste (create_deep_agent, streaming SSE, persistance PostgreSQL, tool resolution, MCP, sub-agents, prompt management via Phoenix).

Un agent aujourd'hui ressemble à ça :

name: haiku-files
model: openai:anthropic/claude-haiku-4.5:nitro
mcp_servers:
  - name: my-mcp
    url: https://awsomemcp/your/mcp
    headers: { X-API-Key: ${AWESEOME_API_KEY} }

Le YAML fait 20 lignes. Tout le reste (thread persistence, streaming, tool loader, MCP lifecycle) est dans le framework.

Puis le marché a rattrapé

Des solutions plus sérieuses sont arrivées, dont Docker Agent et Kagent spécifique à Kubernetes.

Elles font exactement la même chose (déclarer un agent, l'encapsuler dans des comportements standards).

Ce qui devrait arriver, arriva — des acteurs plus gros ont produit des outils meilleurs que le mien.

C'est le jeu de l'open source. Tu livres, tu apprends, et quand le géant sort la même chose, tu sais que finalement l'idée n'était pas si mauvaise.

Mon repo en commentaire. Docker Agent et Kagent en alternative si vous voulez du plus industrialisé.