How Feedback Loops Turn Agentic Coding Into a Self-Improving Factory

Work can begin with a bug report, an agent report, a review finding, or an idea from you. Capture it in a durable work record so the investigation, evidence, decisions, and later results remain connected.

An agent then investigates the work in context. It examines the affected behavior, relevant code, dependencies, risks, and likely consequences. The original request becomes a wider proposal with:

• The outcome the work should produce
• The requirements that shape the solution
• The proposed scope
• Important boundaries
• Known risks and dependencies
• Expected product behavior
• Evidence that can confirm completion

Interface work also receives a design pass. A design agent develops the visual and interaction direction, and that direction becomes part of the proposal.

You review the intent, scope, trade-offs, and design direction. Once you sign off, the proposal is finalized into work that agents can execute.

This planning process applies to most tasks. The amount of investigation scales with the work, while interface changes add the design stage.

Process

Bug report, agent report, review finding, or idea → durable record → investigation → wider proposal → design when needed → user sign-off → agent-ready work

Run the delivery workflow

Once you approve the proposal, one conductor agent owns the delivery run. It creates a dedicated branch and worktree for the task. This keeps each task isolated while several tasks move forward at the same time.

Plan the run. A planning agent reads the approved proposal and investigates the relevant code. It turns the work into an execution plan made of ordered waves and focused lanes.

The plan defines:

• What each lane must deliver
• Which code each lane is responsible for
• The contracts shared between lanes
• The dependencies between waves
• The evidence each lane must return

Each lane should fit within roughly 200,000 to 300,000 tokens of agent context. Larger assignments are divided again so each agent can investigate, implement, test, and repair its work without carrying unrelated parts of the project.

The conductor reviews the plan, adjusts its boundaries, and locks the execution order before dispatching the coding agents.

Execute the waves. Each wave contains the lanes that are ready to run. Several lanes can run in parallel. Later waves begin when the code, contracts, or decisions they depend on are ready.

Each lane goes to a coding agent with its goal, ownership boundaries, shared contracts, and expected evidence. The agent implements its part, writes its tests, and runs scoped checks over the files it changed.

All lanes belonging to the task work inside the same task worktree. The conductor coordinates agents that share contracts or touch the same files, carries decisions between waves, and resolves contradictions as the implementation develops.

The conductor also coordinates expensive checks and shared development resources. Agents check machine capacity before starting resource-heavy runs, and access to ports, services, databases, and shared build directories is scheduled across the active lanes.

Review the combined result. When the implementation waves converge, independent review agents inspect the complete change in parallel. They review the actual code, tests, and outcome against the approved scope.

Their prompts remain neutral. The reviewers receive the scope and implementation evidence without the conductor's diagnosis, suspected problems, or preferred conclusions. Each reviewer forms its own verdict from the code.

The conductor checks every finding against the implementation and the workflow's quality rules. Findings supported by the evidence become repair work. Incorrect findings are rebutted with evidence, and findings outside the task boundary are recorded for later handling.

Run the honesty check. Agents disclose failing tests, tool errors, incomplete work, unverified assumptions, the weakest part of their delivery, and review findings closed without evidence. Every disclosed item enters the repair set or is carried forward as an explicit unresolved finding. This prevents agents from hiding uncertainty behind a confident final report.

Review and honesty findings that require action become focused repair lanes assigned to fresh coding agents. Those agents correct the problems and return new scoped check evidence.

Report the completed run. The conductor verifies the returned evidence and produces one run report covering the implementation, checks, review decisions, repairs, unresolved findings, and significant time sinks. The work remains in the isolated task worktree for the outer delivery process to commit and verify.

Process

Approved proposal → planning agent → conductor-approved wave plan → parallel coding lanes → scoped checks → unbiased reviews → honesty check → repair lanes → run report

Close out and land the completed work

The build loop finishes with an implementation, a run report, and an uncommitted task worktree. The original conductor now turns that result into a deliverable that another agent can verify and land.

Prove the exact branch. The conductor commits the completed work, runs the branch-level checks against that commit, and records proof for the resulting tree. If a check fails, the conductor repairs the branch, amends the commit, and repeats the proof.

Once the committed tree is green, the source branch is published so the close-out agent can retrieve the exact work. A production patch is also generated against the recorded target branch.

When the change requires visual evidence, the conductor writes a targeted browser checklist and adds it to the browser verification queue. The browser run happens later against the assembled product.

The conductor then posts a durable delivery report containing the source branch, target branch, completed checks, review results, browser request, product report, harness debrief, and any deviations from the agreed workflow.

Use a fresh close-out conductor. A different agent reads the delivery report and retrieves the exact source branch and target. It generates a fresh production patch and makes a short, binary judgment:

• Does the patch deliver the agreed outcome?
• Is the solution appropriately scoped and simple?
• Does it avoid introducing new problems?

A mergeable patch continues to landing. A blocked patch returns with the exact defects that require repair.

Land the work. The close-out conductor merges the task as one commit onto its recorded target branch and verifies the resulting commit. It then removes the completed task worktree and source branch, updates the tracker to show that the work is fixed in branch, and reports the exact landing result.

Process

Completed build run → commit exact tree → branch checks and recorded proof → publish source branch → browser and reporting handovers → fresh close-out conductor → production patch judgment → merge and landing proof → tracker update

Verify the assembled product in the browser

Browser verification runs after completed task branches have converged into the assembled application. The browser agent sees the combined product state that people will actually use, and one running development stack can verify several completed changes.

This timing is a portfolio-level efficiency choice. Several tasks may be active at once, each isolated in its own worktree. Starting a complete application stack for every worktree creates repeated setup work and competition for ports, services, authentication, databases, build directories, and browser state. It also verifies an isolated product state that may change as soon as the next branch lands.

The build workflow therefore creates a durable browser request during delivery. The request remains queued while work continues, then runs against the assembled product after related changes have converged.

Browser verification is reserved for evidence that automated tests cannot provide:

• Layout and visual state
• Interaction behavior and usability
• Real-browser rendering
• Loading behavior and interface responsiveness
• Console errors and warnings
• Unexpected or failed network activity

Create a targeted handover. The delivery agent records what changed, where to find it, the exact actions to perform, and the result that should appear. The checklist also identifies the previous failure that must be gone and any console or network behavior that needs attention.

Verify the assembled application. A browser agent starts the shared stack, confirms which application state it is viewing, and works through the queued checklist. After every navigation or state change, it captures and visually inspects a screenshot. It also records relevant console and network activity.

Each checklist item receives a clear result:

• Visually verified
• Functionally verified
• Failed
• Not verified, with the reason

Failures include reproduction steps, expected and observed behavior, severity, screenshots, and captured network evidence. This gives later agents enough information to investigate without repeating the original browser session.

Return findings to triage. Each verified failure becomes a durable product finding in the shared triage intake. Successful checks close their browser request. The evidence remains connected to the change that requested the verification.

The agents handle the detailed browser checks and evidence collection. You can review the final assembled product and decide which verified findings matter most.

Process

Browser request created during delivery → changes converge → assembled application starts once → targeted browser checks → screenshots, console, and network evidence → completed request or durable triage findings → final product review

Additional review loops continue examining the product as new changes arrive and the assembled application evolves.

Review new changes. Automated agents review new commits and proposed integrations independently of the agents that built them. Findings are tied to the exact version reviewed, stored durably, and checked again as the branch evolves so the current report reflects the current code.

Run scheduled code reviews. Scheduled agents examine recently integrated work across task boundaries. This wider view can reveal conflicting assumptions, incomplete integrations, duplicated behavior, and problems created by the combined effect of several changes.

Run scheduled browser reviews. Browser agents inspect the assembled application, exercise current behavior, and capture visual, interaction, console, and network findings.

Preserve the findings. Each review records what was examined, which product version was used, what evidence supports the finding, and how serious the observed problem appears to be.

The reviewers' job ends when those findings have been stored in the shared intake. They surface evidence without expanding active tasks or deciding which findings should become new work.

Review agents are deliberately kept within this reporting role while their prompts and judgment improve. Their findings remain useful without being treated as instructions.

Process

New changes and assembled product → independent automated reviews → evidence-backed findings → durable shared intake

The harness is a separate, versioned project containing the machinery used to manage agents. It makes the workflow reusable across multiple software projects while still allowing each project to supply its own knowledge and specialized processes.

The harness has two layers:

• Shared global layer: reusable agent roles, workflows, prompts, skills, scripts, checks, tools, reporting formats, and safety rules.
• Project layer: architecture facts, commands, coding rules, specialized workflows, integration details, and product conventions.

Agents receive both layers. The shared layer tells them how to work. The project layer tells them how that work must be performed in the current repository.

This allows a new project to reuse the established planning, delivery, review, reporting, and feedback loops while adding only the knowledge and processes unique to that project.

Give each kind of knowledge one home.

• Recurring agent responsibilities become reusable agent roles
• Repeatable workflows become skills
• Repeated command sequences become scripts or tools
• Recurring quality problems become checks
• Safety requirements become guardrails
• Project architecture and commands stay in the project layer
• Specialized product workflows stay with the project that needs them

Clear ownership reduces duplicated instructions and prevents agents from having to guess which rule or process applies.

Collect feedback from real delivery runs. At the end of each run, agents report problems they encountered in the workflow. This includes broken tools, misleading output, repeated manual commands, coordination friction, missing instructions, and guidance that did not match reality.

Each report explains what happened, which part of the harness was involved, the available evidence, and what the problem cost in time, retries, or blocked work.

Turn recurring friction into improvements. Harness debriefs are reviewed together so repeated problems become visible across projects and delivery runs. Each finding is checked against the current harness and assigned to the shared layer or the relevant project layer.

Broken tooling can be repaired directly. Repeated manual work can become a prepared script or workflow. Missing project knowledge can be added to the project layer. Changes to prompts, skills, and agent instructions receive human review because they affect how future agents reason and behave.

Make the improvement available to future agents. Approved changes are versioned in the harness and made available to the appropriate agent environments. Shared improvements benefit every connected project. Project-specific improvements strengthen the workflow for that product.

The next delivery run starts with those improvements already available. Product work therefore improves both the software and the machinery used to build it.

Process

Delivery friction → evidence-backed harness debrief → shared harness intake → verify and classify → improve the global or project layer → version the change → better future runs across one or many projects

The goal is straightforward: every run should require less human attention than the one before it.

The workflow concentrates your time on decisions that require product judgment. Agents gather evidence, process findings, prepare proposals, execute the work, and return with concise decisions for you.

Process findings into approved work

Findings from every agent source enter the same processing workflow. This includes delivery reviews, honesty reports, commit and integration reviews, scheduled reviews, and browser verification.

An agent investigates each finding against the current product. It:

• Verifies the evidence
• Groups findings that share a root cause
• Removes duplicates
• Checks for matching open or closed issues
• Applies predefined acceptance rules
• Discards findings that are unsupported, outdated, or already resolved
• Removes speculative scope, unnecessary complexity, and YAGNI

Each surviving finding becomes a proposed issue in a consistent, easy-to-read format. It explains what is broken, where it occurs, why it matters, what evidence supports it, and what outcome is required.

You can approve the issue, reject it, or request a change. An approved issue enters the Todo list.

Process

Agent findings → investigate → verify → deduplicate → accept or discard → remove bloat → present issue → user decision → Todo

Triage the Todo list

A triage agent reviews the approved Todo list and confirms which items are ready for execution. It checks that each item has enough evidence, a clear outcome, workable scope, known dependencies, and no unanswered decision blocking the work.

The agent then selects the most urgent or desirable ready items. The ranking can consider:

• Your current preferences
• Product impact
• Risk
• Dependencies
• Delivery effort
• The cost of delaying the work

You receive a short ranked selection with a reason for each item's position. You choose what enters planning next.

Process

Todo list → readiness check → rank by urgency and user preference → present selection → user chooses the next work

Approve the direction

The selected item enters the planning workflow. Agents investigate it, expand the requirements and scope, and prepare any required design direction.

You review the intended outcome, boundaries, trade-offs, and design. Your approval turns the proposal into agent-ready work.

The agents then carry the implementation, testing, review, repair, reporting, and technical close-out. Their product findings return to the findings workflow, and their workflow findings return to the harness.

Review the harness decisions

Harness debriefs can produce direct tooling repairs, new automation opportunities, and proposed changes to agent instructions.

Agents handle the investigation and mechanical work. You review changes that affect prompts, agent responsibilities, workflow rules, or other decisions that will influence future agent behavior.

Review the assembled product

Browser agents work through the verification queue and collect detailed visual, functional, console, and network evidence.

You eventually review the assembled product itself. You decide whether it meets the intended product direction and which verified findings should return to the findings workflow.

The resulting user workflow

Your recurring work becomes:

1. Approve or reject verified issue proposals
2. Choose the next item from a ranked Todo list
3. Approve the intent, scope, and design direction
4. Review proposed changes to agent behavior
5. Review the assembled product

The agents handle the detailed investigation, implementation, testing, review, evidence collection, reporting, and feedback processing between those decisions.

Overall loop

Agent findings → approved Todo → ranked ready work → user selects and approves direction → agents deliver → product and workflow feedback → user reviews the assembled product → next cycle

As a workflow becomes repeatable, a skill can make it more precise by giving the agent the exact tool call to execute.

Several predetermined steps can be supplied as one chained command:

Bash({ command: "command1 <args> && command2 <args>" })

The agent receives the intended order directly, and leaves no room for guessing.

Use scripts to turn complex commands into agent-friendly tools

When commands become complex, need several variants, or produce large output, they can move into a script exposed through a skill or MCP tool. The script gives the agent one simple interface while handling the underlying commands and output processing.

A test runner is one example. A script can run Vitest, keep the complete raw output on disk, and return a compact summary with pass and failure counts, links to the artifacts, and instructions for extracting additional details from the raw files. This keeps large logs out of the agent's context while preserving the full evidence.

An issue tracker is another example. A skill can define the required fields, labels, statuses, and allowed lifecycle operations. A script or MCP tool can then expose simple actions such as finding ready work, picking up an issue, recording browser-verification state, or marking work fixed in a branch. Agents use those controlled actions without constructing raw GitHub commands, while the tracker and its boards remain consistent.