A Recursive Project-Improvement Loop
This article summrize what I am currently use as my optimzed way of agentic coding workflow. Hope it will be helpful to you as well.
Here is the main thesis: Most agentic coding setups still treat AI agents like fast freelancers. They produce useful patches, but the project rarely becomes easier for the next agent to understand, verify, or extend. Compound Orchestrator is a reusable project harness designed to make each serious agent-assisted task leave behind better planning contracts, clearer ownership, stronger reviews, fresher documentation, and durable learning.
The model matters, but the harness is part of the intelligence. A stronger harness changes agent work from a sequence of disconnected chats into a cumulative project system.
Figure 1. Compound work loops planning, review, implementation, verification, and durable memory.
Why Agent Coordination Is Now the Bottleneck
Modern coding agents can inspect unfamiliar repositories, draft architecture, modify code, write tests, and explain trade-offs. The bottleneck has shifted from output generation to coordination. Teams now need predictable ways to prevent conflicting edits, require review comments to be addressed, keep README files current, and preserve decisions outside ephemeral chat transcripts.
One agent edits a file another agent was relying on.
A design decision exists only in a chat thread.
Tests cover happy paths because edge cases were never promoted into the spec.
A second agent reviews work, but the authoring agent never revises it.
The README drifts, so the next agent starts from stale context.
What Compound Orchestrator Adds
Compound Orchestrator installs a project-local operating model for agentic work. It includes scripts, skills, command templates, ownership tracking, review gates, README maintenance rules, and compound learning folders. The goal is not ceremony. The goal is to make high-quality agent behavior the default path through the project.
The public implementation is available here: Compound Orchestrator on GitHub.
Six Planning Contracts
The plugin promotes six HTML planning artifacts as visible contracts rather than private scratchpads. They are intentionally readable in a browser and can be reviewed by humans, Codex, Claude Code, or other agent teams.
Figure 2. PRD, users, architecture, and planning drafts feed the spec; test cases are derived from the spec.
prd.html defines the problem, scope, success criteria, non-goals, and business intent.
users.html defines roles, workflows, user journeys, permissions, outcomes, and handoffs.
architecture.html defines system boundaries, dependencies, failure modes, and diagrams.
planning.html defines phases, ownership, sequencing, risks, and delivery strategy.
spec.html turns intent into behavior: states, inputs, outputs, validation rules, errors, and acceptance criteria.
test-cases.html maps the spec to happy paths, edge cases, error cases, performance checks, and acceptance coverage.
Parallelize Drafting, Serialize Acceptance
The strongest pattern is not simply to parallelize everything. Discovery and drafting should run in parallel, but integration and acceptance should be serialized. A PRD agent, users/workflow agent, architecture agent, planning agent, and risk scout can all work at the same time. The spec agent should run only after those drafts are reconciled, and the test-case agent should run only after the spec is stable.
Figure 3. Agent teams draft in parallel, while the lead integrator serializes acceptance and conflict resolution.
Two-Round Cross Review
A review is only valuable if it changes the work. Compound Orchestrator treats cross-review as a two-round contract: the reviewing tool comments, the authoring tool revises, the reviewer checks again, the author closes remaining comments, and final acceptance records the result. This avoids both shallow one-pass review and endless review loops.
Figure 4. Two review rounds require explicit author responses before final acceptance.
GitHub Examples
README Freshness as a Gate
Every generated project carries a README maintenance rule: remove stale information, preserve unchanged information that remains useful, add new content, and reorganize the README so the current project state is easy to follow. This is mundane on purpose. The README is often the first context future agents read. If it lies, the next task starts with bad priors.
