Skip to content
← Back to MasuGate overview

Interactive OpenClaw developer demo

See one action stay connected.

Follow a selected OpenClaw action from request to governed effect, then see the same pattern extend across the product.

Try the walkthrough ↓

Deterministic product walkthrough

Watch one governed action move.

Three-stage walkthroughStart with one governed action

Begin with one governed path, then add shared-state concurrency and more resource types.

Outcome shown first. Scroll sideways to inspect the full path; during playback, the view follows the action until you scroll it yourself.

A governed action moving through MasuGateAn OpenClaw request crosses the MasuGate boundary, reads governed state, reaches a policy decision gate, and then either runs the permitted effect or stops without one; its operation record remains inspectable. Agent request states: Work Manager: Ready. The governed path is ready for a request. Shared budget: $0 committed, $0 held during review, and $100 available out of $100 total.OpenClaworchestrationMasuGate governed pathMasuGate boundaryOpenClaw agentWork ManagerReady01RequestIdentity + route02Read stateRegistereddependency03DecidePolicy gate04Effect + recordEffectNot startedOperationNot StartedRecordShared budget$100 total$100 available$0 committed$0 held
One governed purchaseApply a category budget, business purpose, review threshold, and retained record to one purchase.
01

Walkthrough timeline

  1. Upcoming · Work Manager · RequestWork Manager requests the project-planning subscription
  2. Upcoming · Work Manager · Host ContextTrusted OpenClaw context bound
  3. Upcoming · MasuGate · Route ResolutionGoverned purchase route resolved
  4. Upcoming · MasuGate · State ReadRead the business-category budget
  5. Upcoming · MasuGate · DecisionPolicy decision: allow
  6. Upcoming · Configured provider · EffectGoverned purchase committed
  7. Upcoming · MasuGate · RecordDecision record retained
03

Outcome and next action

No policy decision yet

The starting state is ready. Decision and operation lifecycles will remain separate as the sequence advances.

The rule is reviewed and tested outside the agent prompt and provider implementation.

Optional: inspect stage setup and policy maintenance
Current governance need

Apply a category budget, business purpose, review threshold, and retained record to one purchase.

Publish the reviewed categorized-purchase@v1 scenario revision with its registered budget dependency.

A governance requirement becomes a validated, reviewed policy revision, registered state dependency, governed route, and inspectable result.

Active agents
Work Manager
Governed resource
Business purchase budget
Stage setup and provenance
Product version
Stage 1
Policy revision
categorized-purchase@v1
Policy owner
Operations policy owner
Scenario owner
demo-owner
Version fixture reset
$100 available in the Stage 1 version fixture
Browser mode
Simulation · no external effects
Policy management
  1. RequirementApply a category budget, business purpose, review threshold, and retained record to one purchase.
  2. Policy editcategorized-purchase@v1
  3. Validate and testPassed · 4 authored cases
  4. Reviewed revisioncategorized-purchase@v1 · ready for runtime

Prompts, OpenClaw orchestration, and provider code remain outside this policy-management plane.Current runtime evidence: named version fixture.Start or step through the stage to connect a request to its active policy clause.

Optional developer evidenceInspect policy, configuration, trace, and records
Developer inspector

Separate configuration, policy, trace, and record.

Initial purchase policyPresentation: Simulated · Evidence: Reference

Simulated policy shape · Evidence: Reference. Readable scenario revisions are distinct from immutable release identifiers and digests.

MasuGate policy

categorized-purchase@v1

Evidence: Reference
policy categorized_purchase on purchase {
  deny missing_business_purpose when
    args.category == "business" and args.purpose == "";

  deny category_budget_exceeded when
    budget.spent(principal.agent_id, args.category, 30 d) + args.amount_cents
      > budget.limit(principal.agent_id, args.category);

  escalate procurement_review when
    args.category == "business" and args.amount_cents >= 5000;

  allow otherwise;
}
Policy owner
Operations policy owner
Scenario revision
categorized-purchase@v1
Validation
Passed · Reference scenario check
Fixed cases
4 authored scenario cases
Review
Reviewed · scenario reference
Release revision
Pending release alignment
Selectable Reference excerpt
categorized-purchase@v1
policy categorized_purchase on purchase {
  deny missing_business_purpose when
    args.category == "business" and args.purpose == "";

  deny category_budget_exceeded when
    budget.spent(principal.agent_id, args.category, 30 d) + args.amount_cents
      > budget.limit(principal.agent_id, args.category);

  escalate procurement_review when
    args.category == "business" and args.amount_cents >= 5000;

  allow otherwise;
}

Policy as an independent program

Policy as code makes rules ownable, testable, versioned, reusable, and traceable.

The same sentence behaves differently in a prompt, in application code, and in a policy program.

Shared ruleBusiness purchases must fit the current shared budget.

Scroll, swipe, use arrow keys, or choose a case.

  1. Policy program

    Defines one reviewable rule

    A structured artifact that can be owned, tested, versioned, reused, and named in a decision record.

    Best atOne shared rule across action paths.

    Trade-offEvery path must invoke it; decisions do not execute effects.

    1. Agents + apps
    2. policy@v2
    3. Allow · deny · escalate
    4. Effect + record

    Independent artifactOwned · tested · versioned · reused

  2. Prompt guidance

    Helps one model reason

    Useful context for planning and explanation, but not an independent enforcement artifact.

    Best atPlanning and explanation.

    Trade-offOther paths may omit or reinterpret it.

    1. Rule in prompt
    2. Agent reasons
    3. Tool effect

    Possible bypassOther path → effect

  3. Application check

    Blocks one code path

    Runs in trusted code, but often couples the rule to one tool implementation and release cycle.

    Best atOne trusted application path.

    Trade-offCopies can drift with each release.

    1. App A request
    2. Local trusted check
    3. Effect

    Drift riskApp B → stale copy

Policy example · categorized-purchase@v2
- budget.spent(principal.agent_id, args.category, 30 d)
-   + args.amount_cents > budget.limit(principal.agent_id, args.category)
+ budget.available(owner.id, args.category, 30 d)
+   < args.amount_cents
Details, limits, and sources: Policy as Code, Not Prompt (9 min) →

Ownership boundary

Keep OpenClaw orchestration and MasuGate governance distinct.

The host, governance runtime, and provider each keep one clear job.

OpenClaw owns

Orchestration

AgentDeclared route
Agents · sessions · models · routes

MasuGate owns

Governed action

RequestPolicy + stateRecord
Selected request · coordination · lifecycle

Provider owns

Facts and effect

State viewConfigured effect
Certified views · configured consequential action

Only declared consequential routes cross the boundary. Unrelated tools remain outside.

OpenClaw governed purchase route

Presentation: SimulatedEvidence: Reference
  1. Host-ownedOpenClaw governed tool callOrchestrates agents and selects the registered purchase tool.
  2. Deployment-owned adapter edgeBind trusted request contextPrincipal and stable action identity come from host context—not model arguments.
  3. MasuGate-owned runtimeResolve route + categorized-purchase@v2Runtime protects the owner-and-category scope; produces allow, deny, or pending.
  4. Provider-ownedCertified state → Configured provider effect
    • Certified view: budget.available
    • Execute: configured purchase effect only after allow or approval
  5. MasuGate outcome → hostCanonical record + authoritative resultThe governed tool returns the authoritative MasuGate operation result.
Text equivalent

OpenClaw continues to orchestrate the Travel Planner and Work Manager.

Their declared purchase tool sends the shared-budget request through the selected MasuGate route.

MasuGate applies categorized-purchase version 2 to certified budget state, coordinates the owner-and-category scope, returns the authoritative operation result, and retains the canonical record.

Unrelated OpenClaw tools remain outside this boundary.

Reference profile: OpenClaw 2026.7.1. Unrelated OpenClaw tools remain outside the declared MasuGate route. Adapted from Figure 4 of Stateful Governance for Concurrent Agentic Systems (arXiv 2608.02764v1).

Framework portability

Keep the governance contract fixed. Change the host binding.

OpenClaw is the concrete walkthrough; other hosts change the adapter edge, not the governed-action contract.

Reference profiles

One governed-action contract, expressed at each host edge.

  • OpenClaw logoOpenClaw
  • LangChain logoLangChain / LangGraph
  • Microsoft Agent Framework logoMicrosoft Agent Framework
  • CrewAI logoCrewAI
Host-native edge · changes

Adapter responsibilities

  • Tool or function registration
  • Trusted principal and stable retry identity
  • Request normalization and native result conversion
Governed-action contract · held fixed

Comparable MasuGate core

  • Request, policy revision, route, and expected lifecycle
  • Provider views, scopes, and effect contract
  • Canonical outcome and operation-record fields

Evidence boundary: Public-source Reference bindings, not Verified or drop-in integrations.

Review Reference adapter profiles →

No-JavaScript and review path

Static transcript for every deterministic branch.

Every event remains available as ordered text independently of playback. Open each stage to review the approve, decline, calendar alternative, and protected-file paths.

Stage 1One governed purchase

Policy revisions: categorized-purchase@v1

One governed-purchase path

One governed purchase runs from request to a committed effect and retained record.

  1. Work Project Manager: Work Manager requests the project-planning subscriptionThe governed business purchase is submitted for $40.No policy decision at this event
  2. Work Project Manager: Trusted OpenClaw context boundThe host supplies the Work Manager identity and stable invocation context; neither comes from model arguments.No policy decision at this event
  3. MasuGate: Governed purchase route resolvedMasuGate resolves the declared purchase route and its registered budget dependencies.No policy decision at this event
  4. MasuGate: Read the business-category budgetThe registered view reports $100 available.No policy decision at this event
  5. MasuGate: Policy decision: allowThe $40 request remains below the $50 review threshold and within capacity.Policy decision: allow
  6. Configured provider: Governed purchase committedThe configured purchase effect completes and $60 remains.Policy decision: allow · Operation status: committed
  7. MasuGate: Decision record retainedThe request, policy decision, governed effect, and result remain linked.Policy decision: allow · Operation status: committed
Stage 2One budget across agents

Policy revisions: categorized-purchase@v2

Approve branch

The exact pending travel operation is approved once; the work operation remains denied.

  1. Scenario fixture: Version fixture resetStage 2 begins from its own $100 shared-budget baseline.No policy decision at this event
  2. Travel Planner: Travel Planner requests a refundable hotel depositThe first overlapping business purchase requests $60.No policy decision at this event
  3. MasuGate: Read shared business capacityThe owner-and-category view reports $100 available.No policy decision at this event
  4. MasuGate: Travel request enters reviewThe policy decision is escalate because $60 meets the $50 threshold.Policy decision: escalate · Operation status: pending
  5. MasuGate: $60 of capacity is protectedLater requests now see $40 available while review is pending.Policy decision: escalate · Operation status: pending
  6. Work Project Manager: Work Manager requests hosted testing capacityThe second overlapping business purchase also requests $60.No policy decision at this event
  7. MasuGate: The second request reads current capacityThe shared view includes protected work and reports only $40 available.No policy decision at this event
  8. MasuGate: Second request denied$60 exceeds the $40 that remains available.Policy decision: deny · Operation status: denied
  9. Human reviewer: Travel request awaits reviewThe visitor chooses whether to approve or decline the exact pending operation.Policy decision: escalate · Operation status: pending
  10. Human reviewer: Reviewer allows this operation onceThe resolution remains bound to the pending travel operation.Policy decision: escalate · Operation status: pending
  11. Configured provider: Travel purchase committedThe protected $60 effect completes and $40 remains.Policy decision: escalate · Operation status: committed
  12. MasuGate: Separate operation records finalizedOne record is committed after review; the other remains denied.Policy decision: escalate · Operation status: committed

Decline branch

The travel operation is declined without an effect or receipt; protected capacity is released.

  1. Scenario fixture: Version fixture resetStage 2 begins from its own $100 shared-budget baseline.No policy decision at this event
  2. Travel Planner: Travel Planner requests a refundable hotel depositThe first overlapping business purchase requests $60.No policy decision at this event
  3. MasuGate: Read shared business capacityThe owner-and-category view reports $100 available.No policy decision at this event
  4. MasuGate: Travel request enters reviewThe policy decision is escalate because $60 meets the $50 threshold.Policy decision: escalate · Operation status: pending
  5. MasuGate: $60 of capacity is protectedLater requests now see $40 available while review is pending.Policy decision: escalate · Operation status: pending
  6. Work Project Manager: Work Manager requests hosted testing capacityThe second overlapping business purchase also requests $60.No policy decision at this event
  7. MasuGate: The second request reads current capacityThe shared view includes protected work and reports only $40 available.No policy decision at this event
  8. MasuGate: Second request denied$60 exceeds the $40 that remains available.Policy decision: deny · Operation status: denied
  9. Human reviewer: Travel request awaits reviewThe visitor chooses whether to approve or decline the exact pending operation.Policy decision: escalate · Operation status: pending
  10. Human reviewer: Reviewer declines the travel operationNo travel effect occurs and the protected capacity is released.Policy decision: escalate · Operation status: denied
  11. MasuGate: Declined branch record finalizedThe record contains no connector receipt or purchase effect.Policy decision: escalate · Operation status: denied

Coordination counterfactual

A non-interactive teaching comparison shows why two detached checks over the same old observation can break the combined rule.

  1. Scenario fixture: Version fixture resetStage 2 begins from its own $100 shared-budget baseline.No policy decision at this event
  2. Detached comparison: Travel request checks the original capacityThe detached stateful check sees $100 and escalates the $60 request.Policy decision: escalate · Operation status: pending
  3. Detached comparison: Work request checks the same original capacityThe overlapping check also sees $100 and escalates its $60 request.Policy decision: escalate · Operation status: pending
  4. Human reviewer: Both detached reviews approveBoth approvals were based on the same original capacity.No policy decision at this event
  5. Configured provider: First detached effect commitsThe travel purchase consumes $60 and leaves $40.No policy decision at this event · Operation status: committed
  6. Configured provider: The stale second effect also commitsThe combined spend reaches $120 against $100 of capacity.No policy decision at this event · Operation status: committed
  7. Scenario fixture: Combined outcome violates the budget ruleEach check looked valid when made, but the second decision became stale.No policy decision at this event
Stage 3More governed operations

Policy revisions: categorized-purchase@v2 · governed-calendar@v1 · governed-workspace@v1

Named fixtures: Client launch review 14:00–15:00; conflicting request 14:30–16:00; fixed alternative 15:15–16:45; travel path /shared/travel/trip-104/itinerary.md; protected path /shared/work/launch-review/brief.md.

Calendar alternative and workspace path

The conflict is denied, OpenClaw presents the fixed alternative, and separate calendar and itinerary effects commit.

  1. Scenario fixture: Version fixture resetStage 3 begins from named calendar and workspace fixtures.No policy decision at this event
  2. Travel Planner: Travel Planner requests an overlapping travel blockThe requested 14:30–16:00 block overlaps the protected review.No policy decision at this event
  3. MasuGate: Read protected calendar stateThe registered overlap view finds the protected 14:00–15:00 Client launch review.No policy decision at this event
  4. MasuGate: Conflicting calendar request deniedThe protected Client launch review remains unchanged.Policy decision: deny · Operation status: denied
  5. Travel Planner: Try the non-conflicting alternativeThe Travel Planner requests 15:15–16:45 instead.No policy decision at this event
  6. MasuGate: Read calendar state for the alternativeThe protected event is unchanged and the 15:15–16:45 request does not overlap it.No policy decision at this event
  7. MasuGate: Alternative calendar request allowedThe later block does not overlap the protected event.Policy decision: allow
  8. Configured provider: Alternative calendar effect committedThe travel block is added as a separate governed operation.Policy decision: allow · Operation status: committed
  9. Scenario fixture: Inspect the governed workspaceTravel and protected work paths are separate.No policy decision at this event
  10. Travel Planner: Travel Planner creates an itineraryThe new file is inside the declared travel workspace.No policy decision at this event
  11. MasuGate: Read the declared workspace boundaryThe workspace views confirm that the itinerary path is inside the Travel Planner's declared workspace.No policy decision at this event
  12. MasuGate: Itinerary creation allowedThe requested path is inside the agent's declared workspace.Policy decision: allow
  13. Configured provider: Itinerary file committedThe file effect completes as a separate governed operation.Policy decision: allow · Operation status: committed

Optional protected-file probe

These three request, state-read, and denial events append after the default path; the itinerary effect is not replayed.

  1. Travel Planner: Travel Planner probes a protected work fileThe agent attempts to replace the protected project brief.No policy decision at this event
  2. MasuGate: Read the protected workspace boundaryThe workspace views report that the work brief is outside the Travel Planner's declared workspace and protected.No policy decision at this event
  3. MasuGate: Protected-file replacement deniedNo file effect occurs and the workspace remains unchanged.Policy decision: deny · Operation status: denied

Stage fixtures reset between product versions. Calendar and workspace calls are separate governed operations; this transcript does not imply one atomic purchase, scheduling, and filesystem transaction.

MasuGate 0.1.1 · separate source reference

Inspect the bounded OpenClaw purchase reference.

Review the exact OpenClaw 2026.7.1 and adapter 0.1.1 purchase surface, its public-source run path, and its evidence boundary. This companion view does not relabel any simulated stage as recorded execution.

Public source · ReferenceInspect OpenClaw source reference

Continue from the Reference demo

Run the public source or bring your own agent scenario.

MasuGate 0.1.1 is a public-source, experimental research preview. The exact source workflow is runnable; package registries, a tagged GitHub Release, and independently retained verification remain separate publication boundaries.