Inside Anthropic: the harness wrapped around the model is being torn down
- The code layer wrapped around the model — the harness — is getting thinner. What it encodes are assumptions about what the model can't do, and those assumptions expire as models improve
- As it thins, a new layer grows on top that decides which play to run. Anthropic's own blog calls it a meta-harness
- The permission model is shifting: from "what can this user do" to "what can this Agent do inside this compartment"
- For enterprises, the recommended order is individual → team → cross-team process. Don't start with the hardest layer
- The easiest trap: once everyone can go it alone, staying aligned gets harder, not easier
- On the platform side it lands on outcomes — you hand over acceptance criteria, not steps
Tearing down the scaffolding around the model
Anthropic recently released a conversation titled Building the future of agentic infrastructure, running about 16 minutes. Two people on camera: Angela covers the usage patterns she sees on the customer side and how the harness has evolved; Caitlin works on the Managed Agents product line and talks about Agent identity, engineering teams, and where the platform is headed.
Six months ago the Claude platform was mostly an inference endpoint: text goes in, results come out. Since then two layers of trouble have been stacked on top — infrastructure, and harness engineering.
A model does exactly one thing: read text, emit text. It can't open a file, run a command, or query a database on its own. The harness is everything wrapped around it — it reads what the model emits as "it wants to use this tool," actually runs that tool, and feeds the result back so the model can keep thinking. When the context is nearly full, it compresses. When something crashes, it checkpoints and resumes.
If the model is the engine, the harness is the rest of the car: steering wheel, gearbox, fuel gauge, seatbelts.
But "harness" is a loose word for a bundle of very different things. Pull it apart and you get four categories:
The first three cover things a model fundamentally cannot do, no matter how capable it gets — someone will still be writing that code a decade from now. The fourth is different: it makes decisions on the model's behalf, and the only reason it ever existed is that the model made poor ones.
A few months ago the standard practice was to pile that fourth box high: chop the business into boxes and wire them together, gate A before B, let B fire only when a stack of conditions is satisfied, until you have a genuinely complicated web. There was a reason for it at the time — model unpredictability used to be far more painful, so you pinned it down with a standard operating procedure.
The cost is brittleness. And the logic runs backwards: you bought the model's intelligence, then the orchestration boxed it in, so the Agent never gets to show the capability you were paying for.
A concrete case: the patch that became dead weight
Anthropic's engineering blog records an incident that beats any abstract argument. Sonnet 4.5 had a quirk: partway through a task, as it approached the context limit, it would start rushing to wrap up. The engineering team called this "context anxiety." So they added a patch to the harness that did context resets specifically to fix it.
Then they moved to Opus 4.5, and the quirk disappeared on its own. The patch became, in their words, dead weight.
That's the whole meaning of "the harness is thinning." The layer made sense when it was built. Once the model improves, the part that was covering for it flips from insurance to drag. Anthropic's own framing: everything encoded in a harness is an assumption about what the model can't do, and those assumptions expire as models get stronger, so they have to be dragged out and questioned again and again.
- A web of conditions: A first, and only a qualifying A reaches B
- A standard operating procedure pinning down every step's order
- Built to hedge against model unpredictability
- Brittle, and it locks the model's judgment out
- Thin: the deciding-for-the-model part gets deleted
- The model works out its own steps inside the guardrails
- Runs longer, lives in a persistent workspace, fires on events
- Completes a whole run and comes back only when it's genuinely ready
Two things happened at once to make this possible. First, the models evolved: they use tools, reason further, and can loop through "assess, decide the next move, act, check the result" instead of just answering a single question. Second, infrastructure caught up: an Agent can live in a persistent workspace, wake on an event, run a whole sequence for a while, and come back to you only when it's actually ready.
What's being torn out: the "deciding for the model" box — the orchestration code that hardcodes step order and conditional gates in advance. Legwork, cleanup, and guardrails stay exactly as they are.
Why: that box only exists because the model couldn't decide well on its own. Once it can work out its own steps, the box flips from insurance to drag — exactly like the context-anxiety patch turning into dead weight on Opus 4.5.
Put another way, what changed is who plans the route. People used to hardcode the route and leave the model to fill in each box; increasingly, the job is to hand over a goal and let the model plan as it goes. Anthropic calls these two shapes workflows and Agents. The difference isn't how smart the model is — it's structural: who laid out the route.
Once it's thin, who decides how to play it
A thinner harness doesn't mean nothing is left on the outside. Something else grows on top of it — the speakers hadn't settled on a name, and joked it might end up being called the saddle.
This layer doesn't dictate step one and step two. It decides which play to run against this particular problem.
The old harness was a hardcoded assembly line: every station's job, and when it hands off to the next, all planned in advance. The new layer is more like a coach calling plays. It isn't standing on the line; it decides which formation this game gets played in.
This isn't just improvised on camera. Anthropic's engineering blog uses exactly the term "meta-harness" when writing about Managed Agents, defining it as a system that takes no position on which specific harness will be needed later — it just offers generic interfaces so many different harnesses can run on top of it.
All three of the plays below are already in use:
Fire off several Agents against one problem at the same time, let them compete, and take whichever result is best. This itself gets built into the harness.
Two Agents with opposing jobs: one proposes the approach, the other's entire role is to poke holes. Adversarial pressure replaces a single forward march.
A recent Anthropic experiment. When the model can't figure out what to do next, it asks a "friend" — hopefully a smarter one — to help it get unstuck.
In practice these plays get mixed, and staged. Early on you spread out with best of N — run the same problem independently N times, then pick the best — to see which paths work at all. Once the right framework settles, you grind on that framework instead. Exploration and convergence don't use the same strategy.
Worth noting: "run it a few times and pick the best" isn't a universal answer. A fair amount of recent research finds that on complex tasks, repeated independent sampling loses badly to iterating against a standard — which is the road outcomes take, covered below.
Agents need identities of their own
Nearly every Agent working today runs on borrowed permissions: it enters systems under some person's account, goes wherever that person can go, and when something breaks the audit trail points at that person. The conversation's read is that this road runs out — Agents need identities of their own.
A company issues employees a badge, and the badge decides which rooms they can enter. A service account is a badge issued to a program: no inbox, no password, no admin login — purely something a machine swipes. Managing human badges separately from machine badges is old practice in enterprises. What's new is that Agents now get one of their own.
Two unavoidable reasons this has to change. One is timing: an Agent schedules its own tasks and starts work long after you've gone home, at which point "acting on your behalf" doesn't hold up. The other is attribution: a channel with three engineers and a product manager — whose permissions should the Agent use? No single choice is right in every case.
In a blog post on Agent identity, Anthropic sums the shift up bluntly: the question moves from "what can this user do" to "what can this Agent do inside this compartment."
Here's the back-and-forth the conversation describes:
"Every Monday, give me a sales report for last week." You don't tell it where to pull the data, which template to use, or how to compute year-over-year.
"To do this, I need to read the sales database, fetch the report template, send email, and query the finance system." This step is the crux. It doesn't just grab your account and go — it lists what it needs to touch and shows you the list first.
First three approved, finance denied. It now has to produce the report inside that boundary; for the missing piece it either routes around or comes back to you. Your approvals are exactly its range of motion — no more, no less.
After it lands the job once, it can more or less create a service account for itself. From then on it acts under its own identity, every action logged in its own name, auditable line by line after the fact.
The exchange above is an illustrative scenario, assembled from the conversation's description.
This model has a cost, and Anthropic names it in their blog: you can end up with a room you personally can't enter but can send an Agent into, as long as that compartment grants the Agent the permission. Their framing is that this is genuinely counterintuitive, but necessary for shared, autonomous Agents. What you get back is easy revocation: kill the identity and its access ends everywhere at once.
How Agents call each other
One related thread: wrap an Agent and expose it, and another Agent knows how to put it to work. The conversation mentions people building a very thin MCP server layer on top of Claude Managed Agents to do this.
MCP is a protocol Anthropic open-sourced in November 2024, described in their own analogy as "a USB-C port for AI applications." But what actually makes "another Agent just knows how to call it" work is one specific design choice:
The caller asks "what can you do," and gets back a list of capabilities. Every item on that list carries two things: a plain-language description (what this does, when to use it) and a parameter schema (which fields, what type each is, which are required).
And "read an annotated list, then decide which dish to order and how to fill in the form" happens to be exactly what large models are best at. So nobody has to hardcode the calling logic in advance — it reads on the spot and knows how to use it on the spot.
The self-deprecating line that opens the video is about precisely this.
You can tell we're API geeks, because we're saying Agents should talk to each other over APIs.Opening line of the conversation
Don't start surgery on 120 processes
When enterprises do the math on Agents, two opening moves are most common: convert every legacy process they own — maybe 120 of them — into an Agent version, working down the list; or decide this is the moment to rebuild the entire product surface from scratch. Both are fine ideas, and both are extremely hard to see through.
The alternative the conversation offers is a simpler mental model, and the order can't be reversed:
Watch how much faster one person actually gets. The speakers admit this sounds almost too unsophisticated, but it's where the starting line belongs.
Once one person speeds up, push it to the team and start looking at the velocity and output it generates there.
Only now should you ask whether that team can drive a process end to end across the company. In reality one process touches many teams and many people who share no standard operating procedure and don't necessarily share a discipline. Which is exactly why it's the hardest, and belongs last.
Follow that order and the metrics a company cares about light up one at a time, until you eventually reach the 120-item list you wanted to work through anyway. Most ROI math should lead with velocity and output efficiency as the primary handle — it usually lands sooner and works better. Once this is spreading through the company, shifting toward financial and user metrics makes more sense.
Everyone can go it alone, and coordination gets harder
Asked about failure modes, the conversation gives an unflattering answer: Agents produce a feeling of super-independence, and that feeling is somewhat hollow.
You start believing everyone's a developer now and anything can be done solo. You used to weigh which of a few approaches was best; now it's cheap, so you build ten prototypes and take whichever wins.
Everyone got super-independence, and nobody got organized around a specific direction. The more systemic, more holistic work is where quality becomes hardest to coordinate — and everyone doing their own thing just spreads out from there.
What engineering teams look like now
The structure hasn't changed much: you still need people who understand what system they're building, how to operate it, and how to be on call when it breaks. What changed is the mix inside the team.
- One tech lead with strong opinions on how the system should be designed
- A large group of engineers working tickets
- Opinions concentrated in a few people
- Nearly everyone holds strong opinions about the end-to-end design
- Each person directs their own Claude to execute
- Similar headcount, dramatically more shipped
The scarce thing moved from "who writes it" to "who can articulate what it should become."
From a rack of tools to a single substrate
The endgame they picture isn't opening Agent tools one by one, this one good at this, that one good at that. It's a shared substrate everyone collaborates on top of.
The interfaces stay familiar, but you can summon an Agent whenever you want, start it, stop it, and let it work quietly in the background. It might even come to you first: this thing broke, I dug into the details, figured it out and fixed it, here's the diff, want a look? And you can reply that something this small shouldn't reach you at all — just ship it.
Further out, team Agents map onto the collaboration preferences of specific groups of people: the workflow between you and me has one Agent, a three-person team has another, and its sense of the preferences is slightly different. Less a rack of tools you reach for than an operating system.
The platform's handle is called an outcome
It ends on a concrete mechanism: instead of telling Claude how to do the work, you tell it what counts as done, with a rubric attached. It works, scores itself against the rubric, and repeats until it passes.
This isn't a slogan — the official docs describe a real design. Define an outcome and the system automatically attaches a grader that inspects the artifact against your rubric. That grader runs in a separate context so the main Agent's own implementation reasoning can't sway it. Failures get sent back for another pass, with a default retry limit of 3 and a ceiling of 20.
Extend that line and the imagined usage is: you say "I want this result, here's the budget, go," and you're largely done worrying about the rest.
Where things actually stand: Claude Managed Agents is currently in public beta, and within it both outcomes and dreaming are marked research preview, requiring separate access requests. Part of the full picture described in the conversation is direction, not product sitting on the shelf today. Also, "the Agent creates a service account for itself" is the conversation's phrasing; the official docs currently describe an admin provisioning the service account and the Agent acting under that identity.
Background material drawn from Anthropic's other public materials: the engineering post Scaling Managed Agents (the meta-harness definition, and the context-reset patch that became dead weight), an engineering post on building effective Agents (the workflow/Agent distinction), Agent identity (the permission model shift and its cost), the outcomes documentation (the grader mechanism and retry limits), and the MCP site.
This is a secondary interpretation; wording has been edited, and names keep their original spelling. The weekly-report scenario and the diagrams are the editor's, not examples from the source.
The process web around the model went from insurance to cage
A 16-minute Anthropic conversation: once a model can plan its own steps, which layer of the shell gets torn out, and what grows back — one page, with diagrams
↓ One page · one of the diagrams animates
A large model does exactly one thing: read text, emit text. It can't open a file, run a command, or query a database on its own. So people wrapped a layer of code around it — the harness — which reads what the model emits as "it wants to use this tool," actually runs it, and feeds the result back so the model keeps thinking. If the model is the engine, the harness is the rest of the car.
But the parts inside that car aren't the same kind of thing. Some cover what a model fundamentally can't do and will still need doing a decade from now. One box doesn't.
✘ The box being torn out: deciding for the model — do A then B, which conditions gate the next step, the exact order every step must follow
Why this box can't survive: the only reason it existed is that the model decided badly on its own. A few months ago the standard practice was to pile it high — chop the business into boxes, gate A before B, let B fire only after a stack of conditions, until you have a genuinely complicated web. The cost is brittleness, and the logic runs backwards: you bought the model's judgment, and the orchestration boxed it in.
The conversation's read: that box is being deleted. Not because deleting it is tidier — it's actively holding things back. Anthropic's engineering blog records a specific case. Sonnet 4.5 had a quirk: partway through a task, as it neared the context limit, it would rush to wrap up. The team called it "context anxiety" and added a patch to the shell that did context resets. On Opus 4.5 the quirk vanished by itself, and the patch became, in their words, dead weight.
if B output passes → C
else → back to A, retry
- The model only fills in each box
- Change one condition and the whole web shakes
Guardrails: sales DB yes, finance no
Route: the model plans as it goes
- Lives in a workspace, wakes on events
- Finishes a full run, returns when truly ready
This became possible because models learned to loop through "assess, decide the next move, act, check the result." But a thinner shell doesn't mean nothing is left outside — another layer is growing on top, and the speakers hadn't settled on a name for it, joking it might end up being called the saddle.
This layer doesn't dictate step one and step two. It decides which play to run against the problem. Anthropic's engineering blog calls it a meta-harness. The diagram below lays the old approach and three new plays side by side on one problem: XiaoHu has to write a 2,000-word review of a new AI headset, working from 12 user complaints.
One more thing comes with it: once the model plans its own steps, permissions have to change hands too. Nearly every Agent today (an AI program that plans and executes its own steps) runs on borrowed permissions, entering systems under a person's account and going wherever that person can go. The conversation's read is that this road runs out: the Agent starts work after you've gone home, so "acting on your behalf" doesn't hold; and in a channel with three engineers and a product manager, whose permissions is it supposed to use? The direction instead: it reports which systems it needs to touch, you approve item by item and can refuse, and once it succeeds it gets an account of its own, with every action logged in its name and auditable afterward.
The two most common enterprise opening moves: convert all hundred-plus legacy processes into Agent versions, working down the list; or decide this is the moment to rebuild the whole product. The conversation's alternative is a dumber order, and it can't be run backwards. Take a 40-person content company — here's roughly how long each rung takes:
Cross-team process
Whole team
One person
All of this comes from a conversation video and blog posts Anthropic published itself, with both speakers describing their own platform's direction, so anything about product capability is one side's account. Outcomes and similar capabilities still require a separate access request, and "the Agent creates a service account for itself" is the conversation's phrasing — the official docs describe an admin provisioning the account.
Fixed order, conditions on conditions.
He locked down every step.
Models improve, assumptions expire.
12 user complaints in hand.
to a coach calling plays.
what it needs, you approve or refuse.
every step logged in its name.
Exactly where not to start cutting.
② Whole team → weeks
③ Cross-team process → months+
- × Ten prototypes at once
- × Everyone off doing their own thing
- × Nobody aligning direction
The scarce thing isn't who writes it,
it's who can say what to build.
Members can copy or download the full Markdown, and let their AI subscribe and ask.
Found this useful? Leave your email — every new explainer, the moment it's out. Unsubscribe anytime.