Most AI agent runtimes currently follow the same execution pattern:

LLM -> tool call -> runtime executes side-effect

That works reasonably well for read-only tasks. But once agents start mutating external state (payments, databases, infrastructure, PII), the execution model becomes difficult to reason about operationally.

While preparing some of our internal agents, we ended up separating reasoning from execution authority entirely.

We built nano-vm: a deterministic FSM runtime where:

• the model proposes actions,
• but the runtime controls state transitions and side-effects.

The runtime enforces:

• finite execution graphs,
• compile-time step ordering,
• capability-gated tools,
• replay/idempotency boundaries,
• append-only audit history.

One design choice that turned out important:
the policy layer is intentionally less expressive than Python.

We removed eval-style execution entirely and constrained policies to a small deterministic AST subset:

• simple operators,
• no loops,
• no system calls.

That limitation simplified auditability and removed several classes of runtime behavior we did not want in financial-style workflows.

To test failure semantics, we added a Sabotage Mode with several adversarial cases:

• unauthorized tool injection,
• replay attempts,
• hash corruption,
• skipped transitions.

The most useful property operationally so far has probably been deterministic replay boundaries around side-effects.

We also had to deal with an awkward compliance problem:
preserving immutable audit chains while supporting GDPR-style erasure requests.

Our current approach replaces vault references with tombstones while preserving hash continuity and referential integrity.

I'm mostly curious how others are handling execution authority in stateful agent systems.

Are you letting the model directly drive side-effects, or inserting a deterministic control layer in between?

I'll drop the GitHub links to the core runtime and MCP layer in the comments if anyone wants to look at the implementation.

Most AI agent runtimes currently follow the same execution pattern:

LLM -> tool call -> runtime executes side-effect

That works reasonably well for read-only tasks. But once agents start mutating external state (payments, databases, infrastructure, PII), the execution model becomes difficult to reason about operationally.

While preparing some of our internal agents for white-label deployment, we ended up separating reasoning from execution authority entirely.

We built nano-vm: a deterministic FSM runtime where:

• the model proposes actions,
• but the runtime controls state transitions and side-effects.

The runtime enforces:

• finite execution graphs,
• compile-time step ordering,
• capability-gated tools,
• replay/idempotency boundaries,
• append-only audit history.

One design choice that turned out important:
the policy layer is intentionally less expressive than Python.

We removed eval-style execution entirely and constrained policies to a small deterministic AST subset:

• simple operators,
• no loops,
• no system calls.

That limitation simplified auditability and removed several classes of runtime behavior we did not want in financial-style workflows.

To test failure semantics, we added a Sabotage Mode with several adversarial cases:

• unauthorized tool injection,
• replay attempts,
• hash corruption,
• skipped transitions.

The most useful property operationally so far has probably been deterministic replay boundaries around side-effects.

We also had to deal with an awkward compliance problem:
preserving immutable audit chains while supporting GDPR-style erasure requests.

Our current approach replaces vault references with tombstones while preserving hash continuity and referential integrity.

I'm mostly curious how others are handling execution authority in stateful agent systems.

Are you letting the model directly drive side-effects, or inserting a deterministic control layer in between?

I'll drop the GitHub links to the core runtime and MCP layer in the comments if anyone wants to look at the implementation.

Most AI agent runtimes currently follow the same execution pattern:

LLM -> tool call -> runtime executes side-effect

That works reasonably well for read-only tasks. But once agents start mutating external state (payments, databases, infrastructure, PII), the execution model becomes difficult to reason about operationally.

While preparing some of our internal agents for white-label deployment, we ended up separating reasoning from execution authority entirely.

We built nano-vm: a deterministic FSM runtime where:

• the model proposes actions,
• but the runtime controls state transitions and side-effects.

The runtime enforces:

• finite execution graphs,
• compile-time step ordering,
• capability-gated tools,
• replay/idempotency boundaries,
• append-only audit history.

One design choice that turned out important:
the policy layer is intentionally less expressive than Python.

We removed eval-style execution entirely and constrained policies to a small deterministic AST subset:

• simple operators,
• no loops,
• no system calls.

That limitation simplified auditability and removed several classes of runtime behavior we did not want in financial-style workflows.

To test failure semantics, we added a Sabotage Mode with several adversarial cases:

• unauthorized tool injection,
• replay attempts,
• hash corruption,
• skipped transitions.

The most useful property operationally so far has probably been deterministic replay boundaries around side-effects.

We also had to deal with an awkward compliance problem:
preserving immutable audit chains while supporting GDPR-style erasure requests.

Our current approach replaces vault references with tombstones while preserving hash continuity and referential integrity.

I'm mostly curious how others are handling execution authority in stateful agent systems.

Are you letting the model directly drive side-effects, or inserting a deterministic control layer in between?

I'll drop the GitHub links to the core runtime and MCP layer in the comments if anyone wants to look at the implementation.

Most AI agent runtimes currently follow the same execution pattern:

LLM -> tool call -> runtime executes side-effect

That works reasonably well for read-only tasks. But once agents start mutating external state (payments, databases, infrastructure, PII), the execution model becomes difficult to reason about operationally.

While preparing some of our internal agents, we ended up separating reasoning from execution authority entirely.

We built nano-vm: a deterministic FSM runtime where:

• the model proposes actions,
• but the runtime controls state transitions and side-effects.

The runtime enforces:

• finite execution graphs,
• compile-time step ordering,
• capability-gated tools,
• replay/idempotency boundaries,
• append-only audit history.

One design choice that turned out important:
the policy layer is intentionally less expressive than Python.

We removed eval-style execution entirely and constrained policies to a small deterministic AST subset:

• simple operators,
• no loops,
• no system calls.

That limitation simplified auditability and removed several classes of runtime behavior we did not want in financial-style workflows.

To test failure semantics, we added a Sabotage Mode with several adversarial cases:

• unauthorized tool injection,
• replay attempts,
• hash corruption,
• skipped transitions.

The most useful property operationally so far has probably been deterministic replay boundaries around side-effects.

We also had to deal with an awkward compliance problem:
preserving immutable audit chains while supporting GDPR-style erasure requests.

Our current approach replaces vault references with tombstones while preserving hash continuity and referential integrity.

I'm mostly curious how others are handling execution authority in stateful agent systems.

Are you letting the model directly drive side-effects, or inserting a deterministic control layer in between?

[ Removed by Reddit on account of violating the content policy. ]

[ Removed by Reddit on account of violating the content policy. ]

[ Removed by Reddit on account of violating the content policy. ]

[ Removed by Reddit on account of violating the content policy. ]

[ Removed by Reddit on account of violating the content policy. ]

nano-vm v0.7.3 / nano-vm-mcp v0.3.0

A previous article on programmable execution semantics for LLM systems triggered strongly polarized reactions. Some readers viewed the proposed architecture as excessive rigidity for probabilistic AI agents. Others recognized it as a missing execution layer between stochastic planners and production infrastructure.

The discussion exposed a more fundamental problem:

>the industry still conflates semantic nondeterminism with execution nondeterminism.

These are not the same thing.

An LLM may be probabilistic. A production execution system should not be.

This distinction is the core architectural direction behind nano-vm.

Core Thesis

The project is built around three foundational assumptions:

1. LLMs are probabilistic signal decoders, not execution authorities.
2. Execution semantics must remain deterministic even when model behavior is stochastic.
3. The hard problem is distributed systems for stochastic actors.

In other words:

• models may propose different trajectories,
• planners may be nondeterministic,
• semantic outputs may drift,

but:

• state transitions,
• persistence,
• replay,
• governance,
• recovery semantics,
• execution invariants

must remain reproducible and structurally constrained.

From Agent Orchestration to Deterministic Execution Substrate

nano-vm is evolving away from a traditional “agent orchestration framework” toward a deterministic execution substrate for stochastic systems.

The separation of responsibilities is explicit:

Component	Nature
Planner	Stochastic
Validator	Deterministic
Policy Layer	Deterministic
Execution VM	Deterministic FSM

The critical boundary is:

• semantic determinism is not guaranteed,
• state determinism is guaranteed.

The Execution VM remains the source of truth regardless of planner behavior.

Execution Pipeline

The execution model is formalized as:

where:

• EE — incoming event,
• E′E′ — normalized event,
• A(S)A(S) — admissible action set,
• a∗a∗ — selected action,
• δ(S,a∗)δ(S,a∗) — deterministic state transition.

Stochasticity is allowed only during action selection.

Transition semantics themselves remain deterministic.

What Changed in nano-vm v0.7.3 / nano-vm-mcp v0.3.0

This release focuses on execution invariants rather than “smart agent” abstractions.

Main areas:

• FSM execution invariants
• deterministic replay
• crash consistency
• suspend/resume semantics
• append-only traces
• MCP-governed execution
• governance envelopes
• observable execution flows

nano-vm-mcp also begins shifting the system from a library toward an execution platform with externally governed runtime control.

Benchmarks: Testing Invariants, Not Model Intelligence

These are not model-quality benchmarks.

They are execution-invariant benchmarks.

The goal is to validate:

• replay equivalence,
• duplicate resistance,
• crash recovery semantics,
• invariant preservation,
• idempotent execution behavior.

Methodology

The runtime is treated as a state transition system rather than an agent loop.

Testing includes:

• fixed seeds,
• append-only traces,
• replay equivalence checks,
• out-of-order event injection,
• adversarial duplicate delivery,
• crash/recovery cycles,
• bounded-state validation.

Environment

• QEMU/KVM
• Intel Xeon E5-2697A v4
• 2 cores / 2 threads
• 2GB ECC RAM
• Python 3.12
• Mock adapter
• No network I/O

The environment is intentionally constrained to measure runtime semantics rather than infrastructure variability.

Results

Total workload:

• 10 scenarios
• 3 cycles
• 5 runs
• 10,000 elements

Total:

Results:

Metric	Result
Replay equivalence	100.00% trace hash match
Invariant violations	0
Invalid resumes	0
Double executions	0
Adversarial retry violations	0

These results indicate:

• replay behavior is deterministic,
• duplicate execution is suppressed,
• crash recovery preserves valid state,
• execution semantics remain stable under stochastic planning behavior.

Why This Matters

Many current agent frameworks blur the boundary between:

• reasoning,
• planning,
• execution authority.

This often leads to:

• non-replayable failures,
• hidden state drift,
• duplicate tool execution,
• inconsistent recovery,
• non-auditable behavior.

nano-vm is built around the opposite principle:

>

A planner may:

• propose continuations,
• extend trajectories,
• trigger replanning,

but it must not:

• mutate runtime invariants,
• bypass governance,
• violate the append-only execution model.

Current Focus

The current development focus is on observability:

• real-time trace visualization,
• live execution graph streaming,
• observable replay,
• trace export pipelines.

The goal is to make execution semantics visually inspectable rather than hidden behind opaque “agent loop” abstractions.

Roadmap

v0.8.x

ProgramValidator

Static analysis for execution graphs:

• unreachable states,
• invalid transitions,
• missing branch targets,
• mandatory guardrail reachability,
• cycle analysis.

depends_on + TopologicalSorter

Declarative dependency DAGs layered on top of existing parallel execution semantics.

v0.9.x

replan_on_interrupt

Trajectory continuation after:

• BUDGET_EXCEEDED
• STALLED

without weakening VM invariants.

Architectural Boundary

We are not trying to make stochastic systems deterministic.

We are trying to make their execution:

• observable,
• reproducible,
• structurally constrained.

Probabilistic components should not become sources of execution authority.

We believe this separation between:

• stochastic planning,
• deterministic execution,

is a necessary next step for production-grade LLM infrastructure.

Verifiability Matters More Than Claims

nano-vm and nano-vm-mcp are open projects.

Anyone can:

• download the packages,
• reproduce benchmark scenarios,
• verify replay semantics,
• test suspend/resume behavior,
• inspect duplicate-execution resistance,
• analyze trace behavior directly.

We value engineering feedback, architectural criticism, and technical discussion around execution semantics for stochastic systems.

nano-vm v0.7.3 / nano-vm-mcp v0.3.0

A previous article on programmable execution semantics for LLM systems triggered strongly polarized reactions. Some readers viewed the proposed architecture as excessive rigidity for probabilistic AI agents. Others recognized it as a missing execution layer between stochastic planners and production infrastructure.

The discussion exposed a more fundamental problem:

>the industry still conflates semantic nondeterminism with execution nondeterminism.

These are not the same thing.

An LLM may be probabilistic. A production execution system should not be.

This distinction is the core architectural direction behind nano-vm.

Core Thesis

The project is built around three foundational assumptions:

1. LLMs are probabilistic signal decoders, not execution authorities.
2. Execution semantics must remain deterministic even when model behavior is stochastic.
3. The hard problem is distributed systems for stochastic actors.

In other words:

• models may propose different trajectories,
• planners may be nondeterministic,
• semantic outputs may drift,

but:

• state transitions,
• persistence,
• replay,
• governance,
• recovery semantics,
• execution invariants

must remain reproducible and structurally constrained.

From Agent Orchestration to Deterministic Execution Substrate

nano-vm is evolving away from a traditional “agent orchestration framework” toward a deterministic execution substrate for stochastic systems.

The separation of responsibilities is explicit:

Component	Nature
Planner	Stochastic
Validator	Deterministic
Policy Layer	Deterministic
Execution VM	Deterministic FSM

The critical boundary is:

• semantic determinism is not guaranteed,
• state determinism is guaranteed.

The Execution VM remains the source of truth regardless of planner behavior.

Execution Pipeline

The execution model is formalized as:

where:

• EE — incoming event,
• E′E′ — normalized event,
• A(S)A(S) — admissible action set,
• a∗a∗ — selected action,
• δ(S,a∗)δ(S,a∗) — deterministic state transition.

Stochasticity is allowed only during action selection.

Transition semantics themselves remain deterministic.

What Changed in nano-vm v0.7.3 / nano-vm-mcp v0.3.0

This release focuses on execution invariants rather than “smart agent” abstractions.

Main areas:

• FSM execution invariants
• deterministic replay
• crash consistency
• suspend/resume semantics
• append-only traces
• MCP-governed execution
• governance envelopes
• observable execution flows

nano-vm-mcp also begins shifting the system from a library toward an execution platform with externally governed runtime control.

Benchmarks: Testing Invariants, Not Model Intelligence

These are not model-quality benchmarks.

They are execution-invariant benchmarks.

The goal is to validate:

• replay equivalence,
• duplicate resistance,
• crash recovery semantics,
• invariant preservation,
• idempotent execution behavior.

Methodology

The runtime is treated as a state transition system rather than an agent loop.

Testing includes:

• fixed seeds,
• append-only traces,
• replay equivalence checks,
• out-of-order event injection,
• adversarial duplicate delivery,
• crash/recovery cycles,
• bounded-state validation.

Environment

• QEMU/KVM
• Intel Xeon E5-2697A v4
• 2 cores / 2 threads
• 2GB ECC RAM
• Python 3.12
• Mock adapter
• No network I/O

The environment is intentionally constrained to measure runtime semantics rather than infrastructure variability.

Results

Total workload:

• 10 scenarios
• 3 cycles
• 5 runs
• 10,000 elements

Total:

Results:

Metric	Result
Replay equivalence	100.00% trace hash match
Invariant violations	0
Invalid resumes	0
Double executions	0
Adversarial retry violations	0

These results indicate:

• replay behavior is deterministic,
• duplicate execution is suppressed,
• crash recovery preserves valid state,
• execution semantics remain stable under stochastic planning behavior.

Why This Matters

Many current agent frameworks blur the boundary between:

• reasoning,
• planning,
• execution authority.

This often leads to:

• non-replayable failures,
• hidden state drift,
• duplicate tool execution,
• inconsistent recovery,
• non-auditable behavior.

nano-vm is built around the opposite principle:

>

A planner may:

• propose continuations,
• extend trajectories,
• trigger replanning,

but it must not:

• mutate runtime invariants,
• bypass governance,
• violate the append-only execution model.

Current Focus

The current development focus is on observability:

• real-time trace visualization,
• live execution graph streaming,
• observable replay,
• trace export pipelines.

The goal is to make execution semantics visually inspectable rather than hidden behind opaque “agent loop” abstractions.

Roadmap

v0.8.x

ProgramValidator

Static analysis for execution graphs:

• unreachable states,
• invalid transitions,
• missing branch targets,
• mandatory guardrail reachability,
• cycle analysis.

depends_on + TopologicalSorter

Declarative dependency DAGs layered on top of existing parallel execution semantics.

v0.9.x

replan_on_interrupt

Trajectory continuation after:

• BUDGET_EXCEEDED
• STALLED

without weakening VM invariants.

Architectural Boundary

We are not trying to make stochastic systems deterministic.

We are trying to make their execution:

• observable,
• reproducible,
• structurally constrained.

Probabilistic components should not become sources of execution authority.

We believe this separation between:

• stochastic planning,
• deterministic execution,

is a necessary next step for production-grade LLM infrastructure.

Verifiability Matters More Than Claims

nano-vm and nano-vm-mcp are open projects.

Anyone can:

• download the packages,
• reproduce benchmark scenarios,
• verify replay semantics,
• test suspend/resume behavior,
• inspect duplicate-execution resistance,
• analyze trace behavior directly.

We value engineering feedback, architectural criticism, and technical discussion around execution semantics for stochastic systems.

nano-vm v0.7.3 / nano-vm-mcp v0.3.0

A previous article on programmable execution semantics for LLM systems triggered strongly polarized reactions. Some readers viewed the proposed architecture as excessive rigidity for probabilistic AI agents. Others recognized it as a missing execution layer between stochastic planners and production infrastructure.

The discussion exposed a more fundamental problem:

>the industry still conflates semantic nondeterminism with execution nondeterminism.

These are not the same thing.

An LLM may be probabilistic. A production execution system should not be.

This distinction is the core architectural direction behind nano-vm.

Core Thesis

The project is built around three foundational assumptions:

1. LLMs are probabilistic signal decoders, not execution authorities.
2. Execution semantics must remain deterministic even when model behavior is stochastic.
3. The hard problem is distributed systems for stochastic actors.

In other words:

• models may propose different trajectories,
• planners may be nondeterministic,
• semantic outputs may drift,

but:

• state transitions,
• persistence,
• replay,
• governance,
• recovery semantics,
• execution invariants

must remain reproducible and structurally constrained.

From Agent Orchestration to Deterministic Execution Substrate

nano-vm is evolving away from a traditional “agent orchestration framework” toward a deterministic execution substrate for stochastic systems.

The separation of responsibilities is explicit:

Component	Nature
Planner	Stochastic
Validator	Deterministic
Policy Layer	Deterministic
Execution VM	Deterministic FSM

The critical boundary is:

• semantic determinism is not guaranteed,
• state determinism is guaranteed.

The Execution VM remains the source of truth regardless of planner behavior.

Execution Pipeline

The execution model is formalized as:

where:

• EE — incoming event,
• E′E′ — normalized event,
• A(S)A(S) — admissible action set,
• a∗a∗ — selected action,
• δ(S,a∗)δ(S,a∗) — deterministic state transition.

Stochasticity is allowed only during action selection.

Transition semantics themselves remain deterministic.

What Changed in nano-vm v0.7.3 / nano-vm-mcp v0.3.0

This release focuses on execution invariants rather than “smart agent” abstractions.

Main areas:

• FSM execution invariants
• deterministic replay
• crash consistency
• suspend/resume semantics
• append-only traces
• MCP-governed execution
• governance envelopes
• observable execution flows

nano-vm-mcp also begins shifting the system from a library toward an execution platform with externally governed runtime control.

Benchmarks: Testing Invariants, Not Model Intelligence

These are not model-quality benchmarks.

They are execution-invariant benchmarks.

The goal is to validate:

• replay equivalence,
• duplicate resistance,
• crash recovery semantics,
• invariant preservation,
• idempotent execution behavior.

Methodology

The runtime is treated as a state transition system rather than an agent loop.

Testing includes:

• fixed seeds,
• append-only traces,
• replay equivalence checks,
• out-of-order event injection,
• adversarial duplicate delivery,
• crash/recovery cycles,
• bounded-state validation.

Environment

• QEMU/KVM
• Intel Xeon E5-2697A v4
• 2 cores / 2 threads
• 2GB ECC RAM
• Python 3.12
• Mock adapter
• No network I/O

The environment is intentionally constrained to measure runtime semantics rather than infrastructure variability.

Results

Total workload:

• 10 scenarios
• 3 cycles
• 5 runs
• 10,000 elements

Total:

Results:

Metric	Result
Replay equivalence	100.00% trace hash match
Invariant violations	0
Invalid resumes	0
Double executions	0
Adversarial retry violations	0

These results indicate:

• replay behavior is deterministic,
• duplicate execution is suppressed,
• crash recovery preserves valid state,
• execution semantics remain stable under stochastic planning behavior.

Why This Matters

Many current agent frameworks blur the boundary between:

• reasoning,
• planning,
• execution authority.

This often leads to:

• non-replayable failures,
• hidden state drift,
• duplicate tool execution,
• inconsistent recovery,
• non-auditable behavior.

nano-vm is built around the opposite principle:

>

A planner may:

• propose continuations,
• extend trajectories,
• trigger replanning,

but it must not:

• mutate runtime invariants,
• bypass governance,
• violate the append-only execution model.

Current Focus

The current development focus is on observability:

• real-time trace visualization,
• live execution graph streaming,
• observable replay,
• trace export pipelines.

The goal is to make execution semantics visually inspectable rather than hidden behind opaque “agent loop” abstractions.

Roadmap

v0.8.x

ProgramValidator

Static analysis for execution graphs:

• unreachable states,
• invalid transitions,
• missing branch targets,
• mandatory guardrail reachability,
• cycle analysis.

depends_on + TopologicalSorter

Declarative dependency DAGs layered on top of existing parallel execution semantics.

v0.9.x

replan_on_interrupt

Trajectory continuation after:

• BUDGET_EXCEEDED
• STALLED

without weakening VM invariants.

Architectural Boundary

We are not trying to make stochastic systems deterministic.

We are trying to make their execution:

• observable,
• reproducible,
• structurally constrained.

Probabilistic components should not become sources of execution authority.

We believe this separation between:

• stochastic planning,
• deterministic execution,

is a necessary next step for production-grade LLM infrastructure.

Verifiability Matters More Than Claims

nano-vm and nano-vm-mcp are open projects.

Anyone can:

• download the packages,
• reproduce benchmark scenarios,
• verify replay semantics,
• test suspend/resume behavior,
• inspect duplicate-execution resistance,
• analyze trace behavior directly.

We value engineering feedback, architectural criticism, and technical discussion around execution semantics for stochastic systems.

Every week I see the same discussion:

>

I increasingly think this is wrong.

Most long-horizon agent failures I’ve seen are not:

• IQ failures,
• reasoning failures,
• or benchmark failures.

They are:

text
execution dynamics failures

And we keep trying to solve them with:

• better prompts,
• larger context windows,
• reflection loops,
• constitutional layers,
• self-critique,
• more reasoning tokens.

But the underlying issue is that modern agents are effectively:

text
opaque stochastic distributed systems

with almost no runtime observability.

The hidden problem

A coding agent runs for 6 hours.

At the beginning:

text
read → validate → patch → test

6 hours later:

text
rewrite → retry → rewrite → rollback → retry → patch → retry

Final output still sometimes works.

But the trajectory has already degraded.

This is the scary part:

most agent failures are not catastrophic.

They are:

• gradual,
• sparse,
• silent,
• accumulative.

Exactly like entropy growth in distributed systems.

Current agents are architecturally weird

Right now we ask the LLM to simultaneously be:

• planner,
• memory,
• scheduler,
• filesystem manager,
• execution engine,
• validator,
• recovery layer.

That’s insane if you think about it.

We essentially turned a probabilistic next-token predictor into:

text
kernel + RAM + orchestrator + process manager

with almost no formal execution semantics.

The industry keeps focusing on "reasoning"

But I think the real bottleneck is:

Stability(T0→Tn)Stability(T_0 \rightarrow T_n)Stability(T0​→Tn​)

not:

Correctness(output)Correctness(output)Correctness(output)

where:

• TTT = execution trajectory.

Modern evals mostly measure:

text
single-shot correctness

Real production systems fail because of:

• drift,
• retry storms,
• state corruption,
• context erosion,
• tool oscillation,
• entropy accumulation over long horizons.

What if we treated agents like observable stochastic systems?

Not deterministic systems.

Not explainable cognition.

Observable stochastic systems.

This changes everything.

Instead of asking:

text
"why did the model think this?"

(which is probably impossible)

we ask:

text
"how is the execution behavior changing over time?"

Runtime metrics become more important than prompts

Imagine monitoring agents like distributed infrastructure.

Metrics like:

Transition Entropy

H(At∣St)H(A_t \mid S_t)H(At​∣St​)

How chaotic action selection becomes over time.

Rollback Density

R=#rollback#stepsR = \frac{\#rollback}{\#steps}R=#steps#rollback​

A surprisingly strong early-warning signal.

Path Variance

How much execution trajectories diverge from healthy baselines.

Invariant Violation Rate

V=#violations#transitionsV = \frac{\#violations}{\#transitions}V=#transitions#violations​

Filesystem corruption.

Invalid transitions.

Unexpected mutations.

Tool Churn Rate

Repeated useless tool invocations:

text
edit → rewrite → retry → rewrite

Often the first sign the agent is "melting".

This is NOT about understanding latent reasoning

That’s the key distinction.

I am NOT claiming:

text
we can explain transformer cognition

We probably can’t.

I’m saying:

text
we can observe execution dynamics

Huge difference.

The uncomfortable analogy

Modern agents increasingly resemble:

• distributed systems,
• autonomous robotics,
• stochastic control systems.

NOT chatbots.

And distributed systems engineering learned this lesson decades ago:

You do not eliminate uncertainty.

You:

• contain it,
• observe it,
• replay it,
• bound the blast radius.

The really hard problems

This is where things get ugly.

1. What is "healthy" behavior?

A successful execution can still be degraded.

Example:

• task succeeded,
• but:
  • 14 retries,
  • 3 rollbacks,
  • exploding token usage,
  • unstable tool loops.

Success metrics alone completely miss this.

So now you need:

• trajectory families,
• probabilistic baselines,
• task archetypes.

This becomes:

text
runtime science

not prompt engineering.

2. Snapshotting state is expensive

For coding agents:

state ≈ entire filesystem.

Naive observability will kill performance.

You probably need:

• selective snapshots,
• Merkle DAG state trees,
• incremental replay,
• content-addressable runtime layers.

Basically:

text
Git/Nix semantics for agents

3. Adapter layers are hell

LangChain.

Claude Code.

OpenHands.

MCP.

Streaming tools.

Nested tools.

Async execution.

Normalizing execution traces across frameworks is probably a research project itself.

4. Thresholds are dangerous

Simple:

python
if drift_score > threshold:

will absolutely fail.

Healthy exploration can look unstable.

Hard tasks naturally produce entropy spikes.

You likely need:

• Bayesian change point detection,
• probabilistic regime shifts,
• adaptive thresholds.

But despite all this…

…I increasingly think this direction is inevitable.

Because the alternative is:

text
trust increasingly autonomous opaque systems

with no runtime observability.

And I don’t think that scales.

The core idea

The future may not belong to:

text
smarter prompts

but to:

text
observable stochastic execution systems

Systems that:

• track trajectories,
• detect drift,
• replay failures,
• monitor entropy,
• bound degradation,
• escalate instability before collapse.

Not AGI gods.

More like:

text
Kubernetes for stochastic actors

And honestly?

We spent decades learning that distributed systems become production-safe only after observability, replayability, and bounded failure semantics.

Why are we assuming stochastic autonomous systems will be different?

Maybe the next major leap in agent engineering is not better reasoning.

Maybe it’s finally admitting that reasoning is not enough without runtime observability.

Every week I see the same discussion:

I increasingly think this is wrong.

Most long-horizon agent failures I’ve seen are not:

• IQ failures,
• reasoning failures,
• or benchmark failures.

They are:

text
execution dynamics failures

And we keep trying to solve them with:

• better prompts,
• larger context windows,
• reflection loops,
• constitutional layers,
• self-critique,
• more reasoning tokens.

But the underlying issue is that modern agents are effectively:

text
opaque stochastic distributed systems

with almost no runtime observability.

The hidden problem

A coding agent runs for 6 hours.

At the beginning:

text
read → validate → patch → test

6 hours later:

text
rewrite → retry → rewrite → rollback → retry → patch → retry

Final output still sometimes works.
But the trajectory has already degraded.

This is the scary part:
most agent failures are not catastrophic.
They are:

• gradual,
• sparse,
• silent,
• accumulative.

Exactly like entropy growth in distributed systems.

Current agents are architecturally weird

Right now we ask the LLM to simultaneously be:

• planner,
• memory,
• scheduler,
• filesystem manager,
• execution engine,
• validator,
• recovery layer.

That’s insane if you think about it.

We essentially turned a probabilistic next-token predictor into:

text
kernel + RAM + orchestrator + process manager

with almost no formal execution semantics.

The industry keeps focusing on "reasoning"

But I think the real bottleneck is:

Stability(T0→Tn)Stability(T_0 \rightarrow T_n)Stability(T0​→Tn​)

not:

Correctness(output)Correctness(output)Correctness(output)

where:

• TTT = execution trajectory.

Modern evals mostly measure:

text
single-shot correctness

Real production systems fail because of:

• drift,
• retry storms,
• state corruption,
• context erosion,
• tool oscillation,
• entropy accumulation over long horizons.

What if we treated agents like observable stochastic systems?

Not deterministic systems.
Not explainable cognition.
Observable stochastic systems.

This changes everything.

Instead of asking:

text
"why did the model think this?"

(which is probably impossible)

we ask:

text
"how is the execution behavior changing over time?"

Runtime metrics become more important than prompts

Imagine monitoring agents like distributed infrastructure.

Metrics like:

Transition Entropy

H(At∣St)H(A_t \mid S_t)H(At​∣St​)

How chaotic action selection becomes over time.

Rollback Density

R=#rollback#stepsR = \frac{\#rollback}{\#steps}R=#steps#rollback​

A surprisingly strong early-warning signal.

Path Variance

How much execution trajectories diverge from healthy baselines.

Invariant Violation Rate

V=#violations#transitionsV = \frac{\#violations}{\#transitions}V=#transitions#violations​

Filesystem corruption. Invalid transitions. Unexpected mutations.

Tool Churn Rate

Repeated useless tool invocations:

text
edit → rewrite → retry → rewrite

Often the first sign the agent is "melting".

This is NOT about understanding latent reasoning

That’s the key distinction.

I am NOT claiming:

text
we can explain transformer cognition

We probably can’t.

I’m saying:

text
we can observe execution dynamics

Huge difference.

The uncomfortable analogy

Modern agents increasingly resemble:

• distributed systems,
• autonomous robotics,
• stochastic control systems.

NOT chatbots.

And distributed systems engineering learned this lesson decades ago:

You do not eliminate uncertainty.
You:

• contain it,
• observe it,
• replay it,
• bound the blast radius.

The really hard problems

This is where things get ugly.

1. What is "healthy" behavior?

A successful execution can still be degraded.

Example:

• task succeeded,
• but:
  • 14 retries,
  • 3 rollbacks,
  • exploding token usage,
  • unstable tool loops.

Success metrics alone completely miss this.

So now you need:

• trajectory families,
• probabilistic baselines,
• task archetypes.

This becomes:

text
runtime science

not prompt engineering.

2. Snapshotting state is expensive

For coding agents:
state ≈ entire filesystem.
Naive observability will kill performance.

You probably need:

• selective snapshots,
• Merkle DAG state trees,
• incremental replay,
• content-addressable runtime layers.

Basically:

text
Git/Nix semantics for agents

3. Adapter layers are hell

LangChain.
Claude Code.
OpenHands.
MCP.
Streaming tools.
Nested tools.
Async execution.

Normalizing execution traces across frameworks is probably a research project itself.

4. Thresholds are dangerous

Simple:

python
if drift_score > threshold:

will absolutely fail.

Healthy exploration can look unstable.
Hard tasks naturally produce entropy spikes.

You likely need:

• Bayesian change point detection,
• probabilistic regime shifts,
• adaptive thresholds.

But despite all this…

…I increasingly think this direction is inevitable.

Because the alternative is:

text
trust increasingly autonomous opaque systems

with no runtime observability.
And I don’t think that scales.

The core idea

The future may not belong to:

text
smarter prompts

but to:

text
observable stochastic execution systems

Systems that:

• track trajectories,
• detect drift,
• replay failures,
• monitor entropy,
• bound degradation,
• escalate instability before collapse.

Not AGI gods.
More like:

text
Kubernetes for stochastic actors

And honestly?
We spent decades learning that distributed systems become production-safe only after observability, replayability, and bounded failure semantics.

Why are we assuming stochastic autonomous systems will be different?

Maybe the next major leap in agent engineering is not better reasoning.
Maybe it’s finally admitting that reasoning is not enough without runtime observability.

Over the last year, benchmarks like METR, SWE-Bench Pro, Terminal-Bench and newer long-horizon agent evaluations have quietly shifted the conversation around AI systems.

The interesting part is that the bottleneck is increasingly not the model itself.

METR’s latest work focuses on “task-completion time horizons” — effectively measuring how long an agent can sustain coherent autonomous execution before failing.

At the same time, SWE-Bench Pro explicitly moved toward “long-horizon tasks” involving multi-file coordination, state management, and execution consistency across extended trajectories.

And many independent analyses are converging on the same conclusion:

«“The harness determines how close you get to [the model ceiling].”»

or:

«“The next frontier is not single-model capability — it is orchestration.”»

This is exactly the direction we’ve been building toward with nano-vm.

nano-vm v0.7.0 and nano-vm-mcp v0.3.0 are evolving into a deterministic execution substrate where:

- FSM transitions are the source of truth

- execution is replayable

- state is externalized from the model

- projections isolate LLM/TRACE/TOOL views

- capability references replace raw plaintext state

- hydration/dehydration enables resumable execution

- governance and provenance are runtime primitives

Importantly, we no longer see this as “just an LLM runtime”.

The same execution model is now being integrated into real production business workflows:

- payments

- PDF/report pipelines

- Telegram Mini Apps

- multilingual UI/state synchronization

- governed tool execution

- concurrent stateful processes

The architecture direction is becoming increasingly clear:

[

Agent Capability

\neq

Model Capability

]

More realistically:

[

Capability =

f(

Model,

Runtime,

State,

Policies,

Tools,

Memory

)

]

or even simpler:

[

LLM

+

Runtime

+

Policies

+

State

]

The industry seems to be rediscovering something systems engineers already know:

state management, orchestration, replayability, and execution semantics matter more as systems become long-horizon.

LLMs are improving fast.

But runtime architecture is becoming the real differentiator.

Over the last year, benchmarks like METR, SWE-Bench Pro, Terminal-Bench and newer long-horizon agent evaluations have quietly shifted the conversation around AI systems.

The interesting part is that the bottleneck is increasingly not the model itself.

METR’s latest work focuses on “task-completion time horizons” — effectively measuring how long an agent can sustain coherent autonomous execution before failing.

At the same time, SWE-Bench Pro explicitly moved toward “long-horizon tasks” involving multi-file coordination, state management, and execution consistency across extended trajectories.

And many independent analyses are converging on the same conclusion:

«“The harness determines how close you get to [the model ceiling].”»

or:

«“The next frontier is not single-model capability — it is orchestration.”»

This is exactly the direction we’ve been building toward with nano-vm.

nano-vm v0.7.0 and nano-vm-mcp v0.3.0 are evolving into a deterministic execution substrate where:

- FSM transitions are the source of truth

- execution is replayable

- state is externalized from the model

- projections isolate LLM/TRACE/TOOL views

- capability references replace raw plaintext state

- hydration/dehydration enables resumable execution

- governance and provenance are runtime primitives

Importantly, we no longer see this as “just an LLM runtime”.

The same execution model is now being integrated into real production business workflows:

- payments

- PDF/report pipelines

- Telegram Mini Apps

- multilingual UI/state synchronization

- governed tool execution

- concurrent stateful processes

The architecture direction is becoming increasingly clear:

[

Agent Capability

\neq

Model Capability

]

More realistically:

[

Capability =

f(

Model,

Runtime,

State,

Policies,

Tools,

Memory

)

]

or even simpler:

[

LLM

+

Runtime

+

Policies

+

State

]

The industry seems to be rediscovering something systems engineers already know:

state management, orchestration, replayability, and execution semantics matter more as systems become long-horizon.

LLMs are improving fast.

But runtime architecture is becoming the real differentiator.

Over the last year, benchmarks like METR, SWE-Bench Pro, Terminal-Bench and newer long-horizon agent evaluations have quietly shifted the conversation around AI systems.

The interesting part is that the bottleneck is increasingly not the model itself.

METR’s latest work focuses on “task-completion time horizons” — effectively measuring how long an agent can sustain coherent autonomous execution before failing.

At the same time, SWE-Bench Pro explicitly moved toward “long-horizon tasks” involving multi-file coordination, state management, and execution consistency across extended trajectories.

And many independent analyses are converging on the same conclusion:

«“The harness determines how close you get to [the model ceiling].”»

or:

«“The next frontier is not single-model capability — it is orchestration.”»

This is exactly the direction we’ve been building toward with nano-vm.

nano-vm v0.7.0 and nano-vm-mcp v0.3.0 are evolving into a deterministic execution substrate where:

- FSM transitions are the source of truth

- execution is replayable

- state is externalized from the model

- projections isolate LLM/TRACE/TOOL views

- capability references replace raw plaintext state

- hydration/dehydration enables resumable execution

- governance and provenance are runtime primitives

Importantly, we no longer see this as “just an LLM runtime”.

The same execution model is now being integrated into real production business workflows:

- payments

- PDF/report pipelines

- Telegram Mini Apps

- multilingual UI/state synchronization

- governed tool execution

- concurrent stateful processes

The architecture direction is becoming increasingly clear:

[

Agent Capability

\neq

Model Capability

]

More realistically:

[

Capability =

f(

Model,

Runtime,

State,

Policies,

Tools,

Memory

)

]

or even simpler:

[

LLM

+

Runtime

+

Policies

+

State

]

The industry seems to be rediscovering something systems engineers already know:

state management, orchestration, replayability, and execution semantics matter more as systems become long-horizon.

LLMs are improving fast.

But runtime architecture is becoming the real differentiator.

A payment went through, but the order was never created. A zap broke late Saturday night. A customer never got a single reminder about an expired card. Sound familiar?

https://preview.redd.it/glizb5yrj8zg1.png?width=667&format=png&auto=webp&s=9dbcf3cf4f97d66657e5a239660addc98059d9b3

https://preview.redd.it/255amfctj8zg1.png?width=667&format=png&auto=webp&s=aaf5cd2538d7eba263d7f7a2e2528ecd1b662647

A payment went through, but the order was never created. A zap broke late Saturday night. A customer never got a single reminder about an expired card. Sound familiar?

70%+ abandoned carts, 5–10% of MRR leaking away due to failed payments, silent subscription churn that Stripe cancels without notifying the customer - these are not “growing pains.” This is technical friction that can and should be eliminated.

But typical AI agents (LangChain, custom GPT chains) don’t solve the problem - they often make it worse. A model can skip a step, mix up the order, or decide the workflow is done while a critical guardrail hasn’t run yet. That’s where nano-vm comes in - a runtime where an LLM becomes a predictable tool, not an unpredictable teammate.

nondeterminism ∈ Planner (1 LLM call, optional)
determinism     ∈ ExecutionVM (FSM)

Three words that change everything: determinism, reproducibility, guarantees

nano-vm is not another agent framework. It’s a deterministic virtual machine for running AI pipelines. You describe a workflow in a declarative DSL (JSON/YAML/Python), and the VM guarantees that every step executes in a strictly defined order.

Here, the LLM is just a stateless worker: it gets a prompt, returns a string - and that’s it. It cannot skip validation, bypass a guardrail, or “finish early.”

Clear separation of responsibilities:

LLM decides	DSL (VM) decides
WHAT to say, how to reason, what content to produce	WHICH step runs next, WHEN to branch, WHEN to stop

LangChain can’t guarantee execution order. nano-vm can.

What this looks like in practice: a guardrail you cannot bypass

program = Program.from_dict({
  "name": "customer_refund",
  "steps": [
    {"id": "analyze", "type": "llm", "prompt": "Is this a valid refund request? ..."},
    {"id": "guardrail",
     "type": "condition",
     "condition": "'yes' in '$decision'.lower()",
     "then": "process_refund",
     "otherwise": "reject"},
    {"id": "process_refund", "type": "tool", "tool": "issue_refund"},
    {"id": "reject", "type": "tool", "tool": "send_rejection"},
  ]
})

Even if the model says “This is definitely a refund, just process it,” the VM will still execute the guardrail step before making a decision. The DSL is the source of truth. The model has no control over it.

This is the same principle demonstrated in the interactive demo: the same name and birth date always produce the same Tarot hash. Change one character - the hash changes, and the diff shows exactly what changed. Reproducibility and tamper detection aren’t just for demos - they work in real business systems.

Four business problems nano-vm solves out of the box

1. Failed payments and subscription billing failures

Problem: Silent revenue loss (3–8%) even after Stripe retries. Customers are not notified in time. Recovery rates for insufficient funds stay around 25–30%. The best recovery window - the first few hours - is missed.

How nano-vm solves it:

• Guaranteed sequencing: check payment status -> send SMS -> retry -> notify support. No step is skipped.
• Deterministic branching: insufficient_funds triggers card update flow, fraud triggers immediate block and alert. Logic is yours, not the model’s.
• Full trace: every charge attempt and retry is logged with duration and status.

2. Checkout drop-off and abandoned carts

Problem: 70%+ abandonment rates. Hidden costs, forced registration, missing fast payments, slow pages - all kill conversion. Worse, post-checkout failures (payment succeeded, order missing) permanently lose customers.

How nano-vm solves it:

• Reliable post-checkout pipelines: webhook -> validation -> inventory reservation -> confirmation -> communication. Failures don’t disappear silently.
• Condition steps: fraud, country, amount checks always run - no “forgotten” validations.
• Parallel steps: email + SMS + warehouse notification without extra orchestration.

3. Orders stuck in processing

Problem: Payment completed but order is stuck. Integration bugs between storefront, payment gateway, and ERP. Manual fixes and no visibility.

How nano-vm solves it:

• Finite state machine with explicit terminal states: SUCCESS, FAILED, BUDGET_EXCEEDED, STALLED. No hanging processes.
• Execution limits: max_steps, max_tokens, max_stalled_steps prevent infinite loops.
• Append-only trace: once a terminal state is reached, steps are never re-executed. No duplicate charges.

4. Automation reliability without black boxes

Problem: Automations break when APIs change. Sensitive to formats. Poor observability. Costs grow. Critical flows fail at the worst time.

How nano-vm solves it:

• Executable logic instead of glue: workflows run on your infrastructure, defined in DSL.
• Determinism and reproducibility: same input always produces the same result and hash.
• LLM caching: repeated calls return instantly (<10 ms, $0.00).

Why this matters right now

Most companies focus on acquiring users but lose revenue after the customer is ready to pay. Technical friction and weak recovery flows create leaks that marketing cannot fix.

nano-vm provides three properties missing in typical AI agents:

Property	LangChain / custom agents	nano-vm
Step execution guarantee	no	yes
Step skipping possible	yes	no
Reproducible trace	no	yes
Execution control	model	developer
Cost visibility	partial	per-step

Demo: Tarot with engineering precision

We deliberately chose a mystical scenario to show that even “magic” can run on strict engineering principles:

• Reproducibility: same inputs -> same hash, always
• Tamper detection: one character change -> visible diff
• Full trace: every step logged with duration and output
• LLM caching: repeated runs return instantly

Try it yourself:
https://ale007xd.github.io/nano-vm-demo/

Quick start

git clone https://github.com/your-org/nano-vm-demo.git
cd nano-vm-demo
chmod +x deploy.sh
./deploy.sh

One command and you get a working demo: web UI, Telegram bot, FastAPI backend, and nginx frontend in Docker containers.

Requirements: Ubuntu 22.04+ or Debian 12, 1+ vCPU, 512 MB RAM.

Engine installation:

pip install llm-nano-vm
pip install llm-nano-vm[litellm]

Roadmap

• nano-vm-mcp - sidecar for Model Context Protocol
• nano-vm-vault - secure data integration
• Redis LLM cache - persistent caching
• HTTPS via Caddy - automatic certificates

Links:

• Engine: https://github.com/Ale007XD/nano_vm
• Demo: https://ale007xd.github.io/nano-vm-demo/
• Install: pip install llm-nano-vm

Stop losing money on systems that already “work.” Make your AI workflows predictable.

Most “LLM frameworks” don’t fail in demos.

They fail in production — under retries, partial failures, race conditions, and garbage outputs.

So we stopped benchmarking happy paths.

We built a chaos suite instead.

What we tested

Not prompts. Not accuracy.

We tested failure modes:

- duplicate execution attacks

- replay storms (450k replays)

- mid-step crashes

- out-of-order event delivery

- corrupted payloads

- tool failure cascades

- timeout drift (66% timeout rate)

- reentrancy + concurrent mutation

- LLM output noise / injection

And finally:

«full system chaos mode (all of the above combined)»

Result

13 / 13 tests passed

0 invalid states

0 double executions

0 undefined transitions

Let that sink in.

The uncomfortable truth

Most LLM systems today implicitly assume:

next\_state = f(LLM\_output)

That’s where things go sideways.

We took a different approach:

next\_state = δ(current\_state, event)

Where:

- transitions are predefined

- LLM output is just data, not control flow

- every step is validated + normalized

What this gives us

- Idempotency under replay: 450,000 replays → 0 violations

- Duplicate safety: 0 double executions

- Crash recovery: 0 broken resumes

- LLM isolation: 0 transitions influenced by model noise

- Corruption handling: 50,000 / 50,000 normalized

- Out-of-order safety: 0 invalid events accepted

- Chaos mode: 50,000 runs → 0 invalid final states

Throughput (yes, it’s fast too)

- up to 190k ops/sec (pure execution safety)

- ~148k ops/sec under LLM noise

- ~4k ops/sec in full chaos mode

What this actually means

This isn’t “faster LangChain”.

This is a deterministic execution layer for LLM systems.

- FSM defines what can happen

- runtime enforces what does happen

- LLM is reduced to a probabilistic input, not a decision-maker

Why this matters

Because production failures don’t come from:

- “bad prompts”

They come from:

- retries

- race conditions

- partial failures

- undefined states

We designed for that.

Repo

https://github.com/Ale007XD/nano_vm/

What’s next

We’re shipping a visual demo landing soon where you can:

- see the state machine live

- inject failures

- watch how the system recovers in real time

No slides. No hand-waving.

If your system can’t answer:

«“What happens under 1M adversarial events?”»

…it’s not production-ready.