Anti-Pattern Giant System Prompt : prompt système géant

Idée en 30 secondes

Giant System Prompt est un anti-pattern où l'on tente de mettre presque toute la logique de l'agent dans un seul grand system prompt.

Résultat : les instructions entrent en conflit, les priorités deviennent floues, et le comportement du modèle devient instable. Cela augmente latency, cost et le risque de régressions après de petites modifications.

Règle simple : le system prompt doit rester court et stable, tandis que la logique variable doit aller dans des blocs de route, des couches policy et une validation output dans le code. Le system prompt doit définir le rôle et les règles de base, mais ne doit pas contenir toute la logique métier du système.

Exemple de l'anti-pattern

L'équipe construit un agent support et ajoute progressivement de nouvelles règles dans un seul system prompt.

Avec le temps, ce prompt devient un bloc géant d'instructions pour tous les scénarios à la fois.

SYSTEM_PROMPT = """
You are support agent.
- Always be brief.
- Always provide detailed step-by-step explanation.
- Never call tools unless user asks.
- For payment issues always call get_payment_status.
- Reply only in strict JSON.
- Prefer natural text if JSON looks unnatural.
... hundreds of lines ...
"""

response = agent.run(
    system_prompt=SYSTEM_PROMPT,
    user_message=user_message,
)

Dans ce schéma, le modèle voit trop d'instructions avec des priorités concurrentes :

always_be_brief + give_step_by_step_explanation
json_only + prefer_natural_text
never_call_tools + always_call_payment_tool

Pour ce cas, il vaut mieux un prompt de base court et des blocs route-specific séparés :

system_prompt = BASE_PROMPT + ROUTE_PROMPTS[route]

Ici, un giant prompt ajoute :

• des conflits entre règles
• une maintenance difficile après changements
• un format et un ton de réponse instables

Pourquoi cela arrive et ce qui se passe mal

Cet anti-pattern apparaît souvent quand l'équipe veut "tout résoudre rapidement par prompt" sans frontière claire entre instructions, policy et logique runtime.

Causes typiques :

• chaque nouvel incident est "corrigé" par une ligne en plus dans le system prompt
• pas de modularité : un prompt pour toutes les routes
• les règles policy vivent dans le texte du prompt, pas dans le code
• pas de propriétaires clairs ni de versioning des blocs prompt

Cela crée des problèmes :

• conflit d'instructions - le prompt contient des règles contradictoires en même temps
• comportement instable - une même demande peut produire style et format différents
• latency et cost plus élevés - un prompt long augmente les tokens à chaque run
• fragilité des changements - une petite modification peut casser d'autres scénarios
• debug difficile - difficile d'identifier quelle règle a réellement été appliquée

Signaux production typiques indiquant que le system prompt est déjà trop grand :

• un changement de règle crée une régression sur une autre route
• le cost per request augmente à cause d'un prompt long et inchangé
• l'équipe ne peut pas expliquer rapidement la priorité entre deux instructions en conflit
• après une petite modification du prompt, le success rate baisse sur une partie des cas

Le choix d'outil, de format et de style fait partie de l'inference LLM. Quand le prompt contient trop d'instructions hétérogènes, le nombre d'interprétations possibles augmente, et le modèle choisit plus souvent une règle qui convient formellement mais n'est pas la meilleure pour cette route.

Quand ce schéma grossit, sans trace et visualisation d'exécution, il devient difficile de comprendre quel bloc prompt a été utilisé dans un run concret et quelle règle a influencé le comportement du modèle.

Bonne approche

Commencez avec un system prompt court et stable qui définit le rôle et les règles de base. Déplacez la logique variable dans des blocs de route, des policy gates et des vérifications output dans le code.

Cadre pratique :

• gardez un petit BASE_PROMPT pour les règles communes
• ajoutez ROUTE_PROMPTS seulement pour des types de tâches précis
• implémentez policy et contraintes dans le code, pas dans un texte géant
• validez output et mesurez l'effet des changements (par exemple, amélioration de success rate sans forte hausse de latency et de cost per request)

Par exemple, le format de réponse doit être vérifié via schema validation avant de retourner le résultat.

BASE_PROMPT = """
You are a support agent.
Follow safety and output rules.
"""  # stable instructions shared across all routes

ROUTE_PROMPTS = {
    "payment": "Use payment policy. Return strict JSON.",
    "refund": "Use refund policy. Ask clarifying question if needed.",
}

def run_support_agent(user_message: str):
    route = classify_intent(user_message)  # simple classifier or rules
    system_prompt = BASE_PROMPT + "\n\n" + ROUTE_PROMPTS[route]

    response = agent.run(
        system_prompt=system_prompt,
        user_message=user_message,
    )

    if not validate_output(response):  # schema / required fields / safety checks
        return stop("invalid_output")

    return response

Dans ce schéma, les règles deviennent plus transparentes : plus facile de mettre à jour une route précise et moins de risques de casser des scénarios voisins.

Test rapide

Si vous répondez "oui" à ces questions, vous avez un risque giant-system-prompt :

• Un system prompt essaie-t-il de couvrir presque tous les scénarios à la fois ?
• Une petite modification de prompt crée-t-elle souvent des régressions latérales dans d'autres cas ?
• Est-il difficile d'identifier quelle règle a la priorité dans un conflit ?

Différence avec les autres anti-patterns

Overengineering Agents vs Giant System Prompt

Too Many Tools vs Giant System Prompt

Agents Without Guardrails vs Giant System Prompt

Auto-vérification : avez-vous cet anti-pattern ?

Vérification rapide de l'anti-pattern Giant System Prompt.
Cochez les points pour votre système et regardez le statut ci-dessous.

Vérifiez votre système :

FAQ

Q : Un system prompt long est-il toujours mauvais ?
R : Non. Le problème n'est pas la longueur en soi, mais la structure monolithique et les conflits. Si le prompt grandit mais reste modulaire avec des priorités claires, les risques sont nettement plus faibles.

Q : Quand faut-il déplacer une règle du prompt vers le code ?
R : Quand la règle est critique pour la sécurité, le coût ou la stabilité de format. Ces contraintes doivent être implémentées comme vérifications runtime explicites, pas seulement comme instruction textuelle.

Q : Comment passer d'un giant prompt à un schéma modulaire sans gros refactor ?
R : Commencez petit : extrayez BASE_PROMPT, ajoutez 1-2 blocs route-specific pour les cas les plus fréquents, puis déplacez progressivement les règles policy du prompt vers des gates dans le code.

Et ensuite

Anti-patterns proches :

• Overengineering Agents - quand la complexité croît plus vite que la valeur.
• Too Many Tools - quand le bruit de choix d'outils rend le comportement instable.
• Agent Everywhere Problem - quand un agent est utilisé même pour des tâches déterministes.

Ce qu'il faut construire à la place :

• Allowed Actions - comment imposer des limites d'actions dans le code.
• Routing Agent - comment séparer les routes et donner des instructions pertinentes.
• Policy Boundaries in Architecture - comment déplacer policy du prompt vers des frontières d'architecture explicites.