Architecture Center
Propose-only vs effect-capable workers
Give clear criteria for setting a worker's authority ceiling between read-only, propose-only, and effect-capable.
previewdecisionContract >=0.8 <1.0Reviewed 2026-07-20
Problem statement
Granting a worker too much authority removes the human review boundary; granting too little forces manual steps. The right ceiling depends on reversibility, risk, and trust.
When to use
- You are registering a worker and must set its ceiling.
- You are deciding whether automation may execute irreversible effects.
When not to use
- There is no worker; a human performs every action.
Flow
Assess risk + reversibilityRead-onlyPropose-onlyEffect-capable (low-risk only)Policy enforces ceiling
Resource inventory
- Authority ceiling
- Caps what the worker may propose or execute.
- Policy
- Enforces the real limit regardless of client config.
Failure modes
- Ceiling too high
- An irreversible effect runs without review; lower the ceiling to propose-only.
- Ceiling too low
- Every action needs a human; raise it for low-risk, reversible effects.
Security controls
- Frontend config cannot raise the ceiling above tenant policy.
- Ceiling changes go through an authorized administrator path.
Deployment checklist
- Default to propose-only for new workers.
- Reserve effect-capable for low-risk, reversible operations.
- Review ceilings when risk changes.
Related quickstart: Register a bounded worker →