Skip to content
MasuGateRequest a customized demo
Menu
← 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 ↓

Policy as an independent program

Maintain policy here. Use it there.

Policy maintenance stays outside the policy engine. A reviewed revision becomes an input to each governed action.

Policy maintenance feeds the runtime

A policy program is maintained outside the policy engine, then used by each governed action.

Presentation: SimulatedEvidence: Reference
Outside the policy engine

Policy maintenance

People and delivery tools own this lane.

  1. 1AuthorWrite the policy program.
  2. 2ReviewInspect the proposed rule.
  3. 3TestValidate expected outcomes.
  4. 4DeployPublish one reviewed revision.
Reviewed revision → runtimeThe runtime reads categorized-purchase@v2; it does not rewrite, approve, or deploy policy.
Inside each governed action

Governed runtime

One operation connects the inputs to its outcome.

Host inputRequestTrusted actor and action.
Policy inputRevisioncategorized-purchase@v2
Provider inputState + effectDeclared views and scopes.

Bound to one operation ↓

  1. RouteUse the declared action.
  2. CoordinateProtect scopes, read state.
  3. DecideApply that exact revision.
  4. EffectRun only when permitted.
  5. ReceiptKeep the linked outcome.

Outcome: deny stops the effect; pending waits for a decision; committed retains the effect and its receipt together.

OpenClaw orchestration and provider implementation remain outside policy maintenance. This is a Reference scenario, not a release binding. Adapted from Figure 4 of Stateful Governance for Concurrent Agentic Systems (arXiv 2608.02764v1).

Deterministic product walkthrough

Watch one governed action move.

Presentation: SimulatedEvidence: Reference
Walkthrough stagesChoose one bounded scenario

Each tab resets to its own versioned fixture.

Selected-stage detailsStage 1 · One governed purchase

Controls, state, and evidence for this scenario.

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.

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
Optional: inspect how policy maintenance reaches runtime
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.

The simple flowChoose a stage, then move one action from request to receipt.

Technical evidence and full transcripts stay optional.

  1. 01Request
  2. 02State + policy
  3. 03Decision
  4. 04Effect + receipt
More options
Idle · BaselineNext: Start Stage 1; the walkthrough will advance automatically.
01

Conversation and agent lanes

Active in this stageWork Project Manageropenclaw:work-manager
  1. User requirement

    Buy the project-planning subscription for $40 and charge it to business.

  2. OpenClaw agent

    I found the requested plan. I am submitting the purchase through the governed business-purchase tool.

  3. Named version fixture$100 available in the Stage 1 version fixture

    Select Start walkthrough to begin the deterministic sequence.

02

Governed resource

Governed resource

Business budget

$100 available
Committed spend
$0
Protected pending capacity
$0
Available capacity
$100
Fixture capacity
$100
03

Outcome and next action

No policy decision yet

The named fixture is ready. Decision and operation lifecycle will remain separate as the sequence advances.

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

The rule is reviewed and tested outside the agent prompt and provider implementation.
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;
}

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: Reference candidate 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.

Milestone 3B · separate candidate path

Inspect the bounded OpenClaw purchase candidate.

Review the exact OpenClaw 2026.7.1 and adapter 0.1.0 purchase surface, its related concurrency workload, and the publication gates still ahead. This companion view does not relabel any of the three simulated stages as recorded execution.

Unreleased · ReferenceInspect OpenClaw reference candidate

Continue from the Reference demo

Inspect the release path or bring your own agent scenario.

MasuGate is currently an unreleased, experimental research project. Installation commands and Verified integration claims remain gated until public release artifacts pass their named checks.

View release-candidate documentationRequest a customized demo