The Control Plane Needs a Stop Condition

This article extends Small Language, Big Control Plane with a narrower operating lesson: predictable automation depends not only on routing work to tools, but also on making restraint observable. A runner that can say skipped, blocked, or needs_review without pretending those outcomes are failures is easier to operate than one that treats every invocation as a mandate to create a side effect.

Starting work is not the same as having permission to finish it

A task description usually tells an agent what outcome is wanted. It does not always authorize every step implied by that outcome.

“Prepare today’s article” may authorize a draft in a drafts directory. It does not authorize publication. “Clean up old email” may authorize inspection and a proposed action list. It does not authorize deletion. “Run the scheduled queue” may authorize evaluation of due items while still requiring a review gate before an external send.

The control plane has to represent that difference explicitly. Otherwise, a script can successfully call a tool while violating the intended boundary of the job.

A useful runner therefore separates at least three stages:

1. Evaluate whether the work is applicable and sufficiently specified.
2. Prepare an artifact or proposed effect in the allowed lane.
3. Commit an external or irreversible effect only when its gate is satisfied.

The no-op lives in the first stage. It is the correct result when evaluation finds that the work is redundant, unsupported, already complete, or waiting for approval.

A no-op is a result, not an absence of a result

An empty response leaves too much to guess. Did the job run? Did it find nothing? Did it fail before inspection? Did it decline an action because approval was missing?

A verified no-op answers those questions with a small record. It can contain:

• the task or schedule identifier,
• the evaluated scope,
• the outcome, such as skipped or needs_review,
• a short reason,
• and a proof reference showing what was checked.

For a draft workflow, the proof might be a directory read showing that the requested artifact already exists. For a review-gated cleanup, it might be a report listing eligible candidates while confirming that no mutation was applied. For a publishing job, it might be the absence of an approved source in the publish lane.

This is deliberately less glamorous than another autonomous action. It is also more useful. A recorded no-op gives the next run something to understand instead of asking it to rediscover the same state from scratch.

Stop conditions make glue scripts composable

Small scripts become difficult to trust when every script assumes that the previous one produced a usable input. A publishing script assumes a draft exists. A notification script assumes publishing succeeded. A metrics job assumes the notification was sent. One ambiguous result can propagate through the whole chain.

Explicit stop conditions create seams between these steps.

A draft runner can finish with verified when its file exists and can be read back. It can finish with blocked when required source material is missing. The publishing runner should treat blocked as a reason to stop, not as an invitation to improvise a replacement article. The notification runner should wait for a publish result that is both successful and authorized.

This is where a small language and an opinionated script reinforce each other. The language can express the intended route in readable terms. The script can enforce the finite set of allowed transitions. Neither needs to pretend that every possible state is a successful completion.

Verification should prove restraint as well as action

Teams often attach evidence to side effects and forget to attach evidence to skipped effects. That creates an asymmetry: action has a receipt, while restraint looks like a missing log line.

The fix is simple. Verify the decision that was made, not only the change that occurred.

For an action, verification may be “the file was written and read back” or “the API returned the expected send result.” For a no-op, verification may be “the existing draft was inspected and no new material was available” or “the policy gate was closed, so the proposed mutation remained unapplied.” Both are claims about system state. Both deserve proof.

This also protects against a common automation error: confusing a tool invocation with a completed outcome. A model can call a route, return a polished explanation, and still leave no artifact behind. Conversely, a runner can correctly decide not to call the route at all. The operator needs to distinguish those cases.

Design the operator’s next move into the result

A control plane is calm when each outcome tells the operator what happens next.

• verified means inspect or consume the artifact according to the normal workflow.
• needs_review means approve or reject the proposed external effect.
• blocked means supply a missing input or resolve a stated dependency.
• skipped means no intervention is needed unless the underlying condition changes.
• failed means retry or investigate an execution problem.

These labels are not a replacement for detail. They are a compact index into the detail. The reason and proof reference should make the state auditable without forcing the operator to reconstruct the entire prompt history.

The benefit compounds in scheduled systems. A scheduler can safely retry failures while leaving deliberate skips alone. A review queue can show proposed effects without mixing them with completed ones. A daily digest can report healthy restraint instead of treating every quiet run as suspicious.

Conclusion: make stopping a first-class operation

The companion lesson to a small language and a big control plane is that the control plane needs a reliable stop condition. It should know when to create a draft, when to wait for review, when to report a blocker, and when to do nothing because doing nothing is the verified result.

When building the next agent workflow, define outcome states before adding more tools. Give each state a reason and a proof reference. Keep draft creation separate from external commitment, and let downstream scripts advance only from explicitly acceptable states.

That discipline does not make an agent less capable. It makes capability legible. A system that can start work, finish work, and stop work without ambiguity is one that operators can safely extend.