Trust infrastructure demo

Before and after Mission.

A workspace agent moves from risky automation into a public permission ladder: Observe, Draft, Prepare, Execute with approval, and Autonomous within bounds.

Workflow redesign

The work is the same. The trust surface changes.

Mission does not ask buyers to trust an autonomous agent in one leap. It teaches the agent through bounded work, tests the boundary with approval packets, shares receipts, and uses feedback to improve.

before

Prompt confidence decides too much.

  • Agent reads context and drafts a reply.
  • The same tool path can send externally.
  • Approvals, edits, and refusals disappear into chat history.
  • Enterprise governance sees activity after the fact.
after

Permission is earned by action class.

  • Observe and Draft stay fast because they have no external effect.
  • Prepare creates an approval packet with external_actions: 0.
  • Execute with approval records the human decision and outcome.
  • Autonomy expands only within proven, reversible bounds.
Public ladder

Choose the permission step.

The same agent can observe and draft quickly, prepare consequential work for review, execute only after approval, and earn bounded autonomy from receipts.

01Proposed action

02Action class

03Permission state

04Approval packet

05Receipt effect

Why this matters

Autonomy should graduate in public language.

A useful agent can observe and draft today without earning permission to send, spend, delete, publish, or mutate production state. Receipts make that boundary inspectable.

ObserveRead, search, inspect, summarize, and notice. No external effect.
DraftCreate local drafts, options, and next-step proposals for humans to shape.
PrepareAssemble an approval packet for consequential work with evidence, risk, recipient, and external_actions: 0.
Execute with approvalSend, post, commit, schedule, or change external state only after the human approves the packet.
Autonomous within boundsRepeat proven, reversible actions inside clear limits after receipts show the agent has earned that permission.
Builder integration

Wrap this around an existing agent loop.

The demo maps to the reference wrapper: canExecute, prepareApprovalPacket, and recordReceipt.

const decision = canExecute("email.send.external", {
  evidenceCount: 2,
  reversible: false,
  humanApproved: false
})

// decision.status = "review_required"
prepareApprovalPacket({
  actionClass: "email.send.external",
  external_actions: 0
})
Critique ask

Where should this permission layer live?

Inside each agent app, inside MCP metadata, inside evals/observability, or as a small receipt layer across them? That is the builder question.