Why AI Should Propose, Not Execute

In software engineering, we have spent decades constructing systems with crisp, formal boundaries: relational databases guarantee ACID transactions, operating systems enforce kernel vs. user-space privilege separation, and distributed systems rely on monotonic event clocks and consensus protocols.

Invariant starts from those lessons, not in opposition to them. The new problem is that one component of the application can now reason usefully without being a reliable source of execution authority.

The rise of Large Language Models introduces non-determinism directly into the core loop of application software. Non-determinism is valuable when understanding ambiguous natural language, formulating hypotheses, and evaluating open-ended options. But when non-determinism is given autonomous execution authority over persistent state and real-world side effects, systems become fragile in predictable ways.

We Didn't Reinvent Distributed Systems

Invariant did not begin as an attempt to reinvent workflow engines, distributed systems, or durable execution.

It began with a different question:

What should the architecture of an application look like when part of its reasoning is delegated to a probabilistic model?

Many of the engineering mechanisms required to answer that question are not new. Event sourcing, optimistic concurrency control, idempotency, transactional outboxes, durable state machines, retries, and compensation are lessons the software industry has developed over decades.

Invariant builds on those ideas rather than replacing them. What changes is the computational assumption around which they are composed.

Traditional application infrastructure was largely designed around software whose execution logic is authoritative: the program decides what should happen, and infrastructure makes that execution reliable.

A probabilistic model introduces a fundamentally different relationship:

Traditional software

Application code
      │
      │ expresses execution
      ▼
Durable infrastructure
      │
      ▼
External systems


Probabilistic software

Human intent
      │
      ▼
Probabilistic reasoning
      │
      │ proposes
      ▼
Authority boundary
      │
      │ validates + commits
      ▼
Durable infrastructure
      │
      ▼
External systems

The model is useful precisely because it is not deterministic. It can interpret ambiguous language, reason over incomplete information, and choose among possibilities.

The mistake is not introducing probabilistic reasoning into software. The mistake is allowing probabilistic reasoning to silently become authoritative execution.

Invariant applies proven systems-engineering principles at this new boundary:

• Durability protects progress.
• Event sourcing preserves truth.
• Optimistic Concurrency Control (OCC) protects against stale authority.
• Projections constrain observation.
• Runtime Actions constrain proposals.
• Schemas validate re-entry.
• The Outbox protects durable effect intent before delivery.
• Compensation acknowledges that external reality cannot simply be rolled back.

In that sense, Invariant is AI-native not because it discards traditional systems engineering, but because it reorganizes those lessons around a new primitive: a probabilistic reasoner that may propose what happens next, but does not own the authority to make it true.

The Ambiguity of "Tool-Calling"

In many agent architectures, tool-calling ultimately collapses reasoning and execution into the same application loop:

[Prompt / Context] ──► [LLM Inference] ──► [Tool Proposal] ──► [Direct In-Memory Handler] ──► [Side Effect]

Even when schema validation is attached, executing side-effecting handlers directly from the model inference loop produces four distinct systems engineering problems:

1. Authority Without Verification

The model decides both what to do and when to execute it. Unless the application explicitly builds such a boundary, the tool loop itself provides no durable execution boundary between proposal and effect. If a model hallucinates a parameter or calls a tool for which the business process is not ready, the side effect executes immediately.

2. Time-of-Check to Time-of-Use (The Stale Authority Problem)

LLM reasoning is not instantaneous—it takes hundreds of milliseconds to several seconds. During that inference window, external reality moves forward: an invoice may be paid, an appointment slot booked, or a transaction cancelled. If the model's tool call is executed without optimistic concurrency verification (STALE_REVISION), it operates on a stale snapshot of reality, producing silent race conditions.

3. The Illusion of Database Rollback for External APIs

In traditional databases, failed multi-step operations are cleanly unwound with ROLLBACK. In the real world, you cannot "un-send" a confirmation email or "un-charge" a credit card by rewinding process memory. Undoing an action requires explicit, durable compensation (lifecycle.cancel)—an execution that creates new historical facts rather than attempting to rewrite the past.

4. Conflating Observation with Authority

When an agent is given the raw, unrestricted state of the application, two problems compound: sensitive data (PII, billing tokens, internal risk metrics) leaks into third-party model logs, and the expanded context window increases the likelihood of model confusion.

The Four Symmetrical Boundaries

Invariant addresses these challenges by composing proven systems-engineering mechanisms around the boundary introduced by probabilistic reasoning. The result is an Execution Control Plane structured around four explicit boundaries:

┌────────────────────────────────────────────────────────────────────────┐
│ 1. KNOWLEDGE / INGESTION BOUNDARY (Hydration & Session Context)        │
│    What external facts are admitted into runtime context?              │
├────────────────────────────────────────────────────────────────────────┤
│ 2. PROJECTION BOUNDARY (app.projection)                                │
│    What may this consumer or model observe?                            │
│    (Context Minimization, PII Redaction, Channel Views)                │
├────────────────────────────────────────────────────────────────────────┤
│ 3. AUTHORITY BOUNDARY (validActions & STALE_REVISION)                  │
│    What may this consumer or model propose next?                       │
│    (Dynamic action spaces, schema validation, optimistic freshness)    │
├────────────────────────────────────────────────────────────────────────┤
│ 4. EXECUTION BOUNDARY (Workflows, PostgreSQL Event Sourcing, Outbox)   │
│    What may become authoritative progress and external side effects?   │
│    (Monotonic event logs, Transactional Outbox, Declared Compensation) │
└────────────────────────────────────────────────────────────────────────┘
Notice the structural sequence:

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

• ADMIT: Hydration admits external facts into runtime context under application-defined rules.
• EXPOSE: Projections decide what subset of durable truth is exposed to a channel (Voice, UI, Agent, MCP).
• PROPOSE: Runtime Actions define what the model is permitted to propose.
• COMMIT: The Kernel validates the proposal against fresh state and commits the transition to the immutable event log.
• EFFECT: The Transactional Outbox commits side-effect intent before the current in-process dispatcher invokes the outside world. Providers must honor stable idempotency keys; declared compensation paths do not guarantee an external reversal.

How It Looks in Code

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

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

// 1. PROJECTION: Control Exposure (No PII, tailored for voice)
export const bookingVoiceProjection = app.projection(
  "booking-voice",
  ({ session, runtime }) => ({
    customerName: session.context.clientInfo?.firstName ?? "there",
    spokenPrompt: runtime.expectedInput
      ? "Which date works best for your visit?"
      : "Welcome to Boulevard Salon. How can I help you?",
    voiceTools: toVoiceTools(runtime.validActions), // Strictly bounded action space
  })
);

// 2. WORKFLOW & COMPENSATION: Control Execution & External Reality
export const bookingWorkflow = app.workflow("salon-booking", {
  description: "Handles salon appointment booking with deposit",
  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. AGENT: Propose Actions (The model reasons; the runtime enforces authority)
export const conciergeAgent = app.agent("concierge", {
  instructions: "Help clients schedule salon services. Never promise a booking without confirmation.",
  projection: bookingVoiceProjection,
  workflows: [bookingWorkflow],
});

The Important Part is What the Model Does Not Own

Model sees:
  projected context (PII-redacted)
  + currently valid actions

Model proposes:
  submit_input({ confirmed: true })

Runtime owns:
  action authorization
  schema validation
  revision freshness validation (OCC)
  durable event commit
  transactional outbox intent + in-process dispatch

Invalid Proposal
      │
      ▼
   REJECT
      │
      ├── No state mutation
      ├── No event history
      └── No side effect

Valid Proposal
      │
      ▼
   COMMIT
      │
      ├── Durable event history
      └── EFFECT (Outbox dispatch + declared compensation path)

Three Different Starting Assumptions

| Paradigm | Computational Premise | Execution Relationship | | :--- | :--- | :--- | | Traditional Workflows (Temporal, Cadence) | Deterministic program logic | Program code $\longrightarrow$ Reliable execution | | Agent Frameworks (LangChain, CrewAI) | Autonomous model driving tools | Model $\longrightarrow$ Tools $\longrightarrow$ In-memory loop | | Invariant Control Plane | Probabilistic reasoning requiring explicit authority boundaries | Model (Proposes) $\longrightarrow$ Authority Boundary (Validates) $\longrightarrow$ Durable Execution |

The Core Axiom

The runtime owns truth.
Projections control exposure.
Runtime Actions control authority.
Capabilities deliver effects.

Invariant isn't distributed systems reinvented for AI. It is what happens when you take those lessons seriously after reasoning itself becomes probabilistic.