Harness engineering
Operating Claude is a full-time job
Agents got powerful — and operating them quietly became the job. The industry has a name for what's missing. We automated it.
June 11, 2026 · The AgentLoom team
AI coding agents crossed a threshold in the last year: given the right context, they implement real features, write real tests, and reason about real codebases. What didn't change is who runs them. A developer still starts the task, chooses the context, approves the permissions, inspects the output, feeds the CI failure back, asks for the fix, runs the review, resolves the conflicts, and decides what happens next. Nobody designed that job. It accreted.
Run the loop for one agent window and it feels like leverage. Run it for two or three and it feels like air-traffic control. Past that, it stops working entirely — not because the model gets worse, but because the human does: as sessions stretch, context drifts, attention fragments, and the operator becomes the bottleneck the agent was supposed to remove.
The industry named the missing layer
Over the past year, the discipline of making agents reliable got a name: harness engineering. The framing is simple — an agent is a model plus a harness, where the harness is everything around the model: the tools it can use, the permissions that bound it, the verification loops that check its work, the memory that carries state between sessions, and the observability that lets humans trust it. Teams that invest in the harness get dramatically better results from the same model. That finding keeps repeating across the industry.
So engineering teams everywhere are now hand-building harnesses: permission configs, custom hooks, context files, review scripts, memory conventions. It works — and it's a second job. Every repo needs its own setup. Every stack change invalidates part of it. Every improvement someone makes in one repo has to be copied to the others. Hand-built harnesses drift, sprawl, and rot, exactly like hand-built CI did before CI platforms existed.
Harness engineering, automated
AgentLoom's position is that the harness should be derived, not authored. When you connect a repository, AgentLoom reads the codebase, the stack, and the roadmap, and derives the harness from what it finds: role-specialized skills shaped to your technology, permission envelopes scoped to what each role actually needs, verification gates wired to your own test suite and CI, and delivery rules that decide when work may advance.
Derived from your repo — roles, permissions, and gates come from the code that exists, not from a template.
Staged per task — each run gets only the skills, tools, and context the task needs; structured artifacts and validation rules are generated from the active team.
Re-derived as you evolve — periodic roadmap refresh re-evaluates the roadmap, the team design, and the tooling against what the repo has become.
At runtime the harness does what no human operator can sustain: it carries runtime memory scoped to each issue, validates structured artifacts with hooks, checkpoints the run so CI waits and review rounds cost nothing, and logs every action under an audit trail. Claude is the model. AgentLoom is the harness — engineered, governed, and run for you.
You stop operating and start steering
None of this removes the human. It relocates them. The delivery loop — backlog to merged PR to follow-up — runs itself, and loops you in only where you gate it: approvals, merge policy, sensitive transitions. Direction stays yours: ask for a feature, report a bug, change a priority, and it becomes scoped work in the pool. Operating Claude is a full-time job. It shouldn't be yours — and now it doesn't have to be.