From Workflow Harness to Lightweight Prompts: What I Removed After Codex 5.6

In August 2026, I made a near-rewrite-level reduction to the AI development Harness I had used for several months.

This was not about shortening a few Prompts. It removed a control plane that already worked: the stage DAG, StateV3, append-only event chains, Worker plans, one-time write authorization, isolated worktrees, Patch Bundles, the Promotion Runtime, Provider receipts, and recovery logic all left the main path of day-to-day development.

The change was dominated by deletions. Both the stable control surface and the Prompts loaded at startup became a small fraction of their previous size.

The numbers are dramatic, but “deleting a lot” is not the conclusion. What is actually worth recording is why a system that clearly improved efficiency with Codex 5.4 and 5.5 began to slow the process down with 5.6—and where rigor and safety went after the runtime was removed.

The conclusion first: I removed duplicate control, not engineering discipline#

The old Harness got many things right. It turned engineering habits that had depended on experience into explicit contracts:

• Current source code and real Provider state take precedence over chat memory;
• clarification, design, implementation, review, and delivery have different authorization boundaries;
• state, events, and artifacts cannot masquerade as one another;
• Workers can only provide evidence; the main Agent owns the final synthesis;
• writes, external calls, and releases must produce results that can be read back;
• passing tests, a successful Pipeline, and correctness in production are different levels of fact.

What I ultimately removed was the general-purpose orchestration that had grown layer by layer to enforce these principles. The principles remain, but every ordinary change no longer has to enter a self-built workflow engine first.

The new division of responsibility can be summarized as:

The model and platform handle exploration, planning, editing, and verification for common tasks
The repository owns stable domain knowledge and mechanical constraints
Top-level rules define authorization boundaries for high-consequence actions
Git, tests, Providers, and production entry points supply factual evidence

This is not a retreat from a “system” to “one Prompt.” It is a move that puts each kind of control back into the layer best suited to it.

Why the old Harness grew into a control plane#

The mature version of Marshall was not a linear checklist. Stable rules lived in a versioned repository-local control directory, while the state and evidence for each run lived in an ignored per-run evidence directory. The former was the Control Plane; the latter was the Runtime/Data Plane.

The actual path of an implementation task looked roughly like this:

Goal routing
  -> Progressive Context / Perception
  -> Stage DAG and dependency checks
  -> StateV3 lease, revision, generation, and fencing
  -> change plan
  -> StageWriteGrantV1
  -> isolated-worktree Executor
  -> PatchBundleV1
  -> Patch Verification
  -> Trusted Host Promotion
  -> target-workspace readback
  -> tests, specification synchronization, and StageResultV1

For design and review, the system also generated WorkerSelectionV1 and WorkerPlanV1 first, binding risks, roles, context Hashes, output locations, concurrency limits, and convergence barriers together. Workers were read-only by default, and completion did not mean acceptance; the main Agent could synthesize a conclusion only after confirming that a result still matched the current inputs.

This design addressed very real failures: a long task interrupted by Compaction and executed twice after recovery; a review citing stale code; a late Worker result overwriting a newer judgment; an Executor crossing file-scope boundaries; an external write being submitted again after a timeout; or “the patch was applied” being misreported as “it is live.” During the Codex 5.4 and 5.5 period, the extra mechanisms bought stability, and in my actual experience the tradeoff was worthwhile.

The problem is that once any control plane starts taking responsibility for recovery, isolation, approval, and auditability, it naturally grows Schemas, registries, adapters, compatibility layers, and tests. It stops merely helping the model work and becomes another software product that must be continuously developed.

The turning point was not an article, but several tasks without the Harness#

What actually prompted me to act was not a theoretical judgment, but several Codex 5.6 tasks in which I deliberately did not use the Marshall Runtime.

I gave the model only the current goal, repository rules, and safety boundaries, then let it read the code, form a minimal plan, edit files, run tests, and inspect the diff directly. The results did not show the obvious degradation I had expected: the model still maintained scope, proactively traced the real call path, and distinguished implementation, commit, and deployment. At the same time, it reached the domain code faster, produced fewer intermediate artifacts, and accumulated context more slowly on long tasks.

This is only a small sample from my personal workflow, not a controlled experiment. I cannot use it to prove that “5.6 does not need a Harness,” much less that every project should remove its workflow. But it was enough to expose an architectural problem: when the model can already perform a piece of general-purpose orchestration reliably, forcing the repository to implement the same capability again may have negative net value.

OpenAI's GPT-5.6 model guidance later offered a clearer migration direction: compare quality, evidence completeness, Tokens, latency, and cost on representative tasks; remove duplicated instructions group by group rather than clearing everything at once based on intuition; and keep explicit authorization boundaries for external writes, destructive actions, cost, and scope expansion. This guidance aligned with what I had observed, while also reminding me that simplification is an engineering change that must be validated, not an aesthetic preference.

The real bottleneck was the Harness entering the context itself#

The old version did not put a hundred thousand lines of documentation into the model all at once. It already had P0-to-P3 Progressive Context: each stage loaded only the necessary commands, relevant domain specifications, risk perspectives, and a small number of runtime artifacts, while large materials were retained as handles whenever possible.

But on-demand loading can reduce domain material; it cannot eliminate the fixed cost of the control plane. On every round, the model still had to understand:

• which Stage corresponded to the current goal;
• which Nodes and Completion Barriers had to be satisfied;
• which authority belonged to State, Event, and Artifact respectively;
• why Lease, Generation, and Freshness might invalidate a result;
• how Worker Reports converged;
• what Write Grants, Patch Bundles, and Promotion each permitted;
• which logical Artifact Role should receive the current result.

The system then continued to generate state projections, events, receipts, Hash bindings, and verification artifacts. These were not entirely useless, but they competed with requirements, source code, and tests for the same attention budget.

Anthropic's article on Context Engineering treats Context as a finite resource and emphasizes that the marginal value of additional Tokens declines as content grows. It also presents Compaction, structured notes, and multiple Agents as tools for different task shapes, not as a standard bundle that must always be enabled together. That describes my problem more accurately: although the old Harness helped with recovery, it also caused Compaction to happen sooner; after compression, the first thing the model had to reconstruct was the Harness's own runtime semantics.

The cost of one compression was not merely “losing some text,” but a chain of recovery work: reconfirming the stage, lease, input Hash, incomplete nodes, valid artifacts, and next permitted Transition. When the model was less capable, those costs bought determinism; when it could complete common paths reliably without them, the same costs became a process tax.

I used four questions to decide whether each mechanism should stay#

This time, I did not mechanically delete directories. I asked four questions about every mechanism:

1. Does it constrain model reasoning, or real-world consequences?
2. Does the platform, Git, or Provider already offer an equally trustworthy capability?
3. Does failure require cross-process recovery, replay, or auditing?
4. Is the reduction in risk greater than the context, latency, and maintenance costs it introduces?

The final result was:

Mechanism	Problem solved by the mature version	Final treatment
Goal routing	Separate authorization boundaries for clarification, implementation, review, and delivery	Keep as a lightweight Goal Map
Progressive Context	Prioritize current source, domain specifications, and risk evidence	Keep on-demand loading; remove the complex Loader Runtime
Stage DAG	Express parallelism, waiting, re-entry, and completion barriers	Let the model plan ordinary tasks; continue to make truly non-interchangeable dependencies explicit
State / Event / Artifact	Separate long-task recovery, causal chains, and deliverable results	Stop generating by default; adopt them on demand for long-running and auditable automation
Fixed Workers and Team Plan	Reduce confirmation bias through independent perspectives	Delegate temporarily according to risk instead of maintaining a fixed team
Write Grant and isolated worktree	Limit a write to one use, one version, and one set of paths	Remove from the daily path; sandboxes/worktrees can still be used in high-risk environments
Patch Promotion	Validate transfer between a low-trust executor and the real workspace	Remove the self-built Runtime; use native editing, Git diff, and tests
Preview / Approval / Readback	Prevent unauthorized external side effects or uncertain retries	Keep in full
Protected Branch / Data / Cost / Destructive Gates	Control high-consequence actions	Elevate into top-level configuration and mechanical Hooks

The key distinction is this: a model can become increasingly capable at planning, but that does not give it the authority to decide on my behalf whether to write to production, incur real costs, or perform irreversible actions. Capability changes with model versions; authorization relationships do not.

The new architecture does not “hand everything to the model”#

The simplified Marshall is a very thin Context Router:

User goal
  -> Marshall Skill parses the goal
  -> read one corresponding command
  -> read domain Spec / risk Lens / Local RAG / Provider evidence on demand
  -> use Codex's native planning, tools, editing, testing, and optional delegation
  -> return results, evidence, and residual risks

The always-loaded layer contains only the project's AGENTS.md, the simplified constitution, and the routing Skill. Commands such as impl, local-review, and pr-submit are loaded separately according to the goal; the full specification tree, historical research, old audit packages, and unrelated domains are no longer preloaded.

Implementation tasks no longer require a Jira item, design file, audit directory, Worker Report, or State Object as a pass. Their common path is only:

Confirm the branch, scope, and sources of truth
  -> trace the affected code
  -> form a minimal safe plan
  -> modify the accepted scope
  -> validate according to risk
  -> inspect the final diff
  -> report verified findings and residual risks

This path remains rigorous; it simply moves evidence back to the sources of truth that already exist: current code, git diff, test output, remote Refs, CI status, deployment records, and production readback.

The change to pr_commit best illustrates the new authorization model#

The old delivery flow depended on Hash-bound previews, runtime Gates, approval Envelopes, Provider Adapters, and multiple layers of Receipts. The mechanism was rigorous, but the distance between the action named by the user and the internal protocol was too great.

After simplification, commit, push, pr-submit, merge, and deploy are once again five distinct literal goals. For compatibility, pr_commit means only: validate the accepted scope, commit on a feature branch without necessarily pushing, and then prepare the PR title, body, Reviewer, source branch, and target branch. Creating or updating the Bitbucket PR still requires an exact preview and renewed confirmation; merge and deployment remain outside the authorization.

This does not reduce control. It places control at the moment immediately before a side effect occurs. Ordinary local work no longer pauses repeatedly, while high-consequence actions still must stop.

Safety contracted from process machinery into a small set of invariants#

After removing the Promotion Runtime, safety no longer depends on “every change must first execute in isolation.” Four layers share the responsibility:

1. Top-level configuration defines confirmation thresholds for protected branches, production or persistent data, cost, destructive actions, and external actions;
2. repository rules constrain branch, scope, and domain behavior for the current project;
3. sandboxes, file permissions, and protected-branch Hooks provide mechanical boundaries;
4. Git, tests, Providers, and production entry points provide independent post-execution readback.

This resembles the direction OpenAI summarizes in Harness Engineering: entry points should work more like maps than like permanent manuals containing all knowledge; at the same time, boundaries that genuinely matter should be mechanically enforced rather than repeatedly asking the model to be careful in a Prompt.

What the current evidence can—and cannot—prove#

In a local snapshot of the simplification branch, the structural facts I could confirm were that the old Runtime and fixed Agent/Team/Promotion directories had left the main path; a lightweight Validator still checked structural budgets, resolvable routing, residual Runtime references, Agent migration, read-only RAG markers, diagram validity, and protected-branch Hooks. These details continue to evolve and must not be treated as permanent current truth.

I can also confirm the subjective experience: several tasks reached real code faster, required less intermediate bookkeeping, triggered Compaction later, and were simpler to recover after compression.

But none of this proves that the new approach is superior in long-term correctness. Fewer files are not a quality metric, and a green Pipeline proves only that the contract is internally consistent within the current checks. The next step is to keep recording:

• Time to First Useful Edit;
• total Tokens, tool calls, and Compaction count per task;
• first-pass focused-test success rate;
• useful-findings and false-positive rates from Local Review;
• number of post-PR rework cycles;
• counts of correct and incorrect interventions by safety Gates;
• post-deployment regressions and time spent on manual intervention.

Only when these metrics remain stable over time across comparable tasks can simplification be said to improve net efficiency. Otherwise, some of the removed mechanisms may need to return on a risk-based basis.

My final understanding: the Harness must also be questioned version by version#

The value of early Marshall was that it turned implicit engineering discipline into a structure visible to the model and enforceable by the runtime. It solved problems that genuinely existed with Codex 5.4 and 5.5, so it was not simply a history of “taking the wrong path.”

But every rule in a Harness contains an assumption about model capability: the model cannot plan for itself, cannot maintain scope reliably, cannot recover after Compaction, or cannot use native tools dependably. After a model upgrade, those assumptions must be revalidated. Otherwise, scaffolding designed around an old capability boundary gradually becomes a burden on the new model.

I now prefer to see a Harness as a set of falsifiable assumptions rather than a permanent architecture:

• when the model cannot perform a capability reliably and the cost of failure is controllable, help it with context, tools, and evaluation;
• put mechanically verifiable boundaries into code, Hooks, or Provider Policy;
• preserve clear and independent authorization for actions with real-world consequences;
• promote a process to a persistent workflow only when it truly needs recovery, retries, and auditing.

This transition is not a move from rigor to carelessness. It is a move from “using a workflow to constrain every step” to “letting the model own the path, letting evidence prove the result, and letting Gates control the consequences.”

Further reading#

• GPT-5.6 Model Guidance: simplify Prompts, define authorization boundaries, and compare quality, Tokens, latency, and cost on representative tasks.
• Harness engineering: leveraging Codex in an agent-first world: repository knowledge, Agent-readable systems, feedback loops, and mechanical boundaries.
• Effective context engineering for AI agents: Context budgets, Compaction, structured notes, and the task shapes suited to multiple Agents.
• Effective harnesses for long-running agents: how long-running tasks maintain continuity across sessions with progress files and Git history.

The Chinese Harness series continues with the overall architecture (Chinese) and examines the final mature design of the old Harness layer by layer. The top-level safety boundary is covered separately in Safety Gates Before Agent Autonomy.