Planning agents et reactive agents ressemblent souvent a des concurrents, mais en pratique ce sont deux modes de pilotage du comportement agent. L'approche planning met l'accent sur un plan explicite, l'approche reactive sur l'adaptation rapide a l'etat courant.
Comparaison en 30 secondes
Planning agents sont une approche ou l'agent construit d'abord un plan (etapes, ordre, criteres de fin), puis l'execute avec des corrections controlees.
Reactive agents est une approche ou l'agent decide l'etape suivante en runtime sans long plan upfront : observe -> decide -> act.
Difference principale : l'approche planning optimise la coherence des longues taches, l'approche reactive optimise la reaction rapide aux changements de contexte.
Regle pratique : si la tache est longue et demande une sequence previsible d'actions, planning gagne souvent. Si la tache est courte, dynamique, et depend fortement de "ce qui vient de se passer", reactive gagne souvent.
Tableau comparatif
| Planning Agents | Reactive Agents | |
|---|---|---|
| Idee centrale | Plan explicite d'abord, puis execution et controle des ecarts | Etape suivante choisie depuis l'etat courant sans long plan upfront |
| Controle d'execution | Eleve : le plan peut etre valide avant demarrage, le replanning peut etre limite, et les criteres de fin (criteria of done) fixes | Potentiellement eleve, mais pas automatique : il faut des budgets stricts, des stop conditions et des policy checks a chaque etape |
| Type de workflow | Par etapes : plan -> execute step -> verify -> next step | Iteratif : observe -> decide -> act -> observe |
| Stabilite en production | Souvent plus elevee sur les longs scenarios si le plan et les criteres sont valides avant execution | Atteignable, mais pas "out of the box" : sans limites et memoire des etapes, la boucle reactive degrade vite |
| Complexite de debug | Plus faible sur longues taches : plan, ecarts et point d'echec sont visibles | Plus elevee : la chaine causale est dispersee sur beaucoup de petites decisions |
| Risques typiques | Plan obsolete, poids excessif du upfront planning, replanning loops (risque reduit avec limites de replanning) | Optimisation locale sans strategie longue, tool spam, explosion de budget |
| Quand utiliser | Longues taches avec etapes explicites, dependances, et exigences d'audit des decisions | Taches operationnelles rapides ou l'adaptation apres chaque action est critique |
| Meilleur fit quand | Vous avez besoin d'un parcours d'execution previsible et d'un controle de progression par etape | Vous avez besoin de pas rapides dans un environnement dynamique ou le plan vieillit vite |
La difference architecturale cle est l'endroit ou se prend la decision de pilotage principale : avant le demarrage de l'execution, ou a chaque etape en runtime.
Difference architecturale
Planning agents sont construits autour d'un plan explicite et d'un controle d'execution par etapes. Reactive agents sont construits autour d'une boucle de decisions rapides basee sur l'etat courant.
Analogie engineering : Planning est un itineraire avec checkpoints, validable avant depart.
Reactive est la conduite en temps reel, ou la prochaine manoeuvre depend de la situation de route actuelle.
Dans ce schema, la force est la prevision du long parcours d'execution. La faiblesse est le risque de plan obsolete.
Dans ce schema, la force est l'adaptabilite runtime. La faiblesse est le maintien plus difficile d'une strategie long-terme.
Ce que sont les Planning Agents
Planning agents sont une approche ou l'agent construit d'abord un plan de tache, puis execute les etapes avec verification explicite de la progression.
Flux typique :
request -> create plan -> validate -> execute steps -> replan (if needed) -> finalize
Exemple d'idee Planning Agents (pseudocode)
Ci-dessous, illustration de logique, pas API litterale.
KNOWN_STEP_STATUSES = {"done", "blocked", "failed", "needs_replan"}
def run_planning_agent(request):
state = init_state(request, max_steps=20, max_replans=3, budget_usd=1.4)
plan = planner.create_plan(request)
if not validate_plan(plan, max_steps=state.max_steps):
return fail("invalid_plan")
step_idx = 0
replans = 0
# Timeout global d'execution et watchdog sont geres au niveau infrastructure.
while step_idx < len(plan.steps) and state.cost_usd < state.budget_usd:
step = plan.steps[step_idx]
verdict = policy.check(step)
if verdict == "deny":
return fail("policy_denied")
if verdict == "needs_approval":
if not wait_for_human_approval(state.trace_id, timeout_sec=120):
return fail("approval_timeout")
result = executor.run(step, timeout_sec=10, retries=1)
if result.status not in KNOWN_STEP_STATUSES:
emit_trace(state.trace_id, step, "unknown_step_status")
return fail("unexpected_step_response")
emit_trace(state.trace_id, step, result.status)
if result.status == "failed":
return fail("step_failed")
if result.status == "needs_replan":
replans += 1
if replans > state.max_replans:
return fail("replan_limit_exceeded")
plan = planner.replan(state, failed_step=step)
if not validate_plan(plan, max_steps=state.max_steps):
return fail("invalid_replan")
# Apres replanning, on relance le nouveau plan depuis le debut ; boucle limitee par max_replans.
# max_steps limite la longueur d'un plan ; la borne haute totale depend du replanning
# (souvent estimee comme max_steps * (max_replans + 1)).
step_idx = 0
continue
if result.status == "blocked":
return fail("blocked_without_recovery")
state = observe(state, step, result)
step_idx += 1
if state.cost_usd >= state.budget_usd:
return fail("budget_exceeded")
if step_idx < len(plan.steps):
return fail("step_limit_or_incomplete")
return finalize(state)
La force de l'approche planning est la pilotabilite des longues taches. La faiblesse est que si le plan est faible ou obsolete, les erreurs se propagent plusieurs etapes en avant.
Ce que sont les Reactive Agents
Reactive agents est une approche ou l'agent ne garde pas un long plan fixe, et decide l'etape suivante depuis l'etat courant.
Flux typique :
request -> observe -> decide next action -> act -> observe
Exemple d'idee Reactive Agents (pseudocode)
Ci-dessous, illustration de logique, pas API litterale.
KNOWN_ACTION_STATUSES = {"ok", "blocked", "failed", "no_op"}
def run_reactive_agent(request):
state = init_state(request, max_steps=16, budget_usd=0.9)
# Timeout global de boucle et watchdog sont geres au niveau infrastructure.
while state.step < state.max_steps and state.cost_usd < state.budget_usd:
action = reactive_policy.decide(state)
if action.type == "final":
return finalize(state)
verdict = policy.check(action)
if verdict == "deny":
return fail("policy_denied")
# Approval avant action risquee pour eviter une boucle approved_retry separee apres blocked.
if verdict == "needs_approval":
if not wait_for_human_approval(state.trace_id, timeout_sec=90):
return fail("approval_timeout")
result = tool_gateway.call(action, timeout_sec=8, retries=1)
if result.status not in KNOWN_ACTION_STATUSES:
emit_trace(state.trace_id, action, "unknown_action_status")
return fail("unexpected_action_response")
emit_trace(state.trace_id, action, result.status)
if result.status == "failed":
return fail("action_failed")
if result.status == "blocked":
# blocked signifie ici un blocage d'execution externe, pas une absence d'approval.
return fail("blocked_without_recovery")
# no_op ne termine pas la boucle : arret controle par max_steps/budget/explicit final.
# observe/state update doit incrementer step pour qu'aucun retry-path ne contourne le compteur.
state = observe(state, action, result)
if state.step >= state.max_steps:
return fail("step_limit_exceeded")
if state.cost_usd >= state.budget_usd:
return fail("budget_exceeded")
return finalize(state)
La force de l'approche reactive est l'adaptation rapide au changement. La faiblesse est que sans limites dures, la boucle devient vite un essai de pas couteux et bruyant.
Quand utiliser Planning Agents
Planning agents convient quand le scenario est long, structure et sensible a l'ordre des etapes.
Convient
| Situation | Pourquoi Planning convient | |
|---|---|---|
| ✅ | Longs processus operationnels avec etapes | Un plan explicite reduit le risque de rater une etape critique au milieu du processus. |
| ✅ | Scenarios avec fortes exigences d'audit | Plan et ecarts sont facilement tracables pour investigation d'incident et compliance. |
| ✅ | Taches multi-etapes avec dependances | On peut fixer formellement l'ordre : ce qui doit etre fait avant l'etape suivante. |
| ✅ | Cas ou une erreur en milieu de route coute cher | Validation du plan avant depart reduit le risque d'improvisations dangereuses en runtime. |
Quand utiliser Reactive Agents
Reactive agents conviennent quand l'environnement change souvent et qu'une reaction locale rapide est importante.
Convient
| Situation | Pourquoi Reactive convient | |
|---|---|---|
| ✅ | Courtes taches operationnelles en temps reel | Inutile de construire un long plan si l'etat peut changer apres chaque etape. |
| ✅ | Scenarios avec reponses externes imprevisibles | La boucle reactive ajuste rapidement l'action suivante au nouveau resultat API. |
| ✅ | Premiere phase de lancement produit | Plus rapide d'obtenir une boucle operationnelle et valider la valeur avant d'investir dans un planning complexe. |
| ✅ | Scenarios avec horizon court de decision | Quand 1-3 etapes d'avance suffisent, reactive est souvent moins cher et plus simple. |
Limites de Planning Agents
L'approche planning apporte de la previsibilite, mais a ses propres risques en environnement dynamique.
| Limite | Ce qui se passe | Pourquoi cela arrive |
|---|---|---|
| Plan obsolete | L'agent continue des etapes qui ont deja perdu leur pertinence | L'etat externe a change plus vite que la mise a jour du plan |
| Poids excessif du upfront planning | Le temps jusqu'a la premiere action utile augmente | Le systeme depense trop d'etapes et de tokens dans le detail du plan |
| Replanning loops | L'agent reconstruit le plan plusieurs fois au lieu d'executer | Pas de limites dures de replanning ni de criteres de plan "suffisant" |
| Dependances fragiles entre etapes | Une erreur sur une etape initiale casse tout le parcours | Le plan contient des etapes fortement couplees sans branches fallback fiables |
| Cout eleve des erreurs de plan | Un mauvais choix de planning etend l'echec a tout le processus | Le plan est l'ancrage principal du systeme, et son defaut se propage aux actions suivantes |
Limites de Reactive Agents
L'approche reactive est flexible, mais sans discipline bascule vite en boucle instable.
| Limite | Ce qui se passe | Pourquoi cela arrive |
|---|---|---|
| Optimisation locale sans strategie longue | Chaque etape est "logique", mais le parcours final est faible | L'agent optimise l'action immediate, pas l'objectif global |
| Tool spam | Le cout et la latence montent sans gain proportionnel de qualite | Pas de budgets stricts ni de stop conditions dans la boucle |
| Actions repetees ou contradictoires | Le systeme duplique des operations d'ecriture ou fait des etapes incompatibles | Memoire d'etat faible, absence d'idempotency et de verification des actions precedentes |
| Debug difficile de la raison de decision | Incident difficile a expliquer au business ou a la compliance | Decision repartie sur beaucoup de petites etapes sans structure explicite de plan |
| Degradation silencieuse sur longues taches | La qualite baisse de facon peu visible quand la longueur du scenario augmente | L'approche reactive sans couche planning tient mal un horizon long de decision |
En pratique, une approche hybride fonctionne souvent
Scenario courant en pratique : l'automatisation des operations support en SaaS a commence comme agent reactif.
Au debut, la boucle reactive fonctionnait bien pour les taches courtes : verifier statut, recuperer donnees, repondre ou executer une action.
Puis des triggers sont apparus pour ajouter une couche planning :
- les demandes enterprise exigeaient un long parcours avec plusieurs dependances
- le nombre d'incidents a augmente, avec des etapes localement correctes mais une action finale incorrecte
- la compliance a demande une trace explicite : pourquoi cet ordre d'etapes a ete choisi
Ce qui est reste dans la boucle reactive :
- actions operationnelles courtes avec feedback rapide
- adaptation runtime apres les reponses API externes
- chemin peu couteux pour les demandes "rapides" a grand volume
Ce qui a ete deplace vers la couche planning :
- construction d'un parcours par etapes pour les cas longs
- validation du plan avant demarrage de l'execution
- limites de replanning et criteres explicites de fin (criteria of done)
Pourquoi cela a fonctionne :
- les taches courtes sont restees rapides
- les taches longues sont devenues plus previsibles et plus faciles a debugger
- l'equipe n'a pas reecrit toute la boucle, elle a seulement isole les scenarios a horizon long de decision
En bref
Planning agents, c'est un parcours coherent et le controle des longues taches.
Reactive agents, c'est l'adaptation rapide pas-a-pas dans un environnement changeant.
Regle cle : ne choisissez pas planning ou reactive comme une ideologie. Choisissez le mode de pilotage selon la nature de la tache, la longueur de l'horizon et les exigences de controle.
FAQ
Q: Que choisir d'abord : planning ou reactive ?
A: Les equipes commencent souvent par reactive pour un lancement plus rapide. Mais pour les scenarios high-risk ou auditable, planning peut etre le choix initial.
Q: Quand l'approche reactive ne suffit plus ?
A: Quand trois signaux apparaissent ensemble : la longueur des scenarios augmente, les incidents "les etapes etaient logiques, le resultat etait faux" deviennent plus frequents, et le debug exige de reconstruire des dizaines de petites decisions sans plan explicite.
Q: Quand planning est de l'overengineering ?
A: Quand la majorite du trafic est composee de taches courtes et dynamiques, et que l'equipe passe plus de temps a construire et maintenir des plans qu'a livrer de la vraie valeur utilisateur.
Q: Peut-on combiner planning et reactive dans un meme systeme ?
A: Oui, et c'est souvent la voie la plus pratique. Planning pilote souvent le "squelette" du long processus, tandis que reactive execute des etapes individuelles qui dependent de l'etat courant.
Q: Quels signaux montrent qu'il faut ajouter une couche planning ?
A: Signaux pratiques : echecs repetes au milieu de longs parcours, interventions manuelles frequentes pour corriger l'ordre des etapes, exigences de compliance sur une sequence explicable de decisions.
Q: Quel controle minimum faut-il dans les deux approches ?
A: Pour planning minimum : validation du plan, limites de replanning, criteres de fin (criteria of done), policy checks par etape, audit des ecarts. Pour reactive minimum : budgets, stop conditions, policy checks a chaque etape, memoire d'etat, idempotency et tracing.
Comparaisons liees
Si vous choisissez l'architecture d'un systeme d'agents, ces pages aident aussi :
- LLM Agents vs Workflows - quand une boucle agent est necessaire et quand workflow suffit.
- Single-Agent vs Multi-Agent - une boucle de decision versus la coordination de plusieurs agents.
- OpenAI Agents vs LangGraph - runtime gere versus controle explicite des transitions du graphe.
- LangChain vs LangGraph - composants versus graphe d'etats formalise.
- RAG vs Agents - knowledge pipeline versus decision loop.