Why AI Agents Never Hold Execution Authority

An agent can inspect evidence, compare scenarios, and propose a course of action. None of those abilities make it appropriate to hand the agent a wallet key, a venue credential, or the last word on a transaction.

Mowazi treats that distinction as a system boundary, not a policy reminder.

Separate capabilities by consequence

The agent layer receives bounded inputs and returns structured evidence, signals, syntheses, and proposals. It does not receive signing adapters or execution tools. Wallet ownership stays with Particle or Magic. Venue preparation and deterministic preflight live behind separate execution boundaries.

Before a prepared action can reach a signing flow, the system obtains a current quote and re-runs the relevant checks: policy, balance, health, freshness, quorum, and reconciliation. The fact that a model generated a plausible proposal is never sufficient evidence that an action should execute.

Why this matters

This architecture protects against more than an incorrect prediction. It narrows the blast radius of prompt injection, stale context, provider failure, malformed output, and an agent that is simply overconfident.

It also makes the product easier to explain. A user can see that analysis is analysis, policy is policy, and signing is signing. The system is intentionally harder to shortcut because financial authority should be difficult to acquire by accident.

A product status note

Mowazi's live execution path remains activation-gated. The boundary exists so that certification, signing controls, and venue readiness can be assessed independently rather than being implied by a polished interface.

What the current implementation actually separates

In the current Mowazi architecture, the browser-facing product is not the execution system. Next.js and Convex own authenticated product state, policies, proposals, approvals, venue readiness, and current snapshots. The Python agent service performs bounded analysis. Temporal coordinates durable work. The execution gateway and TypeScript sidecar are separate processes responsible for quotes, deterministic checks, and venue preparation.

That shape is deliberate. A model worker can produce a proposal with a market, side, size, evidence references, and candidate venues. It cannot import an owner signer, unwrap a venue credential, or call a broadcast adapter. The architecture documentation makes this an explicit rule: agent and model code must never import signing adapters or credentials.

01 / analysis

Evidence + proposal

Workers create bounded evidence and a proposal.

02 / control

Policy + approval

Convex and the owner control the next eligible action.

03 / execution

Gateway + venue

Only the isolated boundary may handle restricted credentials.

The user-owned wallet is also not replaced by a convenient application key. Mowazi normalizes Particle and Magic behind an owner-signer abstraction. Shadow and approval flows remain usable without autopilot capability; autopilot requires supported Arbitrum EIP-7702 delegation. That matters because a missing capability should reduce what the system can do, not cause it to invent a second owner wallet.

A proposal is structured input, not a command

The execution workflow assembles a scoped payload around a proposal before it can enter preflight. The exact models evolve, but the important shape is stable:

# Representative shape of the current execution workflow.
safety_payload = {
    "venue": venue,
    "proposal": proposal.model_dump(mode="json"),
    "policy": policy.model_dump(mode="json"),
    "context": risk.model_dump(mode="json"),
    "quote_request": {
        "market": proposal.market,
        "side": proposal.side,
        "size_usd": proposal.size_usd,
    },
    "idempotency_key": idempotency_key,
    "safety_subject_key": f"proposal:{proposal_id}",
    "safety_bindings": {
        "market": proposal.market.upper(),
        "venue": venue.lower(),
    },
}

The useful engineering detail is not the serialization syntax. It is that the proposal is bound to an exact market, venue, scope, and idempotency key before the gateway makes a decision. A later request cannot silently reuse an earlier allow result for a different venue or instrument.

The workflow first calls a preflight-admission boundary, then a fresh preflight boundary. The latter retrieves a current quote, evaluates deterministic policy, and returns safety decisions. Only a passing decision reaches dispatch. A simplified version of the control flow looks like this:

checked = await gateway_call("/internal/preflight", safety_payload)

if checked["decision"]["result"] != "pass":
    await convex.command(
        "transitionTradeProposal",
        proposalId=proposal_id,
        status="blocked",
    )
    return {"status": "blocked", "checks": checked["decision"]["checks"]}

return await gateway_call("/internal/dispatch", {
    "venue": venue,
    "request": proposal.model_dump(mode="json"),
    "decision": checked["decision"],
    "idempotency_key": idempotency_key,
})

Why the boundary survives model improvement

It is tempting to treat a better model as a reason to remove steps. In a consequential system, better analysis should make the evidence more useful; it should not make the authority boundary disappear. Models can be wrong, manipulated, stale, or unable to see a venue's current state. A deterministic policy check can also fail for reasons that have nothing to do with intelligence: expired approval, an emergency stop, missing reconciliation, quote age, balance, or certification.

This is why Mowazi records execution traces and preserves an idempotency key through the route. The system needs to explain whether an operation was blocked by policy, safety, a venue state, or later reconciliation—not merely that an agent changed its mind.

Closed Beta is a product boundary too

Mowazi is currently presented as Closed Beta. That status is not softened by the presence of public market data, shadow evaluation, or a working proposal surface. Current implementation notes distinguish public/read-only routing from private execution: some quote and preparation paths exist, while signing methods, certification, and live submission remain gated. The right engineering claim is therefore narrow: the controls are being built and inspected under constrained access, not that every visible surface carries production execution authority.