Why Agents Overstep Skill Constraints: How Ambiguity Triggers Error Cascades

DxC is an Agent-native writing system for WeChat official accounts that runs in environments like Codex and WorkBuddy. Users interact primarily through natural language; Skill is the product interface, while CLI handles deterministic operations.

WorkBuddy Turns a Single Push into an Entire Engineering Project

WorkBuddy's execution replay shows clear overstepping. The Skill only required passing work items unchanged, but WorkBuddy first extracted parameters, then arranged phases on its own. Rules explicitly forbade inspecting internal implementations, yet the tool trace later included protocol research and state guessing. A single push was wrapped in a Python scaffold, and a manual rewrite dropped a character, creating a new error.

WorkBuddy's long-term memory already stated: from version 0.3 onward, the Agent no longer stitches tasks together and does not need to understand each private protocol step. During execution, however, these actions were repeated anyway. The explanation "rules missed a sentence" no longer accounts for this action chain.

Three Reasons WorkBuddy Misbehaves

Re-examining run logs revealed that I had conflated several distinct problems. After each error, I kept patching the same rule file, which only made things worse.

First, the target Skill never entered the current context. The controller had read it, and CLI returned the correct Skill name, but the tool trace shows no load record for that Skill. Subsequent commands executed anyway. In this run, further editing of a Skill that wasn't in context would have no effect.

Second, the Agent retained only the task gist. Old summaries, old plans, and the user's new "continue" all pointed toward finishing the current phase, so the execution trace followed that direction. The stop conditions written in the Skill never appeared in later actions.

The third is hardest to judge. WorkBuddy did read the rules and could recite them afterward. When the normal path broke, familiar engineering problem-solving took over: checking help, reading implementations, writing scripts. In ordinary engineering tasks this looks proactive; inside DxC's delivery flow it crosses the product contract.

Tool traces only prove what the Agent did, not what the model was thinking. That boundary must remain.

Another case: the Agent connected to the official npm registry even though the CLI was already installed locally. Review showed it was executing the original Skill contract — the error was in the contract, not the Agent. This calibrated my attribution order: when seeing anomalous behavior, first determine whether the problem lies in Skill loading, rule execution, or product boundaries, then decide what to fix.

Earliest Approach: Write the Flow Clearly, Let the Agent Drive

After rejecting a Web-based solution, my initial design was simple: put the task flow in the Skill, make executable actions into CLI commands, and let the Agent decide the next step based on the situation. Understanding context and scheduling work are what Agents excel at; there was no reason to build another flow engine inside the product.

In an early run, the Agent failed to stop as expected. I rewrote the confirmation requirement more emphatically. Similar issues kept appearing, so more error-prone actions were moved into CLI. The assumption was still that the more the program handles, the fewer mistakes the Agent makes. But as commands were split finer, orchestration drifted back to the Agent — a realization that came later.

Later, the Agent started inventing parameters, saving temporary state outside the product, and designing recovery methods for failures. My fix was still editing the Skill. After the same class of problems recurred, the conclusion was unavoidable: adding more words will not turn a Skill into a program.

How Errors Snowball

These issues rarely stop at the first guess. When CLI doesn't specify a clear next step, the Agent picks a plausible command. If parameters are missing, it invents them. If the task must continue, it saves temporary results. A whole flow the product never designed has now appeared.

When the ad-hoc flow errors out, the Agent doesn't know the original path shouldn't have existed; it only patches along the existing assumptions. Scripts, protocol guesses, and recovery methods quickly pile up. The original ambiguity becomes invisible.

This is what I call "the Agent adding its own drama." It doesn't just fill one blank — it keeps building a plot around what it just invented.

First Anti-Pattern: Letting the Skill Become a CLI Manual

My approach was essentially whack-a-mole. Missing confirmation? Write confirmation heavier. Wrong parameter? Stuff field formats into the Skill. Recovery runs wild? Add a few "must stop" lines. Every edit targeted only the hole that just appeared.

After a while the Skill spanned several screens of commands, fields, and error handling. The actual content-creation parts were pushed to the margins; the working method had turned into a CLI user manual.

File length is a surface issue. I had effectively rewritten a state machine in natural language, yet nothing guaranteed the Agent would follow the same path each time. A program can reject illegal input; a Skill emphasized ten times is still just a reminder. The two kinds of constraint are fundamentally different.

Skills should clearly describe content methods, judgment criteria, and user intervention points. Once a Skill starts explaining commands, fields, and error branches at length, I now check whether that content belongs inside the product.

Second Anti-Pattern: CLI Provides Bricks, Skill or Agent Does the Masonry

After the Skill grew too long, I pinned hopes on CLI. Operations were split into ever more commands; the calling sequence was written back into the Skill, so the Skill took on orchestration duty. Handing commands directly to WorkBuddy wasn't better — it would assemble its own flow on the spot. CLI didn't need more bricks; it needed a single action that directly fulfills the user's intent.

Both Paths End Up Leaving the State Machine to the Agent

When writing articles, I don't mind the Agent thinking a bit more — a spontaneous argument angle might improve the piece. Creating a WeChat draft is different. The first call either succeeds or fails, and we need a definite answer. If the Agent decides to retry on its own, the draft box may end up with an extra copy.

Whether orchestration is maintained by the Skill or improvised by the Agent, the distinction vanishes here: the state machine and external side effects are still entrusted to a probabilistic model.

When the Entry Point Is a Skill, Testing Loses Determinism Too

Once boundaries shifted, a new trouble surfaced: how to test this? I reused traditional CLI testing — fixed input, check output. The Skill entry quickly broke that plan. The same task run twice might make the Agent choose different actions. One success doesn't prove the next run will follow the same path.

End-to-end smoke tests became especially painful. A single run is influenced by model behavior, host capabilities, Skill version, and CLI contract. One misstep means re-reading logs to locate where things diverged. Tests often end without a clean red or green light, only another process to investigate.

WorkBuddy acts like a high-pressure real user, often hitting boundaries I never anticipated. Its root-cause claims can't be taken at face value. Once, a legal input produced no error, so WorkBuddy concluded the CLI lacked validation. After adding negative test cases, the program was already rejecting illegal inputs. Field friction can be evidence; field attribution must be verified separately.

I stopped trying to prove everything with one end-to-end run. CLI and underlying contracts are tested repeatedly with fixed fixtures; WorkBuddy stays in real workflows to hit boundaries. When errors recur, I first check whether the fixed fixtures fail, then determine from which step the host started drifting.

Version 0.3 Starts Pulling Orchestration Back into CLI

Version 0.3 introduced the beginnings of opaque handles. After receiving a work item, the Agent only needs to pass it unchanged to the next call — no need to unpack, study, or save separate state. Subsequent 0.3.x releases further tightened the command surface. More internal steps, validations, and recoveries moved back into DxC, with structured results exposing only the currently executable next step.

Complexity didn't disappear; it returned to the CLI. The Agent's freedom to orchestrate shrank. After the changes I still have to watch WorkBuddy run, because CLI only constrains what happens after it receives a call. The target Skill not loading, or an old plan in a long session interfering with execution — these happen outside the CLI.

At this point I no longer chase 100% Agent compliance. Creative judgment can stay in the Skill to raise the probability of correctness. State, confirmation, idempotency, recovery, and external side effects cannot tolerate probability; the program must block errors that must not happen.

With boundaries pulled back, the real question becomes clear: what should Agent, Skill, CLI, and the underlying contract each own? The next article will continue settling this account.