Most of what's written about agent harnesses comes from people building coding agents. That's where the memory systems, plan modes, compaction strategies and context engineering playbooks were born, and it's where they make sense. Hugo Bowne-Anderson's argument, delivered in a 45-minute Lightning Lesson and a companion essay on O'Reilly Radar, is that this advice misleads anyone building the far more common kind of agent: the support bot that has to resolve a request in one reply, the sales workflow with a single reasoning step, the enterprise assistant with a handful of tightly controlled tools.
The claim underneath is sharper. Every feature you add to a harness is a bet that the model can't do something on its own. As models improve, those bets lose, and the scaffolding you built becomes the thing holding the system back.
The average agent describes almost nobody
Bowne-Anderson opened by polling the room: how many turns does the average agent conversation last? Most guesses landed between four and 50. The true figure is somewhere around three to five, and he immediately called his own question horrible.
His explanation came from his years in biology and statistics, where a crude joke about the average human's anatomy was used to teach how badly summary statistics mislead when the underlying distribution is bimodal. The agent population is exactly that. Coding agents and open-ended conversational agents routinely run past 50 turns. Customer support agents live in the one-to-three range, and they need to, because time to resolution is a core metric.
So "the average agent" is a fiction, and harness advice tuned to it fits nobody.
He proposed two axes instead. Context complexity asks how much information the agent has to hold and how it grows over the task. Action complexity asks how many tools the agent needs and how complicated those tools are. William Horton at Maven Clinic built a women's health agent whose context needs were simple but whose tool count went from 15 to 20 at launch to 30 to 40 four months later. That's a bounded-context, medium-action agent, and its harness looks nothing like Claude Code's.
Four tools and 147 lines turn an LLM into a computer-use agent
Before arguing about how much harness to build, he showed how little it takes to build one at all.
An agent, in his working definition, is an LLM with tools in a loop. The model triggers an action, observes the result, and decides what to do next. Ask a coding agent to edit app.py and it won't touch the file first; it reads it, gets the contents back into context, then edits, and keeps cycling until it emits text instead of a tool call.
The live demo was a single Python file, 147 lines, defining four tools: read, write, edit, and bash. Below those, the executors. Below those, the reasoning loop, wrapped in a conversational loop so a human could keep talking to it. He pointed it at a messy desktop folder full of PDFs and spreadsheets and asked it to clean up. The agent ran one bash command to confirm the folder existed, asked whether it should create organized subdirectories, then made five tool calls and sorted everything into documents, images and spreadsheets.
Nothing about that task is coding. A coding agent with file and shell access is already a general-purpose computer-use agent, and the industry's habit of calling these tools coding agents hides how much else they can do.
His second example made the same point at production scale. Part of his YouTube publishing pipeline now runs on the same four-tool pattern: an agent reads live stream transcripts and proposes clips, cuts them with FFmpeg, burns in word-highlighted captions and the Vanishing Gradients logo, verifies the output against criteria he's iterated on, and uploads drafts with titles and descriptions through the YouTube API. Fifteen clips used to cost him four to five hours. Now it's about 20 minutes of his attention inside an hour of wall-clock time while he manages other agents. The missing fifth step, feeding performance data back into the system, is what he's building next.
Model calls inside a workflow don't make it an agent
The most frequent "we want to use AI" request he sees doesn't need an agent at all.
His example: a sales call gets transcribed with a speech-to-text model, an LLM extracts fields (deal stage, company, lead score), a human reviews, and the CRM updates. Two frontier models sit in that pipeline. There's no reasoning loop. Each step is deterministic, and the code decides what happens next.
In a workflow, your code chooses the sequence. In an agent, the model does.
The two coexist comfortably. You can embed a reasoning loop inside a step, say a generator-evaluator pair where one model extracts fields and another checks them and sends bad results back. He walked through the patterns Anthropic's Building Effective Agents post laid out at the end of 2024: prompt chaining (extract a LinkedIn profile to JSON, add company context, draft an outreach email, with gates between steps for malformed output), routing (send a profile to an executive handler, a recruiter handler, or a default, and pull a human in early for executives), and evaluator-optimizer (draft, critique, revise until the critic is satisfied). All of these predate generative AI in spirit. All of them ship value without an agentic loop.
Pi keeps the loop small while OpenClaw grows a product around it
He reached for a Ninja Turtles analogy to define the harness. Krang is a brain with no way to act on the world, so he has a body built around him. The LLM is Krang. The agent harness is everything around it: the runtime that runs the loop, executes tools, assembles context, persists state, and enforces boundaries.
Pi, the minimal agent inside OpenClaw, is his favorite production example of the small end. Four tools (possibly three now), a system prompt, context loaded from an agents.md file, and one trick that separates it from the 147-line demo: it extends itself. Ask it to do something it can't, and it writes a skill for that task and hot-reloads it mid-conversation. His own OpenClaw instance, reached over Telegram, went silent for a minute when he sent a voice message, then explained it had no speech-to-text model and was downloading Whisper. It finished the download and answered.
OpenClaw is what happens when a product grows around that loop. Gateways, sessions and channels let you talk to it from Telegram or Discord. Proactivity, the morning summary of inbox, calendar and overnight AI news, is a cron job. Hooks trigger actions after events. Delegation runs through sub-agents and handoffs. All of that is ordinary software engineering paired with a model. The loop stayed small. The harness became the product.
There's a corollary he wanted to make explicit: you're never just using a harness someone else shipped. Every line in your agents.md, every skill, MCP server or trace-based check you add is reshaping it. Claude Code is bad at data science, he said, and shouldn't be expected to be good at it out of the box; the harness around it has to make it so.
Map the job on two axes before you build anything
Put the two axes together and you get a rough map of which harness belongs to which job.
Coding agents and deep research agents sit far right on context complexity. In coding, the repository grows inside the conversation; the agent writes code that gets fed back in, which is why these tools compact so aggressively. In deep research, evidence accumulates. The standard moves, which he credited to Lance Martin (formerly LangChain, now Anthropic), are reduction (summarization, sliding windows, compaction), offloading (a scratch-pad file the agent reads when it needs to), and isolation (sub-agents that get only the context for their slice and return only the useful result, so the main agent's window doesn't fill with search noise).
Most enterprise agents live somewhere else entirely. Support, sales and internal ops agents should resolve in one to five turns. His rule of thumb for support: three turns is the target, five is the ceiling, seven is a failure. At that length, in-conversation memory isn't a concern and compaction is irrelevant.
That doesn't make them simple. Maven's agent has input guardrails that intercept certain questions before any model sees them and route the person to a human. A lead agent then dispatches to sub-agents for appointments, provider search, health content, or account help. The difficulty moved out of context management and into architecture: routing logic, narrow tool interfaces, deterministic guardrails, explicit handoffs.
And then there's the label "personal assistant," which he flagged as useless for design purposes. It covers a calendar-booking bot and it covers OpenClaw's "manage my work and life," with persistent state, dozens of integrations and shifting priorities. The product name tells you nothing about which harness to build; the two axes do.
Every harness feature is a bet on something the model can't do
This was the framing he borrowed from Nico Gerald at AMP, and it reorganizes everything else.
When long context degraded, teams built compaction, handoffs and external memory. When tool selection was unreliable, they built routers, constrained menus and extra validation. When planning was unreliable, they built plan modes, scaffolds and prescribed steps. Each of those was a reasonable response to a real weakness. Each is also a constraint the model may no longer need.
AMP has removed plan mode entirely because the models handle planning well enough on their own. Claude Code and Codex still ship one. Manus tore out and rebuilt its harness five times in a year. Open Deep Research did the same. Claude Code rearchitects as its underlying models change.
There's a feedback loop driving this. New models are trained with reinforcement learning on verifiable rewards over coding traces that came from these very harnesses. The models absorb the scaffolding. What you built to compensate for a weakness gets pulled into the weights, and your compensation turns into friction. He called it a pseudo arms race.
The practical rule: retest the harness every time the model changes. Keep a gold dataset and evals that let you rerun the whole thing, roll to a subset of users where the risk profile allows, and keep a feature only if it still improves the system.
The runtime harness does the work; the eval harness measures it
He was careful to separate two things that share a word. The runtime harness shapes what happens during a task. The eval harness tells you whether the system is getting better, and it's a different piece of software with a different job.
His build sequence: pick one real task with a real input someone at work cares about. Define what a good result looks like before adding any machinery. Build the shortest path, whether that's one model call or a fixed workflow. Ship it, capture traces, outcomes, cost and latency, then build the minimal eval harness that can run real cases and surface failures. Fix the failure with the biggest payoff. Repeat.
Get the first eval set from real work rather than synthetic data, and put the thing in front of real users early even if those users are the internal sales or support team. Label successes and failures with reasons. Log inputs, decisions, results and outcomes. Build interfaces for inspecting all of it that are comfortable for developers; if you're building an email agent, look at traces inside something that resembles the email client the user sees.
Then let failures decide what to add next. Add complexity only in response to failures you've actually seen.
Change one layer, hand-roll your evals, and automate the tests but not the release
The most common failure he sees in early teams is changing the model, the system prompt and the tool definitions in one go, then having no idea which change moved the behavior. Change one layer at a time.
A consultant in the audience, KBY, pushed on this: moving responsibility from instructions into a tool touches both layers at once. Bowne-Anderson's answer was that "one change" is a conceptual unit rather than a file count. Shifting a specific behavior from prompt to tool is one change even when it edits several files. What you're avoiding is two unrelated hypotheses tested simultaneously.
Scott, who works on customer simulation with model-agnostic pipelines, asked how much of the retesting can be automated given how often models ship. Most of it, was the answer. With a gold set of input-output pairs and either deterministic checks or an LLM judge, you can automatically measure what any update does across the whole set. The decision to push to production is where he keeps a human. Coding agent vendors can afford to release same-day when a new model lands, because their users are engineers and the risk is low. A healthcare assistant can't. Look at false positives and false negatives alongside accuracy, and calibrate how much you automate to how much a mistake costs.
KBY's last question was whether hand-rolling small bespoke Python apps for evals was reinventing the wheel. Bowne-Anderson said it's the best pattern he's seen, and it's cheaper than ever because agents write the tooling. Adopt Phoenix, Arize, Pydantic's tooling, Logfire or the LangChain family when the hand-rolled version has accumulated enough debt to justify it. Not before.
The through-line is a discipline. Start with the simplest architecture that can do the job. Match harness complexity to action complexity and context complexity, measured for your task rather than borrowed from a coding agent. Use workflows where the code should decide and loops where the model should. Let observed failures drive every addition. And go back to the scaffolding you built last quarter, because the model it was compensating for may already be gone.
