Harness Model
A minute for the overview.
Your team uses AI. What has the team agreed around it?
Imagine a team where AI drafts changes quickly, but review waits for two senior engineers. Another team repeats the same mistake for the third sprint in a row.
The Harness Model is a maturity model for AI engineering practice: a shared map on which software teams and their leaders assess how they work with AI today and choose where to invest next. Its thesis: once AI takes part in the work, the craft moves to designing the system that controls the AI, the Harness.
Four stages to explore and a fifth reserved as a future horizon, twelve aspects in four clusters, a profile rather than one grade.
The model is a diagnostic conversation starter, not a certification.
The result is a profile, not one grade, because a team is rarely at one stage across all aspects. The profile matters because maturity does not average: the weakest aspect erodes the returns of the others over time, like compounding debt rather than a hard ceiling.
We are Hands-on Architects. This model draws on first-hand experience of leading AI engineering teams.
A note and link to forward
This looks relevant to how we use AI. Can we spend an hour on it with the team?
https://handsonarchitects.com/harness-model
Note and link copied. Couldn’t copy. Select the note and link and copy them.
Read the stages
A stage names where the team's harness lives: what the team has made shared and repeatable around AI. The way of working the team repeats sets it, never one person's most advanced use, and it is not a score to optimise.
Read these against your team’s usual way of working, not its best day. Which sounds closest, and where does it not fit?
The harness is what the Harness Model measures: whatever a team puts around an AI model to make its work trustworthy, understood in the way the team understands it at the time.
Dotted-underlined names of practices, traps and questions open a one-sentence explanation from the model.
-
Stage 1 - Ad Hoc AI
Stage 1 is AI as an individual tool: the team cannot rely on a shared approach to AI, because nothing about its use has been agreed or made repeatable.
Stage 1, the first stage of the Harness Model, has no harness: the team has agreed nothing about how AI is used. That does not mean no AI. The company may have bought a tool that nobody quite knows how to use yet, and a few early adopters try it on basic tasks; where no tool is offered, or AI is forbidden, people often use their own out of sight, the trap Shadow AI Use, which can recur at any stage.
What marks the stage is that nothing about AI is shared at the team level. Each person finds out about it alone, and the team does not talk about it openly. Nobody steers how it is used: there is no agreed way of working with it, no rule on what may be sent to an assistant and no check aimed at what comes back. Nothing is shared, so what one person learns stays with them, and whatever AI contributes reaches the work unseen. Where a few people use AI to speed up their own delivery, their changes spike beyond what the others can match, and the team meets them as conflicts, in the code and between people, and as single, oversized code reviews. The team's tools, tests and documentation are the ones it had before AI, often automated, but not shaped for an agent.
-
Stage 2 - Team AI Practice
Stage 2 is AI as a team competence: the team relies on what its people know and share about AI, and each answer is still applied and checked by hand.
Stage 2, the second stage of the Harness Model, has a harness held in people's hands and heads. The Guides are mostly what a person writes into a prompt, plus the first rules for the assistant in a prompt file (Agent Instruction Files); the only Sensors are people reading the answers.
What marks the stage is that AI is in the open. The team has an agreed tool and written rules, on a wiki everyone can read, on what may be sent to it. People talk about how they use it and share what works: prompts that give a usable first answer, mistakes to avoid, which tool suits which task, sometimes kept in a Shared Prompt Library. They know AI from their own hands-on work, best on problems they already understand, where they can judge the answer (Start on Familiar Territory). They control it by hand: a person asks, reads the answer, applies what holds up and checks it, more strictly the harder the change is to undo. The tools are secondary; a team that measures itself by the tools it has adopted misses what changed (Counting Tools as Maturity).
-
Stage 3 - Reusable AI Workflows
Stage 3 is AI as a standard way of working: the team relies on reusable instructions and commands written for its agents, which people still start and steer, reading the checks' results themselves.
Stage 3, the third stage of the Harness Model, has a harness written down for the agent: mostly Guides, from the instruction files the agent reads before every task to reusable prompts and commands that a person starts and steers. These are not yet the versioned workflows that agents run at Stage 4 - Governed Agentic Delivery (Versioned Workflow Definitions). The first computational Sensors may run in the agent's path, and an agent may rerun the tests a person asks for within a session that person steers. What the stage lacks is the loop of Stage 4 (Steering Loop): the harness does not yet hand every check's result back to the agent to correct itself, so a person reads the results, and people remain the main sensor, reviewing what the agent produces and deciding what goes back into the harness.
What marks the stage is that what people know is written down for the agent. A person keeps the file the agent reads before every task and structures the documentation in the repository, so the agent reads the team's context, the same information people work from, instead of someone pasting it (Agents Are First-Class Team Members). Agents are part of the daily work: they read and edit files and run commands, and a person delegates several tasks at once. People control the work by staying in the loop: the agent generates, a person reviews every line, and boundaries live in convention, review and people's heads. What the team shares now includes the agent's mistakes: lessons from review reach the retrospective and from there, by hand, the instruction files and conventions.
-
Stage 4 - Governed Agentic Delivery
Stage 4 is AI as a supervised executor of work: agents run the team's agreed workflows, while people review plans and results against criteria and remain accountable.
Stage 4, the fourth stage of the Harness Model, has a harness automated and governed by people: Guides and Sensors are built into the work, and agents run the team's versioned workflows (Versioned Workflow Definitions), with gates between research, planning and execution. Sensors hand their results straight back to the agent, which corrects itself before a person looks, and people build and tune the harness instead of supervising each task. Review does not disappear: it moves from lines of code to specifications, plans and agent output judged against criteria, so people's time shifts from code review to specification.
What marks the stage is that the harness itself holds what the team knows and wants. Knowledge lives in the repository as the system of record, and the design taste people once enforced in review is codified into checks that flag a violation to the agent. People control the system rather than reading each change line by line: a person is on the loop and improves the harness when a mistake recurs (Steering Loop), autonomy grows only as fast as verification earns it (Maturity Is Trust Earned), and a person still answers for what the agents do (Accountability Stays With the Human). What the team shares now reaches agents as well as people: every signal a person decides from is reachable by agents (Agents Are First-Class Team Members), agent failures feed the harness, and handing judgment on from person to person becomes someone's job.
-
Stage 5 - Self-Improving Harness
Reserved future horizon.
Explore an aspect
As you read an aspect, which stage sounds closest to your team, and which sentence would you challenge?
For the team waiting on review, read Cognitive Load and Time Allocation. For the team repeating a mistake, read Feedback.
Most excerpts walk through the stages in their own words. Look for the sentence that sounds like your team.
Dotted-underlined names of practices, traps and questions open a one-sentence explanation from the model.
People
The People cluster of the Harness Model asks who does the work in a delivery unit and what that work asks of the people in it.
-
Role in a Team, an aspect of the People cluster, asks how the work of a delivery unit is divided: which work people do, which work agents do, and what shape the team takes as that division shifts.
The aspect moves along two axes at once. Team shape runs from a large team of specialists, through a team organised around delivery, to generalists who each own an initiative. Agent capability runs from no agent, through suggestions only and access to files and the terminal, to full-stack environments in which an agent builds, runs and checks a change with a real browser and local observability (Ephemeral Full-Stack Agent Environments). As agents take over execution, the human part moves from doing the work to leading delivery (Human Role Evolves, Never Disappears). Agents can supply technical depth on demand; domain depth (business rules, customer workflows, the market) stays with people, and where it is tacit the team boundary can be drawn around it (Complicated-Subsystem Boundary Around Tacit Knowledge). The diagnostic question for the aspect is the Specialist Removal Test.
The stage 3 to 4 jump is where both axes move together, and it is expensive. A team that gets leaner pays for it with the platform its agents run on, usually owned by a platform team (Platform Team Owns the Harness), and with the governance that keeps their extra leverage safe. A team that tries to shrink without paying either ends up with as many people as before and less trust in its agents (Shrinking the Team Without Paying the Platform Cost); building the platform before anyone has lived the patterns is the opposite failure (Speculative Harness Platform). Whether a team then gets smaller or keeps its size and owns more scope is left open; what the work left with people costs them is the subject of Cognitive Load and Time Allocation.
It is the one People aspect that describes people and agents together, as one team, because the model rejects treating agents as second-class members (Agents Are First-Class Team Members). It describes how the work is divided, not how many people do it.
Which stage sounds like your team here? Which sentence would you challenge?
-
Cognitive Load and Time Allocation, an aspect of the People cluster, asks where people spend their time and minds: which work fills their day, how much attention it takes, and what comes back to them when the harness takes work away.
The load changes shape across the stages. At Stage 1 the load falls on the people who review: a few colleagues' AI-assisted pull requests arrive with large code and documentation changes, and reviewing them change by change, as the team always has, cannot keep up with that pace and size, because the team has no tools to manage them. At Stage 2, once the team uses AI in the open, mechanical work such as boilerplate, syntax and first-draft documentation starts to leave, and a person's time moves to directing and checking, while understanding the problem, designing the solution and judging the result stay with them (Human Role Evolves, Never Disappears). At Stage 3 agents take drafts, glue code and search, but people supervise each task closely, so the day goes into watching and steering agents live (Which Harness Your Hands Touch), and the load the agents send back is not yet budgeted. At Stage 4 the trade is made on purpose: the time generation used to take now goes to writing and reviewing specifications and plans, judging agent output against criteria, making the integration calls agents cannot make, keeping context current and learning, and the team plans for that load. Two traps wait there: planning on fewer people without budgeting for the load that comes back (Budgeting From Half the Ledger), and mentoring and one-to-ones dropping off the calendar because nobody owns them (Mentoring as the First Thing to Go). The question that tests the trade is Whose Workload Does This Team Reduce and What Work Flows Back.
The harness does not remove load; it moves it. Producing work gets cheap, while checking it, fitting it into the system, deciding and keeping the context current become the expensive part that stays with people (Harness as Cognitive-Load Lever); this is Discipline Relocates, It Does Not Disappear at the level of a team. Team Topologies treats each team's load as a finite budget, and one small study found verification load measurable and a driver of fatigue, so the load that comes back is a cost to plan for, not slack.
Where Role in a Team asks who does each piece of the work, this aspect asks what the work left with people costs them: a team can keep the same people and the same hours while every item of its week changes.
Which stage sounds like your team here? Which sentence would you challenge?
-
Skills, an aspect of the People cluster, asks which skills matter most to the people on the team at a stage: what they must be able to do well to work with agents.
The skills that matter move from a single conversation to the system around the agent. At Stage 2 the skill is getting a useful first answer: structuring the input so that it names the files, the patterns in use, the edge cases and the conventions, called Context Engineering and practised with the rigour of Prompt Engineering. Next to it sits learning, on code a person already knows, how far to trust the assistant (Start on Familiar Territory). The traps are leaning on generation while the fundamentals are still being learned (Generation Replacing Fundamentals) and retrying a session that has lost its direction (Iterating a Lost Session). At Stage 3 the skills turn into durable artifacts an agent works from: scenarios and one-page domain aggregates (SCN - Scenario Format, Domain Aggregates as Spec Origin), documentation an agent can find its way through, and project-specific Agent Skills. The test: if a person cannot write the scenario, neither can the agent (Spec-First Commits). Only some skills become durable, though. As much of the technical work passes to agents at this stage, judgment and the attitude to learn and adopt, to work well with people and with agents, to solve problems, find the right trade-offs and put options into words become the critical human skills, and they are the hardest to codify or delegate. Engineers whose strength is only writing code lose the very activity agents take over.
At Stage 4 three skills define the stage. Senior engineers name and codify the design taste they have always applied by instinct (Taste Invariants as Code, Where Design Taste Lives); this is slow work and the cost of the step from Stage 3 to 4, and teams that skip it stay at Stage 3 (Uncodified Taste). People run the Steering Loop, so that a mistake seen twice becomes a guide or a sensor (Recurring Mistake Converted into a Guide or Sensor). And they hold Calibrated Trust: knowing when to override the agent, how to tell that the harness itself is wrong (Guardrails Never Fire), and what honest verification looks like when the same agent wrote the tests.
Where Role in a Team asks who does each piece of work and Cognitive Load and Time Allocation what that work costs, this aspect asks what capability it takes. How a team absorbs AI change and passes a capability on, through experiments, enabling teams and mentoring, belongs to Learning.
Which stage sounds like your team here? Which sentence would you challenge?
Governance
The Governance cluster of the Harness Model asks what keeps agents safe and who decides.
-
Control, an aspect of the Governance cluster, asks where the autonomy lies: what an agent may do without a person, where the person engages relative to the agent's loop, and whether the boundaries and design taste that constrain agents are held by review or by tooling.
Where the person engages follows Kief Morris's loop progression. At Stage 2 autonomy is minimal: a person prompts an assistant and applies or checks each answer by hand, and the first rules for the assistant get written down in a prompt file (Agent Instruction Files). At Stage 3 the person is in the loop: the agent generates, the person reviews every line, and boundaries live in convention, review and people's heads, so steering and correction never stop, even in sessions that go well. The traps there are review that becomes the bottleneck (Line-by-Line Review Bottleneck), generation that outruns the structure meant to hold it (Fast Generation Without Structural Enforcement), a prompt that stays the only definition of the workflow (Prompt as the Permanent Workflow) and a team that stops at Stage 3 because the verification that would make more autonomy safe is missing (Withholding Autonomy for Lack of Verification).
At Stage 4 the person is on the loop, improving the harness rather than reviewing each output (Steering Loop, Which Harness Your Hands Touch). Module boundaries and data shapes are enforced; implementation choices are left to the agent. Each area of the repository, such as requirements, architecture and designs, has named owners whose approval the harness enforces, and changes to the harness itself are approved by a named team or named people and recorded with their rationale. Limits that can be stated as rules become Computational Sensors: Custom Linters with Remediation, Structural Tests for Module Boundaries and Taste Invariants as Code. Judgment that no rule expresses can still be written down as criteria a review agent applies (Inferential Sensors, Discipline Relocates, It Does Not Disappear). The price is the slow work of codifying taste (Uncodified Taste) and, on a brownfield system, a codebase that can hold a harness at all (Skipping Harness-Readiness on Brownfield). The stage is tested with Time to Notice a Boundary Violation, Where Design Taste Lives and Ownership When an Agent Ships a Break.
At platform scale the same move crosses teams: each team keeps autonomy over how it builds, while a Decision Harness governs what crosses from one team to another, working from a shared, machine-readable model of the platform (Machine-Readable Platform Model) that an Ingestion Harness keeps current.
Where Decision Making asks how a choice is reached and on what evidence, and Risk Mitigation what could go wrong and how far it would reach, this aspect asks who checks the agent and what it cannot break unnoticed; naming the taste to enforce is a capability people bring (Skills). Wherever the autonomy lies, a person still answers for the result (Accountability Stays With the Human), and it grows only as the harness earns it (Maturity Is Trust Earned).
Which stage sounds like your team here? Which sentence would you challenge?
-
Decision Making, an aspect of the Governance cluster, asks how decisions are made and on what basis.
The basis moves from opinion to measurement. At Stage 1 decisions rest on experience and opinion. At Stage 2 a person asks an assistant for options and their trade-offs and treats the answer as a menu, not a recommendation, because the assistant cannot judge organisational or operational fit (Brainstorm Architectural Options); the trap is an assistant that falls back on familiar patterns where the problem is new (Anchoring on Familiar Patterns for Novel Problems). At Stage 3 the decisions that matter are checked with a proof of concept instead of argued from experience (Validate Decisions with Cheap Prototypes), and a structured interview or a second model can test a concept before the choice is made (Decision-Tree Interview, Cross-Model Concept Review). Agents can triage and score, but people still gather the basis for each decision by hand.
At Stage 4 every signal a person decides from (backlog, metrics, logs, traces, fitness functions, customer feedback) is reachable by agents as well (Equal Access to Decision Signals), which is the deciding side of Agents Are First-Class Team Members. Agents propose and score candidates against those signals, and people check the decisions that matter with cheap prototypes measured against real outcomes, so the team moves from believing it is right to having measured. A signal only people can see is the trap Information Reachable by Humans but Not Agents; answering a platform question with task-level productivity figures is the Productivity Measurement Trap; building a harness platform on guesses before anyone has lived the patterns is Speculative Harness Platform. The question that tests it is Decision Signals Available to Agents. At platform scale a Decision Harness runs a feature through a structured canvas, so that vague vocabulary must resolve to named entities and contract collisions surface before code, while the people involved resolve what it surfaces; it is a designed pattern, not yet a validated result.
Where Plan asks what to build, why it matters and under which constraints, and Control who checks the agent and what it cannot break unnoticed, this aspect asks how any choice is reached and what evidence it rests on: what a choice contains belongs to Plan, the method and evidence behind it belong here, and a gate the choice must pass belongs to Control. However the evidence is gathered, a person still makes and answers for the decisions that matter (Accountability Stays With the Human).
Which stage sounds like your team here? Which sentence would you challenge?
-
Risk Mitigation, an aspect of the Governance cluster, asks how risks are managed: what could go wrong when agents take part in the work, how far the damage would reach, and how strict oversight should be in proportion.
The model covers two kinds of risk so far: security, framed as a zero-trust progression, and changes that are costly to reverse. At Stage 1 nothing about AI is agreed at the team level, so nobody manages its risk: a tool the company bought is tried without rules on what may be sent to it, and where no tool is offered people use their own out of sight (Shadow AI Use). At Stage 2 a person checks AI output by eye, more strictly the harder the change is to undo (Reversibility-Scaled Review), and code for authentication, authorisation, input validation and secrets always gets a human audit, however clean it looks (Security-Critical Code Without Human Audit). At Stage 3 generated code runs through the static and dynamic security testing the team already has, exactly like code a person wrote (Security Scanning of Agent Output), while an agent can still reach whatever the developer's own credentials allow. At Stage 4 agents get their own scoped, logged access (Scoped Auditable Agent Access), threat models include the agent as an actor (AI-Specific Threat Modeling), and tool descriptions, MCP servers and skills are verified like any other dependency because they can carry an attack (Supply-Chain Verification for Agent Tools). The question that tests it is Scope of Agent Access. Wherever the boundary is drawn, a person answers for what the agent does with its access (Accountability Stays With the Human).
Where Control asks who checks the agent and which boundaries and taste it cannot break unnoticed, and Decision Making what evidence a choice rests on, this aspect covers limits on what agents and their tooling may reach and checks aimed at a named risk, such as security, the supply chain or a change that is hard to undo. The risks of one piece of work, weighed while it is scoped, belong to Plan.
Which stage sounds like your team here? Which sentence would you challenge?
SDLC - Software Development Life Cycle
The SDLC cluster of the Harness Model asks how work gets done, from an idea to software running in production and back.
-
Plan, an aspect of the SDLC - Software Development Life Cycle cluster, asks what to build, why it matters, which constraints apply and how success and risk will be managed.
Plans move from boards only people read to plans that agents read, update and work from. At Stage 1 people write and order tickets on manual boards, from experience. At Stage 2 a tech lead hands an assistant a loosely defined feature and reworks the first-draft backlog items it returns (Decompose a Feature into Backlog Items); a team that keeps prompting from scratch and builds nothing reusable around it tends to give up on AI (Stalling at Chatbot Use). At Stage 3 the backlog moves where agents can read and update it: a Markdown file in the repository (Markdown Backlog in Repository) or, for a larger project that keeps its tracker, local files pulled from it and pushed back after the work (Sync-Work-Sync with Issue Tracker). Agents triage issues and people set the priorities. Planning grows and moves earlier: before code is written, the work is cut into explicit, scoped and well-ordered milestones and tasks, which early in a project takes more time than coding and is what lets agent-first execution speed up later (Implementation-Ready Task Decomposition). An agent can interview a person to draw out the open decisions before the breakdown (Decision-Tree Interview). The traps at this stage are a backlog item that only people can reach (Information Reachable by Humans but Not Agents), backlog items derived from meeting records in which every remark weighs like a decision (Every Statement Read as a Requirement, answered by Annotated Records for Agents), and a triage or progress report rebuilt from a fresh prompt every week (Prompt as the Permanent Workflow). The question that tests it is Information Equally Reachable by Agents.
At Stage 4 the plan is a first-class artifact in the repository, versioned and carrying its progress and decision logs, so people and agents work from the same plan and can compare its iterations (Versioned Plans with Decision Logs). It covers more than the technical work: it takes in the requirements and the architecture the change lands in, with its context, its constraints and the decisions already recorded (decision records). Work passes gates between research, planning and execution: agents research and draft, and people review the specification and the plan before execution starts, which takes much of the time code review used to take. Recurring planning work runs as a versioned workflow that a person triggers rather than from a fresh prompt (Which Harness Your Hands Touch), and the way the team captures requirements is written down and checked by a sensor instead of living in its owner's head (Where Verification Criteria Live). People set priorities and direction; agents work from the plan. At platform scale a Decision Harness shows product managers the contract changes a feature would need before the sprint is fixed, so they can choose the scope with its cost in view; it is a designed pattern, not yet a validated result.
Plan, Build & Deliver and Run & Improve are not a waterfall: building can send work back to planning, and what is learned in production feeds the next planning cycle. With agents, coding takes far less time than it did, so planning takes a larger share of the effort up front, and work that keeps coming back from Build & Deliver to Plan can mean the plan is not doing its job.
It covers the work before building starts: capturing what is needed, scoping it, cutting it into items and ordering them. What a choice contains belongs here, and so do the risks of one piece of work weighed while it is scoped. The method and evidence behind a choice belong to Decision Making; limits on what agents may reach and checks aimed at a named risk to Risk Mitigation; the documentation and records a plan draws on to Knowledge; turning a ready item into a deployable change to Build & Deliver.
Which stage sounds like your team here? Which sentence would you challenge?
-
Build & Deliver, an aspect of the SDLC - Software Development Life Cycle cluster, asks how a piece of work becomes a trustworthy, deployable change and reaches production safely.
Delivery moves from occasional AI help checked by eye to agent-first delivery in which the checking has moved into tooling (Discipline Relocates, It Does Not Disappear); the question Share of the Day with an Agent Running follows that move, from none of the day to most of it. At Stage 1 AI has no agreed place in the workflow: a few people use it on their own, and the pipeline and tests are the ones the team had before AI. At Stage 2 people use AI now and then for specific tasks; an agent may run the tests, but a person checks the result and owns the change. The step to Stage 3 is turning the prompts people repeat into reusable commands and prompts that a coding agent runs, reading files, running tests and iterating on failures (Agentic Coding), together with a habit of sharpening one part of the harness every sprint (Sprint-Aligned Harness Investment). The traps are prompting from scratch and building nothing reusable (Stalling at Chatbot Use), a one-off documentation sprint instead of that steady pace (Skipping Sprint-Aligned Investment), and investing in context while manual review stays the only check (Context Investment Without Automated Verification).
At Stage 3 agents are part of the daily work: a person delegates several tasks in parallel and integrates the results (Agentic Coding, Parallel Delegation to Agents), sometimes to scoped Subagents. Deterministic checks sit in the agent's path (Sensors, Computational Sensors): tests that fail the build when a module boundary is crossed (Structural Tests for Module Boundaries), tests and linters that run whenever an agent finishes a task (Agent Lifecycle Hooks), AI review before a person looks (AI Code Review as First Pass), a real browser the agent can inspect (Browser Automation for Agent Verification), and fast checks early with slower ones later (Keep Quality Left); Böckeler calls the internal-quality share of these the Maintainability Harness. A person still reviews the results. One worked example is an end-to-end test harness: a one-page domain aggregate and short scenarios are the spec (Domain Aggregates as Spec Origin, SCN - Scenario Format), four narrow agents plan, implement, review and run the tests with one human gate after planning (Specialized Agent Pipeline with Human Gate), the loop of spec, generate, run and sharpen makes the spec work compound (Artifact Loop), and the tests run against the production image (Production-Shaped Test Image). Its git log and pipeline give three observables: Commits per Test Step, Flat CI Time While Coverage Grows and Spec-First Commits. The traps are reviewing every line until review is the bottleneck (Line-by-Line Review Bottleneck), generating faster than the structure can hold (Fast Generation Without Structural Enforcement), a harness of guides with no sensors (Guides Without Sensors) and a prompt that stays the only definition of the workflow (Prompt as the Permanent Workflow). A further question is Where Verification Criteria Live.
At Stage 4 delivery is agent-first, and the change is one of interface, not of model: a person triggers a workflow versioned in the repository (Versioned Workflow Definitions), the Work Harness drives the agent through guides and sensors, and what comes back has already passed lint, tests and review (Which Harness Your Hands Touch). People review the specification and the plan at the gate before execution, and one person can take a whole feature from research to production. Changes arriving at that pace need more advanced continuous deployment: each one is activated gradually, through a canary release or behind a feature flag. Agents run all the time while people set priorities (Always-Running Agents), each in a disposable environment that runs the whole stack (Ephemeral Full-Stack Agent Environments), with the state of unattended work kept in files and git (Durable Agent State in Files and Git). Review itself becomes a sensor: agents review agents against criteria and quality scores people define (Agent-to-Agent Review with Quality Scoring, Inferential Sensors), linters tell the agent how to fix what they flag (Custom Linters with Remediation), mutation testing checks that the tests catch injected faults (Mutation Testing), approval files let a person check agent-written cases at a glance (Approved Fixtures), and stubs are curated as contract artifacts (Stub Mappings as Contract Artifacts). Whether the application behaves as needed is still the open problem (Behaviour Harness). The traps are merging on a green suite written by the agent that wrote the code (Merging on Green Tests the Same Agent Wrote), inherited tests that teach the agent the wrong way to assert (Low-Value Tests Teach the Wrong Style), stubs treated as throwaway fixtures (Stubs Treated as Fixtures) and, on a brownfield system, skipping the check that the codebase can hold a harness at all (Skipping Harness-Readiness on Brownfield). The readiness questions are Agents Can Verify Their Own Changes and Codebase Harnessability. Each step of autonomy here is earned by that verification (Maturity Is Trust Earned).
It covers two sides of the same change: how people and agents share the daily work of building it, and how the team judges that what they built is correct. Where Plan decides what to build and cuts it into items ready for implementation, this aspect turns a ready item into a change; operating that change once it runs belongs to Run & Improve. The checks a change passes on its way to production, the test infrastructure they run on and the way the building work is organised belong here; where a person engages relative to the agent's loop and what holds boundaries and design taste belong to Control; a check aimed at a named risk, such as security, to Risk Mitigation; how fast a check's result reaches the agent and turns into a new guide or sensor to Feedback. Building can send work back to Plan; when it does so often, the plan rather than the build is the place to look.
Which stage sounds like your team here? Which sentence would you challenge?
-
Run & Improve, an aspect of the SDLC - Software Development Life Cycle cluster, asks how a team operates its service in production, learns from how the service really behaves and feeds that learning into the next planning cycle.
Operations move along two lines at once, the runbooks and the handling of alerts, while the person's part shrinks from working every incident to owning only the ones that matter most. The question that tests it is Initial Incident Context from an Agent: when an incident fires at night, is context already waiting for the responder, or does the responder start from an empty terminal? At Stage 1 runbooks live in people's heads or are kept by hand, and engineers write their own queries, triage every alert and mitigate every incident. At Stage 2 the same operations team works the same way, with runbooks as markdown in the repository; an assistant drafts and simplifies the observability queries a senior engineer used to write, so reading them becomes a skill the whole team shares (AI-Drafted Observability Queries). People still mitigate.
At Stage 3 runbooks are structured so a model can read and follow them (Structured Runbooks for Agents), and an alert wakes an agent that gathers its context and surfaces it within minutes (Agent Alerts); people decide and mitigate. The trap at this stage is a runbook, metric or decision that people can reach but agents cannot (Information Reachable by Humans but Not Agents), and the question is whether everything people work from is Information Equally Reachable by Agents.
At Stage 4 runbooks become playbooks an agent can execute (Agent-Executable Playbooks), and agents triage and close low-severity alerts end to end while people handle the critical incidents (Severity-Based Auto-Triage). The step from Stage 3 is not a smarter agent: the runbooks and observability the team builds are what make it safe to trust agents with that triage (Maturity Is Trust Earned). The person on call owns the incident, whichever agent's change caused it, and the person who introduced the change still answers for it: the team checks who did and can hand them the fix (Accountability Stays With the Human). The improve half gains agents of its own here: Böckeler describes agents that watch runtime signals such as falling service-level objectives, or sample response quality and flag anomalies in logs, and propose improvements (Runtime Feedback Sensors). They watch, without being asked, the signals a person first learned to query at Stage 2, and what they find goes back to Plan for the next cycle.
It covers runbooks, alerts, triage and mitigation, and the production signals that show how the service is doing. Where Build & Deliver turns a ready item into a change and checks it on its way to production, this aspect takes over once the change runs, and what production teaches goes back to Plan as input for what to build next. The runbooks an operation works from belong here, while where the team's documentation is stored and how agents reach it belongs to Knowledge; signals that propose improvements to the service belong here, while how fast a result reaches the agent and changes the harness itself belongs to Feedback; where a person engages relative to the agent's loop, and who answers for an incident, belong to Control.
Which stage sounds like your team here? Which sentence would you challenge?
Information Flow
The Information Flow cluster of the Harness Model asks where knowledge lives, how fast feedback moves and how quickly the team absorbs change.
-
Knowledge, an aspect of the Information Flow cluster, asks where the team's knowledge is stored, how it is structured, how people and agents reach it, and how the team tends it as it grows and decays.
Knowledge moves from people's heads to a repository whose structure is itself the context, the agent's part moves from receiving pasted snippets to finding what it needs on its own, and upkeep moves from occasional clean-ups by people to checks that catch decay as it happens. Two questions test the move: Where Team Knowledge Lives and What the Agent Reads Before a Task. At Stage 1 knowledge is tribal or sits in wikis, written for people only, and whatever reaches an assistant is pasted in private. At Stage 2 documentation is at README level, and a person pastes snippets into an assistant and carries the rest in their head. Structuring that input so the first answer is useful is Context Engineering, and prompts that work are kept in a Shared Prompt Library, the seed of later instruction files.
At Stage 3 a person keeps a file the agent reads before every task (Agent Instruction Files) and loads further context by hand, and people structure the documentation in the repository: written in Markdown (Markdown as Documentation Language), with map files that show where the rest is (Documentation Map Files), diagrams kept as code (Diagrams as Code) and decisions recorded with their reasons (ADR - Architecture Decision Records). These are the text-based Guides of the harness, which Böckeler calls Inferential Guides; they include project-specific Agent Skills and a few deliberate bridges to live systems (MCP Servers as Context Bridges). Records from outside the code reach the repository too: meeting transcripts converted into documents (Meeting Transcripts to Repository Docs) and annotated by a person who knows what the text leaves out (Annotated Records for Agents), and research filed by a repeatable pipeline (AI Research Pipeline). Domain knowledge is written down where agents read it: a ubiquitous language, one-page domain aggregates and the scenarios built on them (Domain Aggregates as Spec Origin, SCN - Scenario Format); when the agent gets something wrong, the team corrects the document it read rather than the output (Fix the Spec). End-to-end test work shows the payoff in Commits per Test Step, and also the cost: documentation that was good enough for people becomes load-bearing, because an agent does not ask about a contradiction (Documentation Accuracy Becomes Load-Bearing), and what nobody wrote down becomes a limit on correctness (Tribal Knowledge Becomes a Correctness Ceiling). The other traps are knowledge people can reach but agents cannot (Information Reachable by Humans but Not Agents), records whose every sentence the agent reads as a requirement (Every Statement Read as a Requirement), and a domain vocabulary nobody wrote down (Undocumented Domain Vocabulary). The questions here are Information Equally Reachable by Agents and Where Verification Criteria Live, and, on a shared platform, Where the Domain Vocabulary Lives and Onboarding Path to the Contract Surface.
At Stage 4 the repository is the system of record and its structure is the context (Repository as System of Record): an agent starts from a map and pulls detailed documents only when a task needs them (Progressive Disclosure), so the information architecture is what the agent navigates, and linters keep the documentation true (Documentation Linters). Requirements, architecture and designs sit in that one place, in a vocabulary product, design, engineering and the agents share, so every role works from the same words. Code that steers the agent joins the text (Computational Guides), such as language servers that give it precise knowledge of the code before it acts (Language Server Integration). At platform scale the domain context that crosses team boundaries becomes a shared artifact kept with the same discipline as code: a Machine-Readable Platform Model of bounded contexts and their vocabulary, the teams that own each component, diagrams and decision records, kept in a shared Knowledge Base and filled in and challenged by an Ingestion Harness, which a platform change, newly shipped work or a diagram past its freshness timer sends back for another session. The new trap at this step is decay agents cannot see: a specification they trust while the code drifts away from it (API Contract Drift); the reachability and vocabulary traps of Stage 3 persist.
Structure is the information architecture of a knowledge base that people and agents share: how it is divided into documents, how they are named and linked, and where a reader starts. Upkeep is never a one-time effort; a burst of writing goes stale quickly, as a one-off documentation sprint shows: it can be out of date by its third week (Skipping Sprint-Aligned Investment). The team tends its knowledge like a garden: it adds what is new, cuts what no longer holds and replaces old parts with better ones. Knowledge left untended decays, and the decay costs more once agents read it, since they take what is written at face value.
Whatever the people work from should be as reachable by the agents as by the people (Agents Are First-Class Team Members), because knowledge an agent cannot reach does not exist for it. Documentation and records belong here, and so do the shared domain model, its vocabulary and the path a new team takes into it. How fast a result comes back to the agent and turns into a new guide or sensor belongs to Feedback; the capability to write such knowledge well to Skills; how fast the team absorbs change, such as adopting and retiring tools, to Learning; the plan itself to Plan, the runbooks an operation works from to Run & Improve, and the evidence behind a choice to Decision Making.
Which stage sounds like your team here? Which sentence would you challenge?
-
Feedback, an aspect of the Information Flow cluster, asks how fast the result of an agent's work comes back and how it changes the work: whether a mistake is noticed by a person and discussed at the next retrospective, or caught by a check that hands the result straight back to the agent and, when it recurs, changes the harness itself.
Feedback moves from mistakes a person notices and fixes one session at a time to a loop in which the harness corrects the agent and learns from what recurs (Steering Loop). Guides steer the agent before it acts and Sensors observe what it produced; as Böckeler puts it, a harness with only sensors keeps repeating its mistakes, and one with only guides never learns whether its rules worked. At Stage 1 there is no harness to turn a mistake into: whatever a person learns from one stays with them. At Stage 2 the harness is held in people's heads: the team holds its usual retrospective once per iteration, but nothing afterwards makes sure its actions are carried out. The question across the stages is Recurring Mistake Converted into a Guide or Sensor.
At Stage 3 the sensors are mostly people: agent mistakes are noticed in review, and the lessons are captured in retrospectives and turned by hand into changes to instruction files and conventions (Retrospectives Capturing Agent Lessons). The loop exists, but it runs at the pace of the meetings. In an end-to-end test harness the same loop runs on specifications: the runner attributes each outcome to the spec, the application code, the test code or the infrastructure (Outcome Attribution by the Runner), the team corrects the spec rather than the output (Fix the Spec), and each generation starts from a better spec (Artifact Loop); a person still decides what to sharpen. The trap at this stage is a session a person keeps steering back on course instead of carrying the lesson into the harness (Iterating a Lost Session).
At Stage 4 sensors return their results straight to the agent, so it corrects itself before a person looks. Deterministic checks run on every change (Computational Sensors), often when the agent finishes a task (Agent Lifecycle Hooks), with messages that tell the agent how to fix what they found (Custom Linters with Remediation); model-run reviews sit behind them (Inferential Sensors), checks are ordered by cost so the cheapest results come first (Keep Quality Left), and drift checks run against the codebase outside any change (Continuous Drift Sensors). Only issues that keep recurring reach a person, who answers the second occurrence with a new guide or sensor. Quality grades, benchmark results and regression signals live in the repository, so one agent iteration can be compared with the last (Quality Grades in the Repository). This is where agents earn the trust they are given (Maturity Is Trust Earned). The traps are a harness of guides with no sensors, the loop stopped before it produced any (Guides Without Sensors), and supervising one task instead of improving the harness (Iterating a Lost Session). A sensor set that never fires is a warning rather than a win (Guardrails Never Fire).
A sensor counts in two aspects: as a check a change must pass on its way to production it belongs to Build & Deliver, and as a result that returns to the agent, sooner or later, it belongs here. Signals from the running service that propose improvements to it belong to Run & Improve; the documents a corrected guide lives in, and their upkeep, to Knowledge; where a person engages relative to the agent's loop to Control; the skill of running the loop to Skills; how fast the team as a whole absorbs change to Learning.
Which stage sounds like your team here? Which sentence would you challenge?
-
Learning, an aspect of the Information Flow cluster, asks about the pace of change and how fast the team absorbs it: how people build judgment about AI, how the toolset keeps changing, and who passes judgment on when the harness moves work around.
Learning moves from what each person finds out alone, through experiments the team runs in the open and shares, and a team habit of trying and retiring tools, to a transfer of judgment that someone owns. At Stage 1 what one person learns about AI stays with them. At Stage 2 people learn by running small, bounded experiments on code or problems they already know, because ground truth is what lets them judge where the assistant gets it right (Start on Familiar Territory); two weeks of hands-on work teach more than a year of reading. The first experiments come one per role: an engineer has the assistant explain a module they know (Explain a Known Module), a tech lead has it break a feature into backlog items (Decompose a Feature into Backlog Items), and an architect has it list design options (Brainstorm Architectural Options). Prompts that work are kept in a Shared Prompt Library, one of the fastest ways to spread the practice across a team. The trap is to count the tools adopted as progress (Counting Tools as Maturity).
At Stage 3 the team absorbs change through a habit of experiments rather than a search for a final setup: tools are adopted, tested and retired on a roughly quarterly rhythm, and what leads one quarter may be the baseline, or gone, the next (Quarterly Toolset Review). A toolset review shows it: a coding agent expected to lead fell short within a quarter, and once skills became a standard the team's use of MCP servers narrowed to reaching remote services and live data. Research runs as a repeatable pipeline whose entries land in the team's knowledge base and become training material for the team (AI Research Pipeline), so learning compounds instead of evaporating. The harness itself is sharpened a little every sprint, because the models and tools it is built from keep changing (Sprint-Aligned Harness Investment). Counting tools stays a trap here too: an inventory describes a moment, not a capability.
At Stage 4 passing judgment on becomes someone's job. Once agents take over execution, mentoring and one-to-ones are the first things to drop off the calendar, as Jamie Hurst's field report observed, because they are the load AI does not absorb (Mentoring as the First Thing to Go). A small enabling team introduces the harness to a stream team, teaches it Calibrated Trust and leaves once the team can carry the verification load alone (Enabling Team Teaches Calibrated Trust); writing an exit date, exit criteria and a named owner into the kickoff document is the cheapest defence against the transfer quietly lapsing (Time-Boxed Enablement with Named Owner). The time this takes is budgeted as part of the team's load (Cognitive Load and Time Allocation). Growing the next tech leads and architects is part of that job: juniors join as an investment in future leads rather than as delivery capacity, learn the fundamentals faster with AI, and gain the judgment that comes only with experience by working beside experts. At Stage 4 learning also crosses team boundaries: teams unify the patterns that have proved themselves, a company-level AI radar, after Thoughtworks' Technology Radar, tracks which AI tools to adopt, trial or retire and sets the standard, and an AI enablement team helps every team move up the stages.
Which capability matters at a stage belongs to Skills, while how the team acquires it and hands it on belongs here; the time that learning and mentoring take, as a line of the team's load, belongs to Cognitive Load and Time Allocation; the knowledge base that research and lessons are filed in, and its upkeep, to Knowledge; how fast a result reaches the agent and changes the harness to Feedback.
Which stage sounds like your team here? Which sentence would you challenge?
Five principles
Open a principle for the rest of the excerpt.
-
At every stage of the Harness Model, a person answers for the outcome.
Maturity does not move responsibility to the agents. What grows is how much execution people can delegate, and only as far as the harness around the agents catches their mistakes (Maturity Is Trust Earned). When an agent ships a defect, someone on the team still answers for it, and every decision about where to invest next should start from there.
-
Being first-class is about place and access, not responsibility: agents work beside the people, but a person still answers for the result (Accountability Stays With the Human).
A team in the Harness Model is one composition of people and agents, and the model rejects any framing that treats the agents as lesser participants. Where accountability holds at every stage, this principle shapes the matrix itself, and it shows in two places.
The first is who makes up the team. Role in a Team describes the people and the agents together: the shape of the human team and, beside it, what the agents can do, from suggestions only, through file and terminal access, to running the full stack in environments of their own.
The second is equal access. Whatever the team works from, a backlog item, an architecture decision, a runbook, a metric, should be as reachable by the agents as by the people, and each piece that is not leaves a hole in the harness. The anti-pattern is "it sits in my slide deck" (Information Reachable by Humans but Not Agents): knowledge kept only in a chat thread, a private note or someone's head does not exist for an agent. The assessment question Information Equally Reachable by Agents tests the principle directly. In Knowledge it takes the form of the Repository as System of Record; in Decision Making it is Equal Access to Decision Signals. Reachable is not the same as understood: a record an agent can open may still have lost the context the people in the room had (Every Statement Read as a Requirement). Equal does not mean unlimited: from Stage 4 an agent reaches what it needs under its own scoped, logged access, not through a person's credentials (Scoped Auditable Agent Access).
-
As agents take over execution, what people do on a team changes, but people stay in it.
It shows most clearly in Role in a Team: the human role moves from executing the work to leading delivery.
-
When agents generate the work, the rigour of engineering does not go away; it moves into the Harness, the system around the agents that guides them before they act and checks what they produce.
Because the discipline now lives in that system, the model assesses the system rather than the list of tools (Counting Tools as Maturity).
-
Moving up a stage does not mean taking control away from people; it means agents have earned more autonomy because the structure around them now catches what a person used to catch.
What is earned is the delegation of execution, never responsibility (Accountability Stays With the Human), and the structure that earns it is where the rigour of engineering has moved (Discipline Relocates, It Does Not Disappear).
Use this with your team
Place: where the team stands.
Each person may place one or two aspects on their own, but the placements only bring disagreements into the room, and those disagreements are the signal: the team needs the conversation, not consensus.
Navigate: where to go next.
The outcome is a plan the team owns, not a prescribed route: the team chooses which aspect to move, how far and how fast, and one stage in one aspect is a valid step.
Note for your team
The Harness Model: can we look at it together?
Choose one aspect and compare where each of you would place the team, using a recent piece of work.
Which sentence would you challenge, and what would you want to change in how the team works?
Each person may place one or two aspects on their own, but the placements only bring disagreements into the room, and those disagreements are the signal: the team needs the conversation, not consensus.
https://handsonarchitects.com/harness-model
Note and link copied. Couldn’t copy. Select the note and link and copy them.
Before you send it, add a line of your own: what made you think of the team, and who you want to look at it with.
Note for: Role in a Team
Role in a Team, from the Harness Model: can we look at it together, with one recent piece of work in mind?
Which stage sounds like your team here? Which sentence would you challenge?
Each person may place one or two aspects on their own, but the placements only bring disagreements into the room, and those disagreements are the signal: the team needs the conversation, not consensus.
https://handsonarchitects.com/harness-model#aspect-role-in-a-team
Note and link copied. Couldn’t copy. Select the note and link and copy them.
Before you send it, add a line of your own: what made you think of the team, and who you want to look at it with.
Note for: Cognitive Load and Time Allocation
Cognitive Load and Time Allocation, from the Harness Model: can we look at it together, with one recent piece of work in mind?
Which stage sounds like your team here? Which sentence would you challenge?
Each person may place one or two aspects on their own, but the placements only bring disagreements into the room, and those disagreements are the signal: the team needs the conversation, not consensus.
https://handsonarchitects.com/harness-model#aspect-cognitive-load-and-time-allocation
Note and link copied. Couldn’t copy. Select the note and link and copy them.
Before you send it, add a line of your own: what made you think of the team, and who you want to look at it with.
Note for: Skills
Skills, from the Harness Model: can we look at it together, with one recent piece of work in mind?
Which stage sounds like your team here? Which sentence would you challenge?
Each person may place one or two aspects on their own, but the placements only bring disagreements into the room, and those disagreements are the signal: the team needs the conversation, not consensus.
https://handsonarchitects.com/harness-model#aspect-skills
Note and link copied. Couldn’t copy. Select the note and link and copy them.
Before you send it, add a line of your own: what made you think of the team, and who you want to look at it with.
Note for: Control
Control, from the Harness Model: can we look at it together, with one recent piece of work in mind?
Which stage sounds like your team here? Which sentence would you challenge?
Each person may place one or two aspects on their own, but the placements only bring disagreements into the room, and those disagreements are the signal: the team needs the conversation, not consensus.
https://handsonarchitects.com/harness-model#aspect-control
Note and link copied. Couldn’t copy. Select the note and link and copy them.
Before you send it, add a line of your own: what made you think of the team, and who you want to look at it with.
Note for: Decision Making
Decision Making, from the Harness Model: can we look at it together, with one recent piece of work in mind?
Which stage sounds like your team here? Which sentence would you challenge?
Each person may place one or two aspects on their own, but the placements only bring disagreements into the room, and those disagreements are the signal: the team needs the conversation, not consensus.
https://handsonarchitects.com/harness-model#aspect-decision-making
Note and link copied. Couldn’t copy. Select the note and link and copy them.
Before you send it, add a line of your own: what made you think of the team, and who you want to look at it with.
Note for: Risk Mitigation
Risk Mitigation, from the Harness Model: can we look at it together, with one recent piece of work in mind?
Which stage sounds like your team here? Which sentence would you challenge?
Each person may place one or two aspects on their own, but the placements only bring disagreements into the room, and those disagreements are the signal: the team needs the conversation, not consensus.
https://handsonarchitects.com/harness-model#aspect-risk-mitigation
Note and link copied. Couldn’t copy. Select the note and link and copy them.
Before you send it, add a line of your own: what made you think of the team, and who you want to look at it with.
Note for: Plan
Plan, from the Harness Model: can we look at it together, with one recent piece of work in mind?
Which stage sounds like your team here? Which sentence would you challenge?
Each person may place one or two aspects on their own, but the placements only bring disagreements into the room, and those disagreements are the signal: the team needs the conversation, not consensus.
https://handsonarchitects.com/harness-model#aspect-plan
Note and link copied. Couldn’t copy. Select the note and link and copy them.
Before you send it, add a line of your own: what made you think of the team, and who you want to look at it with.
Note for: Build & Deliver
Build & Deliver, from the Harness Model: can we look at it together, with one recent piece of work in mind?
Which stage sounds like your team here? Which sentence would you challenge?
Each person may place one or two aspects on their own, but the placements only bring disagreements into the room, and those disagreements are the signal: the team needs the conversation, not consensus.
https://handsonarchitects.com/harness-model#aspect-build-deliver
Note and link copied. Couldn’t copy. Select the note and link and copy them.
Before you send it, add a line of your own: what made you think of the team, and who you want to look at it with.
Note for: Run & Improve
Run & Improve, from the Harness Model: can we look at it together, with one recent piece of work in mind?
Which stage sounds like your team here? Which sentence would you challenge?
Each person may place one or two aspects on their own, but the placements only bring disagreements into the room, and those disagreements are the signal: the team needs the conversation, not consensus.
https://handsonarchitects.com/harness-model#aspect-run-improve
Note and link copied. Couldn’t copy. Select the note and link and copy them.
Before you send it, add a line of your own: what made you think of the team, and who you want to look at it with.
Note for: Knowledge
Knowledge, from the Harness Model: can we look at it together, with one recent piece of work in mind?
Which stage sounds like your team here? Which sentence would you challenge?
Each person may place one or two aspects on their own, but the placements only bring disagreements into the room, and those disagreements are the signal: the team needs the conversation, not consensus.
https://handsonarchitects.com/harness-model#aspect-knowledge
Note and link copied. Couldn’t copy. Select the note and link and copy them.
Before you send it, add a line of your own: what made you think of the team, and who you want to look at it with.
Note for: Feedback
Feedback, from the Harness Model: can we look at it together, with one recent piece of work in mind?
Which stage sounds like your team here? Which sentence would you challenge?
Each person may place one or two aspects on their own, but the placements only bring disagreements into the room, and those disagreements are the signal: the team needs the conversation, not consensus.
https://handsonarchitects.com/harness-model#aspect-feedback
Note and link copied. Couldn’t copy. Select the note and link and copy them.
Before you send it, add a line of your own: what made you think of the team, and who you want to look at it with.
Note for: Learning
Learning, from the Harness Model: can we look at it together, with one recent piece of work in mind?
Which stage sounds like your team here? Which sentence would you challenge?
Each person may place one or two aspects on their own, but the placements only bring disagreements into the room, and those disagreements are the signal: the team needs the conversation, not consensus.
https://handsonarchitects.com/harness-model#aspect-learning
Note and link copied. Couldn’t copy. Select the note and link and copy them.
Before you send it, add a line of your own: what made you think of the team, and who you want to look at it with.
Keep the example, the disagreement and the next step in your own notes. There is nothing to submit here.
Tell us where the model is wrong
Tell us where you would place your team in one aspect, and which stage or sentence you think is wrong. One concrete reaction is enough; you do not need to read everything or try this with your team first.
Disagreement is useful. If the page gave you nothing you could use, tell us where it fell short.
- Where did you stop or lose the thread? Point to the sentence or section.
- If you used it with your team, what did people disagree about, and did that change what you want to try next?
Write to us through our contact form and mention the Harness Model.
A few lines are enough. Please leave out other people’s names and confidential details; we do not need company information.