A note before I start: this one runs longer than my usual article. There’s a single concept underneath the whole series that I’ve been describing without naming, and it needs the room to be laid out properly.
In the first article I wrote about encoding what good looks like into something that can watch continuously. In Five is the Floor I wrote about a flow enabler whose value lives in the systems they build rather than the hours they’re present.
When I started my journey into AI-driven development, I knew instinctively that there was a place for ALL the different functions of an agile team in the agentic stack, and I just assumed it would be a group of agents that fills those functions. As I become more familiar with agentic systems, the more I realize that my first assumption was incorrect. Those functions don’t live in a roster of agents. They live in the harness, as an extension of it.
My argument in this piece is that the harness isn’t strictly an engineering artifact, and that treating it as one is the mistake most organizations are about to make.
What actually exists today
The engineering harness is real and it exists today. If you’re close to teams doing serious agentic development, you already know this. It’s the structure that wraps around the models and makes them useful to a real codebase: the rules, the memory, the accumulated context about how this particular system is built, the standards and conventions and architectural knowledge that the agentic stack reads from so that what it generates fits the code you actually have instead of fighting it. It’s the difference between vibe coding and optimizing inputs to produce meaningful code at scale.
Context files like AGENTS.md, CLAUDE.md, and the various tool-specific rule files have converged into a genuine industry standard over the last year. They’re versioned, reviewed, quality-assured, and maintained like any other software artifact. There is a large and fast-moving body of work here, with people shipping skills, frameworks, and tooling at a rapid rate. Real momentum, real practitioners, real convergence happening in public.
The harness is model-agnostic. It isn’t built into any single model. The harness is scaffolding that wraps around the model and encompasses it. The model sits inside; the harness holds it. So when the model changes, weights shift, behavior evolves. When a new one arrives, you may modify what’s inside without tearing down the structure around it. The harness will probably be a durable, persistent element of agentic coding, while the models it wraps keep evolving and changing.
If you’ve read my white paper on [LINK: The Living Product], I referred to the SDLC as “scaffolding,” the human scaffolding built around our cognitive limits, and argued that much of it comes down once those limits dissolve. That scaffolding falls away. The harness is a different kind of scaffolding: the structure around the agentic model, and it’s the kind that holds. Same word, opposite fates, and worth noting.
That’s the ground truth. Engineers are building this, in the codebase, right now.
It’s already more than engineering. It’s just not labeled that way.
Here’s what took me a while to see. The harness already contains far more than engineering knowledge. Engineers have been pulling the other functions in to prop up what they previously received externally.
Look at what’s actually in a mature engineering harness today. Product ideation is happening in it, because engineers need product direction to generate anything useful and they’re encoding what they can get. Design constraints and uniformity rules are in it, because engineers need consistency and they’re building it themselves. And the coaching layer is in it too, though nobody names it as coaching. There are already agents watching for bottlenecks and trying to resolve them. That is precisely what coaches have always done: watch the flow, spot where it’s clogging, intervene. It’s in the harness right now, woven into engineering agents.
The harness is where engineers, out of necessity, grabbed the highest-impact pieces of every function and encoded those, and excluded anything they deemed less valuable to engineering. They took the definition of done because it obviously moved delivery. They took bottleneck detection because it obviously mattered. They took the product direction they couldn’t proceed without. What they left behind is a lot of the functional pieces that require human judgment, because that judgment is the tacit knowledge the models can’t reliably capture or act on, the part of each function that was never written down because it lived in a practitioner’s head.
That reframes what I’m extrapolating, and I want to be precise about the line, because the honest version of this depends on it.
What’s fact: the functions are already in the harness, harvested by engineering.
What I’m extrapolating: that the experts whose work was harvested should have oversight and input into their own layers, because engineering took the artifact without the judgment that makes the artifact work. If we want to optimize the product we’re creating, the functions that own the respective domains should be the ones authoring and evolving those pieces.
Translation and transformation
There are two different things happening when a function’s knowledge enters the harness, and blurring them is what makes this hard to talk about.
Some of it translates. A definition of done in a wiki and a definition of done encoded as a gate the system checks against are recognizably the same object doing the same job, just alive now instead of inert. The lineage is clear. You can look at the harness version and see the artifact you already knew.
Some of it transforms into something you wouldn’t quite recognize. Take the definition of ready. On paper it looks like a checklist: is the story sized, are the dependencies known, is the acceptance criteria written. But that was never what it was actually for. Its real job was to force a conversation at refinement, to surface the hidden assumption and get product thinking and technical thinking to collide before anyone wrote code. When that moves into the harness, it doesn’t stay a checklist-checker. It becomes a gate that has to catch the thing the checklist was always a proxy for: the un-surfaced disagreement, the missing conversation, the story that looks complete and isn’t. Same instinct underneath, but the artifact has become a genuinely different creature than the list it started as.
This distinction matters most for the transformed pieces, because that’s where the originating function’s judgment does the heavy lifting. Translating a definition of done is straightforward, the object survives the move largely intact. But rebuilding a definition of ready as a refinement gate means knowing what it was actually protecting: which missing conversation is the expensive one, what un-surfaced disagreement looks like when a story still reads as complete, why a team quietly stops raising the hard technical questions at refinement. That’s the coaching function’s home knowledge, and it isn’t visible from the checklist. An engineer can build the gate brilliantly, and will build it better with that knowledge in hand than without it. That’s the sharpest case for why authoring the harness is a shared act: some of these artifacts aren’t being copied over, they’re being reimagined, and reimagining them well takes both the person who knows how to build it and the person who knows what it was for.
The part engineering can’t harvest at all
There’s a layer past this that doesn’t translate or transform, because it can’t be encoded at all, and naming it is what keeps the whole argument honest.
Break any function down into its atomic parts and you find two kinds. The parts that can be encoded into the harness, and the part that can’t. The product person’s personas and success definitions can go in. Their market knowledge, their in-depth read of a customer, the judgment that knows when the persona is wrong, that can’t. The coach’s readiness gates and bottleneck scenarios can be encoded. The read on where the team actually is this week, who’s stretched thin, who’s quietly checked out, what the last reorg did to trust, that can’t. The harness holding the first kind doesn’t threaten the second. It never reaches it.
And there’s a pattern to which parts survive the reduction. The encoding eats upward from the bottom, taking the concrete, the mechanical, the rule-shaped pieces first. What it can’t reach is the higher-abstraction judgment, the integrative, big-picture work, and that was always the more valuable part. This is true for every function, engineering included. Engineers are no longer writing the code; they’re holding the larger picture of how the whole thing fits together, the judgment about the system that the harness runs beneath but can’t itself supply. The same lift happens everywhere the harness reaches: it clears the concrete floor of a function and pushes the human up to the abstract ceiling, which is where the seniority and the value always lived. The harness doesn’t hollow a function out. It raises it.
That’s also the mechanism that makes the oversight argument airtight. Every function keeps an irreducible core, and that core is the high-abstraction judgment that knows what the encodable pieces were for. So the expert isn’t a nice-to-have for polishing their layer. They’re the only one who can author the encodable part with the judgment behind it intact and supply the part no encoding will ever capture.
The practitioner knowledge that refines what’s already there
So what does a domain expert actually add, concretely, to a harness that engineering already populated?
Take the bottleneck-detecting agents that already exist. The stack notices when throughput slows and immediately responds, usually by throwing more resources at the blockage. And it works, in the sense that the thing looks unblocked. But it’s inefficient, and it’s treating the symptom, not the cause. The stack clears the fever without ever touching the infection, and clearing the symptom can quietly entrench the cause.
What it lacks is the practitioner knowledge a coach carries: if throughput slows, here are the plausible causes, here are the distinguishing signals that tell you which one is actually in play, and here is the judgment that the right intervention is often not “more” at all but addressing why the flow clogged in the first place. That discrimination is the essence of the role. It’s not a bag of scenarios, it’s the accumulated judgment of the function, the tacit knowledge that was never written down because it lived in the practitioner’s head and never had anywhere else to go.
That’s the thing the harness can finally hold, and it’s what makes the difference between a stack that reflexively over-resources a symptom and one that knows what’s actually wrong. The coach refining that detector isn’t decorating engineering’s work. They’re stopping the stack from confidently doing the wrong thing. The same is true for the product expert refining the signals that read customer behavior, and the designer refining what the harness treats as a design violation versus an acceptable variation.
There’s an unexpected piece of evidence for this. When teams let the models auto-generate their context files, the files made agent performance worse. Human-curated files, written by people who actually knew the domain, were the ones that helped. The knowledge has to come from someone who holds it. You can’t synthesize your way to it. That’s the whole argument in a single empirical finding: the harness is only as good as the practitioner knowledge encoded into it, and that knowledge has an author who has to be the real expert.
It’s already starting
I’m seeing the early edge of this, and I want to be careful about what I can and can’t claim.
Across the industry, product knowledge is starting to move into the harness as memory and context. This is a reasonable read of where things are heading, and it’s grounded in something we’ve done for decades: we taught engineers user-story mapping, and user-story mapping has always depended on user personas that come from product. Engineers utilize those personas; product authors them. Extending that so the personas live in the harness rather than in a deck is not a stretch. It should be best practice, and given how much of the agentic “80% problem” comes from agents missing exactly this kind of upstream context, I’d bet it’s already becoming one. The mechanism is proven. The extension is the obvious next move.
The one I’ll name specifically, because it’s observable and it’s hers to show, is a UX designer I’ve watched start encoding her design considerations into the harness. Nobody told her to. She saw where this was going and decided, on her own, to demonstrate that the function has a place in the stack. I want to be honest about the limits of that observation: it’s one person, and it’s the kind of early individual signal that proves a gradient is real without proving it’s widespread. But that’s exactly why it matters. It wasn’t rolled out. It wasn’t a framework being executed. It was a practitioner reading the situation correctly, under real pressure, and moving before anyone asked her to. When the pull toward the harness is strong enough that people feel it and act on it unprompted, you’re looking at something structural, not a plan.
And notice why the non-engineering layers are still so thin. It’s the same reason the engineering layer is dense: attention follows the code. That asymmetry has a consequence, and it determines how much of this work is ever finished.
Why this work is never done, unevenly
The harness is never finished, but not uniformly, and the uneven part is the honest part.
The churn is a given. We’re in a new area with tools that are themselves still forming, and that means constant change while the field figures itself out. But it settles unevenly. Large parts of the engineering layer will stabilize, and stabilize relatively soon, precisely because so many people are working on it and converging. That’s what a large active body of work does: it hardens practice.
The other layers are different. The coaching, product, and design layers will keep evolving far longer, because almost nobody is working on them yet. There’s no convergence to settle into, and new ideas about what belongs in them will keep arriving because the field is only now starting to look. So the functions closest to human judgment are the ones whose harness contribution stays live the longest, which is the same reason the human floor never automates: human practice doesn’t hold still, and neither does the encoding of it.
That’s not job security through complexity. Large parts genuinely do settle. The parts that don’t are the parts where the field is still learning what good even looks like, and being early to those is the opportunity, not a moat.
Why the harness is the whole game
In [LINK: The Living Product] I argued that agentic AI doesn’t improve the software development lifecycle, it eliminates the justification for it, and what replaces it is a product that observes its own behavior, generates its own demand signals, and routes them back into the development motion without a human translation layer. A living product.
That observing and routing has to physically happen somewhere. It happens in the harness. The monitoring the living product depends on is harness monitoring. Which means the harness isn’t adjacent to the living product. It’s the substrate the living product runs on. The living product is what a mature, comprehensive harness produces.
And this is exactly why the harness has to become comprehensive, why it can’t stay an engineering-only harness. A product that observes its own behavior needs product signal, design signal, and outcome signal to observe, not just code signal. If the only layer built out is engineering, the monitoring is partial, and a partial monitor can’t sustain a living product. The comprehensive harness isn’t a nice-to-have on the way to the end state. It’s the precondition for the end state existing at all. Every function’s layer has to be there because the living product needs to watch across all of them.
That’s the connection the series has been missing. The white paper describes the destination. The harness is the machine the destination runs on. And the road from here to there is the road of the harness filling in, function by function, from the engineering layer that exists today toward the comprehensive one a living product requires.
Ensure oversight before you open the gates
I’ve made the harness sound like something you want everyone piling into. Here’s where I need to pump the brakes, and it’s important enough that I’d rather flag it and leave it open than pretend I’ve solved it.
The harness lives in the codebase and is operated through agentic code. That means contributing to it is not a neutral act. When a non-engineer encodes something into a system that generates and acts on code, a change that looks harmless at their altitude can propagate into real damage through the agentic stack, the same way a bad input propagates through an automated pipeline before anyone catches it. Only now the bad input is a change to the operating system itself, not a single story.
So “the experts should author their layers” cannot mean “everyone gets open write access to the harness.” Those are different things, and the gap between them is where a genuine governance problem lives. The designer encoding her considerations is real and good. Whether she should be able to commit directly into an agentic harness, unmediated, without anyone who understands the engineering layer in the loop, is a separate and unsolved question.
The gates have to do something I can name even if I can’t yet tell you how to build it: preserve a domain expert’s ability to contribute their knowledge while preventing them from breaking things they don’t understand. Make everyone an engineer first and you lose the point of a multi-function harness. Leave access open and anyone can damage everything. The answer lives somewhere in between, and I don’t think anyone has designed it well yet. I certainly haven’t.
This is a problem that intensifies with maturity, and most organizations aren’t mature enough for it to be acute yet. It’s the bridge out ahead, not the fire you’re standing in. I’ll come back to the governance of the shared harness in more depth when this series’ successor takes on the end state directly. For now it’s enough to say: build knowing the gates will be needed, so you’re not surprised when the road demands them.
There’s a person-shaped version of this problem too. Someone has to understand both a function and the engineering substrate well enough to steward how the two meet. That profile, coordination across functions plus enough technical literacy to keep contributions safe, is close to the flow enabler I keep pointing at. I’ll take that up properly in the next article. [LINK: The Coach Who Builds]
Where you actually are on this road
If all of that felt like it sprinted to a future you don’t recognize, good, because here’s the correction, and it’s the most important part.
Almost nobody is where the end of this argument is. The comprehensive, governed, living-product harness is the horizon, not the current weather. Where your organization actually sits on this road determines how much of this is even live for you, and for most teams the honest answer is: early. You have an engineering harness or the beginnings of one, already quietly holding harvested pieces of the other functions. The experts whose work got harvested haven’t stepped in to author their own layers yet. Your governance problem is still theoretical because participation is still small. That’s not behind. That’s where the road actually starts.
The maturity of your harness is, more or less, the maturity of your whole transition. Early on it’s an engineering artifact holding fragments of everything else, tended by a handful of people who understand it. Further along, each function’s experts step into their layers, the monitoring gets richer, and the questions get harder. At the mature end, the harness is comprehensive enough that the living product becomes possible and the governance of shared access becomes unavoidable. You don’t jump there. You build toward it one layer and one expert at a time, and the pace is set by how deliberately you cultivate the contributions, not by how fast the technology moves. That mature end is years out for most large organizations, and there is nothing wrong with operating in the transition. It’s where the real work is right now.
The harness is the thing everyone will need and no one can touch carelessly. Getting from the first half of that sentence to the second, safely, is most of the work ahead.
This is part of The Agentic Reality Series. The white paper, describes where agentic delivery is heading. This series fills the gap between that destination and where organizations are today. This piece names the system the rest of the series has been built on. Next: The Coach Who Builds, on what it means for a coach to author their layer of the harness, and to become one of the people who can steward it.
