La façon la plus rapide de gaspiller un trimestre d'ingénierie est de construire un agent quand un workflow aurait suffi. La façon la plus lente de livrer quelque chose d'utile est de construire un workflow quand le travail demande vraiment un agent.
Nous avons livré les deux, et nous avons livré le mauvais. Voici la forme de la question que nous nous posons désormais avant de toucher au code.
Les workflows sont le défaut
Un workflow est une série d'étapes avec un branchement explicite. Vous écrivez la logique. Le système l'exécute de la même façon à chaque fois. Quand quelque chose casse, vous pouvez pointer la ligne.
Si vous pouvez décrire le travail comme un organigramme et que l'organigramme n'est pas embarrassant de grand, construisez un workflow. Ils sont moins chers à écrire, moins chers à déboguer, et les personnes qui vous remplaceront dans trois ans vous remercieront.
Le piège : "décrivable comme un organigramme" exige une vraie
honnêteté. Un organigramme avec 47 branches et quatre cas default
qui veulent dire "demander à Sarah" n'est pas un workflow — c'est un
workflow qui essaie d'échapper à sa propre peau.
Les agents sont pour le jugement irréductible
On tend la main vers un agent quand le travail a deux propriétés :
- L'espace des inputs est trop large pour être énuméré à l'avance.
- Il y a un jugement dans la boucle qui ne se compresse pas en règles.
Le support client est l'exemple classique. Vous pouvez écrire des règles pour les quatre-vingt-dix cas évidents. Les dix pour cent restants sont la raison pour laquelle votre équipe est épuisée. Un agent gagne sa place dans ces dix pour cent — et sur les quatre-vingt- dix ennuyeux, vous l'enveloppez dans un workflow.
Le terrain intermédiaire que les gens ratent
La plupart de ce que nous construisons n'est ni un workflow pur ni un agent pur. C'est un workflow avec un petit agent dans une étape : l'étape qui exige du jugement, de la récupération, ou de la reformulation.
Cette forme hybride a deux énormes avantages :
- L'observabilité reste saine. Vous pouvez toujours pointer la ligne où ça a cassé. L'agent ne décide pas quoi faire ensuite — il décide une chose précise à l'intérieur d'une étape connue.
- Vous pouvez remplacer l'agent plus tard. Quand le modèle s'améliore, ou quand votre jugement se compresse en règles, vous échangez l'étape.
Si vous pouvez décomposer le travail en un workflow où l'agent ne gère qu'une ou deux étapes, faites-le. La boucle d'agent pur est rarement la bonne réponse.
Les questions que nous posons d'abord
Quand une équipe vient à nous, avant de suggérer quoi que ce soit, nous passons en revue :
- Pouvez-vous me donner les règles ? Si oui, c'est un workflow. Si "eh bien, ça dépend de la situation" — nous nous rapprochons d'un agent.
- Quel est le coût d'une mauvaise réponse ? Coûts plus élevés signifient plus de garde-fous, plus de human-in-the-loop, plus de forme déterministe.
- À quelle fréquence le travail change-t-il ? Règles volatiles → agents (ils généralisent). Règles stables → workflows (ils sont bon marché à maintenir).
- Qui en sera propriétaire après notre départ ? Si l'équipe ne peut pas maintenir un service Python, nous ne devrions pas leur en construire un. Le bon outil est celui qu'ils peuvent faire tourner un mardi matin.
Une heuristique utile
Si vous pouvez imaginer un Notion qui décrit tout le processus en moins d'une page, c'est un workflow.
Si le processus s'échappe constamment du document — si chaque trimestre l'équipe demande "attendez, on fait toujours comme ça ?" — il y a un problème en forme d'agent caché dedans. Trouvez-le.