Ungoverned Competence

OpenClaw, agent work, and the need for an operating surface

While setting up OpenClaw, the failure mode I kept hitting was ungoverned competence. One of my projects, Topology, had grown over time into a state where several filesystem locations could plausibly look like the source of truth. There was a runtime folder, an exporter folder, a public docs folder, an iCloud handoff copy, generated build artifacts, and a couple of legacy directories I had not yet retired. A capable agent asked to fix a bug there could find three or four locations that all looked like the right place to edit, write a plausible diff in any of them, and produce a confident summary afterward. The agent could write the patch correctly. It was wrong about which surface owned the truth, and that kind of wrongness shows up as overconfident success.

The base runtime was already good enough to do useful local work, which meant the failures were rarely clean. They were cases where the agent had enough capability to act without enough operating structure to know where the act belonged. It could work from partial context, touch the wrong surface, assume the wrong authority, and still explain itself afterward in prose that sounded more settled than the underlying state actually was.

That distinction matters once the agent is no longer only answering. Reading files, running commands, editing repos, using Discord, calling APIs, scheduling follow-ups, and handing work to a background lane change the unit of risk. Once tools are involved, the question becomes whether the agent can classify the work before it moves.

In practice, the first question is where the work belongs. A quick inspection can remain in the active thread, while a larger implementation, audit, or documentation pass may need the durability of a separate lane, a status artifact, and a defined return path. Work that touches runtime recovery, config, task state, install paths, restarts, or any other surface with a larger blast radius sits in a different category altogether; it should not be handed off just because the agent is capable of making an attempt.

A fresh OpenClaw install gives you many of the primitives, but it does not by itself impose this particular operating discipline. In a casual setup, the boundary between inline help, durable work, and manual containment is usually left to whatever the model infers from the current thread. In a low-stakes chat that is tolerable. Once the agent can mutate files, hand work to a background lane, or report completion from a surface the operator never inspected, it becomes much less tolerable.

The control-plane repo is the result of iterating until those distinctions had a concrete encoding in my own setup. It is closer to an operating contract than to a prompt pack or a framework. The repo gives the agent a set of policy files, control registries, helper scripts, and example artifacts that define what it is allowed to treat as policy, what counts as evidence, when approval is required, how work should be routed, how state should be preserved, and what has to be true before the system can say something is done. None of the underlying ideas are novel in themselves. Classification before motion, approval gates, source-of-truth discipline, and evidence-bearing completion are ordinary operational ideas. The contribution, if there is one, is giving those ideas a concrete shape around the runtime affordances OpenClaw actually exposes.

A practical caveat on the model side. My setup is tuned around a large-context Codex/GPT-5.5 lane, and that shapes how far the contract can be pushed before it starts to feel heavy. The control plane injects a lot of operating context into each serious turn, so this version assumes a model that can carry dense policy, routing, evidence, and closeout instructions without constantly shedding the task itself. In a smaller-context or more aggressively compacted environment, the policy stack remains understandable but the instruction load makes the system slower, more brittle, or more likely to lose relevant detail over long-running work.

Separating the things that usually get blurred together

In my setup, policy, execution mechanics, voice, durable preferences, and runtime facts live in separate layers rather than a single instruction mass. In most agent setups these collapse into one operational layer. The agent has a tone, a memory, a few tool rules, a few user preferences, some current constraints, some stale facts, and a general injunction to be useful, all occupying the same authority surface. Once that happens, any later instruction can quietly become more authoritative than it should be, because the agent has no stable way to distinguish an operating rule from a remembered preference, a conversational habit, a stale diagnostic note, or an incidental fact that happened to be present in context.

OpenClaw already gives the workspace a set of injectable instruction files. What is specific to my setup is how those files are treated. AGENTS.md, TOOLS.md, and BOOTSTRAP.md operate as a layered contract with explicit precedence. AGENTS.md is the top-level normative authority; it carries approvals, routing, lifecycle states, source-of-truth rules, and the boundaries around what kinds of work can be initiated or delegated. TOOLS.md covers execution mechanics — filesystem boundaries, worktrees, shell execution, browser use, external writes, verification, the distinction between inspection and mutation — and overrides AGENTS.md when a goal cannot be achieved through an allowed mechanism. SOUL.md is voice only, which prevents style from becoming authority by accident. USER.md, MEMORY.md, and IDENTITY.md give the agent continuity without conflating continuity with policy. BOOTSTRAP.md defines load discipline rather than runtime authority, so the system avoids treating every possible instruction surface as equally relevant to every turn.

It is worth sizing this honestly. Most of the weight sits in AGENTS.md and TOOLS.md. The other files are small scaffolds. The layering exists so that lower-precedence files cannot become normative by implication, and supporting files never supply missing authority. That keeps the agent able to tell the difference between how it should sound, what it remembers, what is currently true, and what it is actually allowed to do.

The routing piece is the core

The routing model is where the control plane becomes operational. Before the agent acts, it has to classify the work, because a useful agent will tend to compress the task in front of it. That compression is part of the appeal, but it becomes dangerous once materially different actions are treated as if they were only different sizes of the same request. An inline check, a durable implementation lane, and terminal-side containment differ in authority, visibility, rollback surface, and failure mode, not only in complexity.

The repo names a small number of execution modes: inline, durable isolated lane, and terminal-side or manual containment. It also keeps Discord liveness labels separate from execution mode. An ack-then-inline or ack-then-delegate response describes how the agent stays visible in Discord; it does not decide what authority the work has. That distinction matters because a chat-shaped agent can easily look responsive while drifting across an operational boundary.

A short read-only check can stay inline. A larger implementation, audit, repo hygiene pass, or documentation rewrite may need a durable lane with a status artifact and an explicit return path. Runtime recovery, build/install/restart work, config repair, task DB reconciliation, and destructive filesystem cleanup belong somewhere else. Those should remain in terminal-side or manual containment, where the operator boundary is visible and the blast radius is not hidden inside a worker run.

The repo encodes that through named delegation classes and fail-closed conditions rather than leaving the distinction implicit. If a worktree cannot be established, branch identity is ambiguous, a resume target is missing, or required approval has not been granted, durable delegation should fail closed instead of proceeding on vibes. A separate checkpoint layer names the task classes and the points where the agent has to surface state again. Writing it down this concretely is what prevents a capable agent from reasoning about the task while standing in the wrong operational position.

To stay with Topology, the cleanup that resolved the multi-root problem went through the system as a substantial implementation. Before any mutation, the lane had to declare which root was canonical for runtime (topology-runtime), which was canonical for the exporter (topology-hk-exporter), which was canonical for documentation (topology-public-docs), which directories were handoff or build copies, and which legacy roots needed to be quarantined rather than patched. That classification stayed visible in the status artifact for the duration of the run. When the agent later said it had quarantined an old root, I could check that claim against the declared source-of-truth map instead of trusting a summary after the fact.

Auditing the operating surface

An audit I ran on my own OpenClaw host went through the same lane structure. The objective was to check whether the operating model the templates declared still matched what was actually running on the host: repo state, branch state, worktree state, live processes, and CI configuration, all compared against the declared policy. The audit was treated as a substantial durable lane because no single tool call could carry it and the verification surface had to be defined before the work started.

The lane was launched with a verified workspace path and a status artifact. The audit found that the root repo was dirty despite policy saying it should remain a clean integration checkout. It also found 124 local branches against 125 worktrees, far more than the policy actually expected. One detached worktree was running a live HealthKit API process, which made it unsafe to prune even though it looked dormant at first glance. A CI path had drifted in topology-runtime. The validation evidence was also more subtle than “tests passed”: 70 root tests, 101 runtime tests, and the exporter unit tests all passed, but each result corresponded to a different surface and a different expectation.

None of those findings would have come from running tests alone. What the system audited was the operating environment around the code: which worktree was live, which repo owned which tests, which branch was safe to prune, which lane was protected because a process was actually running from it, and which validation result corresponded to which declared expectation. The result came back to the same Discord control plane that originated the request, with closeout fields populated against real git and process state rather than the agent’s confidence about what it believed it had inspected.

Completion has to mean something

The other recurring failure mode is completion theatre. A worker finishes somewhere internally, a tool returns success, a path exists, a marker string appears, and the agent says done. But nothing has necessarily been delivered to the operator, the source tree may not be clean, the final state may not be normalized onto the standing branch, the relevant artifact may exist only inside a worker lane, and the evidence may be stale, partial, or trapped inside the wrong surface. In a simple chat setting these distinctions often feel excessive because the same conversational surface contains the request, the work, and the result. In a real operating environment they separate quickly.

The cleanest example I have of this is the closeout on Topology’s S6 phase. S6 was eight implementation slices, S6-00 through S6-07. When the agent reported the phase complete, the report did not merely say that S6 was done. It verified that each slice was marked Done on the board, topology-runtime was clean on main, main…origin/main showed no ahead-or-behind delta, the closeout helper returned complete with no blockers, and the status artifact reflected the final state. Each item was a state predicate the operator could check. If any of them had failed, the report would have named the failed predicate instead of rounding the phase to “complete.”

Without the gate, the same work could have been reported the same way — the agent finishes, the worker exits, the cards on the board look right at a glance, and the operator gets a confident summary. The closeout gate is what produces the difference between a summary that aligns with state and a summary that merely looks like it does. The gate itself is mechanical: a script that inspects git state, verifies normalization against the standing branch, checks classified dirty residue against allowed exceptions, and refuses to let “done” or “blocker: none” appear in a final report unless the verification fields are actually populated. It is small and conservative on purpose. The closeout report records what the operator can verify, not what the agent feels confident about.

This feels excessive only when agent work is small, singular, and manually supervised. Once multiple long-running tasks are in flight, the alternative is reconstructing reality from logs, half-updated branches, stale status lines, internal worker messages, and optimistic summaries.

Fresh evidence over historical residue

A smaller but related rule is that the agent classifies findings as fresh-window, mixed-window, or historical-residue when residue is heavy, and prefers current inspection over remembered state. Agent systems accumulate residue quickly through logs, failed experiments, stale task rows, old mitigation notes, and previous incidents that may still be useful as context. Some of that should remain available as hypothesis material. The subtler failure mode is decayed evidence retaining enough explanatory force to pass as current fact.

The clearest case for this in my work has been the HealthKit background-delivery debugging on the Topology exporter. The exporter ingests health data from iOS, moves it through an iCloud copy and a local API to a public receiver, and is supposed to keep flowing data when the app is backgrounded. Across several debugging rounds, the agent had real partial successes: a foreground outbox drain improved measurably, a poisoned respiratory-rate queue self-healed, background delivery stopped being zero. A cooperative summary at that point would have said “background delivery is working,” because by some measures it was.

The discipline the system held to was more precise than the cooperative summary. Foreground worked. The queue self-healed. Background delivery was no longer zero, but it was still bursty and opportunistic. Force-quit behavior was declared irrelevant because normal backgrounding was the actual target. The next slice was a concrete sequence of next proofs: land the background-hardening patch, refresh the handoff, reinstall, and rerun the background proof. The system named the next proof rather than treating partial success as closure. Prior failures shaped the hypothesis space without deciding the diagnosis. When new evidence contradicted the more optimistic interpretation, the new evidence won.

What the public repo contains, and what it does not

The public repo is the reusable shape of this pattern. It includes the policy contract templates, execution-mechanics templates, control registry examples for delegation, checkpoints, schedulers, and worker entrypoints, durable Discord workflow docs, validation and troubleshooting checklists, helper scripts for durable slices and closeout checks, example status artifacts and final reports, invariant tests, a policy-drift check, and a dry-run install helper.

It is not meant to be installed blindly. The templates assume a trusted personal-operator model unless they are hardened for another environment, and they are intentionally context-heavy. The deliberate split is between reusable mechanics — execution modes, approval gates, source-of-truth separation, durable-lane lifecycle, closeout expectations, fresh-vs-historical evidence discipline — and operator-specific policy: trusted senders, channel IDs, project surfaces, integrations, security posture, allowed tools. The first set is meant to survive adoption; the second has to be reauthored.

There is a second split worth being honest about, between policy-expressible and runtime-backed behavior. My own setup runs against a source-built OpenClaw 2026.4.24 environment that exposes the relevant worker, Discord, status-artifact, and closeout behavior. Some of what the templates describe — durable Discord worker lanes, worker/session routing, bootstrap-success suppression, status-artifact delivery, same-surface final delivery — requires the running OpenClaw build to support those code paths. The repo includes a capability matrix and a portable fallback for installs without that support: keep Discord as the control plane, run the worker manually or with a normal local command, record state in a hand-managed status artifact, and paste final completion back to the originating surface. The templates can express the operating discipline either way, but they cannot make a runtime behave that way by themselves.

Why I think this matters

The repo changed what I could ask the agent to do without converting every request into manual supervision. Under this operating model, the agent has moved through Topology’s source-of-truth cleanup, the S6 closeout across eight slices, the HealthKit background-delivery work, an audit of the OpenClaw host itself, and research and simulation work where hypotheses became durable lanes producing real decision artifacts rather than narrated analysis. None of those surfaces are exotic on their own. The leverage comes from having one operating model that preserves the boundary around the work as the work changes shape, instead of relying on a new improvised contract every time the agent crosses into another context.

A lot of the public conversation around agents still treats capability as the scarce thing, as though the primary frontier were better models, more tools, longer context, and more integrations. Those matter, but they also move the bottleneck. Once the agent can actually do things, I care less about whether it sounds careful and more about whether the system has places where care is enforced through approval boundaries, source-of-truth rules, task lifecycle states, status artifacts, closeout checks, memory boundaries, and fallback rules that prevent convenience from becoming policy.

That is what I am trying to make concrete with this repo. OpenClaw provides the runtime, and the control plane supplies the operating discipline around the runtime capabilities it actually supports. The constraint now is making the execution surface legible enough that I can inspect what happened after the fact and know which authority, evidence, and delivery path were actually used. The more capable the agent becomes, the less comfortable I am leaving any of those implicit. The failure case is mundane but consequential: the agent does useful work, crosses a boundary it did not name, and produces a plausible summary that hides the operational mismatch. The control plane is an attempt to make that mismatch harder to miss before the work starts, while the work is in motion, and when the agent says it is done.