Governance Should Run Independently of Development
Governance plane. Governance should run concurrently with, and independently of, development
An agent that meets a bad input will reason about the failure and retry, and nothing in today's stack says stop. What frameworks offer are counters (iterations, rounds, steps), not policies: they count steps rather than dollars, they do not know which run they belong to, and they live in the code, so a new budget waits on a redeploy. Meanwhile the workflow changes every week. Governance has to be independent of development.
How CanyonOS Answers It
The governance plane. CanyonOS puts policy in a file, not in code. A gateway beside every agent enforces which agents may call which model and the most one call may cost; a call that breaks policy is refused before it reaches the provider; the policy file is reloaded in seconds without a redeploy, so governance changes at its own pace, independent of development. Policy per workflow and per query, on the same plane, is next.
See the governance plane in the product: Governance on canyonos.ai. The same argument, in one page with the other three planes: Why CanyonOS.
The Series
- Part 1. Why We Built CanyonOS
- Part 2. Development plane: You should not need a new format for workflows. Python FTW.
- Part 3. Scaling plane: Individual components of a workflow should scale to achieve the desired goals
- Part 4. Observability plane: Observability should be a by-product of inference
- Part 5. Governance plane: Governance should run concurrently with, and independently of, development (this post)
