Models reason.Infrastructure executes.
Build AI agents that execute real business workflows—with controlled actions, traceable execution, and less context overhead. Our reusable framework helps your team focus on business rules, integrations, and customer experience.
Enterprises stay in control.
Your team builds the solution. Invariant provides the infrastructure and technical guidance, with an agreed scope.
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' })),});
Build your agents on Invariant, with technical guidance.
Our framework and runtime help your team focus on business rules, integrations, and customer experience. We support adoption with architecture and integration guidance; your team or integrator develops the final application.
Controlled execution
Bound operations with workflows, rules, permissions, and runtime validation according to the capabilities your application implements.
Execution visibility
Trace proposals, validation outcomes, transitions, actions, and recorded results without claiming access to a model's private reasoning.
Lower Token Overhead
Keep logic and authoritative state outside repetitive model context, then project only what the current decision needs. Lower token overhead is not a promise of lower total operating cost.
Faster implementation
Build on a reusable framework and runtime, with technical guidance for adoption and integration. Your team can focus development on business rules, integrations, and customer experience.
Your team develops the agent, user experience, integrations, and business rules, and validates the resulting application.
Access to the proprietary platform, framework, runtime, and documentation, plus technical guidance for architecture, adoption, and integration within an agreed scope.
- Append-only transactional event log
- Optimistic concurrency & lease locks
- Validation boundary gate on every action
- Transactional outbox intent with in-process dispatch
- Restorable .wait() boundaries; application-owned work recovery
What teams build with Invariant
Collections and e-commerce are applications your team can build on Invariant. The same infrastructure supports other business processes, using the workflows, rules, and integrations your team configures.
Collections
Build an agent that retrieves balances, presents permitted options, and guides customers through a controlled payment flow, using your rules and payment integrations.
E-commerce
Build an agent that looks up products, prepares orders, and guides purchases through your catalog and order integrations, while the runtime controls what may execute.
Shared business infrastructure
Reuse the same execution model across customer service, sales, and internal operations through web, voice, or messaging channels.
As agents move from demos to production, reliability leaks into the prompt.
Application state, execution progress, tool authority, retries, and recovery end up stuffed into conversation history.
More state
More prompt context & token bloat
More tools
Larger blast radius for model mistakes
Longer runs
Harder recovery & lost progress
More effects
Higher retry risk & duplicate actions
Models will make mistakes. Reliable systems are designed for that.
A human support agent can misunderstand a request even after years of training. We don't solve that by giving them unlimited authority and hoping they never make a mistake. We surround them with permissions, policies, workflows, and systems of record.
AI agents should be designed the same way.
Models should interpret, reason, and propose. The infrastructure around them should own state, validate authority, control execution, and recover when things fail.
Models can be wrong. That's unavoidable.
Giving them unlimited authority isn't.
Reliable systems don't require perfect decision-makers. They require reliable boundaries around them.
Let AI reason. Keep your application in control.
AI is probabilistic by nature. Your application doesn't have to inherit that uncertainty.
Invariant sits between probabilistic AI decisions and real application execution — validating what can happen, persisting state, and exposing explicit recovery primitives.
start_workflow("refund", { orderId })Defines what may happen
Explicit graph nodes, branch guards & transitions
Remembers what actually happened
Append-only event log & reducer materialization
Dispatches real-world actions through controlled boundaries
Transactional outbox & idempotency keys
"Models reason. Infrastructure executes."
Explore the full architecture in docs→Don't make the model remember application truth.
Hydrate from authoritative systems. Project only what the model needs now.
Hydration defines where truth comes from. Projection defines how much of that truth and execution state the model sees right now.
Authoritative application state cached and refreshed from source systems
Turn-scoped facts, policies, and actions without token bloat
Six hours later. Step 80.
The model doesn't need six hours of history.
Traditional Agent
History AccumulationExecution history becomes model context.
More history, more tokens, and more context the model must reconcile.
Invariant Runtime
Execution BoundaryExecution history remains runtime state.
The model receives only the active goal, relevant prior facts, expected schema, and allowed actions.
"The execution can be hours old. The model context doesn't have to be."
Don't eliminate AI uncertainty. Contain it.
Models will misunderstand intent, omit required data, choose invalid actions, and occasionally reason from stale state. Invariant assumes this will happen. The Runtime determines whether a proposal is allowed to become execution.
{ title: "Quarterly Report" }{ title: "Quarterly Report", sections: ["Q1 Summary", "Revenue"] }Reasoning may be probabilistic. Progress is not.
Invalid reasoning outputs become feedback, not application state.
Sequential Layers of Containment
See what matters now, not the entire execution history.
Propose only actions available at the current execution boundary.
Invalid outputs cannot advance execution.
Stale decisions are rejected if execution changed while the model was reasoning.
One execution layer.
Multiple interaction channels.
Channels are ways to interact with an agent—not separate Invariant products.
Applications can connect web, voice, messaging, APIs, and external webhooks through configured adapters while sharing durable Session context. A registered .wait() can continue through a restored owned Session; interrupted command work requires application-owned recovery code.
Examples teams can build
Voice & Live Audio Call Centers
Keep call state and transaction progress durable across audio drops, SMS, email, and human handoffs.
Customer Support & Operations
Persist approval boundaries and customer input while the live Session coordinates continuation.
Autonomous System Integrations
Build long-lived workflows with validated actions, transactional outbox intent, leases, and application-owned recovery orchestration.
This sounds like a lot of infrastructure. You don't have to build it.
Durable infrastructure without turning your application code into infrastructure code.
Define type-safe workflows, agents, and capabilities. Invariant persists state, event history, and command intent, validates revisions, and dispatches committed commands in process. Cross-process recovery orchestration remains application-owned in the current release.
import { z } from 'zod';import { app } from './app';// Clean, type-safe workflow definitionexport 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,});
Invariant Handles Underneath
Durable systems engineering, abstracted behind the SDK.
Models reason. Infrastructure executes.
Move state, execution, authority, and recovery primitives out of the model into deterministic infrastructure.
The ideas behind Invariant.
Essays on AI execution, durable state, context, and building reliable systems around probabilistic models.
Why AI Should Propose, Not Execute
Why the fundamental missing boundary in production AI is not orchestration syntax, but the structural separation between probabilistic reasoning and authoritative execution.
Why Agents Need a Deterministic Runtime
Probabilistic models are great for reasoning, but terrible at execution. Infrastructure must enforce the execution boundary.
Context Is Not Memory: Why Durable Agent Memory Must Be Infrastructure
LLMs reason over working context. Durable application memory, idempotency, and state persistence belong in deterministic infrastructure.
Failure modes your runtime should handle—not your model.
Production agents fail when reliability is left to prompt instructions. Invariant contains execution failures at the infrastructure boundary.
Lost Progress on Crash
Hallucinated Tool Mutations
Token Explosion
Concurrent Race Conditions
Human-in-the-Loop Breaks
Frequently asked questions
How to build on Invariant, what our technical guidance covers, and how the runtime works.
What is Invariant?
Invariant is proprietary, horizontal AI-native infrastructure: a TypeScript framework and durable runtime for agents that execute real business workflows within deterministic boundaries.
How is Invariant offered?
Invariant provides proprietary infrastructure, a framework, a runtime, documentation, and technical guidance for architecture, adoption, and integration. We agree the scope of that guidance during evaluation, along with SDK access, deployment, platform support, and commercial terms.
Who develops the final application?
Your team or integrator develops the agent, user experience, external integrations, and business rules, and validates the application. Implementation requires engineering capacity: involve your technology team or an integrator alongside the business team evaluating the use case.
What does technical guidance cover?
Within an agreed scope, we can advise on architecture, explain framework integration, review workflows, and support a proof of concept. Initial guidance and additional assistance are agreed separately. End-to-end custom application development, maintenance of your application, and operation of your business process are not included by default. Support and maintenance of the Invariant platform have their own agreed terms.
How does Invariant differ from LangChain, LangGraph, or CrewAI?
Most frameworks treat the model as the execution authority. Invariant moves state, execution, and side-effects out of the model and into infrastructure. Models propose Runtime Actions; the Invariant Runtime validates and executes them through immutable workflow graphs.
Why does Invariant reduce token usage?
Instead of re-sending full conversation histories on every turn, Invariant stores authoritative state in the runtime and projects only the context and actions relevant to the current decision. This reduces repetitive context; total cost still depends on the application and models used.
How does crash recovery work?
Invariant stores committed state, append-only events, command intent, leases, and runnable execution IDs. A new process can restore an owned Session at a registered .wait() boundary. The current release does not expose portable command claim or arbitrary-run work attachment, and it does not ship a background recovery worker.
Does Invariant support multiple LLM providers?
Yes. Invariant ships adapters for OpenAI, Anthropic, and Google Gemini, including Gemini Live WebSockets. Local providers such as Ollama or vLLM can be integrated through a custom ModelAdapter.
How does Human-in-the-Loop suspension work?
A .wait() node persists the expected input boundary. A valid submit_input action can continue through a live or restored owned Session when the workflow graph is registered. This is request-driven boundary reattachment, not background work redispatch.
What is the Transactional Outbox pattern?
Side-effect intent is committed atomically with execution state. The current in-process dispatcher may deliver an effect more than once if it is redispatched; there is no exactly-once guarantee. The external provider must honor the stable idempotency key.
Can multiple channels interact with the same session?
Channels can share durable Session context. Active workflow continuation is serialized with revisions, and a new process can restore the owned Session at a registered .wait() boundary. Interrupted capability work is not automatically redispatched.