Infraestructura AI-native para agentes empresariales

Los modelos razonan.La infraestructura ejecuta.

Construye agentes de IA que ejecutan procesos reales de negocio, con acciones controladas, ejecución trazable y menos contexto repetitivo. Nuestro framework reutilizable permite que tu equipo se concentre en reglas de negocio, integraciones y experiencia del cliente.

Las empresas mantienen el control.

Tu equipo construye la solución. Invariant proporciona la infraestructura y el acompañamiento técnico, con un alcance acordado.

Acciones controladas
Ejecución trazable
Contexto enfocado
invariant.config.ts
const orderWorkflow = app.workflow('order-fulfillment', {
inputSchema: z.object({
customerId: z.string(),
orderId: z.string(),
reason: z.enum(['damaged', 'wrong_item']),
}),
})
.capability('load-customer', loadCustomer)
.capability('load-order', loadOrder)
.step('check-policy', ({ state }) => ({
approved: isEligible(state.customer, state.order),
amount: state.order.totalAmount,
}))
.branch('decision',
({ state }) => state.approved ? 'APPROVED' : 'REJECTED',
{
APPROVED: app.fragment('approved')
.capability('submit-order', submitOrder),
REJECTED: app.fragment('rejected')
.step('reject', () => ({ status: 'REJECTED' })),
}
);
Durable Event SourcingFast Path & Recovery Primitives
Ventajas de la plataforma

Construye tus agentes sobre Invariant, con acompañamiento técnico.

Nuestro framework y runtime permiten concentrar el desarrollo en las reglas de negocio, integraciones y experiencia del cliente. Acompañamos la adopción con asesoría de arquitectura e integración; tu equipo o integrador desarrolla la aplicación final.

Control

Ejecución controlada

Delimita operaciones mediante workflows, reglas, permisos y validación del runtime, según las capacidades que implemente tu aplicación.

Visibilidad

Visibilidad de ejecución

Traza propuestas, validaciones, transiciones, acciones y resultados registrados sin afirmar acceso al razonamiento privado del modelo.

Eficiencia

Menor sobrecarga de tokens

Mantén lógica y estado autoritativo fuera del contexto repetitivo del modelo y proyecta solo lo necesario. Esto no promete reducir el costo operativo total.

Entrega

Implementación más rápida

Construye sobre un framework y runtime reutilizables, con acompañamiento técnico de adopción e integración. Tu equipo puede concentrar el desarrollo en reglas de negocio, integraciones y experiencia del cliente.

Tu equipo o integrador desarrolla

Tu equipo desarrolla el agente, la experiencia de usuario, las integraciones y las reglas del negocio, y valida la aplicación resultante.

Agent → propone qué debería suceder (proyección de razonamiento)
Workflow → define qué puede suceder (caminos y fronteras permitidas)
Session → define qué persiste (contexto de aplicación hidratado)
Capability → define qué interactúa con el mundo exterior (efectos externos)
Invariant proporciona

Acceso a la plataforma propietaria, framework, runtime y documentación, junto con acompañamiento técnico de arquitectura, adopción e integración con un alcance acordado.

Motor de Durabilidad del Runtime
  • Log de eventos transaccional append-only
  • Concurrencia optimista y bloqueos por lease
  • Frontera de validación en cada acción
  • Intención de outbox transaccional con despacho en proceso
  • Fronteras .wait() restaurables; recuperación de trabajo a cargo de la aplicación

Lo que los equipos construyen con Invariant

Cobranza y e-commerce son aplicaciones que tu equipo puede construir sobre Invariant. La misma infraestructura sirve como base para otros procesos empresariales, con los workflows, reglas e integraciones que tu equipo configure.

Cobranza

Construye un agente que consulte saldos, presente opciones permitidas y acompañe al cliente a través de un flujo de pago controlado, con tus reglas e integraciones de pago.

Explorar controles de workflow

E-commerce

Construye un agente que consulte productos, prepare pedidos y acompañe compras mediante tus integraciones de catálogo y pedidos, mientras el runtime controla qué puede ejecutarse.

Explorar ejemplos

Infraestructura compartida de negocio

Reutiliza el mismo modelo de ejecución en atención al cliente, ventas y operaciones internas mediante web, voz o mensajería.

Por qué Invariant
El Problema en Producción

Al pasar de demos a producción, la confiabilidad se fuga hacia el prompt.

El estado de la aplicación, el progreso de ejecución, la autoridad de herramientas, los reintentos y la recuperación terminan saturando el historial de conversación.

Más estado

Mayor contexto en prompt y desperdicio de tokens

Más herramientas

Mayor radio de impacto ante errores del modelo

Ejecuciones largas

Recuperación difícil y pérdida de progreso

Más efectos

Mayor riesgo de duplicar acciones en reintentos

The Human Analogy

Los modelos cometerán errores. Los sistemas confiables se diseñan para eso.

Un agente humano de soporte puede malinterpretar una solicitud incluso tras años de experiencia. No solucionamos eso dándole autoridad ilimitada y esperando que nunca se equivoque. Lo rodeamos de permisos, políticas, workflows y sistemas de registro.

The Engineering Invariant

Los agentes de IA deben diseñarse de la misma manera.

Los modelos deben interpretar, razonar y proponer. La infraestructura a su alrededor debe poseer el estado, validar la autoridad, controlar la ejecución y recuperarse ante fallos.

Los modelos pueden equivocarse. Eso es inevitable.

Darles autoridad ilimitada no lo es.

Los sistemas confiables no requieren decisores perfectos. Requieren fronteras confiables a su alrededor.

Tesis Arquitectónica

Deja que la IA razone. Mantén el control de tu aplicación.

La IA es probabilística por naturaleza. Tu aplicación no tiene que heredar esa incertidumbre.

Invariant se sitúa entre las decisiones probabilísticas de la IA y la ejecución real de tu aplicación — validando lo permitido, persistiendo el estado y exponiendo primitivas explícitas de recuperación.

Razonamiento de IA
Probabilistic Intent
Interpreta la intención
"Reembolsar esta orden"
Propone una acción
start_workflow("refund", { orderId })
FRONTERA VALIDADA
¿Qué está permitido?
Políticas y permisos
¿Qué es verdad ahora?
Control de revisión y lease
¿Qué puede ejecutarse?
Transiciones de workflow permitidas
Ejecución Confiable
Durable Application Runtime
Workflow

Define lo que puede ocurrir

Nodos de grafo explícitos, guardas y transiciones

Estado

Recuerda lo que ha ocurrido

Log de eventos append-only y materialización

Efectos

Despacha acciones reales mediante fronteras controladas

Outbox transaccional y claves de idempotencia

"Los modelos razonan. La infraestructura ejecuta."

Explorar la arquitectura completa en la documentación
Ingeniería de Contexto

No obligues al modelo a recordar la verdad de la aplicación.

Hidrata desde sistemas autoritativos. Proyecta solo lo que el modelo necesita ahora.

La hidratación define de dónde viene la verdad. La proyección define cuánta de esa verdad y estado de ejecución ve el modelo en cada instante.

1. Authoritative Systems
Sistema CRMCustomer Data
Motor de FacturaciónStripe / Payments
Proveedor de IdentidadAuth0 / Okta
Base de Datos PostgreSQLApp State
hydrate()
2. Session Context

Estado de aplicación autoritativo hidratado y refrescado desde sistemas fuente

customerId: 'cust_812'
accountTier: 'PRO'
billingStatus: 'ACTIVE'
projection()
3. Frontera del Modelo (Enfocada)Contexto Enfocado

Hechos, políticas y acciones acotadas al turno sin sobrecargar tokens

goal: 'generate_report'
actions: ['submit_input', 'cancel_workflow']
Demostración de Frontera de Ejecución

Seis horas después. Paso 80.

El modelo no necesita seis horas de historial.

Agente Tradicional

Acumulación de Historial

El historial de ejecución se convierte en contexto del modelo.

Paso 1 → Paso 2 → ... → Paso 34 → ... → Paso 61 → ... → Paso 80
Contexto creciente: historial · tools · resultados · estado
Prompt accumulates tool calls, tool responses, old reasoning and growing context overhead.

Más historial, más tokens y más contexto que el modelo debe reconciliar.

Runtime de Invariant

Frontera de Ejecución

El historial de ejecución permanece como estado del runtime.

Ejecución durable: Paso 1 → 2 → 3 → ... → Paso 80
[Current Execution Boundary]
Objetivo: Generar reporte trimestral
Hechos relevantes: Resultado del Paso 2
Esquema esperado: ReportSchema
Acciones permitidas: start_workflow · submit_input · cancel_workflow

El modelo recibe únicamente el objetivo activo, hechos previos relevantes, esquema esperado y acciones permitidas.

"La ejecución puede tener horas de antigüedad. El contexto del modelo no tiene por qué tenerla."

Frontera de Seguridad de IA

No intentes eliminar la incertidumbre de la IA. Conténla.

Los modelos malinterpretan intenciones, omiten datos obligatorios, eligen acciones inválidas y a veces razonan sobre estado caducado. Invariant asume que esto ocurrirá. El Runtime determina si una propuesta tiene autorización para convertirse en ejecución.

El Bucle de Rechazo y Recuperación Segura
Step 80 → Rejection → Feedback → Commit
1. Propuesta del Modelo
{ title: "Reporte Trimestral" }
Omite campo requerido: sections
2. Validación del Runtime
✕ Falta campo requerido: sections
RECHAZADO — ESTADO INTACTO
Paso actual: 80 · Revisión: 17
Estado del workflow: sin cambios
Feedback estructurado retornado al modelo
4. Reintento del Modelo
{ title: "Reporte Trimestral", sections: ["Resumen Q1", "Ingresos"] }
✓ schema satisfied
5. Commit en el Log de Eventos
✓ esquema válido · ✓ acción permitida · ✓ revisión 17 actual
Paso 80 ──► Paso 81

El razonamiento puede ser probabilístico. El progreso no lo es.

Las salidas inválidas de razonamiento se convierten en feedback, jamás en estado de aplicación.

Capas Secuenciales de Contención

01
Contexto Relevante

Ve solo lo relevante para este turno, no todo el historial.

02
Acciones Delimitadas

Propone solo las acciones expuestas por la frontera actual.

03
Inputs Validados

Las salidas inválidas no pueden avanzar la ejecución.

04
Validación de Estado Fresco

Decisiones caducadas se descartan si el estado cambió mientras el modelo pensaba.

Cada propuesta, rechazo, transición y hecho confirmado permanece auditable.Explorar observabilidad de ejecución en la documentación

Una capa de ejecución.
Múltiples canales de interacción.

Los canales son formas de interactuar con un agente, no productos separados de Invariant.

Las aplicaciones pueden conectar web, voz, mensajería, APIs y webhooks mediante adaptadores configurados, compartiendo contexto durable de Session. Un .wait() registrado puede continuar mediante una Session propia restaurada; recuperar trabajo interrumpido requiere código de la aplicación.

Canales configurados por la aplicaciónContexto de Session compartidoContinuidad de contexto durable
Canales conectados por la aplicación
Mensajería / WhatsApp
Correo
Voz / Audio
Widget de Chat
Panel Humano
Runtime de Invariant

Mismo Estado Autoritativo

run_idwr_8f29c0
queue_len0
concurrencyIDLE

Ejemplos que los equipos pueden desarrollar

Centros de Llamadas y Voz en Vivo

Preserva el estado y el progreso confirmado ante cortes de audio, SMS, correos y transferencias humanas.

Soporte al Cliente y Operaciones

Persiste fronteras de aprobación y entradas del cliente mientras la Session viva coordina la continuación.

Integraciones Autónomas de Sistemas

Construye workflows de larga duración con acciones validadas, intención de outbox transaccional, leases y recuperación orquestada por la aplicación.

Construido para TypeScript

Esto suena a mucha infraestructura. No tienes que construirla.

Infraestructura durable sin convertir el código de tu aplicación en código de infraestructura.

Define workflows, agentes y capabilities en TypeScript con tipos estrictos. Invariant persiste estado, historial de eventos e intención de comandos, valida revisiones y despacha comandos confirmados en proceso. En el release actual, la orquestación cross-process queda a cargo de la aplicación.

refund-workflow.ts
import { z } from 'zod';
import { app } from './app';
// Clean, type-safe workflow definition
export const refundWorkflow = app.workflow('refund', {
inputSchema: RefundSchema,
})
.capability('load-customer', loadCustomer)
// state.customer → Customer
.capability('load-order', loadOrder)
// state.customer → Customer, state.order → Order
.step('check-policy', ({ state }) => ({
approved: isRefundEligible(state.customer, state.order),
amount: state.order.totalAmount,
}))
.branch('refund-decision',
({ state }) => state.approved ? 'APPROVED' : 'REJECTED',
{
APPROVED: issueRefund,
REJECTED: rejectRefund,
}
);
Los tipos siguen a la ejecución: Cada nodo extiende el estado disponible para los pasos posteriores con inferencia total de TypeScript.

Lo que Invariant gestiona por debajo

Ingeniería de sistemas durable, abstraída detrás del SDK.

Estado de ejecución durable
Log de eventos append-only
Intención de outbox transaccional
Despacho de comandos en proceso
Claves estables de idempotencia para proveedores
Leases y descubrimiento de ejecuciones reanudables
Proyección acotada de contexto por turno
Validación de revisión y estado fresco
La complejidad no desaparece. Se traslada detrás del SDK.
El acceso al SDK y los términos del release se confirman durante una evaluación aprobada del producto.
Garantías complejas. Superficie de API pequeña.

Los modelos razonan. La infraestructura ejecuta.

Traslada el estado, la ejecución, la autoridad y las primitivas de recuperación fuera del modelo hacia la infraestructura determinista.

Modos de fallo que tu runtime debe gestionar—no tu modelo.

Los agentes en producción fallan cuando la confiabilidad se delega al prompt. Invariant contiene los fallos de ejecución en la frontera de infraestructura.

Pérdida de Progreso en Caídas

Pain PointReinicios de procesos o cortes de red pierden el estado de la ejecución.
Invariant persiste estado confirmado e historial de eventos. Un proceso nuevo puede restaurar una Session propia en un .wait() registrado; recuperar comandos interrumpidos queda a cargo de la aplicación.

Mutaciones Alucinadas

Pain PointLos modelos invocan herramientas destructivas con argumentos erróneos.
Los modelos solo proponen Runtime Actions. El Runtime valida esquemas y permisos antes de ejecutar capabilities.

Explosión de Tokens

Pain PointEnviar todo el historial en cada prompt multiplica los costos y la latencia.
Invariant almacena el estado en la infraestructura y proyecta únicamente lo necesario para la decisión actual.

Condiciones de Carrera

Pain PointMensajes concurrentes sobrescriben el estado y duplican efectos secundarios.
Concurrencia serializada y bloqueos optimistas garantizan transiciones atómicas.

Interrupciones por Humanos

Pain PointLas ejecuciones se rompen al esperar aprobaciones o entradas de usuarios.
Un nodo .wait() persiste su frontera de entrada y el estado. Una Session viva o restaurada puede aceptar la siguiente entrada válida si el mismo workflow está registrado.

Preguntas frecuentes

Cómo construir sobre Invariant, qué incluye el acompañamiento técnico y cómo funciona el runtime.

  • ¿Qué es Invariant?

    Invariant es infraestructura AI-native horizontal y propietaria: un framework de TypeScript y runtime durable para agentes que ejecutan procesos reales dentro de fronteras deterministas.

  • ¿Cómo se ofrece Invariant?

    Invariant proporciona infraestructura propietaria, framework, runtime, documentación y acompañamiento técnico de arquitectura, adopción e integración. Acordamos el alcance de ese acompañamiento durante la evaluación, junto con el acceso al SDK, despliegue, soporte de la plataforma y términos comerciales.

  • ¿Quién desarrolla la aplicación final?

    Tu equipo o integrador desarrolla el agente, la experiencia de usuario, las integraciones externas y las reglas del negocio, y valida la aplicación. Implementarla requiere capacidad técnica: involucra al equipo de tecnología o a un integrador junto con el área de negocio que evalúa el caso de uso.

  • ¿Qué incluye el acompañamiento técnico?

    Con un alcance acordado, podemos asesorar sobre arquitectura, explicar la integración del framework, revisar workflows y acompañar una prueba de concepto. El acompañamiento inicial y la asistencia adicional se acuerdan por separado. El desarrollo integral a medida, el mantenimiento de tu aplicación y la operación de tu proceso de negocio no se incluyen por defecto. El soporte y mantenimiento de la plataforma Invariant tienen sus propios términos acordados.

  • ¿Cómo se diferencia de LangChain, LangGraph o CrewAI?

    La mayoría de frameworks le dan autoridad de ejecución directa al modelo. Invariant mueve el estado y los efectos fuera del modelo hacia la infraestructura. Los modelos proponen Runtime Actions y el Runtime las valida y ejecuta a través de grafos inmutables.

  • ¿Por qué Invariant reduce el consumo de tokens?

    En lugar de reenviar todo el historial en cada turno, Invariant almacena el estado autoritativo en el runtime y proyecta únicamente el contexto y las acciones relevantes. Esto reduce contexto repetitivo; el costo total depende de la aplicación y los modelos utilizados.

  • ¿Cómo funciona la recuperación ante caídas?

    Invariant guarda estado confirmado, eventos append-only, intención de comandos, leases e IDs de ejecuciones reanudables. Un proceso nuevo puede restaurar una Session propia en una frontera .wait() registrada. El release actual no expone claim portable de comandos ni attach arbitrario para recuperar trabajo, y no incluye un worker en segundo plano.

  • ¿Invariant soporta múltiples proveedores de LLM?

    Sí. Invariant incluye adaptadores para OpenAI, Anthropic y Google Gemini, incluido Gemini Live WebSockets. Proveedores locales como Ollama o vLLM pueden integrarse mediante un ModelAdapter personalizado.

  • ¿Cómo funciona la suspensión para intervención humana (Human-in-the-Loop)?

    Un nodo .wait() persiste la frontera de entrada esperada. Una acción submit_input válida puede continuar mediante una Session propia, viva o restaurada, si el workflow está registrado. Es reattach de frontera bajo demanda, no redispatch automático de trabajo.

  • ¿Qué es el patrón Transactional Outbox?

    La intención del efecto se confirma atómicamente con el estado de ejecución. El dispatcher actual, que corre en proceso, puede entregar el efecto más de una vez si se vuelve a despachar; no existe garantía exactly-once. El proveedor externo debe respetar la clave estable de idempotencia.

  • ¿Pueden múltiples canales interactuar con la misma sesión?

    Los canales pueden compartir contexto durable de Session. La continuación activa se serializa mediante revisiones y un proceso nuevo puede restaurar la Session propia en una frontera .wait() registrada. El trabajo de una capability interrumpida no se redispara automáticamente.