Normal path: execute → tool → observe.
Le problème (côté prod)
Tout allait bien.
Puis ton agent est devenu “plus intelligent” en ajoutant du contexte :
- plus d’historique
- plus d’output de tools
- plus de “helpful context”
Latence et coût montent. Et ensuite, la policy se fait tronquer et l’agent agit bizarrement.
Pourquoi ça casse en prod
- le contexte grossit par défaut
- la troncature tue le haut du prompt (souvent la policy)
- outputs de tools = bombes à tokens (HTML/logs)
- memory ≠ prompt (stocker ≠ montrer)
Exemple d’implémentation (code réel)
Budgeter cheap (chars) + summarization placeholder :
from dataclasses import dataclass
from typing import Iterable
@dataclass(frozen=True)
class ContextBudget:
max_chars: int = 12_000
def summarize(text: str) -> str:
return text[:2000] + "…"
def build_context(chunks: Iterable[str], *, budget: ContextBudget) -> str:
ctx = "\n\n".join(list(chunks))
if len(ctx) <= budget.max_chars:
return ctx
over = len(ctx) - budget.max_chars
head = ctx[: over + 1000]
tail = ctx[over + 1000 :]
return summarize(head) + "\n\n" + tailexport function summarize(text) {
return text.slice(0, 2000) + "…";
}
export function buildContext(chunks, { maxChars = 12_000 } = {}) {
const ctx = chunks.join("\\n\\n");
if (ctx.length <= maxChars) return ctx;
const over = ctx.length - maxChars;
const head = ctx.slice(0, over + 1000);
const tail = ctx.slice(over + 1000);
return summarize(head) + "\\n\\n" + tail;
}Incident réel (avec chiffres)
Agent “debug job failure” qui collait logs + stack traces dans le prompt. Un client a collé un blob de logs de 2MB.
Impact :
- tokens/request : 4k → 45k
- latence p95 : 3.2s → 19s
- spend : ~$520 sur une journée
- truncation a drop la policy → suggestions de tools pas safe
Fix :
- cap sur input utilisateur
- extraction structurée (erreurs/timestamps) au lieu de dumps bruts
- budget de contexte + tier de summarization
- métriques/alertes tokens/request
Compromis
- summaries = perte de détails (souvent acceptable)
- caps peuvent frustrer certains users → propose async upload
- compter les tokens ajoute de la complexité (ça paie vite)
Quand NE PAS l’utiliser
- besoin d’analyse exacte sur long docs → retrieval ciblé + workflows
- pas de summarization safe → ne colle pas du texte non fiable brut
- pas de mesure tokens → commence char budgets, ajoute token counting ensuite
Checklist (copier-coller)
- [ ] Cap sur input user
- [ ] Cap sur output tools
- [ ] Context builder budgeté
- [ ] Summarization tier
- [ ] Répéter policy critique à chaque tour
- [ ] Metrics: tokens, latence, spend
- [ ] Alerting sur drift/spikes
Config par défaut sûre (JSON/YAML)
context:
max_prompt_tokens: 2500
max_untrusted_chars: 8000
summarize_when_over_budget: true
policy:
repeat_critical_constraints_every_turn: true
metrics:
track: ["tokens_per_request", "latency_p95", "spend_per_run"]
FAQ (3–5)
Utilisé par les patterns
Pannes associées
Gouvernance requise
Q : Je peux juste prendre un modèle avec plus de contexte ?
R : Tu peux, mais tu paieras latence + coût, et tu tronqueras plus tard. Budgéter est plus efficace.
Q : Comment compter les tokens ?
R : Tokenizer du provider. Sinon, char caps en attendant.
Q : Je stocke tout en mémoire ?
R : Stocker events oui. Tout montrer au modèle non. Memory ≠ prompt size.
Q : Pourquoi répéter la policy ?
R : La troncature coupe le haut du prompt. La répétition garde les contraintes en vie.
Pages liées (3–6 liens)
- Foundations: Types de mémoire d’agent · Limites des LLM et agents
- Failure: Budget explosion · Sources hallucinées
- Governance: Tool permissions
- Production stack: Production stack