WASM Is the Sandbox for End-User Agent Logic

Multi-agent systems have a structural problem.

Not capability. Extensibility.

The framework author can build the engine, the merge loop, the safety boundaries.

But the customer knows the real business constraints:

• Which terms are brand-unsafe
• Which approvals are required above a threshold
• Which compliance references must appear before action

The question is not whether users need custom logic.

They do.

The question is how to let them define it without turning the agent runtime into a permissionless scripting environment.

That is the problem WASM solves.

---

Extensibility Without Anarchy

Most systems choose one of three paths:

• Config files (safe, but weakly expressive)
• Scripting (expressive, but hard to constrain)
• Plugins/services (powerful, but operationally heavy)

For agent systems, those trade-offs get worse.

Why?

Because the logic is often executed in the most sensitive place: inside the loop where the system decides what becomes true.

In Converge, agents suggest. The engine decides.

That only works if extension logic can be:

• Bounded
• Auditable
• Deterministic
• Capability-scoped

WASM gives us that shape.

---

Why WASM Fits the Converge Model

Converge is built around a few non-negotiables:

• Agents Suggest, Engine Decides
• Safety by Construction
• Transparent Determinism

WASM aligns with all three.

1. Determinism

A module gets explicit input bytes and returns explicit output bytes.

No ambient file I/O. No ambient network. No hidden process state.

Record the module hash and input hash, and you can replay the result.

That matters when the output is not a convenience feature. It is part of a governance trail.

2. Fuel Metering

Timeouts are a weak control.

Fuel is stronger.

With Wasmtime, the host can allocate an instruction budget before invocation. If the guest burns through it, the execution traps immediately.

That means tenant-supplied code cannot stall a convergence cycle indefinitely.

Budget exhaustion becomes a first-class runtime outcome, not an operational surprise.

3. Capability-Based Security

WASM modules start with zero authority.

They can compute. That is all.

If a guest needs to read context, it must do so via an explicit host function. If it needs logging, same story.

No declared capability, no access.

This is the right model for agent governance because it makes authority visible.

---

The Real Win: A Constitutional Contract

The technical story is not just "run '.wasm' files."

The real win is a constrained contract between host and guest.

In Converge, the guest should not see the engine internals. It should see a projection.

A read-only view of facts. Version metadata. Cycle metadata.

It checks invariants. It returns a verdict.

That preserves the architecture:

• Guests do not mutate shared truth
• Guests do not bypass the engine
• Guests do not gain implicit privileges

WASM makes this contract enforceable at runtime, not just documented in a README.

---

From Gherkin to Executable Invariants

This is where the model gets interesting.

Users already describe requirements in natural language and acceptance criteria.

So let them write business invariants in a structured, Gherkin-like format ('.truth' files), then compile those definitions into sandboxed WASM modules.

Here is a real business case for an accounts payable / treasury workflow:

Truth: Payment Release Controls

  @invariant @structural @id:dual_approval_over_50k
  Scenario: Payments above EUR 50,000 require dual approval
    Given any fact under key "PaymentReleaseRequest"
    Then if field "amount_eur" is greater than 50000
    Then field "approvals" must contain at least 2 entries
    And approvals must include role "Finance Controller"
    And approvals must include role "Budget Owner"

  @invariant @structural @id:segregation_of_duties
  Scenario: Requester cannot be final approver
    Given any fact under key "PaymentReleaseRequest"
    Then field "requester_user_id" must not equal field "final_approver_user_id"

  @invariant @acceptance @id:bank_change_requires_callback
  Scenario: Vendor bank account changes require callback verification before release
    Given any fact under key "PaymentReleaseRequest"
    Then if field "vendor_bank_account_changed_within_days" is less than or equal to 30
    Then field "callback_verification.status" must equal "completed"
    And field "callback_verification.performed_by_role" must equal "AP Specialist"

  @invariant @acceptance @id:release_packet_is_auditable
  Scenario: Payment release packet must include traceable evidence
    Given the engine halts with reason "Converged"
    Then the Context key "PaymentReleaseDecision" contains at least 1 facts
    And each fact must contain fields:
      | field                     |
      | request_id                |
      | amount_eur                |
      | approvals                 |
      | policy_evaluations        |
      | execution_trace_reference |

This is exactly the kind of rule set that should not live only in prompts or tribal process.

It should be executable, metered, and auditable.

That changes the relationship between specification and enforcement:

• The business rule is human-readable
• The executable is deterministic
• The runtime is metered
• The invocation is traced

No framework release required for every customer-specific rule. No prompt-only "please remember this policy."

The rule becomes executable infrastructure.

---

Native Rust vs WASM Is the Wrong Fight

This is not a replacement story.

Rust and WASM solve different layers.

Use native Rust for:

• The convergence engine
• Networking and storage
• Core invariants
• Trusted performance-critical paths

Use WASM for:

• Tenant-defined invariants
• User extensibility
• Sandboxed policy modules
• Capability-scoped execution inside trusted hosts

Rust is the runtime. WASM is the extension boundary.

That distinction is what keeps the system fast and governable.

---

What Changes When You Get This Right

Once extensibility is sandboxed properly, the framework author no longer has to anticipate every business rule in advance.

The platform can remain small, strict, and opinionated.

Customers can still encode the constraints that make their domain real.

This is the path from "agent demos" to systems that can operate inside organizations with actual risk, audit, and accountability.

The agents can generate. The business can constrain. The engine can prove what happened.

That is the point.

And for that job, WASM is not just convenient. It is the right primitive.