Проблема
Multi-tenant агенти ламаються передбачувано:
- дані одного tenant потрапляють у контекст іншого,
- tool call виконується з неправильними credentials,
- ретраї множать writes, бо немає idempotency,
- логів недостатньо, щоб довести що саме сталося.
Це рідко проблема моделі. Майже завжди бракує ізоляції в runtime.
Необхідні умови
1) Прив’язати tenant-контекст до запуску
Ідентичність tenant має йти з auth + routing — не від моделі.
2) Скейпити кожен tool call до tenant
Інструменти мають отримувати tenant-scoped credentials і tenant-scoped resource IDs.
3) Розділяти state (і кеші) по tenant
Memory, artifacts і кеші мають бути keyed по tenant (і часто по environment).
4) Per-tenant budgets і rate limits
Budgets і rate limits мають бути per-tenant, щоб один tenant не спалив бюджет усього системного пулу.
Діаграма (tenant-scoped tool gateway)
Типові failure modes
- Credential bleed: спільні API keys або глобальні клієнти, що перевикористовуються між tenant.
- Cache bleed: retrieval-кеші keyed лише по URL/query, а не по tenant.
- Write duplication: ретраї без idempotency keys.
- Silent partial writes: крок N записав успішно, крок N+1 впав → неконсистентний стан.
Мінімальні контролі для релізу
- Default-deny allowlists, scoped по tenant і environment.
- Idempotency keys для всіх write-операцій.
- Per-tenant budgets (steps/seconds/$) + per-tenant rate limits.
- Повні трейси з tenant_id + stop_reason для кожного запуску.