agents · safety architecture
Authority should increase with consequence
Reading a program, changing a project, deploying software and actuating a machine are different action classes. The tool contract should make that difference explicit.
action ladder
L0ObserveRead source, diagnostics, project or runtime state.read-only
L1AnalyzeCompile, inspect semantics or verify in staged contexts.current building blocks
L2ProposeConstruct a patch, migration or plan without applying it.agent workflow
L3MutatePersistently change source or an offline project.transactional enforcement planned
L4DeployChange controller software or persistent runtime configuration.elevated authority planned
L5ActuateIntentionally affect a physical machine or process.strongest boundary
transaction boundary
Consequential changes need a lifecycle
01Plan + blast radius
02Authorize the concrete change
03Verify base revision
04Snapshot / preimage
05Apply once
06Compiler + vendor verification
07Commit on required evidence
08Rollback and verify restoration
The model proposes
Prompt instructions are not the enforcement boundary.
2ot enforces underneath
Action class, authorization, transaction state and evidence belong below the model.
Rollback ≠ physical undo
Engineering state can be restored; physical history may only be compensated.
CURRENT VS DIRECTION
The stable gateway, dynamic MCP schema discovery, fast compiler checks, structured diagnostics and isolated vendor runtimes exist today. The common six-level authorization model and shared transaction engine shown above are architectural direction under implementation.