Build log
ChaseOS: treating agent governance as the product, not the paperwork
The approval boundary is the most-used surface in ChaseOS. Notes on why the governance layer earned first-class status instead of being bolted on.
Source: Public repository: chasedndt/ChaseOS-Core
Context
ChaseOS runs multiple agents across multiple real projects. Every one of those projects has actions that are cheap to undo and actions that are not.
Problem
Autonomy is easy to add and very hard to retract. An agent that can deploy, post publicly, spend money or mutate canonical state is useful right up until the first time it is wrong, at which point the cost is unbounded.
Architecture
Each project gets its own control-plane lane. Agents draft, implement and test freely inside the lane; a fixed set of actions — production deploys, DNS changes, credential use, public posting, customer commitments — sits behind an explicit human approval gate that the agent cannot self-authorise.
Trade-offs
This is slower than full autonomy and occasionally frustrating. It also means the failure mode of a confused agent is a rejected proposal rather than a live incident.
Lessons
Publishing the boundary is part of the credibility story rather than a footnote. A system that states what it will not do without asking is easier to trust than one that claims it never makes mistakes.
Current status
Active framework in developer preview. Not a production SaaS deployment and not a managed public agent service.