Organizations That Rebuilt Around Agents

The New Role Every Agent Team Now Needs

Somewhere in the middle of this reorganization, a new role has emerged. Different companies give it different names. Harness PM, Agent Reliability PM, Applied AI Lead, Agent Product Lead. And the title is still mutating. The shape of the work, though, is already clear.

What the Harness PM Owns

The Harness PM owns the harness product. Not the model. Not the downstream feature that sits on top. They own the harness itself. Its failure modes, its cost envelope, its eval suite, its tool catalog, its escalation surface, its chWhen a production agent misbehaves at three in the morning, the Harness PM's phone lights up. The triage they run focuses not on whether the model was wrong, but which harness component failed to catch the issue.ponent of the harness failed to catch this.

Daily, the Harness PM manages the eval backlog like a traditional PM manages a feature backlog. New failure modes are filed as eval cases. Eval cases are prioritized against a coverage map. Coverage gaps feed directly into roadmap decisions about harness investment. A Harness PM who cannot tell you their current eval coverage percentage, the top three uncovered failure modes, and the last five eval cases they closed is not yet operating at the level the role demands.

They also negotiate the autonomy envelope. This includes every request from a downstream product team to expand what the agent is allowed to do. For example: new tools, wider scope, less supervision. Lands in their queue.

They do not say yes based on what the agent can do. They say yes based on whether the harness has the verification, the rollback, and the escalation coverage to contain the new surface. This is as much a political jobIt involves telling enthusiastic stakeholders "no" or "not yet," citing specific eval gaps as the reason.m>, armed with specific eval gaps as the reason.

How They Differ From Adjacent Roles

A traditional ML PM owns model selection, data pipelines, and offline metrics. They are measured by model performance against benchmarks, and their calendar is full of retraining decisions and data-sourcing conversations.

The Harness PM owns almost none of these things. They work with whatever model is behind the API, spending their time on infrastructure that decides when to trust, verify, escalate, or entirely reject the model's answer.

A model upgrade is a line item, not the center, of their roadmap.

A traditional platform PM owns shared infrastructure, such as auth, data warehouses, and deployment pipelines. Examples include authentication, data warehouses, and deployment pipelines. And their customers are internal engineering teams. Their success is measured in developer velocity and platform adoption.

The Harness PM shares the internal-customer focus but is measured on something entirely different. This would be the production reliability of the agent programs running on their harness. A platform PM can ship a beautiful new feature that nobody uses and still get promoted.

A Harness PM whose harness has a week of agent incidents does not care about the new tool registry's elegance.

The useful frame is that the Harness PM sits at the intersection of reliability engineering, product management, and applied AI. They are fluent enough in each to make calls the other three roles individually cannot.

They read eval reports like an SRE reads latency dashboards. They negotiate autonomy envelopes like a security PM negotiates access. They read prompt logs like a growth PM reads funnel analytics.

It is a composite role that most existing PM career ladders don't yet know how to evaluate.

The signal that matters is this. The discipline has evolved into an organizational function. When a role requires its own career ladder, performance rubric, and calendar of unique rituals (eval review, failure-mode triage, autonomy expansion review), it is no longer a side of somebody's desk.

It is a function. Companies that have named it are two hiring cycles ahead of those still assigning the work to whichever PM happens to be "interested in AI."

Human in the Loop Became the Wrong Mental Model

Every company that starts an agent program says some version of “we'll keep a human in the loop.” It is comforting. It sounds responsible. It implies that, no matter what the agent does, a person reviews it before anything consequential occurs.

The problem is that "human in the loop" stopped being operationally accurate about a year into the agent era. Nobody quite noticed because the phrase sounds so reassuring.

Human in the loop implies a synchronous checkpoint. The agent proposes, the human approves, the action happens. This works when the agent handles a few actions daily, and the human has the bandwidth to review each one.

It starts breaking at ten actions per day and fails at a hundred. At a thousand, "human in the loop" is a fiction that nobody has been honest enough to rename. The human skims dashboards, approves in batches, trusts the agent to surface what matters, and is structurally unable to serve as a real checkpoint.

Teams that thouInstead, they use "human in the harness."ey use instead is human in the harness. And the distinction isn't cosmetic.

What Changes Under Human-in-Harness

In the harness frame, the human is a system component, not the gate. The review queue is a component. The escalation path is a component. The feedback channel, where humans label agent outputs as correct or wrong (feeding into futureHumans are integrated throughout the harness, but they are not synchronous gates on the critical path. are not synchronous gates on the critical path.

Agents operate asynchronously. They handle the volume. They escalate when the harness routing logic dictates escalation. This is based on confidence thresholds, anomaly detection, policy violations, or explicit triggers the Harness PM has wired up.

When humans are engaged, it is because the harness decided they should be. Not because every action needs them. Human attention becomes a resource the harness allocates, just as it allocates tool calls, context tokens, or retries.

This idea is harder to sell to compliance, legal, and executive stakeholders than the old phrase was. "Human in the loop" provides the picture they wanted. A person makes the call "Human in the harness" is more accurate but requires them to absorb that the system is partially autonomous, that the human is one of several verification layers, and that the question is no longer, "Is there a human involved?" but "Is the harness routing the right cases to the human at the right time?"right cases to the human at the right time.

The Harness PM's job here is the translation work. The system isn't becoming less safe. It is becoming more precisely safe. Humans are engaged where they add decisive value, not where they add latency and fatigue.

But that sentence lands differently in a board review than it does in a product retro, and the PM who cannot land it in both rooms is the PM whose agent program gets frozen at the pilot stage.

The Operating Tell

You can tell which frame a company actually operates under by one question: what is your human review throughput? If the answer is a queue length, a latency, and a service-level target, they are running human-in-harness.

The human review is a service that the harness calls, and it hIf the answer is vague (someone looks at most things), they are still in human-in-loop. They will eventually either stop looking or stop scaling. eventually either stop looking or stop scaling.

There is no third option.

The harness view gives you the metric that lets you actually budget human attention. Ten thousand agent actions per day, a five percent escalation rate, three humans available to review, one-minute average review time. The arithmetic tells you the throughput, the backlog risk, and the budget for additional reviewers.

None of that arithmetic is available under "human in the loop" because the phrase describes a vibe, not a system.

June 2026: the ownership question grew an IAM shape

And then, in June 2026, the ownership question got an IAM-shaped answer. Anthropic shipped Claude Tag, with agents holding their own accounts, permissions, and audit trails, scoped per compartment. The org-chart question this episode keeps circling became concrete.

Somebody now owns the agent's identity the way somebody owns service accounts. Who provisions it. Who scopes its compartments. Who reviews its audit trail.

If no one in your org can name the owner of the agent's principal, the org has answered the ownership question by default, and the answer is nobody. The unowned layer just acquired a login. Name its owner before your auditor does.

Keep In-House

If you outsource them, there are four categories of work where you lose what makes your agent program distinct. They are not flashy. Most don't appear in engineering leveling guides. They are the quiet assets that compound for a specific org.

Harness design discipline. The set of judgment calls about what the harness does and does not do, the autonomy envelope, the verification philosophy, the escalation logic, is the signature of your program.

A consultancy can implement your decisions. A consultancy cannot decide for you, because decisions depend on domain-specific risks, regulations, and workflows. Outsource this, and you'll end up with a well-engineered harness that is wrong for your business.

Eval philosophy. The meta-decisions, what counts as a correct answer, how to weight different failure modes, how to handle ambiguous cases, when to trust human judgment versus structured assertions, are the program's nervous system.

If you outsource eval design, you've outsourced the definition of quality for your agents. You will inherit somebody else's notion of what matters, and your agent will behave accordingly.

your internal stakeholders. No vendor possesses this. It is accumulated from your own incidents, audits, and customer complaints.

It is not transferable. An enterprise platform's top ten failure modes share almost nothing with a consumer app's. An off-the-shelf "failure taxonomy" covers neither.

Org-specific workflows. The sequence of steps a real piece of work takes through your company, who handles intake, who validates, who approves, who reconciles, is unique to you. The harness must understand these workflows.

The team that operates the harness has to be fluent in them. This knowledge disappears the moment you try to hand it to a third party. Whatever they build will be a generic approximation of your process, and your users will quickly learn to route around it.

The May 2026 survey of 170+ agent projects reached the same conclusion from data: harness quality, not model capability, is the primary bottleneck on long-horizon work. And the gains compound where production traces become regression tests and harness fixes.

The organization that names an owner for that layer and hands them the feedback flywheel is the one that compounds. Everything else means renting someone else's learning curve.

Outsource

The other side of the line is equally firm. There is a category of work that, if you insist on keeping it in-house, will slowly drain your team's capacity to do the unique work only you can do.

Observability stack. The plumbing that captures traces, logs spans, measures costs, and surfaces anomalies is a commodity. It is a thoroughly solved problem with a dozen good vendors. Your in-house version will be worse. The engineering hours you spent building it will have been subtracted from the harness work that actually differentiates you.

Model providers. The frontier models themselves are the canonical thing you do not build. You rent them. The few organizations that should train their own models already know who they are. They have training infrastructure, hundreds of researchers, and a product surface that requires a model nobody else has.

Everyone else should be a customer of the model market, not a producer.

Base tool libraries. The retrieval stack, the structured-output schemas, the base prompt libraries, the standard agent patterns. These are becoming open-source commodities and vendor offerings. Building your own version is romantic, not strategic.

The compounding advantage lies in how you configure and orchestrate them for your domain, not in whether your team or someone else wrote the retrieval library.

The Meta-Signal

There is a one-line test that makes the boundary clear. If a role can be written as a short spec, it is outsourceable. If it requires domain-specific judgment calls every week, keep it.

An observability integration has a short spec. These metrics, this cardinality, this retention, this dashboard. You can write the RFP in two pages. A vendor can deliver against it. A Harness PM setting the autonomy envelope for a compliance workflow in a regulated industry has no short spec.

Their judgment calls change with every regulatory update, new audit finding, and production failure mode. The role requires someone inside your org, who sees all the context, and who gets to make the call every week.

Organizations that understand this distinction move faster because they stop burning their rare, expensive talent on commodity problems. Organizations that confuse the two either (a) waste their best harness talent on undifferentiated plumbing, or (b) let unqualified vendors make judgment calls.

Both failure modes look like progress for six months but like a structural disadvantage in the second year.

The Assembler Agent Pattern

Here is a pattern that changes how you staff the harness function. Most orgs design one harness per workflow. A support harness, a compliance harness, a code-review harness. And staff a team to each.

That works at a small scale but breaks at ten. At twenty workflows, the organizational math stops fitting: you cannot afford a dedicated team per harness, and a shared harness platform becomes a bottleneck (as seen in Model One's failure mode earlier in this episode).

The Assembler Agent pattern is a third option. One Harness PM and one engineer pair maintain a library of harness primitives. Identity templates, Memory Policy modules, Orchestration patterns (including Ralph Loop), Interception middleware stacks, Observability & Evals infrastructure.

When a new workflow needs a harness, the Assembler composes one from the library in days instead of quarters. Workflow-specific logic lives on top; everything structural is inherited from the library.

Three signals tell you the Assembler pattern is working. First, the time from “nThe library grows predictably.rops from quarters to weeks. Second, the library grows on a predictable cadence. This means two or three new primitives per quarter, added from lessons learned across existing harnesses.

Third, workflow teams stop rebuilding orchestration from scratch and start requesting primitives.

And the pattern is already evolving past what I just described. In June 2026, the first organization-designer tooling appeared. Repositories that treat the harness not as a single-workflow composer but as a designer of teams.

The tool automatically generates a team of specialized agents, defines their roles, creates the skills they need, and supports six explicit team architectures: Pipeline, Expert Pool, Fan-out/Fan-in, Supervisor, Producer-Reviewer, Hierarchical Delegation. With automatic skill generation underneath.

Call it Assembler 2.0: the harness as organization designer. It is experimental, and I would not bet a production program on it this quarter. But watchMoving from one harness per workflow to a harness that designs the team of agents is the natural extension of the Assembler idea, once you accept that most valuable work is multi-step and multi-skill.bler idea once you accept that most valuable work is multi-step and multi-skill.

We are moving from AI assistants to AI teams. And Episode 8 picks up that horizon. The org-design questions in this episode do not get smaller when that happens. They get recursive.

The First Org Decision, Open Harness or Closed Harness

Before any of The first org decision is one most enterprises never explicitly make.r library. The first decision is the one most enterprises never make explicitly. It is the open-versus-closed choice, and it precedes every other org decision in this episode because it determines whether you are rebuilding your organization around a harness you own or around a harness you rent.

A closed harness is one where a vendor owns the memory policy, the orchestration, the middleware surface, the eval framework, or the trace layer. Salesforce Agentforce, Microsoft Copilot Studio, ServiceNow AI, some configurations of Google Vertex Agent Engine and AWS Bedrock Agents fit this shape.

You configure the vendor's harness. You don't author it.

An open harness is one where your team owns the five clusters from Episode 2. You can export memory. You can rewrite compaction logic. You can add hooks on any of the six primitives. You can change the eval framework. You can run the feedback flywheel at your cadence, noThe question nobody asks cleanly is: for this specific workflow, are we rebuilding our organization around a harness we own or one we rent?rebuilding our organization around a harness we own or around a harness we rent? Because if the answer is “rent,” the three org models are irrelevant. You have outsourced the structural decision the org models describe.

The Harness PM role becomes "vendor relationship manager." The Assembler pattern becomes "configuration manager." The feedback flywheel becomes "submit feature request to vendor."

None of this is wrong for the 60% of workflows where the harness is not your competitive advantage. Internal productivity agents, commodity CX bots, non-differentiating operations agents. Closed harnesses are cheaper, faster, and appropriate.

The mistake is pretending you've made an organizational rebuild when you've actually made a procurement decision.

This applies to the other 40%. This applies to agents that ARE the product, regulated workflows, and anything that depends on proprietary evals as a moat. The organizational rebuild is real only if the harness is open. This is the cost the earlier episodes discussed (see Episode 5's lock-in wedge).

This is also the prerequisite for everything else in this episode.

The sharpest statement of why this decision matters did not come from me, and it did not come from an AI lab with a harness to sell. It came from Mitchell Hashimoto. He is the creator of Terraform, a man who has spent a career watching infrastructure layers commoditize and moats move:

Mitchell Hashimoto, February 2026

“Models are now commodities. Harness is the moat: business rules, data pipelines, verification logic. None of this transfers when you swap models.” ↗

Consider the procurement implication of that sentence. If the harness is the moat, then renting a closed harness means renting the moat. For the 60% of commodity workflows, that's fine. A rented moat around a commodity is no loss.

For the 40% where your advantage lives in the harness, it is the most expensive lease your company will ever sign, and the rent is denominated in everything that does not transfer when you leave.

June 2026: three proof points, one month

One month, June 2026, provided three fresh proof points for the procurement rule. Bring all three to your next vendor review.

And a fourth, written in nineteen days of downtime. After Fable 5's export-control suspension, model portability joined the procurement checklist as a continuity requirement, not a preference. Rented layers can vanish. This can happen by roadmap, sunset, or government directive. Owned layers cannot.

What Practitioners Are Doing in 2026

The shape of an agent program in 2026 has stopped being a forecast. It is in production at named companies. Five public examples are worth noting because they show the range of what "rebuilt around the harness" actually looks like in practice. Two of them deserve a deeper profile, as each settles an argument this episode has been making.

Microsoft Azure SRE Agent. The harness as a reliability engine.

Microsoft published the architecture behind the most data-backed production harness case study available: over a thousand agent instances running across Azure itself, tens of thousands of incidents mitigated autonomously, and time-to-mitigation for a major service class cut from 40.5 hours to 3 minutes.

What makes the document worth a PM's hour is not the outcome. It is the architecture. This includes narroHuman approval is hard-wired for destructive actions: human-in-the-harness by design, not retrofit.ns: harness: review recommendations, suggest mitigations, fully automated.

An audit trail reconstructs every tool call and decision for every incident. The org lesson hiding in plain sight is that the team which built this is not an AI team. It is an SRE team that understooHarness engineering was integral to the engineering.t it.

The harness engineering was the actual engineering.

ServiceNow. The governance harness as a product you can buy.

At Knowledge 2026, ServiceNow made explicit what this episode argued from first principles: the harness is not only something you build. Parts of it are now purchasable. AI Control Tower operates across five named dimensions. These dimensions include Discover (an inventory of every agent in the enterprise, including external ones), Observe (real-time behavioral tracking), Govern (policy enforcement aligned to emerging regulation), Secure (least-privilege access), and Measure (cost and ROI).

Action Fabric lets any external agent, Claude, Copilot, custom-built, Execute governed ServiceNow workflows through the platform's approval chains. The precision this forces is the same one Paradox Four named: ServiceNow has built the governance surface of the harness.

It has not built your Identity, Memory Policy, or Orchestration. An enterprise that buys AI Control Tower as its complete agent strategy will end Year 2 with excellent audit trails and no product differentiation. Buy the governance surface. Build the differentiating one. Confusing the two is the most expensive mistake available in 2026.

What a Rebuilt Org Actually Looks Like in Practice

Pulling these threads together, the picture gets concrete. An organization rebuilt around agents doesn't have an "AI team" like organizations used to have an "ML team." AI is not cordoned off. It is the spine.

The harness has a named owner. There is one Harness PM per major agent program, reporting into a senior product leader who understands that the harness is a product. The eval suite is the system of record. Every change to the harness flows through eval review like code changes flow through code review, and the eval suite has the authority to block ships.

The organization knows what goes to humans and why. This is expressed as a routing spec the harness enforces, not as an aspirational policy someone wrote in a wiki. The boundary of what is built versus bought is explicit, written down, and revisited quarterly, not assumed.

Engineering roles have shifted. There are fewer "generic" engineers who happen to work on AI and more engineers who specialize in specific harness concerns. They specialize in areas like tool design, eval infrastructure, trace analysis, and safety.

These specialties are not yet codified in most leveling guides. This means organizations that build them first are hiring against a title the rest of the market has not caught up to.

Design roles have shifted too. When humans are in the harness rather than in the loop, the designer's job expands. They design the review queue interface. The escalation UI. The audit trail. The feedback capture surface.

Every one of these is a human-facing product. The quality of these surfaces is directly correlated with the harness's quality. A review queue that humans hate is a review queue that humans skim; a review queue that gets skimmed is a harness with a silent failure mode.

The whole thing starts to feel less like "we have an AI initiative" and more like the company's operating model is downstream of how the harness works. This is exactly the phrase a colleague used recently when describing why their team had started shipping twice as fast as the team in the same building using twice the headcount.

They hadn't found a better model. They had rebuilt around the harness instead of adding it on.