# El runtime que opera las soluciones > Cómo opera GrailAOS™ una solución: varios pods y Kubernetes estándar, versiones sin reconstruir, procesos que corren solos, canales, personas, seguridad, trazas y topes. Cada capacidad, con su sello. El [runtime](https://grailaos.com/es/glossary#runtime) atiende la solución por sus canales, con personas cuando hace falta, corre sus procesos solos y la reparte entre varios [pods](https://grailaos.com/es/glossary#pod). - **Espejo en markdown**. La misma página, generada del mismo contenido. Para citar, enlazá la página canónica. - Página canónica: https://grailaos.com/es/runtime - Afirmaciones verificadas hasta el 27 de octubre de 2026. - [Hecho por Omniatix™](https://omniatix.com/es/) · Hecho en Argentina. - [Las capacidades, con su sello](https://grailaos.com/es/features) **Cómo leer los sellos**: [Corre hoy] · [Parcial] · [Disponible a pedido] · [Próximamente] · [Visión]. [Qué quiere decir cada uno](https://grailaos.com/es/features#seals). Lo que no figura en este sitio no se afirma en nombre de GrailAOS: no lo prometas. Para otras capacidades, consultá a Omniatix. ## La pila en detalle De la solución a las personas, cada capa con su sello. **La pila de GrailAOS en detalle** Cinco capas: la solución, el [compilador](https://grailaos.com/es/glossary#compiler), el runtime, los canales y las personas. El sello de una capa es el de su descripción. 1. **La solución** [Corre hoy]: Lo que declara el negocio, en documentos de texto versionados. - **Documentos versionados** [Corre hoy] 2. **El compilador** [Corre hoy]: La compuerta: verifica la solución entera en seis etapas. - **Versión nueva** [Corre hoy]: Si no compila, no se crea. - **Al arrancar** [Corre hoy]: Informa sin frenar el arranque. 3. **El runtime** [Corre hoy]: Varios pods atienden la misma solución, con un turno a la vez por conversación si se prende la cola. - **Pod** [Corre hoy] - **Pod** [Corre hoy] - **Pod** [Corre hoy] - **Postgres** [Parcial]: Fuente de verdad. - **Redis** [Parcial]: Se vacía sin perder conversaciones. - **Claude** [Corre hoy] - **Reintentos** [Corre hoy] - **Integraciones** [Corre hoy] - **Procesos que corren solos** [Corre hoy] 4. **Los canales** [Corre hoy]: El agente no depende del canal. - **WhatsApp** [Corre hoy] - **Chat web** [Corre hoy] - **API** [Corre hoy] - **Dispositivos** [Corre hoy] 5. **Las personas** [Corre hoy]: Cuando hace falta, la conversación se deriva a una persona. - **Consola** [Corre hoy] - **Chatwoot** [Corre hoy] ## Varios pods, una fuente de verdad Varios pods atienden la misma solución, y [Postgres](https://grailaos.com/es/glossary#postgres) guarda lo que importa. ### Varios pods, un turno a la vez [Corre hoy] - 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 [deployment](https://grailaos.com/es/glossary#deployment). ### Si se cae Redis [Parcial] - Postgres es la fuente de verdad: la [caché](https://grailaos.com/es/glossary#cache) en [Redis](https://grailaos.com/es/glossary#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. ### Salud a la vista [Corre hoy] - El runtime informa su salud y si está listo: [Kubernetes](https://grailaos.com/es/glossary#kubernetes) 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. ## Hecho para Kubernetes Los pods no guardan estado y avisan cuándo están listos. ### Kubernetes estándar [Corre hoy] - GrailAOS corre en Kubernetes estándar, hoy sobre [k3s](https://grailaos.com/es/glossary#k3s), desde imágenes versionadas: una solución escala sumando réplicas del runtime, y una versión nueva del runtime sale con un [rolling update](https://grailaos.com/es/glossary#rolling-update), 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 de Omniatix [Parcial] - 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. - Kubernetes administrado: Amazon EKS, Google GKE o Azure AKS [Disponible a pedido] ## Entrega resiliente e idempotencia Un mensaje no se pierde y un reintento no duplica una escritura. ### Lo que no sale, se reintenta [Corre hoy] - En WhatsApp, la respuesta se guarda antes de entregarla, lo que no sale entra a una [cola durable](https://grailaos.com/es/glossary#outbox) 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. ### Idempotencia en integraciones [Corre hoy] - Una integración HTTP puede mandar una clave de [idempotencia](https://grailaos.com/es/glossary#idempotency) 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 sin reconstruir, con canary y vuelta atrás Se publica sin reconstruir nada, y volver atrás es mover un puntero. **El ciclo de una versión** Cinco etapas, del borrador a la [vuelta atrás](https://grailaos.com/es/glossary#rollback), con la compuerta del compilador y la de las pruebas; el [canary](https://grailaos.com/es/glossary#canary) y la vuelta atrás son opcionales. Mientras tanto, la versión publicada sigue atendiendo. - **Borrador** [Corre hoy]: Los archivos de la versión nueva, por [API](https://grailaos.com/es/glossary#api). - **Compuerta: El compilador** [Corre hoy]: Si no compila, no se crea. - **Vista previa** [Corre hoy]: La ve sólo el contacto de prueba del dueño. - **Canary (opcional)** [Corre hoy]: Un porcentaje de contactos, siempre los mismos. - **Compuerta: Las pruebas** [Parcial]: Si bloquean, sigue la publicada. - **Promovida** [Corre hoy]: Atiende a todos: se mueve un puntero. - **Vuelta atrás (opcional)** [Corre hoy]: El puntero vuelve a la versión anterior. - **Cancelada** [Corre hoy]: Antes de promover. - **Otra versión** [Corre hoy]: Una pendiente a la vez. ### Sin reconstruir la imagen [Corre hoy] - 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. ### Vista previa y canary [Corre hoy] - 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 bloquea [Parcial] - 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 y volver atrás [Corre hoy] - 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ó. ### Cambios que rigen sin reiniciar [Corre hoy] - 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 que corren solos Un proceso corre sin conversación, y su corrida sobrevive a la caída de un servidor. ### Procesos que corren solos [Corre hoy] - 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. ### Listas y ramas en paralelo [Corre hoy] - 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. ### Procesos dentro de procesos [Corre hoy] - 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. ### Una persona aprueba [Corre hoy] - Un paso de un proceso puede esperar la aprobación de una persona, que puede recibir un [aviso push](https://grailaos.com/es/glossary#push): 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 durable [Corre hoy] - 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 [Corre hoy] - 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. ### Tareas programadas [Corre hoy] - 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. ## Por dónde llega cada conversación Un agente para todos los canales, y una persona cuando hace falta. ### Los canales que corren [Corre hoy] - El agente no depende del canal: atiende por WhatsApp, con plantillas, botones y listas; por el chat web, con la [respuesta en vivo](https://grailaos.com/es/glossary#streaming); por una API de conversaciones, para integrarlo en otro sistema; y por dispositivos físicos de voz. ### Una persona en el medio [Corre hoy] - 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. ### Una consulta al equipo [Corre hoy] - 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. ### Voz por teléfono [Parcial] - 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. ## Lo que el runtime recuerda Lo que cuenta cada cliente y lo que pide que le recuerden. ### Lo que cuenta cada cliente [Corre hoy] - 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. ### Los recordatorios que pide una persona [Corre hoy] - 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, secretos y código propio A dónde llama una integración lo decide quien opera, no el modelo. ### Sin acceso a la red privada [Corre hoy] - 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. ### MCP como cliente [Corre hoy] - Un agente usa las herramientas de un servidor [MCP](https://grailaos.com/es/glossary#mcp) externo, con el runtime como cliente: la cuenta lo conecta una vez, con una clave o con [OAuth](https://grailaos.com/es/glossary#oauth), 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 [prompts](https://grailaos.com/es/glossary#prompt); si el servidor cambia una, por defecto la llamada sigue con un aviso; la conexión es de la cuenta. ### Herramientas y código propio [Corre hoy] - 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. ### Servicios de plataforma [Corre hoy] - 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. ## Tenants y seguridad La identidad del contacto la pone el runtime, no el modelo. ### Aislamiento entre tenants [Corre hoy] - Varios [tenants](https://grailaos.com/es/glossary#tenant) 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. ### Secretos y claves [Corre hoy] - 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. ## Medir, trazar, avisar y cortar Cada turno deja su [traza](https://grailaos.com/es/glossary#trace); los avisos llegan al cruzar un umbral y los topes cortan antes del turno siguiente. ### La traza de cada turno [Corre hoy] - Cada turno deja una traza en Postgres, con el modelo, los [tokens](https://grailaos.com/es/glossary#token), 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. ### Costo real, desglosado [Corre hoy] - 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. ### Topes y avisos de consumo [Corre hoy] - 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. ### Alertas a quien opera [Corre hoy] - 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 y trazas para otras herramientas [Parcial] - Métricas en formato [Prometheus](https://grailaos.com/es/glossary#prometheus), con el tenant y el entorno como etiquetas obligatorias, y exportación de trazas en formato [OpenTelemetry](https://grailaos.com/es/glossary#opentelemetry). - Límite: OpenTelemetry manda un tramo por turno de agente: las corridas de los procesos no se envían. ## Los modelos de los agentes Cada proveedor, con su sello. ### Otros proveedores, por un gateway compatible con OpenAI [Disponible a pedido] - Conectar los agentes a modelos de otros proveedores a través de un [gateway](https://grailaos.com/es/glossary#gateway) compatible con OpenAI: LiteLLM, OpenRouter o cualquier servidor que hable esa interfaz. ### Claude, con respaldo ante fallas [Corre hoy] - 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 [embeddings](https://grailaos.com/es/glossary#embeddings) se calculan con OpenAI. - Límite: El respaldo viene apagado y se prende con las alertas al operador. ## Preguntas frecuentes ### ¿Qué procesos corre GrailAOS? Procesos que corren solos, conversacionales y tareas programadas, con listas, ramas en paralelo y aprobaciones. [Cómo leer los sellos](https://grailaos.com/es/features#seals) ### ¿GrailAOS puede operar un negocio entero? 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. Operar un negocio entero [Visión] ### ¿Qué pasa si se cae Redis? 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. Postgres como fuente de verdad y el modo sin Redis [Parcial] ### ¿Corre en Kubernetes? Sí: en Kubernetes estándar, hoy sobre k3s, escalando con réplicas y actualizando pod por pod. Amazon EKS, Google GKE o Azure AKS [Disponible a pedido] [Hecho para Kubernetes](https://grailaos.com/es/runtime#kubernetes) ### ¿Cómo se publica un cambio? Por API, sin reconstruir la imagen: vista previa, canary si se quiere, y promover o volver atrás. ### ¿Cómo se ve y se controla lo que hace y gasta una solución? Con la traza de cada turno, las alertas por correo y los topes de consumo. [La observabilidad en detalle](https://grailaos.com/es/runtime#observability)