The Agent Harness Is the Product

Key insights

• The agent harness is the product, not the model. Models are being commoditized. The infrastructure around them is where the real value lives.
• Three-tier orchestration scales AI work horizontally. Orchestrators plan, team leads coordinate, workers execute. One agent is not enough.
• Building the system that builds the system is the fundamental shift. Stop prompting one agent to make things. Build a team of agents that owns the domain.
• When agents can attack, you need agents that defend. The intersection of AI agents and security is a major opportunity in 2026.

In Brief

When Claude Code, Anthropic's AI coding tool, had its source code leaked, most commentators focused on the new features and the model underneath. Dan Disler, the engineer behind IndyDevDan, saw something different: the real product is not the AI model at all. It is the harness around it. In this video, Disler shows a full multi-agent team running on the Pi coding agent (an open-source tool that lets you build and customize your own agent harness) and makes the case that building your own agent harness is the highest-leverage skill an engineer can develop right now.

What is an agent harness?

Imagine a Formula 1 car. The engine is incredibly powerful, but without the steering wheel, the gear system, the safety harness, and the onboard computers, the car goes nowhere useful. The engine alone is not the product. The whole system that makes the engine useful is the product.

An agent harness works the same way. It is the framework that sits around an AI model and controls everything the model does. According to Disler, a harness includes deterministic code (meaning code that always behaves predictably, unlike the AI itself), token caching (saving previous AI responses so you do not have to pay to repeat them), agent orchestration (coordinating multiple AI agents to work together), prompts, skills, and model control.

Without the agent harness, there are no agents, no agentic coding, and therefore no agentic engineering. To understand that chain, think of three levels of working with AI:

• Vibe coding is the entry level: you type a prompt, the AI generates code, you hope it works. No structure, no system.
• Agentic coding is the next step: you use a tool like Claude Code that can read your project, run commands, and fix its own mistakes. The AI is no longer just generating text; it is acting inside your codebase.
• Agentic engineering is the level Disler is describing: you design and build entire systems of AI agents that work together in teams, each with a specific role and domain. You are not prompting one agent. You are engineering a workforce.

The harness is what makes that third level possible. It turns a powerful but unpredictable AI model into a reliable, repeatable system.

Claude Code reached $2.5 billion ARR (annual recurring revenue) faster than any product in history. When its source code leaked, people expected to find some secret sauce in the model layer. Instead, what they found was an elaborately engineered harness: the system that manages how the model reads your project, which tools it can call, how it caches previous work, and how it orchestrates multi-step tasks. The model underneath is powerful, but it is not the reason Claude Code is worth billions. The harness is.

The Claude Code leak tells us that the agent harness is the product. Models, Disler argues, are being rapidly commoditized: many companies are building ones that perform similarly. The harness is the part that is hard to copy.

Three tiers: orchestrators, leads, and workers

Think about how a large construction project works. There is a project manager who decides the strategy. There are site managers who coordinate each crew. And there are the workers who actually pour concrete and lay bricks. The project manager never touches a trowel. That is not their job. Their job is to think, plan, and delegate.

Disler's agent system follows exactly this logic. He calls it a three-tier architecture: one orchestrator, multiple team leads, and hyper-specialized workers.

• The orchestrator takes your single input and decides how to divide the work. It knows how to prompt the team leads. It does not write code itself.
• Team leads receive instructions from the orchestrator and manage their group of workers. Like the orchestrator, they think and delegate rather than build.
• Workers are hyper-specialized agents. Each one does exactly one thing very well: one generates views, another handles animations, another validates the output.

In his demo, Disler runs 15 agents in the full configuration (or 9 in the reduced version used for the video). Here is what actually happens when you send a message: you type one prompt into a chat interface. The orchestrator reads it and writes a full, detailed prompt for each team lead, including variables, instructions, and a workflow. Think of it as a manager who receives "build me three new dashboard pages" and turns that into a specific project plan for each crew.

The team leads then create what Disler calls a till done list: not a regular to-do list, but a list of tasks the agents work through until every item is finished. If a task fails, it stays on the list and gets retried. The system does not stop at "good enough." It keeps going until the list is empty.

Some workers in the demo use Claude Sonnet 4.6 (Anthropic's AI model), while others run experimental open-source models like Minimax 2.7 and Step 3.5 Flash. During the live demo, the open-source models failed to respond entirely. What happened next illustrated the whole point of the architecture: the team leads recognized the workers were not delivering, broke their own rules about not writing code, and did the work themselves. As Disler put it, if a worker falls through, the lead gets the job done, exactly like a real engineering team where the senior developer picks up a failing task rather than letting the project stall.

You send one message to the orchestrator. The entire team springs into action in parallel. You did not scale up your effort; the architecture did.

Agents that learn and stay in their lane

One of the more striking details in Disler's system is that each agent maintains its own mental model: a file where the agent tracks everything it has learned about the project. All the agent gets from Disler is a short skill (about 75 lines) that explains how to maintain the file. What to actually write in it is entirely up to the agent. One agent's mental model had grown to 7,000 tokens (roughly 5,000 words) of accumulated knowledge: notes on design decisions, lessons from previous builds, ideas for improvements, and a running record of completed work.

This means the agent is not starting from zero each session. When Disler boots up his agent team, each agent already knows the codebase, the brand, and the product's history. Compare that to a regular Claude Code session where the agent reads your project fresh every time. An agent that remembers outperforms one that forgets.

The other key discipline is domain restriction. Each agent's configuration file specifies exactly which folders and files it is allowed to touch. A view generator only works on frontend components. A validator only reads output and checks it against rules. An animation specialist never touches the database. One agent, one prompt, one purpose is a massive advantage in multi-agent systems. When an agent tries to step outside its defined area, the system marks it with an X and blocks the action. Keeping agents focused keeps output consistent and trustworthy.

Claude Code as a meta-builder

Here is the part that flips the usual mental model about AI coding. Most people use Claude Code to build their product. Disler uses it to build the system that then builds the product.

He spends 80% of his time in Claude Code as a meta-builder, meaning he is using Claude Code to engineer the agent harness itself, not to build the end product directly. The specialized Pi agent teams he deploys are the output of that harness-building work. Once the harness exists, the team can generate new UIs, new features, and new prototypes without Disler touching them individually.

The analogy here is a factory versus a workshop. A workshop craftsperson makes one chair at a time. A factory owner builds the machines that produce chairs continuously. Building the system that builds the system is factory thinking applied to software. You invest time once in the harness; you collect results indefinitely.

Disler frames this around what he calls the core four: the four things you control for every agent. They are context (what the agent knows about), model (which AI model it runs), prompt (its instructions), and tools (what it can do in the world). When you own the harness, you control all four for every agent in the system. When you use someone else's tool as-is, you control almost none of them.

This also changes what it means to write a prompt. In a well-built harness, your prompt talks to the orchestrator, which knows how to translate your intent into instructions for each team. You are not prompting an individual agent to do a task. You are directing a team that already knows your domain.

Harness engineering as the most valuable skill

There is a concept Disler contrasts with harness engineering: vibe coding. Vibe coding means casually prompting an AI, hoping it produces something useful, without any structure, planning, or engineering discipline. It works for quick experiments. It does not scale.

Harness engineering is the opposite. It means deliberately designing and building the infrastructure that controls your agents. When you own the harness, you control the context each agent sees, the model it uses, the tools it has access to, and the domain it operates in.

The opportunity Disler points to that brings this all together is agentic security. Because AI agents can now be used to automatically probe and exploit software systems, the demand for agents that defend those same systems is enormous. When agents can attack at scale, you need agents that defend at scale. The engineers who can build specialized harnesses for security domains are sitting at a rare intersection of skills.

The theme of 2026 is increasing the trust you have in your agents to do larger scales of work over time. That trust is not built by using a better model. It is built by engineering a better harness — one that is specialized, disciplined, and designed to deliver consistent results across an entire problem class, not just a one-off task.

Glossary

Sources and resources