El
El runtime atiende la solución por sus canales, con personas cuando hace falta, corre sus procesos solos y la reparte entre varios .
La pila
De la solución a las personas, cada capa con su sello.
El diagrama en texto
La soluciónCorre hoy
Lo que declara el negocio, en documentos de texto versionados.
El Corre hoy
La compuerta: verifica la solución entera en seis etapas.
El runtimeCorre hoy
Varios pods atienden la misma solución, con un turno a la vez por conversación si se prende la cola.
Los canalesCorre hoy
El agente no depende del canal.
Las personasCorre hoy
Cuando hace falta, la conversación se deriva a una persona.
Disponibilidad
Varios pods atienden la misma solución, y Postgres guarda lo que importa.
Varios pods atienden la misma solución: comparten las colas de turnos y de trabajos programados, atienden un solo turno a la vez por conversación, y la respuesta del chat web llega en vivo aunque el turno corra en otro pod.
Límite La cola por conversación y la de turnos compartida se prenden en la configuración del .
Postgres es la fuente de verdad: la en Redis se puede vaciar sin perder conversaciones y, sin Redis, el servicio puede seguir en modo degradado, coordinando los pods por Postgres.
Límite Si se pierde Redis, se pierden los trabajos diferidos que estaban ahí; el modo sin Redis se activa por configuración.
El runtime informa su salud y si está listo: le manda tráfico sólo a los pods listos y reinicia los que dejan de responder, y cada solución tiene una lista de puesta a punto que dice si compila, si tiene un canal activo y una versión publicada.
Kubernetes
Los pods no guardan estado y avisan cuándo están listos.
GrailAOS™ corre en Kubernetes estándar, hoy sobre , desde imágenes versionadas: una solución escala sumando réplicas del runtime, y una versión nueva del runtime sale con un , sin corte cuando hay más de una réplica.
Límite Probado sobre k3s; no hay escalado automático por carga, y un pedido que llega justo cuando un pod se apaga puede fallar.
En la infraestructura que opera Omniatix, la base tiene un respaldo por día y relevo automático, la red de cada despliegue arranca cerrada, vaciar un nodo no corta las conversaciones con más de una réplica y un pod se apaga en orden.
Límite Sólo el runtime tiene el resguardo de mantenimiento, y sin la cola por conversación un turno a medias puede perderse al apagar un pod.
Entrega
Un mensaje no se pierde y un reintento no duplica una escritura.
En WhatsApp, la respuesta se guarda antes de entregarla, lo que no sale entra a una que reintenta y, si igual no sale, avisa al operador; un mensaje entrante no se confirma sin registrarlo y un reenvío no se procesa dos veces.
Límite Sólo para las respuestas de la conversación en WhatsApp.
Una integración HTTP puede mandar una clave de para que un reintento no duplique una escritura, si el sistema de destino la respeta.
Límite Viene apagada y se declara herramienta por herramienta.
Versiones
Se publica sin reconstruir nada, y volver atrás es mover un puntero.
El diagrama en texto
Una versión nueva de una solución se publica por API con sus archivos, sin reconstruir la imagen del runtime: antes, el compilador revisa la solución entera tal como quedaría y, si encuentra errores, la versión no se crea.
Por defecto, cada versión nueva nace en vista previa: la ve sólo el contacto de prueba del dueño, y el resto sigue atendido por la versión publicada.
Una versión puede salir en canary: un porcentaje de contactos, elegido por quien opera el deployment, la recibe, y cada contacto cae siempre del mismo lado.
Si la puerta de pruebas bloquea una promoción, la versión no se publica y sigue atendiendo la que estaba.
Límite Mientras la puerta decide, y durante unos minutos después de un bloqueo, algunos turnos pueden recibir la versión nueva.
Promover una versión y volver a la anterior no reconstruyen ni reinician nada: se mueve el puntero de la versión que atiende. Cada solución tiene a lo sumo una versión pendiente, que se puede cancelar en vista previa o en canary.
Límite Volver atrás no deshace los datos que la versión nueva ya escribió.
Sin reiniciar ni redesplegar, se cambian por API las funciones que el dueño prende y apaga, la zona horaria, el conocimiento, la configuración de tareas y campañas, los canales y cada pieza de una solución versionada, en todos los pods.
Límite Editar una pieza así no pasa por vista previa ni por la puerta de pruebas, y lo estructural necesita una versión nueva.
Procesos
Un proceso corre sin conversación, y su corrida sobrevive a la caída de un servidor.
Desde la versión 4.404 del runtime corren los procesos autónomos: un proceso sin conversación arranca por agenda, cuando alguien pide correrlo ahora, por API o porque lo lanza un agente, y encadena pasos de agente, bifurcaciones, variables, decisiones y llamadas directas a herramientas.
Límite Un proceso no arranca por un mensaje de un canal: a la conversación la atiende un agente, que puede lanzarlo.
Un proceso recorre listas de hasta cinco mil ítems y corre ramas en paralelo, hasta diez a la vez, con una regla para cuando una rama falla: seguir con las demás, cancelarlas todas o cortar en la primera.
Límite Las ramas en paralelo de una corrida corren en un mismo servidor.
Un proceso llama a otros procesos, esperando su resultado o sin esperarlo; si se cancela, se cancelan también los que lanzó, y el compilador rechaza los ciclos.
Límite Hasta tres niveles de procesos dentro de procesos.
Un paso de un proceso puede esperar la aprobación de una persona, que puede recibir un : aprueba o rechaza con un comentario desde la consola, y si nadie contesta a tiempo el paso vence; dos resoluciones a la vez no se pisan.
Una corrida vive en Postgres y no en la memoria de un servidor: si el que la avanza se cae a mitad de un paso o se apaga, otro la retoma; puede esperar hasta treinta días y queda fijada a la versión de la solución con la que arrancó.
Cuando un paso falla, el proceso hace lo que declara la solución: reintentar, reintentar contándole el error al modelo, tomar otro camino, usar un valor por defecto o saltear el paso, sin repetir lo que ya terminó.
Límite Una escritura que se cortó sin saber si llegó no se repite: el paso queda interrumpido y sigue lo declarado para el error.
Una tarea programada puede correr un proceso sin una conversación de por medio.
Límite Un proceso no les escribe a los clientes: para eso están las campañas.
También corren como tareas programadas las campañas salientes, los reportes, la ingesta de datos tabulares y la sincronización de bases de conocimiento.
Canales y personas
Un agente para todos los canales, y una persona cuando hace falta.
El agente no depende del canal: atiende por WhatsApp, con plantillas, botones y listas; por el chat web, con la ; por una API de conversaciones, para integrarlo en otro sistema; y por dispositivos físicos de voz.
Cuando hace falta una persona, la conversación se deriva: el operador recibe un aviso push, responde desde la consola de operación, desde Chatwoot o desde la aplicación de WhatsApp Business, y el agente vuelve a atender cuando la persona termina.
El agente le pregunta a una persona del equipo sin pasarle la conversación, sigue atendiendo y le lleva la respuesta al cliente en el mismo hilo, con los datos que dio esa persona y nunca su texto tal cual.
Límite Se activa por configuración, y se responde desde la consola.
Llamadas de voz por teléfono, a través de Telnyx.
Límite En un solo pod, y sin derivar a una persona durante la llamada.
Memoria
Lo que cuenta cada cliente y lo que pide que le recuerden.
Memoria de largo plazo de lo que cada cliente cuenta de sí mismo, con un tope y un aviso de «posiblemente desactualizado» por antigüedad: vence sola al año sin interacción y se borra a pedido, también cuando la persona le pide al agente que se olvide.
Límite Viene apagada y se activa por configuración del deployment.
Una persona le pide a un agente que le recuerde algo, en el chat web o por WhatsApp, y el recordatorio le llega a ella, por el mismo canal y a la hora pedida: el modelo no puede elegir a otra persona ni otro canal.
Límite Necesita una identidad estable de la persona: en una conversación web anónima no se agenda.
Integraciones
A dónde llama una integración lo decide quien opera, no el modelo.
Las integraciones HTTP no pueden llamar a la red privada, a la propia máquina ni a los datos internos de la nube, salvo que quien opera el deployment lo habilite en una lista.
Un agente usa las herramientas de un servidor externo, con el runtime como cliente: la cuenta lo conecta una vez, con una clave o con , sus herramientas quedan fijadas en la solución y la conexión pasa por la misma guarda de red.
Límite Sólo las herramientas, no los recursos ni los ; si el servidor cambia una, por defecto la llamada sigue con un aviso; la conexión es de la cuenta.
El runtime trae 102 herramientas incluidas y rechaza los tipos de herramienta que no sabe ejecutar; con su propio código de arranque, un deployment registra herramientas propias y siembra datos, sin modificar el runtime.
Límite Varias herramientas incluidas dependen de la configuración o del código de arranque del deployment.
Incluye servicios de plataforma: contactos y oportunidades, agenda y reservas con sus recordatorios, Google Workspace, los recordatorios que pide una persona y avisos al dueño de la cuenta.
Límite Contactos, oportunidades y agenda los conecta el código de arranque del deployment, y Google Workspace pide credenciales propias.
Seguridad
La identidad del contacto la pone el runtime, no el modelo.
Varios comparten el runtime con aislamiento a nivel de aplicación, con una guarda contra el acceso cruzado y pruebas de punta a punta, y la identidad del contacto la pone el runtime en cada turno: el modelo no la puede cambiar.
Límite Sin seguridad a nivel de fila en Postgres ni una auditoría externa del aislamiento.
Los secretos se guardan cifrados con AES-256-GCM, los de las herramientas son de cada tenant y de sólo escritura, y cada solución tiene su propia clave de API, que no sirve para otra.
Observabilidad y consumo
Cada turno deja su ; los avisos llegan al cruzar un umbral y los topes cortan antes del turno siguiente.
Cada turno deja una traza en Postgres, con el modelo, los , el costo, la duración, el resultado y cada herramienta que llamó; cada tenant consulta las suyas por API, junto con una foto de su actividad, y vencen solas a los treinta días por defecto.
El consumo de cada turno se mide por el costo real del modelo y se consulta por día, semana o mes, por solución, agente, conversación o tipo de operación, y cada consumo dice de dónde sale.
Los topes de consumo, en dinero facturado o en turnos, se evalúan antes de cada turno y de cada paso de un proceso, y pueden bloquear lo que sigue o pausar la solución; al cruzar un umbral del mes, el tenant recibe un aviso.
Límite El turno en curso siempre termina; los avisos de consumo vienen apagados y, como el tope en dinero, piden la facturación prendida.
Quien opera el deployment recibe un correo cuando falla algo que de otro modo pasaría desapercibido, y al arrancar, el runtime lista lo que está construido pero no conectado.
Métricas en formato , con el tenant y el entorno como etiquetas obligatorias, y exportación de trazas en formato .
Límite OpenTelemetry manda un tramo por turno de agente: las corridas de los procesos no se envían.
Modelos
Cada proveedor, con su sello.
Conectar los agentes a modelos de otros proveedores a través de un compatible con OpenAI: LiteLLM, OpenRouter o cualquier servidor que hable esa interfaz.
Hoy los agentes conversan sobre Claude, de Anthropic, con un respaldo ante fallas que se puede prender, por otra cuenta de Anthropic o por OpenRouter, y un aviso a quien opera cuando el proveedor falla; los se calculan con OpenAI.
Límite El respaldo viene apagado y se prende con las alertas al operador.
Preguntas
Procesos que corren solos, conversacionales y tareas programadas, con listas, ramas en paralelo y aprobaciones.
Es el propósito para el que está diseñado, y el motor que lo sostiene ya corre: procesos que trabajan solos, con personas que aprueban.
No se pierden conversaciones: Postgres es la fuente de verdad, y un modo degradado, si se activa, coordina los pods sin Redis; los trabajos diferidos sí se pierden.
Sí: en Kubernetes estándar, hoy sobre k3s, escalando con réplicas y actualizando pod por pod.
Por API, sin reconstruir la imagen: vista previa, canary si se quiere, y promover o volver atrás.
Con la traza de cada turno, las alertas por correo y los topes de consumo.