Agentic Harness Orchestration
Agentic AI software delivery, with named human approval.
Agents do the work. People approve it. Agentic Harness Orchestration is how Anitech runs AI-led software delivery: three Harnesses for requirements, engineering and quality do bounded work under named human approval gates, and a two-person pod runs them. Requirements is live with one client, Engineering enters first client use in October 2026, and Quality is in development.
The three Harnesses
What each Harness does, and where it stands.
A harness is everything around an AI model that decides what the agent may do, checks what it did and records the result. Ours cover requirements, engineering and quality, with requirements live today.
Live with one client
Requirements Harness
Live with one client. Turns a title-only requirement into a cited draft: every claim carries a source excerpt, a separate critic doubts it, and anything unknown becomes an open question for a person.
Built, first client use October 2026
Engineering Harness
Built, and going into first client use in October 2026. Plans and builds each approved story, runs the quality gates and opens a merge request for a person to review.
In development
Quality Harness
In development. A QA agent is being trialled: it reads a story and drafts executable test cases. It is not yet part of a client delivery.
Governance
People approve. Agents work inside fixed rules.
The control sits in the tools and the gates, not in extra meetings. These are the standing rules every agent in the Harnesses works under; the approval gates are set out below.
A person merges. The client signs off.
Agents open merge requests and a person merges them. The client alone marks user acceptance testing done.
No write path to your systems of record
Agents draft into a repository. One script, run by a person behind a permission prompt, is the only thing that writes to a system of record such as your work-tracking tool.
Evidence comes from the pipeline
An approval binds to the exact plan approved, so editing it afterwards voids it. Test results come from the pipeline that ran, never from an agent saying they passed.
Where people decide
Four approvals before anything is built.
The pod
Two people run all three Harnesses.
The delivery unit is a pod of two, the same size before and after the Harnesses. For AI-led delivery engagements we run flow, not sprints. Conventional delivery stays available alongside it.
Forward Deployed Engineer
Starts each ticket in the Harness, reads the plan with the Product Engineer, oversees the run and creates the merge request.
Product Engineer
The product-side partner. Reviews the plan, prepares the next tickets so they're ready before the current one finishes, and reviews the QA results.
A Planning board and a Live board
Work moves through the approval gates on the Planning board and is built on the Live board. Ready for Development is one shared status, so nothing has to sync.
Two ways to run them
We run them for you, or you run them.
We run them
Our pod operates the Harnesses on your behalf and owns the outcome. You see the gates and sign off what ships. The first engagements run this way.
You run them
Your own team runs the Harnesses, and we set you up and train your people. We agree this per engagement, once the Harness you want is in production use.
Evidence so far
One pilot result, with its limits.
49 stories
taken to opened merge requests by a two-person pod, in a two-week pilot in August 2026 with a North American education-technology client.
About 48 hours
elapsed, human approval gates included. Self-reported from the pilot's run logs.
7 of 10 days
went on access and configuration before the first story ran; about two days were spent running. The merge requests were opened, not yet merged, and quality outcomes are not yet measured.
The working behind it
Read how we run the pilot, the rules and the baseline.
What a two-person pod did in two days, and what it cost to get there
The pilot as we measured it: what we recorded, what we didn't, and how the constraint moved upstream.
The rules our delivery agents work under
The standing rules, written for a CTO and their security reviewer.
Where delivery time goes: nearly half of it is waiting
In 587 timed stories (of 1,244 in one client's work-tracking history, snapshot 24 September 2026), about 47% of story time was spent waiting: statuses where a story sits between people, such as ready, blocked, or finished one stage and waiting for the next. A further 36% of stories (a share of stories, not of time) went back to an earlier status.
Talk to us about the Harnesses.
Tell us what you need built and where AI-led delivery would fit alongside how you work today. We will tell you plainly which Harnesses are ready.