# My agent delivery harness
Source: https://manaienko.com/how-i-work/agent-delivery-harness/
Author: Artem Manaienko

I built NADILI's delivery harness to coordinate coding agents through planning, independent review and checks. I approve the plan and start the work.

I built this harness for NADILI, my independent product since July 2026. As the product owner and hands-on integrator, I set the direction and approve the work. The harness coordinates planning, implementation, independent review and checks. The source and selected tests are public.

[Source on GitHub ↗](https://github.com/artemmanaenko/nadili_harness)Code, docs and selected tests

## My rules, replaceable workflows

The harness owns the delivery contract. An adapter maps a workflow onto it. Codex and Claude Code provide the agent execution environment.

My delivery rulesStages, roles, checks and limitsWorkflow adaptersMap methods onto the same rulesgstackActiveTRIPLegacy workdefine the contractMy delivery rulesStages, roles, checks and limitsWorkflow adaptersMap methods onto the same rulesgstackActiveTRIPLegacy workdefine the contract

gstack is the active adapter. TRIP remains for legacy work.

## From plan to integration

I approve the plan, then tell the harness to start. Review and applicable QA findings return to the builder. The correction goes through review and affected QA again, within the approved limits.

01 / PLAN02 / BUILD AND VERIFY03 / INTEGRATEPlan + reviewScope and designApproveMy decisionStart workMy instructionBuildBounded changeReviewIndependentRuntime QAWhere applicableFinal checksCurrent candidateIntegrateInto mainDone / owner UATRelease is separateReview findingsQA findingsPlan and reviewScope and designApprove, then startMy decision and instructionBuildBounded changeReview + applicable QAIndependent checksFinal checksCurrent candidateIntegrate into mainDone or owner UATfix

Review follows the actual code version and carries earlier findings forward. Production release is separate.

Worktrees isolate edits. Execution leases coordinate heavy checks on the shared machine. The implementer does not approve its own work.

## Where the work comes back to me

The harness coordinatesWork, findings and recorded attemptsChecks passedReview + applicable QA\+ final checksStopScope change, blocker,missing evidence or limitA checked changeReady for integrationBack to meDecide the next stepThe harness coordinatesWork, findings andrecorded attemptsChecks passedReview +applicable QA +final checksStopScope change,blocker, missingevidence or limitA checked changeReady forintegrationBack to meDecide thenext step

The harness stops for a decision when the work cannot continue within the agreed scope and limits.

Some rules are enforced in code; others rely on agent instructions. The attempt counter covers recorded actions, not every tool call or the provider bill. The selected tests check those mechanisms, not every agent judgment.

The [walkthrough](https://github.com/artemmanaenko/nadili_harness/blob/main/docs/WALKTHROUGH.md) uses an imagined failed form save to show the correction loop. My earlier [LinkedIn post and PDF](https://www.linkedin.com/posts/artem-manaienko_my-three-layer-delivery-harness-for-coding-ugcPost-7498712849012391936-OUB7/) show the TRIP-based version.