Diez minutos no es una afirmación sobre velocidad de tipeo. Es una afirmación sobre una propiedad: que todo el camino desde contrato firmado hasta agente funcionando es una secuencia de llamadas, sin una persona en el medio eligiendo algo en una consola. Cuando eso se cumple, el tiempo transcurrido es lo que tarden las llamadas. Cuando no, el tiempo transcurrido incluye la cola de esa persona — y la diferencia entre diez minutos y tres días casi nunca es trabajo. Es espera.
Esta pieza explica cómo AI Agent Builder deja a un cliente funcionando con esa propiedad, y por qué cada paso tiene la forma que tiene. Retoma donde termina por qué cada cliente tiene que ser un tenant propio: esa pieza trata de la frontera, esta trata del procedimiento que la crea.
Qué necesita la agencia
"Un cliente firma el lunes. Quiero que su agente esté respondiendo en su sitio para cuando mande el mail de bienvenida: dentro de los límites que le vendí, con mi clave de proveedor de modelos sin que ellos la tengan nunca, configurado igual que los últimos cuarenta — y quiero poder decir después qué se hizo y quién lo hizo."
En esa frase hay cuatro requisitos que tiran en direcciones distintas. Repetible: el cliente cuarenta tiene que ser igual al primero. Acotado: lo que el cliente puede consumir tiene que estar escrito antes de que pueda consumirlo. Sin llaves: el cliente opera un agente, no tus credenciales. Trazable: cuando algo está mal, alguien tiene que poder decir qué se hizo. Las secciones que siguen los toman en el orden en que corre el camino.
Todo es una llamada, incluida la consola
Cada operación que hace la consola de administración — crear un tenant, importar un agente, escribir límites, invitar a una persona — es también una operación de la API protegida de la plataforma, y el mismo conjunto se expone como herramientas a cualquier cliente MCP. La consola es un cliente más de esa API, no un camino privilegiado por fuera. Todo lo que sigue depende de esto: un paso que existiera solo como pantalla sería el paso donde el reloj se detiene.
Quienes llaman se autentican con claves, y una clave emitida para un tenant queda atada a él y a un único rol: no puede alcanzar los datos de otro tenant.
El diagrama es la forma del argumento, no una medición: los mismos ocho pasos, la misma cantidad de trabajo en cada uno, y lo único que cambia es cuántos esperan a una persona.
Primero, la frontera
Una llamada crea el tenant del cliente debajo del de la agencia: un nombre, un slug, un idioma y el padre del que cuelga. La plataforma guarda la posición de cada tenant como un camino desde la raíz, y eso es lo que vuelve barato todo lo que sigue — "qué ancestros tiene este cliente" es partir un string, no una consulta recursiva.
El padre es la única decisión de la secuencia que es incómoda de deshacer, porque todo lo que el cliente hereda sale de ahí. Un tenant se puede mover después y su camino se recalcula, pero cambia lo que hereda desde ese momento. Es el único lugar que amerita un paso de validación en tu script.
Dos cosas no forman parte de esa primera llamada a propósito: los límites y la herencia de conexiones. Un tenant nuevo arranca sin límites propios y con la herencia apagada. Las dos se escriben explícitamente en los pasos siguientes, y por eso el orden importa.
Los límites son valores, resueltos de lo más cercano hacia arriba
Tres familias de control se escriben sobre el tenant como valores:
| Familia | Ejemplos | Al llegar al borde |
|---|---|---|
| Recursos | agentes, usuarios, tenants hijos, profundidad de jerarquía, almacenamiento | La creación se rechaza, con un error que nombra el recurso y la cuenta |
| Consumo | mensajes por mes, gasto por ciclo | Una conversación nueva se rechaza; una que ya corre no se corta |
| Feature gates | canales, integraciones, el editor de workflows, nodos de código | La capacidad se rechaza para ese tenant |
Un tenant usa su propio conjunto de valores si lo tiene. Si no, usa el del ancestro más cercano que lo tenga. Si no, recibe el default de la plataforma, que es ilimitado. El conjunto se toma entero — no hay mezcla campo por campo. Así que un operador que escribe un techo una vez en la agencia cubre a cada cliente de abajo que no tenga uno propio; y un cliente al que se le da un conjunto propio deja de seguir al de la agencia en todos los campos, no solo en los que cambió.
El enforcement nunca lee el plan. Asignar un plan escribe los valores del plan sobre el tenant — límites, flags, límites de tasa, modo de facturación — y desde ahí el runtime lee solamente esos valores. Los planes son comerciales; los límites son funcionales. Ese desacople es lo que convierte una excepción temporal para un cliente en una escritura sobre ese cliente, en vez de un plan inventado para él.
El consumo se chequea una sola vez, antes de que empiece una conversación, contra un contador que se reinicia el primero del mes calendario en UTC. Una conversación que ya está en curso termina. Ilimitado sigue siendo el default a propósito: un sistema de límites cuyo modo de falla es bloquear tenants existentes se apaga antes del trimestre.
Las conexiones se resuelven, nunca se copian
Los agentes del cliente no reciben una copia de la clave de proveedor de la agencia. En tiempo de ejecución, la plataforma busca las conexiones activas propias del tenant. Si tiene al menos una, esas ganan sin discusión. Si no tiene ninguna y la herencia está encendida, toma las del ancestro más cercano que tenga alguna. Si la herencia está apagada y no tiene ninguna, la corrida falla con un error explícito en vez de adivinar. Los defaults de modelo viajan con las conexiones: un cliente sin defaults propios lee los del tenant que le aportó las conexiones.
Como nada se copia, pasan dos cosas. Rotar una clave es una sola escritura en el padre. Y la credencial nunca existe como fila en el tenant del cliente, así que no hay nada para que lean los administradores del cliente. Ellos operan su agente; no sostienen tu clave.
El agente sale de un artefacto
Un agente se exporta como un solo documento: su workflow — con sus pasos de guardrails incluidos, porque son nodos de ese workflow —, su schedule y sus datos estáticos. Importar ese documento en el tenant del cliente es una única operación, y está construida para que se pueda repetir:
- No crea lo que solo referencia. Las conexiones de proveedor, las de herramientas y las fuentes de API se resuelven por nombre dentro del tenant del cliente, y un nombre que no encuentra vuelve como advertencia, no como una conexión vacía creada en silencio.
- La definición se sobrescribe, no se agrega. Importar dos veces el mismo artefacto deja el mismo agente; la versión guardada siempre coincide con el documento.
- La política viaja con el agente. Como la configuración de guardrails es parte de la definición, no es algo que alguien configure cliente por cliente después — bien para los que estaba mirando, mal para el resto. La superficie de manipulación no debería variar según lo ocupado que estabas esa semana.
La importación devuelve sus advertencias y una lectura de salud del agente nuevo, que es sobre lo que un script debería hacer aserciones.
Quién puede hablarle al agente
El tráfico web se gobierna por tenant con una política de orígenes. Un tenant nuevo permite todos los orígenes; pasarlo a una lista de permitidos restringe el widget a los orígenes listados, comparados de forma exacta, y un pedido de cualquier otro se rechaza con un error con nombre. Los pedidos que no traen origen — de servidor a servidor — no están sujetos a ella.
Así que el default es una puerta abierta, y la lista es el paso que la cierra. Scriptealo, y scripteá el chequeo de que un origen listado funciona y uno no listado no.
Personas, sin contraseña
Invitar al administrador del cliente crea la identidad sin contraseña permanente, emite un token de un solo uso válido por 72 horas, asigna a la persona al tenant del cliente con un rol — owner, admin o viewer — y manda el mail. Un reenvío invalida el token anterior, con un enfriamiento de un minuto, y una invitación pendiente se puede revocar. En ningún momento el alta conoce, transmite o guarda la credencial del cliente, así que no hay un secreto sentado en un log de aprovisionamiento.
Probar que anda antes de que el cliente lo vea
Este es el paso que tiene que aportar el pipeline, porque la plataforma no lo exige: importar un agente lo deja activo en el acto. Lo que la plataforma da es un canal real para probar — el mismo que van a usar los usuarios del cliente. Mandá un mensaje real, hacé una aserción sobre la respuesta, y recién entonces mandá la invitación. La invitación es el paso que hace que el cliente se entere del trabajo, así que va al final.
Sin ese paso, el pipeline confirmó que sus llamadas devolvieron éxito, que no es lo mismo que un agente funcionando. Con él, la falla te cae a vos antes de que al cliente le hayan dicho nada.
Quién hizo qué, y cómo deshacerlo
Cada cambio al plano de control — un tenant, un agente, una conexión, una clave — queda registrado con el actor (una persona, una API key o la propia plataforma), la acción, el recurso y los valores antes y después, en un log donde cada fila está encadenada a la anterior. Registra cambios, no lo que los agentes hicieron en ejecución; eso vive en los registros de corridas. Escribirlo nunca bloquea la operación que está mirando: si falla el registro, se loguea fuerte.
El desmontaje también es una operación. Borrar un tenant elimina todo su subárbol, hijos primero — agentes, conexiones, knowledge bases, sesiones, corridas, facturación, configuración de canales, invitaciones, marca — y devuelve una cuenta por tipo. No se puede deshacer, que es justamente por lo que conviene correrlo primero sobre un tenant descartable: un alta que nunca se desmontó nunca se corrió de verdad dos veces.
Dónde se corta
- Las credenciales propias del cliente quedan en el reloj del cliente. Una cuenta de mensajería que el cliente tiene que pedir es una espera que ningún script elimina. Se puede mover al frente y volverla una precondición, que es lo máximo que el procedimiento puede hacer.
- Cada chequeo de límites y de flags falla abierto. Si la plataforma no puede leer un límite o un flag, deja pasar el pedido en vez de bloquear a un cliente por una falla propia.
- Solo los topes duros de consumo muerden. Los umbrales blandos que los acompañan se guardan, y hoy nada actúa sobre ellos en ejecución.
- Los límites se toman como un conjunto entero, y no son un techo que un cliente no pueda superar. Quien puede escribir el conjunto propio de un cliente reemplaza el de la agencia.
- La herencia de conexiones es todo o nada por tenant. Con una conexión propia el cliente deja de heredar cualquiera; nunca se mezclan.
- La importación busca los nombres de conexión del artefacto dentro del tenant propio del cliente. A un cliente que hereda le avisa que le falta una conexión que de hecho va a usar por herencia. Leé esas advertencias sabiendo eso.
- La política de orígenes está abierta hasta que alguien la cierra, y las invitaciones necesitan un proveedor de identidad que las soporte; si no, la llamada falla de forma explícita.
Ocho chequeos para cualquier alta
Sea lo que sea que deja a tus clientes en producción — este procedimiento u otro — estas son las propiedades que vale la pena puntuar, un punto cada una y sin crédito parcial, 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? Una clave copiada es una clave que rotás en cuarenta lugares y que el equipo del cliente puede leer.
- ¿Los límites están escritos como valores, para que una excepción no necesite un nivel inventado?
- ¿Hay una prueba automática entre el aprovisionamiento y la invitación? Cuarenta llamadas con éxito no es un agente funcionando.
- ¿Podés desmontar un cliente por completo, en una operación? Un desmontaje sin probar significa un alta sin probar.
- ¿El log de auditoría registra qué identidad ejecutó cada paso?
- ¿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 diez minutos no es un problema de herramientas: 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 — aprovisionar es trabajo máquina a máquina — 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.
