Join the alpha
Back to Blog

How ESCLAVE Prevents Hallucinated Desktop Mechanics

By ESCLAVE

The model emits semantic primitives. The local runner executes bounded implementation ladders.

Many agent systems are strong at planning, but desktop execution becomes unreliable when mechanics are improvised at runtime. draws a hard boundary: the model can emit only primitives, and executes them locally with bounded ladders, predictable failure modes, verification gates, stable failure codes, and auditable run logs.

The Three-Layer Model

ESCLAVE separates intent from mechanics. That split is what makes desktop automation safer, more supportable, and easier to improve over time.

1. Intent

A run begins with a human or AI stating a goal - for example, "log in and extract the file." A planner then translates that intent into valid CLAVON primitives.

  • The model emits semantic primitives only - what to do, not how to do it.
  • The planner is bound to a primitive allowlist.
  • Mechanical ladder steps are never exposed to the model.

2. Primitive Contract (CLAVON)

CLAVON is a semantic execution language, not a scripting tool. Each is a formal contract with:

  • a name and typed inputs
  • preconditions
  • anchor requirements
  • a bounded implementation ladder
  • a verification ladder based on observable signals
  • stable failure codes that surface cleanly to the user and logs

Mutations require verified . Ambiguity . Retries stay bounded. Failures resolve to typed codes rather than improvised behavior.

3. Local Execution (CLAVE)

CLAVE is the local executor inside ESCLAVE.

  • It executes only CLAVON primitives.
  • It uses runner-owned bounded ladders.
  • It emits structured run events and NDJSON logs.
  • It does not improvise mechanics at runtime.
  • It verifies outcomes where possible before claiming success.

CLAVE is to CLAVON what a GitHub Actions runner is to a workflow: strict, bounded, and never creative.

A Concrete Run: Intent -> Primitives -> Ladders -> Verified Result

Intent:

"Open Notepad and type 'Q1 Notes' on the first line."

Planner output (CLAVON primitives only):

  1. open_app(appKey="notepad")
  2. focus_window(selector={ app:"notepad" })
  3. type_text(text="Q1 Notes\n")

Runner enforcement (CLAVE):

  • No mutation without a verified window anchor
  • If focus is ambiguous, pause with ambiguous_target
  • If an anchor is missing, pause with anchor_required
  • type_text runs through a bounded input ladder rather than improvised retries
  • Verification checks for observable result state before success is claimed
  • OCR or vision may appear as evidence, but not as the semantic source of truth
  • Every step emits structured events to the run timeline and NDJSON logs

Outcome:

A verified result or a typed . Never silent success.

When ESCLAVE Can't Proceed

ESCLAVE does not guess its way through uncertainty.

  • Ambiguity pauses.
  • Mutations require verified anchors.
  • The runner emits stable failure codes instead of looping indefinitely.
  • The UI shows a structured pause, and the run trace is preserved.

When a run pauses, ESCLAVE tells you what it needs: choose a target, dismiss a blocking modal, or confirm an action.

How Reliability Improves Over Time

Every run produces structured evidence.

  • Failures cluster into repeatable patterns instead of one-off mysteries.
  • High-frequency clusters reveal where primitives, ladders, and verification need to improve.
  • The primitive lexicon expands deliberately rather than through prompt hacks.
  • Updates ship as versioned changes instead of silently rewriting behavior.

This is how the system gets better without becoming less predictable.

What You Can Do With ESCLAVE

Today, ESCLAVE already supports a real product loop around bounded desktop execution:

  • run local desktop automations through CLAVE
  • author and test with live variables
  • publish versioned Releases
  • distribute Cards through the ESCLAVE Marketplace
  • sell Cards with one-time payments via Stripe Checkout
  • receive creator payouts via Stripe Connect
  • use pause/resume, semantic checkpoints, verified anchors, and full trace logs

Why This Matters

A lot of automation demos look capable right up until execution begins. That is where invented mechanics, hidden retries, and silent failure modes start to pile up.

ESCLAVE takes a different approach: the planner stays semantic, the runner owns mechanics, and execution stays bounded, inspectable, and supportable. That does not make desktop automation trivial. It makes it governable.

And that matters beyond ESCLAVE itself. As the broader agentic stack expands, desktop execution still needs a layer that can be reasoned about, audited, supported, and improved without giving models open-ended mechanical freedom.

Alpha Access: CLAVON Founders 3000

ESCLAVE is currently in alpha.

  • CLAVON Founders 3000 is capped at 3,000 seats
  • execution beyond the demo requires a subscription
  • creator subscriptions, card purchases, and payouts run through Stripe-backed billing flows
  • paid Cards are one-time purchases
  • creator payouts run through Stripe Connect
  • during alpha, breaking changes and failures should be expected
  • when runs fail, ESCLAVE preserves typed pauses, failure codes, and run traces rather than hiding the fault

The goal in alpha is not to pretend coverage is complete. It is to make execution bounded, observable, and steadily more reliable as coverage expands.

In the next post, we'll explain why bounded desktop execution is not separate from the agentic future, but part of the substrate that future systems may need.

Join the alpha