Why Invariant?

Building an AI agent is easy. Giving it real responsibility is hard.

"AI makes software probabilistic. Invariant makes its execution durable."

You can build a simple AI agent that answers questions in a few lines of code.

The challenge begins when you want that agent to take consequential actions in the real world:

Process a refund
Modify an account
Book an appointment
Approve a purchase request
Run a multi-hour data job
Wait for human approval
Preserve committed facts across a crash

When an agent takes real actions, critical infrastructure questions arise:

Did this external operation already execute?
Is this customer actually eligible for this operation?
Where in the business process is this execution right now?
What input is the application currently waiting for?
Should a failed external call be retried?
What is the model actually authorized to do?
What happened when an execution failed?

Invariant moves these responsibilities out of the model and into infrastructure.

---

4 Core Problems Invariant Solves

1. Models shouldn't be your application state

Traditional agent patterns stuff conversation history, tool calls, tool results, instructions, and application state into a single growing LLM prompt.

Traditional Agent:
conversation history + tool calls + results + instructions + app state → LLM

Invariant:
durable application state → relevant context projection → LLM

Invariant keeps durable state in the runtime and projects only the context required for the current decision.

Result: Smaller model prompts, lower token costs, and no reliance on asking an LLM to reconstruct where an application is from message transcripts.

2. Models shouldn't determine application truth

Giving an unconstrained LLM a raw refundCustomer() tool grants a probabilistic model direct authority over business actions and real money.

Traditional Tool Calling:
LLM ────────────────────────► refundCustomer($500)  (Direct authority over money)

In Invariant, an Agent interprets user intent ("My order arrived damaged") and requests starting an authoritative workflow:

Invariant Architecture:
User request ──► LLM Agent ──► "start refund workflow"
                                      │
                                      ▼
                               Refund Workflow
                                 ├─ Load real customer
                                 ├─ Load real order
                                 ├─ Apply deterministic policy
                                 └─ Issue refund only if eligible

The model can interpret intent without becoming the authority that determines truth.

3. Committed execution facts should outlive your server process

Node.js processes restart, servers crash, APIs time out, and users take hours to respond to prompts.

The store preserves committed facts when a process dies. A complete future or store-specific recovery path has this target shape:

Start workflow ──► Commit intent ──► 💀 Server Crash ──► Store-specific recovery host ──► Redispatch safely

Your process is temporary. Committed execution facts do not have to be.

With a durable configured store, Invariant persists workflow progress, execution position, and side-effect intent. The current Beta does not expose portable pending-command claim or execution-attach APIs and does not ship a background recovery worker. Therefore, persistence after a crash is supported, but public cross-process continuation is not. See the canonical Recovery Contract Matrix.

4. When AI fails, "the agent failed" isn't enough

When a production action goes wrong, you need to know exactly what happened:

Agent interpreted request
  ↓
Refund workflow started
  ↓
Customer loaded
  ↓
Order loaded
  ↓
Policy evaluated
  ↓
Refund approved
  ↓
issue-refund attempted
  ↓
External API failed (timeout)
  ↓
Store-specific recovery host reused the same application-owned provider request key (target architecture)
  ↓
Workflow completed

Invariant separates reasoning observability from execution observability.

You don't just know that an agent failed. You can know where, when, and at which boundary it failed.

---

The Core Idea

                  Probabilistic
                        │
                        ▼
                 ┌─────────────┐
                 │    Model    │
                 │   reasons   │
                 └──────┬──────┘
                        │
                   constrained
                     intent
                        │
                        ▼
                 ┌─────────────┐
                 │  Workflow   │
                 │defines truth│
                 └──────┬──────┘
                        │
                        ▼
                 ┌─────────────┐
                 │   Runtime   │
                 │  executes   │
                 └──────┬──────┘
                        │
                        ▼
                  Real systems

Models reason. Infrastructure executes.

---

Where Invariant Fits

If you primarily need...	Consider
General-purpose durable workflows across many programming languages	Temporal / Restate
Low-level graph orchestration and agent persistence	LangGraph
AI generation, prompt tools, and frontend streaming UI	Vercel AI SDK
TypeScript-first durable workflows where LLM intent, workflow truth, and runtime execution are explicit boundaries	Invariant

---

Go Deeper

• Introduction — Understand how Workflows, Agents, and .reason() nodes fit together in code.
• Mental Model — Explore the 6 core abstractions of the Invariant architecture.
• Quick Start — Build your first durable AI workflow in 5 minutes.