Observability pentru 9 agenți AI concurenți: ce vezi când latency minte
Marți dimineață, 08:00 EEST. Nouă agenți rulează în paralel pe orchestrator: p50 la 1.2s, p95 la 3.4s, dashboardul e verde. Doi clienți sună. Ce a scăpat?
Observability pentru 9 agenți AI concurenți: ce vezi când latency minte
Marți dimineață, 08:00 EEST. Nouă agenți rulează în paralel pe orchestrator: p50 la 1.2s, p95 la 3.4s, dashboardul e verde. Doi clienți sună. Ce a scăpat?
Latency-ul e metrica implicită pentru că e ieftin de măsurat. Pentru sisteme multi-agent e insuficient: un răspuns rapid de la modelul greșit costă mai mult decât o pauză de 4 secunde care rezolvă cererea. Când rulezi 9 agenți concurent — un supervisor, 7 workeri, un critic — trebuie să instrumentezi patru clase de semnale, nu una.
Cele patru semnale care contează
1. Cost per trace, nu doar tokeni per call. Un trace complet include retry-uri, hand-off-uri între agenți și call-uri de tool. Un worker cu p95 sub 2s poate consuma 47.000 de tokeni pe cerere dacă recontextualizează la fiecare hop. Atributele standardizate gen_ai.usage.input_tokens și gen_ai.request.model sunt definite în OpenTelemetry GenAI semantic conventions — fără ele, agregările pe modele sunt manuale.
2. Tool-call success rate pe agent. Un worker care apelează un search API și primește 429 tăcut degradează întregul plan fără să pice testul de sănătate. NIST AI Risk Management Framework 1.0 tratează măsurarea și gestionarea riscurilor ca funcții separate — la fel și în observability: măsori rata de eșec per tool, per agent, per model.
3. Adâncime span și convergență. Câte hop-uri până agentul decide „gata”? Când adâncimea medie sare de la 4 la 11 fără schimbare de input, ai un loop semantic. Detectezi asta doar cu tracing distribuit end-to-end.
4. Budget guardrails live. Rate limits pe provider, buget lunar pe organizație, cotă de context window per sesiune. ENISA — Multilayer Framework for Good Cybersecurity Practices for AI recomandă alarme pe consum de resurse ca semnal timpuriu pentru abuz sau agenți care intră în bucle.
Cum arată în practică
2026-09-01T14:22:07Z trace_id=8a3f... agent=supervisor span_count=4 tokens_total=12847 cost_usd=0.081 status=ok
2026-09-01T14:22:11Z trace_id=8a3f... agent=worker-3 tool=web_search retries=2 latency_ms=4210 status=degraded
2026-09-01T14:22:14Z trace_id=8a3f... agent=critic verdict=reject reason=cite_missing loop_depth=7 ALERTCele trei linii spun povești diferite. Prima e verde. A doua e „verde-galben” — merge, dar consumă retry budget. A treia e o buclă care trebuie oprită înainte să detoneze factura de luna asta.
Fiecare săgeată e un span. Fiecare span cară trace_id, agent.id, gen_ai.usage.*, tool.name, retry.count. Fără atributele astea, alertele sunt oarbe pe cea mai scumpă componentă a stack-ului.
Perspectiva CAI
Rulăm agenți concurent pe platforma noastră IRIS și lecția e simplă: dashboardele care ne-au salvat nu arată latency, ci cost per intenție rezolvată și rată de abandon pe adâncime. Un agent care termină în 800ms dar e apelat de 6 ori nu e rapid — e o scurgere. Aliniem instrumentarea cu obligațiile de logging din Regulamentul (UE) 2024/1689 (AI Act), art. 12, unde sistemele high-risk trebuie să înregistreze automat evenimentele pe toată durata de viață.
Dacă ai deja 3+ agenți în producție și vezi doar latency, poți cere un audit scurt de instrumentare pe pillarul demeter.