Five recent sources on agent execution. I read all of them wrong the first time, and the mistake is the interesting part.

A builder and their agent

I read five things recently — a practitioner piece from Anthropic, a research prototype from DeepSeek, and three Google papers on harnesses that change themselves. I read every one as advice to someone like me: one person, one workspace, one harness, deciding what to build next. That was the wrong lens, and it took me a while to notice.

The Anthropic article is almost entirely about teams. Its failure modes are teams each shipping a subagent until the architecture is a copy of the org chart, overlapping subagents with no owner, every team appending one more sentence to the shared prompt until the rules conflict, and evals optimized per subtask and owned by nobody. All of it still happens when one person writes everything, with no second owner to notice.

DeepSeek’s prototype is the same story in code. Its domain model has a policy layer, a short allowed list, mandates carrying a policy version and the identity of whoever sent them, and a trigger that serves as the unit of audit. You do not build an immutable mandate with a sender’s identity on it unless somebody other than you might send one. And the three papers all assume, quietly, that someone can approve a change to a harness and someone else will check whether it helped — a proposer, a critic, a pruner, a router, a held-out set. That is an organization with roles, not a person with an evening free.

So the question I thought I was asking — which execution structures are efficient — is half of it. The other half is which can be owned, reviewed and reversed, and by whom.

The tension is already in my own work, which is probably why I missed it. On the operational side I built a lightweight DAG where one composition step decides and an engine carries it out, returning exactly two things: an explicit error, or the final operator’s result. On the personal side, four roles with contracts, knowledge files and a ledger carry work across sessions. That is a division of labor between deciding and executing — with one owner, a division inside my own head. These five sources describe the same division spread across people, which changes what the machinery has to do.

Three directions show up across them: simplify within a task, persist across time, adapt the harness itself. This is an outlook, not a verdict.

Simplify within a task

Anthropic’s piece reads like best practices and is largely a governance document. Its headline observation is that folding routers, planners and domain subagents back into the main loop often outperformed both a single-prompt design and a subagent design on quality, often at lower cost and latency per task. One customer measured roughly 2x faster runtime for a single loop than for their multi-agent harness; another’s dozen specialist subagents made on-brand consistency hard and added latency, while a different case was covered by one clear system prompt, four or five thin data tools, and firm output guardrails. These are deployment observations, not a controlled benchmark. Subagents keep their place for verification, discardable contexts, and modular permissioning.

But look at what the failure modes are. Per-team subagents are Conway’s law, stated plainly: the architecture becomes a picture of who reports to whom. Overlapping subagents with no owner is an ownership gap. Conflicting prompt rules is a change-control gap — many hands writing to one artifact with no one adjudicating. Localized evals nobody owns is an evidence gap. Every one is a question about people, and none disappears in a system one person wrote on a Sunday; there is nobody else to answer them.

The remedies have the same shape. A small central team owns the system prompt and end-to-end quality; there is a responsible individual per skill; skills and tools are vetted before shipping. The migration discipline is a review procedure: a small end-to-end eval first — ten golden examples is enough to start — fold one subagent at a time, run each case twice because a regression showed up in one run out of two, and inspect which tasks flipped rather than the aggregate.

Read as advice to one builder, most of that collapses. Conway’s law does not disappear when you are alone; it becomes the compartments in your own head, the ones that make you reach for a new subagent because the old one sits in a different mental folder. The machinery you need is one eval set and one owner, not a committee.

I should say where my own design diverges, because the divergence is real. Anthropic’s move puts more decision-making back into the model: one loop, better tools, progressive disclosure — they report cutting Claude Code’s system prompt by over 80% for more advanced models. Mine went the other way, pushing strictness into operators with fixed input and output shapes and success conditions an engine can check without asking a model how things went. Both reduce lossy handoffs; they buy different things. Theirs buys flexibility, mine buys a boundary the thing being bound cannot renegotiate. Which is right depends on how expensive a confident wrong answer is for you.

The research question underneath now has two halves. When does a separate loop beat a skill or a tool? And at organizational scale, who is positioned to notice when it does not — the team owning the subagent, or the team owning the outcome?

Persist across time

The last thing I wrote about my DAG engine was that it needed a sense of time: delayed wake-ups, timers, work continuing across hours rather than within one execution. I called it a scheduling feature, then corrected myself — it is a durability problem. Having read DeepSeek’s prototype, I would correct myself again. It is an authority problem first.

The prototype is a proactive coding agent for one GitHub repository. It listens to GitHub, opens a work item, works in its own session and directory, answers in the original conversation — with a pull request, for example — and surfaces a panel of things needing a person. Its principle: take as little human attention as possible and give as much value as possible, act only when asked or when a written rule allows.

The machinery is where the governance lives. A Source produces a Trigger, which is evaluated, which produces a Ticket carrying an immutable Mandate: scope, strength, the policy version in force, the sender’s identity and how the source received the trigger. An Assignment binds a Ticket to one executor session. A Subscription lets later messages on the same thread fan out to that Ticket without a fresh evaluation. Only a person’s stop withdraws a Mandate; a policy change is delivered to live work rather than revoking it. The Trigger is the unit of audit, and accepting the same trigger twice produces one Ticket. Work is stored before it is done, and a restart begins with a recovery note telling the executor to check its directory, git history and pull request before repeating any outside action.

Picture one coding task through that. Someone files an issue. The agent opens a ticket, writes the change, opens a pull request. A reviewer comments. CI fails. A second reviewer asks for something different two days later. There is never one conversation, one session, or one person — and what keeps it coherent is not the session, which died around the CI failure. It is the ticket, the mandate attached to it, and the subscription routing the second reviewer’s comment to that ticket rather than starting a new one. Task identity, session state, context and execution environment have different lifecycles, as I argued last month; here the session is shortest-lived and the mandate longest.

I already have persistent work. Four roles carry state across sessions through contracts, durable knowledge files, topology documents and a ledger, with an approval gate in front of anything that publishes. What I lack is authority expressed as something checkable. My boundaries live in documents and habits: the LinkedIn Operator publishes only through a declared capability, on confirmation; live deploy is out of scope; the news tracker may recommend but not publish. They hold because I wrote them down and I am the only one reading them. My September spike argued a dynamic decision could become a durable execution capability; the ticket adds that it must carry who made it. No object in my system says this work is authorized, by whom, under which rules, and here is how to withdraw it. At my scale I do not need one. The prototype does, because more than one person can start the work.

The caveats are not small. The README says it is a research prototype for reference only, not an official product, adapted for publication, not identical to the internal version or to the implementation described in the accompanying article, and that some designs there are unimplemented future directions. Separately, I could not retrieve the announcement; the critique circulating about it is second-hand, of screenshot-based provenance. That is not a footnote — it is the assurance problem in miniature, and section six returns to it.

Adapt the harness

The three papers are usually read as three techniques. Read them as three different change authorities and they line up differently.

OO-Harness treats a harness as executable code specifying prompts, tools and control flow, and argues a single global harness struggles across heterogeneous tasks. An evolution agent uses execution records to grow a hierarchy of specialized harness classes through inheritance; a router picks one per task from routing lessons accumulated during training. Across three long-horizon benchmarks it was best among compared methods, up to 15% absolute over the base. The governance question: who owns a class once it exists, and who audits the router? A misroute is not a crash. It is a task that ran under the wrong rules and returned something plausible.

Harness² separates task-level recursion — refining the current task’s harness with a contrastive Propose-Probe-Compose step needing no ground-truth verifier — from harnessing-level recursion, which extracts experience from those edits to update a continual-improvement harness. One step improved two models over their base harnesses by up to 11.5 points on one benchmark, 4.5 on another and 11.8 percentage points on a third. The second level is what matters: it changes the machinery that changes the machinery, and in any organization I have worked in that is the change needing a second signature.

RRSI starts from the failure the other two invite — self-improvement can overfit by memorizing training tasks, producing large in-distribution gains that shrink or vanish elsewhere. A temporally annealed budget limits how many edits a candidate may bundle and pushes toward unexplored trajectories; a critic screens benchmark-specific proposals and a pruner removes changes too small, too expensive or no longer useful. That is change control, a rate limit on change, and a retention review, in that order. Across eight benchmarks it gained up to 6.0 points on the split it evolves against and 4.3 on five out-of-distribution ones, on 30% fewer policy tokens than unregularized evolution. I cite the v3 abstract; a secondary summary reports 4.7 for the out-of-distribution figure, and I could not reconcile the two.

Approach What changes Who would authorize it Evidence it offers What it does not establish
OO-Harness The harness classes and the routing policy over them Whoever owns a class; whoever owns routing 15% over base, three long-horizon benchmarks, ablations That a misroute is detectable, or that ownership survives growth
Harness² The task’s harness, and the harness that improves harnesses A proposer for the first, a second owner for the second 11.5, 4.5 and 11.8 points; three benchmarks, four configurations That improvement from one domain is safe in another
RRSI Which changes get in, and which are kept A reviewer willing to reject on cost, not only score 6.0 in-distribution, 4.3 out, 30% fewer tokens That any of it is safe to keep — only that it scored better somewhere

That last column matters most. A benchmark gain establishes a score on a distribution its authors chose — not that a change is safe to retain, that it survives a different workload, or that anyone can explain it later.

All of this automates things I do by hand. My assumption layers — prompt wording suggests an assumption, a contract or gate states it, an engine check holds it — are a manual proposer and selector. The development conventions I called a new kind of unit test are a manual retention review. And the four properties I argued an agent-operable system needs — legibility, semantic observability, verifiability, governability — I presented as architecture. They are governance properties and I should have said so: legibility is who can find out what is true, verifiability is what counts as evidence, governability is who may act and who can stop them.

Every harness change in my workspace passes through me. The open question is which of these automations I would authorize unattended, and at what scale I stop being the reviewer because there is too much to read.

The hypothesis

Harness design is splitting into three decisions usually discussed as one. Execution: how should this task run? Adaptation: is exploring another strategy worth its cost? Retention: is a discovered change reusable enough to keep? Each needs an owner, an evidence bar, and a path back.

For one builder, the three roles collapse into one person and governance is nearly free. Ten golden examples and a documented contract is most of what you need; the reversal path is a re-run, a deleted branch, one edited document. The risk here is the opposite of what the sources warn about: ceremony with no counterparty. A gate where you are both approver and applicant is theater, unless it enforces a decision you would otherwise make badly in a hurry — which is why my publish gate exists.

For a small team the binding constraints are narrow: one shared eval set rather than two, one vocabulary for what the pieces are called, and a change process that does not require a meeting. Most of the Anthropic failure modes start here, in the gap between two people who each think they own the prompt.

For an organization with many owners, the machinery earns its keep because coordination, not computation, is the dominant cost. Mandates with a policy version, a responsible individual per skill, a trigger-level audit trail, a second signature on the change that changes the changer. None of that makes the agent better. It makes the system answerable — a different property, needed only when the answer has to satisfy somebody who was not in the room.

The economics of adaptation sit underneath all three and do not move. Exploring another strategy is worth it where tasks are valuable, recurring and heterogeneous enough that a validated improvement pays for itself over many later runs. Where they are simple and repetitive, exploration overhead dominates and the right answer is to stop adapting. That is the ratio I used to justify a programmable harness in the first place: frequent execution, occasional adaptation. It maps onto the two settings from last month — operational work with expensive failure wants predictability, personal projects where being wrong is cheap want exploration. The decision does not change with scale. The machinery around it does.

Errors persist too — in work and in policy

The critique circulating about DeepSeek’s announcement raises four concerns: routing errors, goal drift, supervision, and recovery. I treat them as testable concerns rather than verified findings, because I could not retrieve the announcement and the critique reached me second-hand through screenshots. I will not quote it or attribute it to DeepSeek. But each hides a distinction I had to learn the hard way.

Recovering execution is not validating correctness. A recovery note telling an executor to check its directory, git history and pull request restores state. It does not establish that the state is right. My engine’s two-outcome contract has the same limit: it tells me a node completed, not that the business outcome happened.

Stopping a session is not reversing an effect. A kill switch is not a rollback, and this is the one I have been most deliberate about. My workspace drafts a post, copies it into the blog repo, commits and pushes, then stops. Deploying the live site is out of scope; I do that by hand, verify the URL, and only then confirm before the LinkedIn share goes out. Killing a session anywhere in that chain would not unpublish what had already left the building. The gate sits before the irreversible step, and that placement is the whole design.

Model-based supervision is not independent evidence. A critic screening proposals is a model judging a model’s output; a held-out task set is evidence from outside the loop. A mechanical success condition is evidence; a model’s self-report is not. I built an execution engine around that one sentence.

Benchmark gains are not transferable improvements. RRSI’s in-distribution and out-of-distribution numbers are that distinction in figures — 6.0 against the split it evolves on, 4.3 on five it did not. The gap is not an embarrassment. It is the measurement.

Now extend all four from work to policy, because that is where persistence bites. A mistaken interpretation does not just produce a bad run; it becomes a rule. A wrong assumption written into an AGENTS.md outlives the session that wrote it and quietly constrains every later one — and because those documents are dense, terse and optimized for the next agent session rather than a human reader, I will not reliably catch it on a re-read. I called that drift a readability problem months ago. It is also an error-persistence problem.

At organizational scale the same failure has a name and a cost. A policy version encoding a misreading, applied to every live mandate. A local eval that was convenient for one team and became the standard because nobody proposed another. A mandate whose scope was written once and never re-read, still authorizing work two quarters later. The rule I keep repeating — if something must happen, do not ask the model to remember it — has an organizational twin: if something must stop happening, do not assume anyone will re-read the document that said so.

Which brings back the screenshot. The honest question the episode raises is an assurance question: what can someone outside the building verify about an autonomous system, and what must they take on trust? For this prototype I can verify a README and a repository. Everything else — including whether the critique is fair — I take on trust, and I would rather say so plainly than write around it.

Three spikes I’d actually run

These are proposals. I have not run them, and I am writing them down mostly so I cannot quietly move the goalposts later.

Spike A — execution boundaries. Compare a single loop, subagents exposed as tools, and persistent workers on the same workloads, same model, fixed budget. Measure task quality, total computation, latency and recovery behavior. My prior, from the DAG work: the single loop wins wherever I can state a success condition mechanically, and loses where contexts genuinely need to be discardable.

Spike B — harness selection. Compare one default harness against a small specialized family, including routing overhead and the cost of misroutes. Misroute cost is the number I care about: work that ran under the wrong success condition and looked fine.

Spike C — controlled evolution. Generate candidate changes in an isolated environment, evaluate on held-out tasks, regression-test before adoption. Pre-register the adoption rule before seeing numbers, because otherwise the rule becomes whatever the numbers suggest.

Then the measurements that only exist above one person: who reviewed the change, how long approval took, how complete the audit trail is, how long a reversal takes, and what fraction of changes needed a second owner. None appear as a metric in any of the five sources, and all are costs a benchmark gain has to clear.

And a fourth spike, this article’s actual contribution and the one I would run first. Run A through C twice: once as a single owner, my normal condition, and once with a second reviewer who did not build the system. If that reviewer finds nothing, I have evidence that minimal governance is sufficient at my scale. If they find things I could not see, I have evidence that what I call thoroughness is mostly familiarity.

What would confirm this direction

I want to leave the hypothesis where it belongs, which is open.

The signal that would confirm it is repeatable evidence that task-dependent execution improves useful outcomes after accounting for exploration, maintenance, review and failure costs — not benchmark deltas, and not on the distribution the system was tuned against. Alongside that, evidence about the boundary: that minimal governance really is sufficient for one builder, and that organizational machinery earns its cost only above some threshold nobody has measured. That threshold is the most useful missing number here.

Disconfirmation is easier to specify, which is usually a good sign. If a single loop with good tools matches specialized harnesses once review costs are included, the adaptive direction is premature. If gains vanish when the evaluator is not the builder, they were never gains. If the audit trail costs more than the failures it prevents, at that scale the machinery is ceremony and should go.

None of the five settles this, and no two evaluate the same workloads, so their numbers cannot be stacked. What they share is a direction: execution structure is becoming something you choose and change rather than set once. That is a design variable now, and design variables need owners.

Can agent systems adapt their execution strategies while keeping those changes understandable, testable and reversible — and attributable to someone who can be asked why?

References

  1. Diane Sarkis, Anthropic — Building agents: When to fold subagents into your main agent loop, 22 Oct 2026. claude.com. Practitioner guidance from the Applied AI team, not a controlled benchmark.
  2. DeepSeek Harness — dsh-superagent research prototype. github.com/deepseek-ai/dsh-superagent-prototype. The README states it is a research prototype for reference only, not an official product, adapted for publication, not identical to the internal version or to the implementation described in the accompanying article. The original announcement could not be retrieved during research.
  3. Object-Oriented Harness: Evolving Agent Harnesses through Object-Oriented Design — arXiv:2610.28380, v1, 20 Oct 2026.
  4. Harness²: Recursive Agent Harnessing for an Open World — arXiv:2610.14224, v1, 9 Oct 2026.
  5. RRSI: Regularized Recursive Self-Improvement of Agent Harnesses — arXiv:2609.24972, v3, revised 4 Oct 2026. Figures cited from the v3 abstract.