Autonomy is granted per workflow. Preparation, recommendation and external action have distinct permissions and approval conditions.
Separate preparation from authority
Morpheus can gather evidence, compare it with prior context and prepare a reviewable output. The authority to send, publish, alter a record or make a commitment is a separate decision.
Name the person responsible for that decision. Give the workflow an explicit objective, a defined set of tools and a clear stop point. A reviewer should be able to see what is proposed, why it is proposed and which permission would allow it to proceed.
For example, a sales workflow can prepare a ranked account list and a proposal draft. The account manager reviews the recommendation and authorises release within the agreed process.
Explore five levels of authority
These levels describe the scope a workflow may receive. A team chooses a level for the work; an animation or a successful run never grants permission. Scheduling is a way to trigger an agreed workflow, and expansion is a separate approval decision.
- 01 / Observe
Make a change visible.
The workflow reads the information it is permitted to access and surfaces a relevant change for the team.
- 02 / Prepare
Prepare something useful.
Assemble a brief, report or draft with its evidence. Preparation has its own permission boundary.
- 03 / Recommend
Bring a decision to its owner.
Present a recommendation and its reasons. A named person decides what may happen next.
- 04 / Act in scope
Act within an approved boundary.
A workflow may execute an action when the necessary grants and approval conditions are satisfied. Its result is recorded.
- 05 / Coordinate
Coordinate the permitted work.
Related work can be coordinated within its agreed permissions. Every workflow retains its own owner, scope and stop conditions.
Make the stop conditions visible
A governed workflow pauses when it reaches a condition that needs resolution. The review should identify the condition and the person or input needed to continue.
- An approval gate requires a decision.
- A required tool or action grant is missing.
- A sensitive or destructive action requires step-up verification.
- Sensitive outbound material requires review.
- Confidence falls below the accepted threshold.
- Evidence contains an unresolved conflict.
- Validation fails.
- An exception exceeds the agreed threshold.
- A proposed action exceeds the workflow’s scope.
These conditions make authority inspectable during the run. They also leave a useful explanation in its history.
Use evidence to widen scope
Before granting more authority, establish seven things: an explicit objective; the necessary grants; evidence from previous runs; outputs accepted by the owner; understood failure cases; an auditable record; and approval from the accountable person.
Review source reliability, the stability of inputs, measurable outcomes and the path for exceptions or reversal. The owner should understand both the intended result and what happens when the work needs attention.
Different workflows in the same organisation can have different permissions. A stable internal report and a customer-facing contractual action have different consequences, even when they share infrastructure.
Build discipline into every run
A workflow can start manually, from an event, on a schedule or through a webhook. Its playbook defines required inputs, reachable systems, output, approval point and retained state.
Dry runs let the team inspect the evidence and proposed result before external action. Changes are versioned so the team can compare behaviour and reverse a change when needed. A critical missing input parks the run and asks for the information required.
Owners, approvers and collaborators are named in the workflow. A proven workflow can be prepared as a callable capability with its policy attached. Cross-instance capability calls through the Mesh are in development; instance connectivity is running on customer zero.
Give administrators a clear control surface
Administrators manage identity, roles, channel grants, privacy and the tools a workflow may reach. Channel-level per-tool grant ceilings limit the permissions available through a conversation surface. Workspace and instance scope define where context belongs.
Always-on redaction and step-up verification for destructive actions support the control boundary. Tool creation requires manual authorisation by default. Admin changes are recorded in the audit log, and model and voice provider configuration sits alongside usage visibility by workspace and surface.
Region, retention and contractual arrangements are confirmed for the engagement. Security & trust brings the control model and supporting policies together.
Read the status attached to a claim
| Evidence status | What it establishes |
|---|---|
| Delivered client workflow — anonymised | A workflow built and delivered to a real client, with the account kept confidential. |
| Named client workflow | A delivered workflow whose client has given written permission to be named. |
| Customer zero | Use inside the business that builds the product. |
| Architecture proof | A design or control that exists and can be demonstrated. |
A measured outcome needs its baseline, timeframe and scope. A public illustration helps explain a sequence; the linked case study establishes the delivery status and operating facts. Keep those distinctions attached to a figure so a buyer can interpret it fairly.
Common questions
Who decides when autonomy increases?
The accountable person approves a wider boundary for a specific workflow after reviewing its objective, grants, prior runs, accepted outputs and failure cases.
Does running on a schedule grant more authority?
A schedule changes when a workflow starts. Its existing permissions, approval gates and stop conditions continue to apply.
What happens when a critical input is missing?
The run parks and asks for the required information, leaving the condition visible for the responsible person to resolve.