El problema
Los agentes multi-tenant fallan de formas previsibles:
- datos de un tenant se filtran al contexto de otro tenant,
- un tool call corre con credenciales del tenant equivocado,
- reintentos multiplican writes porque falta idempotency,
- logs demasiado pobres para probar qué pasó.
Esto rara vez es un problema del modelo. Casi siempre falta aislamiento en el runtime.
No negociables
1) Atar el contexto del tenant antes de que corra el agente
La identidad del tenant debe venir de auth + routing — no del modelo.
2) Scopar cada tool call al tenant
Las herramientas deben recibir credenciales e IDs de recursos scoppados por tenant.
3) Separar el estado (y caches) por tenant
Memory, artifacts y caches deben estar keyeados por tenant (y a menudo por entorno).
4) Budgets y rate limits por tenant
Budgets y rate limits deben ser por tenant para que uno no queme el presupuesto del sistema entero.
Diagrama (tool gateway scoppado por tenant)
Failure modes comunes
- Credential bleed: API keys compartidas o clientes globales reutilizados entre tenants.
- Cache bleed: caches de retrieval keyeados solo por URL/query, no por tenant.
- Write duplication: reintentos sin idempotency keys.
- Silent partial writes: paso N escribe ok, paso N+1 falla → estado inconsistente.
Minimum controls para shippear
- Allowlists default-deny, scoppadas por tenant y entorno.
- Idempotency keys para todos los writes.
- Budgets por tenant (steps/seconds/$) + rate limits por tenant.
- Traces completas con tenant_id + stop_reason por cada ejecución.