Diez minutos no es una afirmación sobre velocidad de tipeo. Nadie está corriendo una carrera contra un formulario.
Es una afirmación sobre una propiedad: que todo el camino desde contrato firmado hasta agente funcionando es una secuencia de llamadas a la API sin ninguna decisión humana en el medio. Una vez que eso es cierto, el tiempo transcurrido es lo que tarden las llamadas, y diez minutos es una estimación generosa. Cuando deja de ser cierto —cuando un paso requiere que una persona abra una consola y elija algo— el tiempo transcurrido ya no se mide en minutos, porque ahora incluye la cola de esa persona.
Ese es todo el hallazgo, y vale enunciarlo antes de los detalles: la diferencia entre diez minutos y tres días casi nunca es trabajo. Es espera.
El aprovisionamiento como protocolo tiene treinta años en el cuarto de al lado
El mundo de identidad zanjó esta discusión hace una década y la dejó escrita.
El RFC 7644, System for Cross-domain Identity Management: Protocol, publicado en septiembre de 2015 por Hunt, Grizzle, Ansari, Wahlström y Mortimore, define un protocolo HTTP para exactamente este problema. Su abstract enuncia la intención sin vueltas: "reduce the cost and complexity of user management operations by providing a common user schema, an extension model, and a service protocol". No una mejor interfaz de administración. Un protocolo, sobre la premisa de que el aprovisionamiento es trabajo máquina a máquina en el que los humanos no deberían estar en el medio.
La literatura de arquitectura SaaS dice lo mismo sobre tenants en vez de usuarios. El Well-Architected SaaS Lens de AWS, publicado el 4 de abril de 2023, define el problema: "SaaS applications rely on a frictionless model for introducing new tenants into their environment. This often requires the orchestration of a number of components to successfully provision and configure all the elements needed to create a new tenant."
Orquestación de una cantidad de componentes. Ese es el encuadre correcto y es el que las plataformas de agentes en general no adoptaron, porque su alta fue diseñada para una empresa que se registra a sí misma —un camino recorrido una vez, por alguien con tiempo— y no para un operador que lo recorre cuarenta veces.
El reloj
Lo que sigue asume que cada operación tiene un endpoint. Donde dice que un paso es una llamada, esa es la prueba: si necesita una consola, el reloj se detiene.
Minuto 0 — qué tiene que existir de antes
La parte honesta, primero. Los diez minutos solo están disponibles gracias a trabajo que pasó antes de que el cliente existiera:
- Un tenant padre que sostiene las conexiones, los defaults de marca y la política que los hijos van a heredar.
- Un artefacto de agente versionado — la definición del workflow, su configuración de guardrails y sus bindings de herramientas, exportados como JSON y guardados en control de versiones como cualquier otro desplegable.
- Un perfil de límites por nivel, expresado como valores y no como un nombre de plan.
- Una API key con alcance de aprovisionamiento, y un log de auditoría que va a registrar qué hizo.
Nada de esto es exótico, y todo esto es el proyecto de verdad. El alta de diez minutos es el resultado de haber construido estas cosas; tratarla como una funcionalidad para agregar después invierte la dependencia.
Minutos 0–1 — la frontera
Una llamada crea el tenant: nombre, slug, locale por defecto, y el padre del que cuelga.
Es la única decisión casi irreversible de la secuencia, porque determina qué hereda el cliente. Todo lo que viene después es un override. Equivocar el padre no es fatal pero es molesto, y es el único lugar que amerita un paso de validación en tu script.
Minutos 1–3 — límites y feature gates
Tres familias de control, escritas como valores sobre el tenant y no como una suscripción:
| Control | Ejemplos | Comportamiento al alcanzarlo |
|---|---|---|
| Límites de recursos | máximo de agentes, usuarios, tenants hijos, profundidad de jerarquía, almacenamiento | La creación se rechaza con un error explícito |
| Límites de consumo | mensajes por ciclo, techo duro de gasto, umbral blando por debajo | Se bloquean los pedidos nuevos; las conversaciones en curso no se cortan |
| Feature flags | qué canales, qué integraciones, si el editor de workflows está disponible | La capacidad simplemente no está |
Vale copiar dos propiedades de diseño si estás construyendo esto por tu cuenta. Los límites resuelven hacia arriba en la jerarquía — el valor propio del tenant, después el ancestro más cercano que tenga uno, después el default de plataforma — así que un operador fija un techo una vez y aplica a cada cliente de abajo sin escribirlo cuarenta veces. Y la capa de enforcement nunca lee el plan. Los planes son comerciales; los límites son funcionales. El aprovisionamiento escribe números, el runtime lee números, y los dos están desacoplados — que es lo que te permite darle a un cliente una excepción temporal sin inventarle un plan.
El default debería ser ilimitado, con los límites restrictivos opt-in. Un sistema de límites cuyo modo de falla es bloquear tenants existentes se apaga antes del trimestre.
Minutos 3–4 — conexiones, heredadas y no copiadas
El hijo no recibe su propia copia de tu clave de proveedor de modelos. Resuelve conexiones hacia arriba en el árbol y no puede modificar lo que resolvió.
Copiar la credencial hacia abajo sería más rápido de implementar y es la decisión equivocada, por una razón que aparece mucho después: una clave copiada es una clave que ahora tenés que rotar en cuarenta lugares, y una clave que el equipo del cliente puede leer. La herencia hace de la rotación una sola escritura en el padre y vuelve la credencial ilegible desde abajo. El cliente opera su agente; no sostiene tu clave. Esa relación es todo el sentido de la jerarquía, y este es el minuto en el que la entendés o la perdés.
Minutos 4–6 — el agente, desde un artefacto
Importar el artefacto versionado y después sobreescribir el puñado de cosas que son genuinamente por cliente: nombre visible, saludo, bindings de knowledge base, marca.
El artefacto lleva su propia configuración de seguridad — qué chequeos corren, sobre qué contenido, con qué acción ante violación. Esto importa más de lo que suena. Si la política de guardrails se configura por cliente después del aprovisionamiento, entonces queda bien configurada para los clientes a los que les prestaste atención y mal para el resto, y la superficie de manipulación no es algo que quieras que varíe según lo ocupado que estabas esa semana. Que viaje en el artefacto y que el override sea la excepción.
El agente se crea inactivo. Se activa en el minuto nueve, después de la verificación, y no antes.
Minutos 6–8 — canales y orígenes
Habilitar los canales que el nivel permite, cablear las credenciales de mensajería del propio cliente donde el canal las necesite, y registrar los orígenes permitidos para el widget web.
La lista de orígenes es el paso que más se saltea y el que más probablemente produzca un ticket de soporte, porque el síntoma de equivocarlo es un widget que carga y después falla en silencio al hablar — un rechazo de CORS en una consola que nadie tiene abierta. Scriptealo, y scripteá el chequeo.
Minutos 8–9 — personas
Crear al administrador del cliente y mandar la invitación. Acotar su rol a su propio tenant.
Invitación y no una contraseña puesta. No deberías conocer, transmitir ni guardar la credencial del cliente, y un script de alta que genera una creó un secreto que ahora existe en algún log.
Minutos 9–10 — verificación
Mandar un mensaje real al agente por un canal real y hacer una aserción sobre la respuesta.
Este es el paso que separa un script de aprovisionamiento de un pipeline de aprovisionamiento, y es el que más implementaciones omiten. Sin él hiciste cuarenta llamadas a la API y confirmaste que cuarenta llamadas devolvieron 200, que no es lo mismo que un agente funcionando. Con él, la activación queda condicionada a que pase un test, y la falla te cae a vos en el minuto nueve en vez de caerle al cliente el día dos.
Por qué el mismo trabajo tarda tres días
Sumá la versión manual y el trabajo son unos cuarenta minutos de clics. Igual tarda tres días, y el diagrama de arriba es la razón: cada paso humano es un traspaso, y cada traspaso espera en la cola de alguien.
Los cuatro que más lo producen:
- Una credencial que hay que pedir. Los datos de la cuenta de mensajería del cliente llegan por mail, en el horario de ellos. Este seguido es genuinamente externo — pero se puede mover al frente y volverlo una precondición en vez de descubrirlo en el paso seis.
- Un paso que sabe una sola persona. Normalmente la lista de orígenes o el cableado del canal. No está documentado, así que espera a esa persona.
- Configurar copiando al último cliente. Rápido, y propaga lo que sea que estuviera mal en el último cliente. Así derivan las flotas: no por una decisión, sino por cuarenta copias sucesivas.
- Sin verificación, las fallas aparecen después. Los tres días se vuelven cinco cuando el día cuatro se va en diagnosticar un widget que nunca iba a conectar.
Cuándo diez minutos es el objetivo equivocado
Dos casos, y los dos son bastante comunes como para nombrarlos.
Cuando los clientes no se parecen. El alta scriptada rinde en proporción a cuánta configuración es compartida. Si cada cliente necesita un workflow a medida, integraciones a medida y un modelo de datos a medida, no estás dando de alta tenants — estás entregando proyectos, y el artefacto que templatizarías no existe. Construí el script cuando la configuración del tercer cliente se parezca a la del segundo, no antes.
Cuando la frontera pesa más que la necesidad. Un tenant por cliente significa una frontera para aprovisionar, permisos para modelar y una jerarquía sobre la que razonar. Algunos clientes necesitan un bot, no una organización. Aprovisionar un agente dentro de tu propio tenant es un camino más corto y el correcto cuando el cliente nunca va a iniciar sesión.
Y una advertencia que aplica incluso cuando el script está bien: automatizar un proceso lo codifica. Si tu alta está mal hoy, scriptearla produce un resultado equivocado rápido y repetible, cuarenta veces, con un rastro de auditoría que prueba que lo hiciste a propósito. Corregí la versión manual una vez, después automatizá la correcta.
La prueba
Tomá el alta que corrés hoy y puntuala. Un punto cada una, y el puntaje es deliberadamente severo porque el crédito parcial es lo que esconde el problema.
- ¿Podés aprovisionar un cliente completo sin abrir una interfaz? No "casi" — en absoluto.
- ¿La configuración del agente es un artefacto versionado en control de código, o vive solo en la plataforma?
- ¿El cliente nuevo hereda tus credenciales de proveedor, o recibe una copia?
- ¿Los límites están escritos como valores, para que puedas dar una excepción sin inventar un nivel?
- ¿Hay un smoke test automatizado entre el aprovisionamiento y la activación?
- ¿Podés desmontar un cliente por completo, en una operación? Un desmontaje sin probar significa un alta sin probar, porque no podés correr la cosa dos veces.
- ¿El log de auditoría registra qué identidad ejecutó cada paso de aprovisionamiento?
- ¿Alguien que entró la semana pasada podría correrlo de punta a punta desde la documentación?
Seis o más y tu restricción es genuinamente el papeleo del cliente. Menos de cuatro, y los diez minutos no son un problema de herramientas — es que el proceso todavía tiene gente parada adentro, y cada una es una cola.
El RFC 7644 hizo este argumento para cuentas de usuario en 2015 y la industria estuvo de acuerdo. El mismo argumento para tenants no es más difícil. Solo es más nuevo, y todavía se hace mayormente en consolas.
