Part one of this series argued that workplace AI needs a control plane — a Chief of Staff that triages, remembers, and governs, instead of a pile of siloed point-solution agents. That piece described the shape of the thing. It didn't answer a harder question: how does a Chief of Staff earn the right to act on your behalf, and prove afterward that it stayed inside that right?
That question is what shaped the Decision Runtime's design. Not "give the agent more tools" — tools were never the constraint. The constraint was that acting on someone's behalf without a provable record of authority isn't delegation, it's just risk with extra steps. Everything below is a design decision made in service of one goal: an agent can do real work, and every piece of that work can be traced back to exactly what allowed it.
1. The gap the design closes
A Chief of Staff that can act but can't account for what it did, why, or under what authority isn't a Chief of Staff — it's a very fast intern with no paper trail. The design had to answer three questions any real operator would ask walking in cold, before it earned the right to touch anything consequential:
- What requires owner attention right now?
- What did the agent already do without me?
- What outcome is still expected, and did it land?
A system that can't answer those on demand isn't trustworthy at any level of autonomy, bounded or not — so the runtime's job is to make those three questions always answerable from durable state, not from someone's memory of what the agent was supposed to be doing.
2. Bounded autonomy, not autonomy
The obvious design would be a single permission flag: this agent may act, or it may not. We rejected that shape because real operating decisions aren't binary. Something can be worth doing without needing a human told about it. Something else can be worth flagging without touching priority at all. Collapsing those into one yes/no either over-grants (the agent silently reprioritizes things it should only ever report) or under-grants (every trivial action waits on a human because the one flag covering it also covers something consequential). So every unit of work the runtime tracks carries three independent authority signals instead of one:
execution: act
attention: inform
priority_effect: within_current_policy
The second, harder design decision: the runtime itself decides none of this. It doesn't grant authority — it records and enforces whatever authority an external operating policy already grants. That line exists because a workflow-neutral runtime that also opined on what agents should be allowed to do would stop being reusable; the moment it bakes in one consumer's judgment about acceptable risk, every other consumer inherits that judgment too. A consumer defines the policy; the runtime's only job is making it impossible to quietly exceed it.
The consequence of designing it that way: the operating mode is governed, not irreversible. A deployment can start a policy conservative and expand it only through a reviewed change, and narrowing it back down is a policy edit, not a rollback or a rewrite. That reversibility is what makes "bounded" an actual property of the system rather than a one-time promise made at launch and never revisited.
3. Attributable work
The cheap way to build this would be a log line per action: timestamp, actor, message. We didn't do that, because a log line answers "something happened" but not "was this actually authorized, and by what chain of reasoning." A prose log can be edited, is easy to leave incomplete under time pressure, and doesn't let you traverse from an outcome back to the exact evidence and approval that produced it — you can only read it linearly and hope the relevant line is in there.
So every event, work item, action attempt, approval, result, and artifact is instead a typed, append-only record connected by explicit edges: what caused it, who or what performed it, which tool invocation ran, what evidence it used, what decision or approval it required, and what it produced. And identity is never a field the caller fills in — the authenticated principal, the effective actor, and the authorization decision are derived server-side, on purpose, so a compromised or careless caller can't self-assign a different identity than the one it authenticated as.
The design bet: a graph you can traverse answers "why did this happen, who or what performed it, and under which authority" on demand. A log you can only grep answers it only if you already know what you're looking for.
4. Portfolio-level reasoning
Part one named the failure mode this is designed against: agent sprawl, where every system gets its own point-solution agent with no shared context. The design response is that the runtime deliberately doesn't care which repository or service an event came from — a subject is just a namespaced type and ID, not "the GitHub domain" or "the deploy domain." That's what makes one reasoning chain possible across systems that share nothing else:
signal → affected bet → current constraint → recommendation → action
A failed deployment, a customer reply, and an open PR can all bear on the same operating decision even though they originate in three unrelated systems. The alternative — a purpose-built integration between every pair of systems that need to inform each other — doesn't scale past a handful of systems; a shared, typed substrate is the design choice that avoids that combinatorics problem entirely.
5. A real Decision Queue
A manually maintained queue rots two ways: someone forgets to add something that mattered, or nobody prunes what stopped mattering, and the queue turns into noise the owner learns to skim past. Both failure modes come from the same root cause — the queue is a second copy of state that a human has to keep in sync with reality by hand.
The design fix is to make the queue a projection of runtime state instead of an independent list: rebuildable from durable records, not hand-curated, surfacing only what the records say genuinely needs the operating owner —
- Approval required
- A material assumption changed
- A priority change was proposed
- Protected attention is needed
- A review deadline was reached
Everything else stays out of the queue by construction. No one has to remember to filter it, because there's no separate list to fall out of sync with the thing it's supposed to represent.
6. Closed feedback loops
The easiest design mistake here would be treating a decision as finished the moment the action fires — which is exactly how automation quietly drifts from reality: an assumption goes stale, nobody re-checks it, and the system keeps acting on it anyway because nothing in the design forces a look back. So a decision in this model isn't a point in time, it's a loop that has to close:
decision → action → observed result → metric or assumption update → continue, reconsider, or escalate
Closing the loop is also what keeps the improvement inside the right boundary. The Chief of Staff can get better at operating within a policy by learning from observed outcomes — but changing the policy itself stays outside that loop, under Git review and owner approval, not inside a model's own judgment about what it should be allowed to do next. Those are deliberately two different mechanisms, not one blurred together.
7. Event-driven operation
The real test of the design in sections 1-6 is whether a new trigger source needs new runtime logic, or just a new registration. A GitHub dispatcher that turns a repository event directly into attributable work is one instance of the pattern:
GitHub event → Chief of Staff review work item → exact-head verification → GitHub MCP actions → review result → runtime attribution and outcome
Nothing about that chain is GitHub-specific at the runtime layer — the event, the work item, the attempt, and the outcome are the same typed primitives every other section describes. The same pattern extends to a deployment, an incident, a schedule, or a Slack message without touching the runtime itself, only adding the typed registration for that new source. If a new trigger required new runtime code, that would mean the earlier design decisions weren't actually general — this is the part of the design meant to prove that they are.
What it is not
- Not a store for private model chain-of-thought.
- Not a replacement for the agent's own memory layer.
- Not a general-purpose job queue.
- Not a source of new authority — it enforces authority, it doesn't grant it.
- Not a replacement for GitHub issues or PRs.
- Not the agent making decisions by itself.
It stores structured reasoning products — facts, evidence, assumptions, recommendations, classifications, decisions, and outcomes — not hidden internal reasoning.
Why this matters
The real shift isn't "the agent can now do more." It's that the Chief of Staff stops being purely reactive. It can hold a durable understanding of what matters, notice when reality changes, act within a policy someone else set and can audit, and bring back only the decisions that actually need a human — instead of every decision, or none of them.
Open source, same repo as part one: github.com/yuens1002/openclaw-control-plane. The Decision Runtime API, its MCP bridge, and the architecture/authentication docs are all public. If you're building something similar, I'd genuinely like to hear where the authority model breaks down in your use case — that's exactly the kind of edge case a workflow-neutral runtime needs to survive.
Top comments (1)
Hello Glad to see you, I am Kane Lim from Hong Kong. I have over 10 years of development experience. I am writing this because your post was interesting.
The separation between execution, attention, and priority authority is the strongest architectural decision here. Treating authorization as an external policy rather than agent generated judgment prevents privilege escalation from becoming an emergent behavior.
I would push this further with capability based authorization and cryptographic provenance. Every action could carry a signed capability containing scope, resource constraints, expiration, policy version, and required approval level. The runtime then evaluates the capability before execution and records the authorization decision alongside the event graph.
For the decision loop, I would also introduce invariant checks and temporal policies. An action should remain valid only while its underlying assumptions and authorization context remain valid. If either changes, the capability becomes stale and execution automatically transitions into escalation.
That creates a much stronger property than auditability: you can formally demonstrate why an action was permitted, what evidence supported it, and exactly which policy boundary constrained it.
This is the kind of architecture I enjoy working on. I would be glad to exchange ideas around policy engines and verifiable agent execution.