DEV Community: Alex Delov

Stop Building Autonomous AI Agents. Build Governed Execution Runtimes Instead.

Alex Delov — Sun, 07 Jun 2026 05:09:32 +0000

Stop Building Autonomous AI Agents. Build Governed Execution Runtimes Instead.

We’ve all seen the standard AI agent architecture:

LLM → Tool → Reflection → Retry → More Tools → Chaos

It works well for demos.

It fails the moment you need:

auditability
replayability
deterministic boundaries
regulator-facing guarantees
operational observability

The core problem is simple:

Most AI systems use probabilistic orchestration.

The LLM controls:

execution flow
tool selection
branching semantics
retry topology

That means your runtime behavior changes dynamically based on latent model state.

For enterprise systems — especially FinTech, KYC/AML, DevSecOps, LegalTech — this is operationally unacceptable.

So we built something different:

Governed Probabilistic Execution

Instead of treating the LLM as the subject of orchestration, we treat it as a constrained compute unit operating inside a deterministic runtime.

Traditional agents:
LLM decides → System adapts

Governed execution:
System decides → LLM computes

The project:

llm-nano-vm
nano-vm-mcp
kyc-demo-streamlit

implements this model explicitly.

The Runtime Model

The architecture is built around a deterministic Finite State Machine (FSM).

The LLM:

does not own control flow
does not mutate execution topology
does not dynamically create new execution semantics
cannot escape governance boundaries

Instead, every execution step is bounded and explicitly governed.

FSM Runtime
    ↓
Projection Layer
    ↓
Bounded LLM Step
    ↓
Typed Transition
    ↓
Execution Trace

ProjectionLayer: Evaluator Blindness

One of the most important architectural properties is evaluator blindness.

The model never receives full runtime context.

It only sees a target-specific projection:

ProjectionLayer(target=LLM)

This creates several important guarantees:

1. Reduced semantic contamination

The model cannot overfit on:

governance prompts
rollback metrics
entropy alerts
audit metadata
unrelated historical state

2. Anti-Hawthorne behavior

The evaluator cannot adapt its behavior simply because it knows it is being monitored.

3. Capability isolation

The Projection Layer acts as:

a semantic firewall
a capability boundary
an information minimization layer

This architecture is closer to capability-security systems than to prompt engineering.

ASTEngine Instead of eval()

The runtime never executes arbitrary Python.

There is:

no eval()
no exec()
no unrestricted expression execution

Conditions are evaluated through a constrained AST engine.

The important point is not just security.

The real goal is bounded semantic expressiveness.

The DSL intentionally forbids:

method calls
arbitrary arithmetic
dynamic execution
unrestricted Python semantics

Why?

Because unrestricted expressiveness destroys:

replayability
analyzability
deterministic guarantees
formal reasoning

This design philosophy is much closer to:

Terraform HCL
Open Policy Agent (Rego)
AWS IAM policy DSLs

than to traditional AI orchestration frameworks.

Observability Beyond Tokens

Most AI observability tooling measures:

latency
token usage
cost
prompt traces

We wanted to measure something deeper:

Structural execution instability

The runtime tracks:

path variance
rollback density
transition sequence variance
transition entropy

Transition entropy is especially important.

If execution entropy exceeds an empirical threshold (2.5 bits), the runtime flags structural degradation.

This is not “AI monitoring”.

It is execution topology observability.

Failure Laboratory

The KYC Governance Simulator intentionally includes adversarial injectors:

tool_injection
policy_bypass
skip_step
reorder_steps
corrupt_receipt
gdpr_erase

The point is not to showcase a happy path.

The point is to demonstrate deterministic failure semantics under attack conditions.

Most AI demos try to hide instability.

We intentionally surface it.

Trace ≠ Receipt

Another core architectural principle:

Execution → Trace → Analyzer → Receipt

Where:

Trace = source of truth
Receipt = deterministic projection
Analyzer = post-hoc interpretation layer

Receipts are:

recomputable
deterministic
derived artifacts

They are not mutable runtime state.

This is heavily inspired by event-sourcing philosophy.

Transactional AI Code Mutation

We applied the same principles to repository mutation.

The companion nano-vm-dev-agent performs code changes transactionally:

stage_patch()
→ validate_staged_mypy(tmpdir)
→ pytest
→ commit OR rollback

The repository is never mutated before type validation succeeds.

This creates CI-grade mutation safety for AI-assisted development.

Most coding agents operate on best-effort mutation semantics.

This runtime applies transactional guarantees instead.

Why Streamlit?

We intentionally skipped:

React
Vite
complex async frontend state systems

The UI is built entirely in Python using Streamlit.

Why?

Because the project optimizes for:

governance correctness
deterministic behavior
engineering simplicity
type safety
operational transparency

Not frontend maximalism.

Current Status

Current ecosystem status:

llm-nano-vm v0.8.4
nano-vm-mcp v0.4.3
kyc-demo-streamlit
nano-vm-dev-agent v0.2.0

Engineering discipline:

mypy --strict
pytest
deterministic constraints
no arbitrary runtime execution

The KYC demo currently passes:

51/51 tests
0 mypy errors

The Bigger Shift

The industry is saturated with autonomous agent hype.

But critical infrastructure does not need autonomous orchestration.

It needs:

bounded execution
deterministic governance
replayability
auditability
operational observability

The future may not belong to autonomous agents.

It may belong to governed execution runtimes for probabilistic systems.

Repositories

Hermes Agent Needs a Flight Recorder - So I Built One

Alex Delov — Fri, 29 May 2026 11:01:26 +0000

This is a submission for the Hermes Agent Challenge

Autonomous agents can now write code, call tools, browse the web, mutate files, and delegate to subagents. But when they fail, they fail invisibly.

"An agent ran overnight, caught an unhandled exception loop, and burned $50 in tokens while corrupting our staging database."

If you've spent more than a week building production systems with autonomous agents, you've lived some version of this nightmare.

Most agent runtimes don't crash cleanly. They slide into retry storms, silently ignore failed tool calls, or recurse through delegation loops until budgets evaporate.

Airplanes have flight recorders. Distributed systems have OpenTelemetry. Autonomous agents need TraceGuard.

What I Built

TraceGuard is a lightweight Python library and CLI that acts as an isolated, non-invasive execution flight recorder for autonomous agent runtimes.

It consumes append-only JSONL execution traces and detects the three silent killers of agentic workflows:

Retry Storms
Silent Failures
Recursive Delegation Cycles

traceguard traces/my_agent_run.jsonl --strict
# exit 0 = clean · exit 1 = WARN · exit 2 = CRITICAL

Instead of scraping human-readable terminal logs, TraceGuard turns runtime execution into a structured, replayable execution event contract.

GitHub: https://github.com/Ale007XD/traceguard

The Problem Nobody Talks About

Modern agent frameworks can browse the web, write files, execute shell commands, and coordinate sub-agents. But when something goes wrong, you're usually left with a giant wall of terminal output and one impossible question:

What actually happened?

Not what the LLM said. Not the final output. The actual execution state:

What tool calls executed?
Which failures were silently ignored?
Where did the retry loop begin?
Which sub-agent delegated back into itself?

Distributed systems engineers solved these problems decades ago using structured traces, append-only logs, and replayable execution histories. Agent runtimes are now complex enough to require the same discipline.

The Mental Model

Autonomous agents are stochastic distributed runtimes.

Distributed System Failure	Agent Equivalent	Observability Primitive
Retry storm	Same tool called repeatedly without progress	Sliding window counter over event stream
Silent failure	Tool fails, agent continues anyway	Error propagation trace
Circular dependency	Agent A delegates to B which delegates back to A	Delegation cycle detection
State divergence	Agent acts on corrupted or stale state	Replayable transition history

δ(S, E) → S'

Agent Runtime
      │
      ▼
Append-Only Event Stream
      │
      ▼
  TraceGuard
      │
  ┌───┴───────┬──────────────┐
  ▼           ▼              ▼
Retry      Silent       Recursive
Storms    Failures     Delegation

Every execution step becomes a formal state transition. The runtime stops being an opaque, ephemeral process and becomes a replayable execution artifact.

The Missing Primitive

Hermes Agent currently exposes beautiful terminal output optimized for humans. Production observability requires something fundamentally different: machine-readable execution semantics.

Example event:

{
  "event_id": "3f8a1c2d-...",
  "session_id": "hermes-session-001",
  "timestamp": "2026-05-29T10:00:00.050Z",
  "schema_version": "1.0",
  "type": "tool_call",
  "tool_name": "bash",
  "tool_args": {
    "command": "git status --porcelain"
  }
}

Each event is:

Immutable — append-only after creation
Self-describing — schema versioned and typed
Replayable — execution can be reconstructed offline
Composable — detectors operate over the same event stream

The missing primitive is not another dashboard. It is a structured execution event stream.

Three Detectors. One Governance Layer.

Retry Storm Detector

Detects identical tool invocations repeating without successful progress.

Example: bash → fail → bash → fail → bash → fail (retry storm)

Silent Failure Detector

Detects agents continuing execution after failed or empty tool outputs.

Example: read_file → empty → continue execution (silent corruption)

Recursive Delegation Detector

Detects sub-agent delegation cycles and self-recursion.

Example: planner → coder → coder → planner (recursive loop)

Each detector operates independently over the same append-only event stream. Multiple detectors can fire simultaneously on the same execution trace.

Execution Governance

TraceGuard is intentionally designed as an external execution observer.

No monkey-patching
No framework lock-in
No invasive runtime hooks
No dependency on Hermes internals

LLM proposes
      │
      ▼
Runtime executes
      │
      ▼
TraceGuard observes
      │
      ▼
Governance layer enforces invariants

This is the critical distinction. Prompt engineering cannot reliably solve retry storms, hidden execution corruption, or delegation cycles. Prompt-layer control is insufficient. Execution-layer governance is required.

Architecture

TraceEvent (schema.py) — Immutable Pydantic v2 execution events
TraceRecorder (recorder.py) — Append-only JSONL persistence
Detectors (detectors.py) — Streaming anomaly detectors
TraceGuard (guard.py) — Batch + real-time governance pipeline

The core invariant is simple: Record every transition. Analyze the record.

Once execution becomes replayable, agent runtimes stop behaving like black boxes.

How This Connects to Hermes

Hermes Agent currently produces terminal output optimized for human inspection. TraceGuard proposes a complementary execution event contract — a machine-readable stream of typed, versioned, append-only events emitted alongside the human-readable output.

This aligns with the discussion in issue #169 on structured execution semantics.

The integration path is additive: TraceGuard requires no changes to Hermes internals. Emit events to a JSONL file; TraceGuard reads them externally.

Demo

$ traceguard traces/retry_storm.jsonl
[WARN] RetryStormDetector: tool 'bash' called 4 times without success (threshold=3)
[WARN] SilentFailureDetector: step 2 failed, execution continued without error handling
[WARN] SilentFailureDetector: step 4 failed, execution continued without error handling
[WARN] SilentFailureDetector: step 6 failed, execution continued without error handling
[WARN] SilentFailureDetector: step 7 failed, execution continued without error handling

$ traceguard traces/recursive_delegation.jsonl
[CRITICAL] RecursiveDelegationDetector: delegation cycle detected — planner → coder → planner

$ traceguard traces/clean.jsonl
✓ No anomalies detected.

$ traceguard traces/retry_storm.jsonl --strict; echo "exit: $?"
exit: 1

Code

from traceguard import TraceGuard

guard = TraceGuard()
report = guard.analyze("traces/my_agent_run.jsonl")

for anomaly in report.anomalies:
    print(f"[{anomaly.severity}] {anomaly.detector}: {anomaly.message}")

if report.is_clean:
    print("✓ No anomalies detected.")

My Tech Stack

Python 3.10+ — minimum target, tested on 3.14
Pydantic v2 — immutable frozen=True event models
Typer + Rich — CLI with structured terminal output
JSONL — append-only trace persistence format
pytest — 13/13 tests passing
hatchling — packaging

No external runtime dependencies. No framework lock-in.

How I Used Hermes

TraceGuard was developed and iterated with Hermes Agent as the primary development environment — reading files, applying patches, running tests, and diagnosing failures through FSM-structured execution loops.

The irony is deliberate: a tool for governing agent execution traces was built by an agent whose execution was governed by the same FSM principles.

Hermes drove: reading source files → generating S&R patches → applying changes → running pytest → diagnosing failures → iterating.

Why This Matters

Most failures in autonomous systems are not model failures. They are execution failures:

Infinite retries
Ignored exceptions
Corrupted state propagation
Delegation recursion
Unbounded token burn

The model is usually doing exactly what it was asked to do. The runtime simply lacks governance.

"LLMs propose. Runtimes govern."

What Comes Next

Replay Engine — Re-execute traces against patched tool implementations
Behavioral Regression Testing — Compare execution traces across models and versions
OpenTelemetry Export — Emit OTLP spans for Grafana, Datadog, and distributed tracing platforms

TraceGuard is to autonomous agents what OpenTelemetry became for distributed systems.

Built for the Hermes Agent Challenge 2026.

Repository: https://github.com/Ale007XD/traceguard

Built on llm-nano-vm — deterministic FSM execution infrastructure.

llm-nano-vm v0.8.0 — deterministic FSM runtime for LLM pipelines, now with output validation and per-step timeouts

Alex Delov — Sat, 23 May 2026 04:36:37 +0000

PyPI: pip install llm-nano-vm

GitHub: http://github.com/Ale007XD/nano_vm

MCP gateway: http://github.com/Ale007XD/nano-vm-mcp

I've been building a deterministic FSM execution kernel for LLM workflows. v0.8.0 just shipped to PyPI. Here's what it is, what's new, and where it's going.

What it is

Most LLM frameworks treat the model as the orchestrator. nano-vm flips that: the runtime is the orchestrator, the model is just one step in a deterministic graph.

δ(S, E) → S'

Current state + validated event = next state. The model cannot skip steps, reorder them, or escape guardrails. The FSM is the source of truth.

Four step types: llm, tool, condition, parallel. Programs are plain Python dicts. No DSL parser, no heavy framework magic, and zero dependency overhead.

program = Program.from_dict({
    "name": "customer_refund",
    "steps": [
        {
            "id": "analyze",
            "type": "llm",
            "prompt": "Valid refund? Reply 'yes' or 'no'.\nRequest: $user_input",
            "output_key": "decision",
            "allowed_outputs": ["yes", "no"],   # ← v0.8.0
        },
        {
            "id": "guardrail",
            "type": "condition",
            "condition": "'yes' in '$decision'",
            "then": "process_refund",
            "otherwise": "reject",
        },
        {"id": "process_refund", "type": "tool", "tool": "issue_refund",   "is_terminal": True},
        {"id": "reject",         "type": "tool", "tool": "send_rejection", "is_terminal": True},
    ],
})

The guardrail step cannot be bypassed regardless of what the model returns.

What's new in v0.8.0

allowed_outputs — LLM enum guard

Validates the model's raw output against an explicit list before the value touches anything downstream.

{
    "id": "classify",
    "type": "llm",
    "prompt": "Classify. Reply ONLY with: refund / query / other",
    "allowed_outputs": ["refund", "query", "other"],
    "on_error": "skip",   # → falls back to "refund" (first element) on mismatch
}

Three policies on mismatch: fail (default, trace → FAILED), skip (substitute allowed_outputs), retry (retry up to max_retries, then FAILED).

timeout_seconds + on_timeout — per-step LLM timeout

Prevents a hung API call from stalling the entire FSM.

{
    "id": "analyze",
    "type": "llm",
    "timeout_seconds": 5.0,
    "on_timeout": "fallback",   # → falls back to allowed_outputs[0] or ''
}

Two policies: fail (default) and fallback. Both features are independent and composable — you can use either or both on any llm step.

What it can do right now

Suspend / resume. Return "PENDING" from any tool → FSM → SUSPENDED, cursor persisted. Resume from any external event (webhook, approval, settlement). RUNNING → SUSPENDED → RUNNING → SUCCESS
Condition branching with ASTEngine. eval() is gone. Conditions are parsed into a validated JSON AST and evaluated by a sandboxed interpreter. No Python builtins accessible. Method calls (.lower() etc.) raise ASTEvalError at parse time, not silently return False.
GDPR tombstoning. Sensitive values stored as CapabilityRef tokens (vault://secret/). On erasure event: ref tombstoned, all projections return [REDACTED_TOMBSTONE], hash chain stays valid.
GovernanceEnvelope. Every successful step produces an immutable, append-only audit record: execution_id, step_id, policy_hash, canonical_snapshot_hash, sanitized payload.
MCP gateway (nano-vm-mcp). Exposes run_program, get_trace, list_programs etc. over stdio or SSE transport with bearer auth and SQLite WAL persistence. Works with Claude Desktop and any MCP client.
Budget guardrails. max_steps, max_tokens, max_stalled_steps — FSM halts with BUDGET_EXCEEDED or STALLED before the next step, not after.

Benchmark — v0.8.0 (WSL2 · Python 3.12 · MockAdapter · 3×5×10k)
10/10 PASS · 1,096,500 ops · 0 violations
ScenarioMean TPSp95
Refund pipeline
2,200/s
123 ms
Double-execution guard
2,800/s
69 ms
Budget enforcement
2,400/s
97 ms
Parallel throughput
1,000/s
196 ms
MCP store round-trip
11,000/s
0.13 ms
GovernanceEnvelope
2,100/s
108 ms
Crash consistency
11/s
115 ms
Replay equivalence
1,300/s
164 ms
Adversarial retries
2,600/s
87 ms
Long-horizon (1k steps)
95/s
11,887 ms

BM-INT-07 (Crash consistency): crash_rate=100% hash_match=100% — replay after simulated crash produces identical trace hash every time.

BM-INT-10 (Memory footprint): peak RSS 76.5 MB, alloc 3.62 MB for 1,000-step programs — no memory leaks detected.

Validated on real payment APIs

Two PoCs, both 9/9 tests passing with mock adapters:
MoMo Payment API v4 — 3-way condition branch, HMAC-SHA256 IPN verification, polling loop with retry, next_step/is_terminal DSL.
Stripe Payment API v1 — 3DS flow (REQUIRES_ACTION sentinel), refund pipeline with LLM classifier, webhook verification. Found and fixed two bugs in the process: "PENDING" sentinel collision (Stripe was returning it as a domain status, triggering FSM suspend), and silent ASTEvalError for .lower() in condition expressions.

What's coming next
Phase 0 (Immediate): ProgramValidator — static analysis at Program build time. Catches missing then/otherwise/next_step targets, unreachable steps, and cycle detection. Currently these fail at runtime; when dealing with LLM-generated workflows, static analysis is a must.

Phase 1 (Gateway Correctness): StateContext persistence between MCP calls in SQLite WAL. Right now, if the gateway process restarts after /create but before polling completes, you get a new requestId — which is a real financial duplicate risk. Closing this with an execution_contexts table + upsert on every step. Up next: TRACE projection to SQLite, GovernedToolExecutor (policy-level tool capability enforcement), idempotency_store, and native vm.step() MCP wiring.

Phase 2 (Dev Agent): nano-vm-dev-agent — the FSM runtime managing its own development stack (read_repo_files → generate_patch(llm) → run_mypy → run_pytest → write_repo_files). DA-1 milestone is done (12/12 tests). DA-2 will be the first live run against a real sprint task (StateContext persistence). Still working on search_code and reproduce_bug tool-functions before launching live.

Phase 3 (Observability): OpenTelemetry span per FSM step + incremental counters in Trace (llm_calls, tool_calls, retries_total).

Install
pip install llm-nano-vm==0.8.0

pip install llm-nano-vm[litellm]==0.8.0 # LiteLLM provider support

pip install nano-vm-mcp # MCP gateway

LLMs are completely optional. The runtime works perfectly fine as a pure, lightweight deterministic workflow engine.

Questions / feedback welcome!

Models shouldn't have execution authority. Why we built a deterministic FSM runtime for AI agents.

Alex Delov — Thu, 21 May 2026 04:49:39 +0000

Modern agent frameworks implicitly treat a probabilistic model as an execution authority. That is acceptable for read-only tasks (e.g., summarizing logs or searching the web). But once an agent can mutate external state — payments, databases, infrastructure, PII — the architecture becomes fundamentally unsafe.

When preparing our internal agents (PlanBot, SkillBot) for white-label distribution, we realized we needed to change the control plane. nano-vm does not attempt to make the model trustworthy. Instead, it assumes model output is untrusted intent and constrains its blast radius through strict deterministic execution semantics.

The Runtime Guarantees (Not just another wrapper)

We built nano-vm — a deterministic FSM runtime for stateful AI systems. The value isn't just in having an FSM; the value is that the execution graph is finite, verifiable, and known ahead of time.

The runtime enforces:

Deterministic transition graph: Execution graph cannot self-modify at runtime.
Compile-time ordering: Attempting a reorder_steps attack is structurally impossible.
Capability gating: Strictly bounded side-effects.
Replay resistance: Idempotency boundaries built into the state transitions.
Immutable auditability: Cryptographic history of every action.

ASTEngine: Limitation as a Security Property

In most agent runtimes, the execution loop is essentially: prompt -> JSON -> dynamic dispatch -> side-effect.

We completely removed eval(). Conditions and side-effects are evaluated by a sandboxed DeterministicSanitizer using an isolated ASTEngine. It supports basic operators (==, contains, $var.field) but completely lacks loops or system calls.

The policy layer is intentionally less expressive than Python. That limitation is a security property, not a missing feature. Loop exhaustion and ReDoS attacks are structurally impossible.

Sabotage Mode: Demonstrating Failure Semantics

To demonstrate the runtime under adversarial conditions, we built a 7-step fintech pipeline (PDF invoice -> Stripe test-mode adapter) with an integrated Sabotage Mode. Instead of a happy-path demo, we built 5 injectors directly into the UI to demonstrate adversarial failure semantics.

1. tool_injection (Capability boundary violation)
Proposed tool invocations are treated as untrusted intent. If the LLM attempts to initiate an unauthorized wire_transfer($50,000), the ExecutionVM resolves the request against a compile-time capability snapshot. The transition is rejected before any external side-effect layer becomes reachable. Zero side effects reach the network.

2. double_exec (Replay & Idempotency)
External side-effects are executed through idempotent adapters keyed by execution_id, allowing deterministic replay of internal state recovery without duplicating external mutations. Once the FSM reaches a terminal state (SUCCESS or FAILED), it becomes an absorbing state (δ(SUCCESS|FAILED, *) = NOP). Replays are silently dropped.

3. `corrupt_hashTampering with the validation hash instantly throws the FSM into aFAILED` state, resulting in a zeroed envelope chain. The audit trail cannot be silently broken.

GDPR Art.17 vs. Immutable Audit Trails

Handling the "Right to Erasure" without breaking cryptographic audit chains is a major headache in fintech.

We implemented a GDPR-erase mechanism that targets specific vault://secret/ref pointers and replaces the PII with a [REDACTED_TOMBSTONE].

The PII becomes completely inaccessible.
The hash_chain and canonical_hash survive.
Cryptographic continuity is maintained.
Referential integrity is preserved.

You delete the data, but you do not destroy the mathematical proof that the operation occurred safely.

Execution Authority vs. Model Quality

LLMs are excellent planners. They are terrible sources of execution truth.

The core design question for stateful AI systems may not be model quality.
It may be execution authority.

Should a probabilistic model be allowed to mutate state directly?
Or should execution pass through a deterministic control layer first?

If you want to try breaking the FSM yourself, the Sabotage Mode is live, and the core is open-source:

Core runtime: github.com/Ale007XD/nano_vm
MCP gateway layer: github.com/Ale007XD/nano-vm-mcp
Live Sabotage Demo: demo.bannerbot.ru:8843

Curious how others here are approaching capability boundaries, replay resistance, and auditability in agent runtimes.