Por qué la IA debería proponer, no ejecutar

En la ingeniería de software, hemos pasado décadas construyendo sistemas con límites formales y rigurosos: las bases de datos relacionales garantizan transacciones ACID, los sistemas operativos separan el espacio de usuario del kernel, y los sistemas distribuidos se apoyan en relojes de eventos monótonos y protocolos de consenso.

Invariant parte de esas lecciones, no en oposición a ellas. El nuevo problema es que un componente de la aplicación ahora puede razonar de forma útil sin ser una fuente confiable de autoridad de ejecución.

El auge de los Modelos de Lenguaje introduce el no determinismo directamente en el núcleo de las aplicaciones. El no determinismo es invaluable para comprender lenguaje natural ambiguo, formular hipótesis y explorar árboles de decisión abiertos. Pero cuando se le otorga autoridad de ejecución autónoma sobre el estado persistente y los efectos secundarios en el mundo real, los sistemas se vuelven frágiles de forma predecible.

Tesis Central

Los modelos razonan. La infraestructura ejecuta.
El razonamiento puede ser probabilístico. El progreso no.
El rol de un control plane es convertir estas fronteras en parte del modelo de ejecución en lugar de dejarlas como composición artesanal a nivel de aplicación.

No reinventamos los sistemas distribuidos

Invariant no comenzó como un intento de reinventar motores de workflows, sistemas distribuidos o ejecución durable.

Comenzó con una pregunta distinta:

¿Cómo debe ser la arquitectura de una aplicación cuando parte de su razonamiento se delega a un modelo probabilístico?

Muchos de los mecanismos de ingeniería necesarios para responder esa pregunta no son nuevos. El event sourcing, el control de concurrencia optimista (OCC), la idempotencia, los outboxes transaccionales, las máquinas de estado duraderas, los reintentos y la compensación son lecciones que la industria del software ha desarrollado a lo largo de décadas.

Invariant se construye sobre esas ideas en lugar de reemplazarlas. Lo que cambia es el supuesto computacional alrededor del cual se componen.

La infraestructura tradicional fue diseñada alrededor de software cuya lógica de ejecución es autoritativa: el programa decide qué debe suceder y la infraestructura hace que esa ejecución sea confiable.

Un modelo probabilístico introduce una relación fundamentalmente distinta:

Software tradicional

Código de aplicación
       │
       │ expresa ejecución
       ▼
Infraestructura durable
       │
       ▼
Sistemas externos


Software probabilístico

Intención humana
       │
       ▼
Razonamiento probabilístico
       │
       │ propone
       ▼
Frontera de autoridad
       │
       │ valida + confirma
       ▼
Infraestructura durable
       │
       ▼
Sistemas externos

El modelo es útil precisamente porque no es determinista. Puede interpretar lenguaje ambiguo, razonar sobre información incompleta y elegir entre posibilidades.

El error no es introducir razonamiento probabilístico en el software. El error es permitir que el razonamiento probabilístico se convierta silenciosamente en ejecución autoritativa.

Invariant aplica principios probados de ingeniería de sistemas en esta nueva frontera:

La durabilidad protege el progreso.
El event sourcing preserva la verdad.
El control de concurrencia optimista (OCC) protege contra autoridad desactualizada.
Las proyecciones delimitan la observación y la exposición de datos.
Las Runtime Actions delimitan las propuestas permitidas.
Los esquemas validan la reentrada.
El Outbox protege la intención durable del efecto antes de la entrega.
La compensación asume que la realidad externa no se puede simplemente "deshacer".

En ese sentido, Invariant es nativo de IA no porque descarte la ingeniería de sistemas tradicional, sino porque reorganiza esas lecciones alrededor de una nueva primitiva: un razonador probabilístico que puede proponer qué hacer a continuación, pero que no tiene la autoridad para convertirlo en un hecho.

La ambigüedad del "Tool-Calling"

En muchas arquitecturas de agentes actuales, el llamado a herramientas colapsa el razonamiento y la ejecución dentro del mismo loop de aplicación:

[Prompt / Contexto] ──► [Inferencia LLM] ──► [Propuesta] ──► [Handler Directo en Memoria] ──► [Efecto Secundario]

Incluso cuando se valida el esquema, ejecutar efectos secundarios directamente desde el loop del modelo produce cuatro problemas críticos:

1. Autoridad sin verificación

El modelo decide tanto qué hacer como cuándo ejecutarlo. A menos que la aplicación construya explícitamente una frontera, el loop de herramientas no provee ninguna separación durable entre propuesta y efecto. Si el modelo alucina un parámetro o invoca una acción para la que el proceso de negocio no está listo, el efecto se dispara de inmediato.

2. Time-of-Check to Time-of-Use (El problema de la autoridad obsoleta)

La inferencia de un LLM no es instantánea: toma cientos de milisegundos o varios segundos. Durante esa ventana, la realidad externa avanza: una factura puede haberse pagado, una cita cancelado o un inventario agotado. Si la llamada del modelo se ejecuta sin validación de concurrencia optimista (STALE_REVISION), opera sobre una foto vieja del mundo, provocando race conditions silenciosas.

3. La ilusión del Rollback para APIs del mundo real

En bases de datos tradicionales, las operaciones fallidas se revierten con ROLLBACK. En el mundo real, no puedes "des-enviar" un correo o "des-cobrar" una tarjeta rebobinando la memoria del proceso. Deshacer una acción requiere compensación durable explícita (lifecycle.cancel): una ejecución que crea nuevos hechos históricos en vez de intentar reescribir el pasado.

4. Confundir observación con autoridad

Cuando se le entrega al agente el estado crudo y sin filtrar de la aplicación, surgen dos problemas: datos sensibles (PII, tokens de pago, métricas de riesgo) se filtran a los logs del proveedor del modelo, y el contexto sobrecargado aumenta la probabilidad de alucinación.

Las cuatro fronteras simétricas

Invariant resuelve estos desafíos componiendo mecanismos probados de ingeniería de sistemas alrededor de la frontera introducida por el razonamiento probabilístico. El resultado es un Control Plane de Ejecución estructurado en cuatro fronteras explícitas:

┌────────────────────────────────────────────────────────────────────────┐
│ 1. KNOWLEDGE / INGESTION BOUNDARY (Hydration & Session Context)        │
│    ¿Qué hechos externos son admitidos en el contexto del runtime?      │
├────────────────────────────────────────────────────────────────────────┤
│ 2. PROJECTION BOUNDARY (app.projection)                                │
│    ¿Qué se le permite observar a este consumidor o modelo?             │
│    (Minimización de contexto, redacción de PII, vistas por canal)      │
├────────────────────────────────────────────────────────────────────────┤
│ 3. AUTHORITY BOUNDARY (validActions & STALE_REVISION)                  │
│    ¿Qué se le permite proponer al modelo en este paso?                 │
│    (Acciones dinámicas, validación de esquema, frescura optimista)     │
├────────────────────────────────────────────────────────────────────────┤
│ 4. EXECUTION BOUNDARY (Workflows, PostgreSQL Event Sourcing, Outbox)   │
│    ¿Qué puede convertirse en progreso autoritativo y efectos reales?   │
│    (Log monótono, Outbox Transaccional, Compensación declarada)       │
└────────────────────────────────────────────────────────────────────────┘
Observa la secuencia estructural:

```text
ADMIT ──► EXPOSE ──► PROPOSE ──► COMMIT ──► EFFECT

ADMIT: La hidratación admite hechos externos bajo reglas definidas por la aplicación.
EXPOSE: Las proyecciones deciden qué subconjunto de la verdad duradera se expone a un canal (Voz, UI, Agente, MCP).
PROPOSE: Las Runtime Actions definen qué tiene permitido proponer el modelo.
COMMIT: El Kernel valida la propuesta contra el estado fresco y confirma la transición en el log inmutable de eventos.
EFFECT: El Outbox Transaccional confirma la intención antes de que el dispatcher actual, que corre en proceso, invoque el mundo exterior. El proveedor debe respetar claves estables de idempotencia; una ruta de compensación declarada no garantiza revertir el efecto externo.

Cómo se ve en código

import { invariant } from "@invariant-tech/sdk";
import { z } from "zod";

type AppContext = { clientInfo?: { firstName: string } };
const app = invariant<AppContext>();

// 1. PROYECCIÓN: Controlar la exposición (Sin PII, adaptada para voz)
export const bookingVoiceProjection = app.projection(
  "booking-voice",
  ({ session, runtime }) => ({
    customerName: session.context.clientInfo?.firstName ?? "there",
    spokenPrompt: runtime.expectedInput
      ? "¿Qué fecha te funciona mejor para tu visita?"
      : "Bienvenido a Boulevard Salon. ¿En qué puedo ayudarte?",
    voiceTools: toVoiceTools(runtime.validActions), // Espacio de acciones delimitado
  })
);

// 2. WORKFLOW Y COMPENSACIÓN: Controlar la ejecución y la realidad externa
export const bookingWorkflow = app.workflow("salon-booking", {
  description: "Gestiona la reserva de citas con depósito",
  lifecycle: {
    cancel: app.fragment("cancel-booking")
      .capability("release-slot", releaseSlot)
      .capability("void-auth", voidPaymentAuth),
  },
})
  .capability("reserve-slot", reserveSlot)
  .wait("await-user-confirmation", {
    schema: z.object({ confirmed: z.boolean(), notes: z.string().optional() }),
  })
  .capability("charge-deposit", chargeDeposit);

// 3. AGENTE: Proponer acciones (El modelo razona; el runtime impone la autoridad)
export const conciergeAgent = app.agent("concierge", {
  instructions: "Ayuda a los clientes a agendar citas. Nunca confirmes una reserva sin validación previa.",
  projection: bookingVoiceProjection,
  workflows: [bookingWorkflow],
});

Lo importante es lo que el modelo NO posee

El modelo ve:
  contexto proyectado (sin PII)
  + acciones actualmente válidas

El modelo propone:
  submit_input({ confirmed: true })

El runtime posee:
  autorización de la acción
  validación del esquema
  validación de frescura de revisión (OCC)
  confirmación durable del evento
  intención de outbox transaccional + despacho en proceso

Propuesta Inválida
        │
        ▼
     RECHAZO
        │
        ├── Cero mutación de estado
        ├── Cero registro en la historia
        └── Cero efecto secundario

Propuesta Válida
        │
        ▼
    CONFIRMACIÓN
        │
        ├── Historia durable en Postgres
        └── EFECTO (Despacho con Outbox + ruta de compensación declarada)

Tres supuestos de partida diferentes

El Axioma Central

El runtime es dueño de la verdad.
Las Proyecciones controlan la exposición.
Las Runtime Actions controlan la autoridad.
Las Capabilities entregan los efectos.

Invariant no es sistemas distribuidos reinventados para IA. Es lo que ocurre cuando aplicas con rigor esas lecciones después de que el razonamiento mismo se ha vuelto probabilístico.

José Vásquez