Why Your AI Harness Matters as Much as the Model
The model will keep changing, but the system around it is what truly improves your work.
Every time a new AI model comes out, the same race starts again.
People compare benchmarks, post one-shot demos, switch subscriptions, and tell you the model they were praising last month is already old news.
I’m sure you’ve seen plenty of people write over-the-top headlines like these: “OpenAI just killed 1,000+ startups,” “Anthropic is DONE,” or “Local models are the future.”
And if you use AI every day, it’s hard not to feel like you should keep up. Otherwise, you might feel like you’re going to get left behind.
This makes us feel guilty for not keeping up, so we switch models every once in a while. But switching models just because the new one is better does not fix the problem on your AI setup around your work.
The new model still needs to understand your AI setup. It still requires the right files, instructions, tools, permissions, and checks. If any of those pieces aren’t properly built, you’ll end up re-explaining the same task to a more intelligent model. But what you do is still the same—like a caveman who keeps repeating the same prompt just to re-explain your context.
I recently heard Matt Pocock compare the model to the engine in a Formula 1 car.
Matt is one of the AI creators I respect because he shares something real, his opinions are grounded, and he avoids the hype, focusing instead on what actually matters: building the right system for the agent.
But that doesn’t mean he ignores how important it is to have a better engine for the model. After all, the engine matters and makes a big difference. Because when you replace it with a stronger one, the whole car gets faster. But what most people tend to ignore is that the chassis, aerodynamics, controls, and feedback from the track still determine whether that power actually helps the driver win the race.
AI works in a similar way.
But what’s happening is that most people treat the model as 90% of the result, when in reality the model and the harness are closer to 50/50.
The model gives the agent its ability to reason, write, and make decisions. The harness gives it the right instructions, information, tools, boundaries, and feedback for the work in front of it.
While the model is the half you can’t control, the harness is the half you can control.
And this completely changes how I use AI.
The reason is because I’ve seen this in my own newsletter setup.
I move between Claude Code, Codex, and local models. Even though the models change, what makes my system work carries across: the files that explain my publication, the rules that protect my voice, the skills that run repeated workflows, and the checks that catch low quality AI outputs before it reaches me.
That difference shows up in what I no longer have to explain every time. When I ask the agent to help with a newsletter, it already knows who I am writing for, how my free and paid posts differ, which sources to read, and which claims may need more evidence.
That does not mean the agent writes exactly like me or makes the final editorial decisions. It gives me a much better starting point. I spend less time rebuilding the brief and more time deciding what the post should argue, which examples feel honest, and whether the writing is ready for readers.
So, the point I’m trying to make here is while it’s true that model choice still matters, what most people ignore is whether they’ve built the right setup for their agent.
That right setup is the harness.
What an agent harness actually is
The word harness makes this sound more complicated than it needs to be.
Claire Vo gave the simplest explanation I have heard: a harness is code around an AI agent that makes it better at a specific job.
But, I would expand that slightly:
An agent harness is the system around the model that helps it perform useful and reliable work consistently.
While the model supplies the intelligence to reason through a problem, decide what to do next, and generate a response, the harness supplies the conditions that let it apply that intelligence to your actual work.
In practice, harness has five parts:
1. Instructions
These define the job. They tell the agent what it is trying to accomplish, how it should approach the work, and which rules it should always follow.
A general instruction might say, “Write a client update.” A harness can already know what belongs in the update, how detailed it should be, and which claims need evidence.
If you have been using Claude Code, Codex, or any other agents, the “instruction” we refer to here is actually the CLAUDE.md and AGENTS.md files.
I spoke about this a lot in my agent guide. This system instruction file is essentially the brain of the system. It tells the agent what to do whenever you work inside your project folder.
2. Context and source material
This is the information the agent needs before it begins. It might include the client’s background, context about who you are and what you do, your previous decisions when running a project, examples of high‑quality work, current project files, or the data behind the task you are working on right now.
Without that context, even a strong model has to guess. Or you have to brief it again.
In my ultimate guide to building a context folder, I strongly emphasize taking your time to fill it out, because context makes the agent’s answers more personalized to you and better suited to your current situation.
With the right context, you’ll be far less likely to get generic output from the agent.
I like what Thariq from the Anthropic team said about this:
This resonates the most with how I’ve been using AI agent.
The right context for your agent can help you move mountains by equipping it with the right data to execute any kind of task more effectively.
3. Skills and tools
Instructions tell the agent what to do. Skills and tools give it ways to do the work.
That could mean searching the web, reading a spreadsheet, checking a database, updating a document, running code, or following a specialist review process. The harness decides which capabilities are available and when the agent should use them.
This explains why I’ve been going hard on how to combine tools and skills, as you can see from some of my previous posts:
How I Run My Entire Notion From Claude Code (Without Clicking Around)
I Rebuilt My LinkedIn Carousel System, It Now Looks Like A Designer Made It
Once you’ve connected your agent to tools and can execute them through skills, you no longer need to use those tools separately or jump between them. With these two combined, the agent becomes more reliable at generating outputs that live up to your standards.
4. Permissions and guardrails
An agent also needs boundaries: Which files can it change? Can it send the email, or should it only draft one? Can it publish the result? Which actions require approval?
These rules become more important as the agent not only generates text, but also performs work inside your tools and modifies your files.
Without these, things can quickly turn into a disaster, with the agent deleting forbidden files, including scripts, emails, and any working documents. Permissions and guardrails ensure that you are always the one steering the agent—not the other way around.
5. Checks and feedback
The first output of the agent should not automatically become the final output.
A harness can check whether the result follows the required format, uses the right evidence, passes a test, or needs another review. That feedback goes back into the process so the agent can fix predictable problems before they reach you.
Put those five parts together and the difference becomes easier to see.
In case you want to take a deeper look on how to improve your agent harness, I already covered it in my previous post.
Now that you understand what the harness is, you’ll start noticing that you already interact with harnesses every day through tools like Claude Code, Codex, or Cursor.
The harness is already shaping your results
When you use an AI coding agent, you’re rarely interacting with the model alone, because the model has been improved by the harness:
Anthropic describes Claude Code as “the agentic harness around Claude.” It gives the model tools, manages the information entering the conversation, and provides the environment where it can read files, edit code, and run commands.
Cursor defines its harness as the combination of instructions, tools, and the chosen model. Its team adjusts those instructions and tools for the different models Cursor supports.
OpenAI documents a similar surrounding layer for Codex. You can use
AGENTS.md, skills, memory, and connections to other tools to shape how Codex works inside a project.
This helps explain why the same model can feel different depending on where you use it. One tool might give it better access to your files. Another might load your instructions more reliably, handle permissions more clearly, or provide better ways to check the result.
The companies building these tools give us the starting harness. Then we add the layer that makes it specific to our work.
And those improvements built on top of our agent can continue working effectively even when the model changes.
Why an AI agent harness compounds across models
Matt said he tries to keep his harness as model-agnostic as possible. So do I.
That means he avoids building an entire way of working around the quirks of one model. He focuses on the parts that should remain on his control: clear instructions, good source material, a codebase the agent can understand, sensible guardrails, and feedback that shows whether the work succeeded.
But carrying the harness forward does not mean you don’t need to tweak them. Ryan Lopopolo recommends testing the surrounding setup again whenever the model or coding agent changes. Your sources, rules, and quality standards may remain useful, while some instructions or checks need adjustment. A stronger model may even let you remove parts you previously needed.
This is where a harness starts to compound.
1. The next model should start ahead
Imagine you spend a month working with an agent and correcting the same problems. You explain how you want reports structured. You clarify which actions need approval. You catch a mistake in the review process and add a check so it gets caught earlier next time.
If those lessons stay locked inside a single agent, most of that work disappears when you switch to another agent that just released a better model.
But if you turn those lessons into instructions, skills, source files, and checks, the next task starts from what you’ve already learned—and so does the next model.
Again, I’ve seen this in my own setup. Claude Code and Codex follow different instruction files and handle parts of the work differently, but the underlying foundation is the same. They can read the same audience research, publication principles, past post archives, and task-specific skills. They can work against the same quality standards even when the model or tool changes.
So when a better model arrives, I do not have to rebuild the publication around it. I can place that model inside a system that already understands how I work.
A concern note by Dr Sam Illingworth expressed this clearly:
Since I’m currently in a model‑agnostic mode and my AI projects live locally and on GitHub (Cloud), I’m not afraid if frontier labs suddenly increase their costs, because I can just switch to another model or go local completely without sacrificing much in terms of the quality of my work.
For me, I don’t worry too much about the specific model and instead focus on the harness. If a model breaks (whether from cost or system issues), I can easily switch it out. But if a new, better model comes along, it becomes a multiplier on top of the same harness.
2. A better harness can make cheaper models useful
This can also change the economics. Matt argues that a clearer codebase and stronger guardrails can sometimes help a cheaper model complete work that would otherwise require a more capable one. The agent spends fewer tokens searching through a mess, misunderstanding the task, or repeatedly correcting avoidable mistakes.
The same principle applies outside coding. If an agent gets the right client files, a clear process, a limited set of tools, and an expected output format, it has less room to wander. More of its intelligence goes toward the judgment the task actually requires.
And the harness can keep improving after the work begins.
3. Review the system, not just the output
When I review an output, I’m also learning something about the system that produced it. Every time I find a bad output from my agent, my first assumption is that it might reveal an issue: a vague instruction, a missing source, a skill that loaded at the wrong time, or a check that doesn’t have clear criteria for what to validate.
This is why it’s important for us to have a process to review not only the final output, but also the system underneath them. That visibility helps you improve the harness over time and decide where the agent can safely do more without you.
This is the part I find more valuable than chasing every model release.
Every correction can become a clearer rule. Every repeated process can become a reusable skill. Every failure can produce a better check. Each improvement becomes part of the starting point for whatever model comes next.
That is how the system compounds.
And you might be wondering what the final goal is with all of this.
For me, the goal is to remove myself from the day-to-day work of handholding and steering the agent. I want to give it a simple prompt, have it know what to do, and receive work that already meets my quality bar.
I am not there yet. I still make the final editorial decisions and review what goes out. But I want the agent to arrive much closer to that standard without me guiding every step.
How one newsletter moves through my harness
The easiest way to understand my harness is to follow my newsletter through the system.
Plan and research
My content calendar lives in Notion. It keeps track of the ideas I am considering, the posts I have decided to write, and where each piece stands.
When I choose a topic, I can use X as a research source. The agent searches recent conversations and posts from people I trust, then pulls useful examples, recurring questions, objections, and source links into a research brief.
That research still needs judgment. A popular post is not automatically good evidence, and a repeated opinion is not automatically true. But the harness gives the agent a defined research process instead of sending it into X to collect whatever looks interesting.
I also have a skill that deploys multiple sub-agents to read all the newsletters I subscribe to and generates summaries for me: what happened this week in AI, which new tools I need to try and why, what the current meta-trends are, what people are saying about these new AI tools, and new ideas I can write about based on what’s happening right now.
It helps me stay up to date with everything happening in AI without feeling overwhelmed by trying to keep up with major news every single hour.
Draft and review
When the agent begins writing, it already has the files explaining my audience, publication, voice, and content rules. It knows where to find previous posts, which sources support the argument, and which claims need to be checked.
After the first draft, I can send it through a review panel made up of sub-agents with different jobs. One reads as a skeptic and challenges weak claims. Another looks for structural and pacing problems. Others respond as a first-time visitor, paying subscriber, content creator, knowledge worker, or entrepreneur.
A moderator agent then compares their reviews, finds the problems several readers noticed, and makes a judgment when the reviewers disagree.
I still decide which feedback is right. The panel gives me more useful material to make that decision without asking me to catch every problem alone.
Package and repurpose
Once the newsletter is approved, it becomes the source for the rest of the promotion.
One process can create the promotional email. Other specialist agents can extract one strong LinkedIn angle, several standalone Substack Notes, and an X thread. Each format follows its own rules, so they do not become shorter copies of the same article.
The visuals have their own processes too. The infographic generator reads the finished post and turns its main ideas into a visual explanation. The thumbnail generator looks for the central transformation or metaphor and creates several symbolic directions for the cover.
All of those outputs begin with the same argument and evidence, but each one has a different job.
Approve and distribute
The agent can prepare the promotional material, but I still approve what gets published.
Once the social posts are ready, I can send the approved X and LinkedIn drafts to Typefully, attach the right visual, and schedule them. I can then update the content calendar in Notion so I know what has been created, reviewed, scheduled, or published.
The value comes from the whole sequence. I am not opening each tool, pasting the newsletter again, restating the audience, and explaining the standards from the beginning.
If I change models tomorrow, this process can remain. The next model can use the same content calendar, research method, publication files, review panel, visual skills, platform rules, and approval points.
That is what makes the harness more valuable over time. Each new model enters a publishing system that already knows how the work moves.
Build the part you control
Another model will arrive soon.
It will score higher on a benchmark, complete a task the previous model struggled with, and make something that took an hour feel strangely easy.
I will probably test it. You might too.
Better models are useful. I just do not want each release to send me back to the beginning.
The model company decides how intelligent the next model becomes. I decide what that intelligence finds when it enters my work.
Does it find a blank chat box and wait for another long explanation?
Or does it find clear instructions, trusted sources, useful skills, sensible boundaries, and a review process shaped by all the mistakes I have already made?
That is the part worth building.
Start with one job you repeat
You do not need to build every layer at once.
Pick one job you already use AI for every week. It could be a client update, research brief, newsletter, meeting summary, or weekly report.
Then give the agent a small system around that job:
Write one sentence explaining what the output should accomplish.
Add one trusted source the agent should always use.
Include one example of a good result.
Save the instructions you find yourself repeating.
Decide which actions still require your approval.
Define one check the result must pass before you accept it.
Run the task once. When the agent misses something, save the correction with the rest of the instructions instead of leaving it inside that conversation.
The next attempt will begin with one more lesson about how you work. That is enough to start the compounding loop.
Your first harness can be one document attached to one repeated job. You can add more sources, skills, tools, and checks when the work proves that you need them.
If you want to turn that starting point into a working Claude Code harness, I have documented the version I use.
In How an Agent Harness Made My Claude Code Setup 10x More Reliable, I walk through the four layers behind it:
Memory that carries repeated corrections across sessions.
Hooks that run quality checks automatically.
Agent orchestration that gives different jobs their own focused process.
Evaluation loops that review and repair work before it reaches you.
The model will keep changing. Give the next one a better system to enter.
I’ve been working on the harness piece of my own setup since I understood the importance of context documents. As you said, better AI results come as much from the system surrounding the model as from the model itself.
I think a lot of people still don’t understand what a “harness” means for them. For me, the value isn’t in having the smartest model or the most automation. It’s in building a clear environment around AI so the model itself is never the foundation (and can be changed without taking the whole system with it).
Amazing post Wyndo. I am seeing more and more people pay attention to harnesses now. Even people were saying that GPT feels better in Claude Code and Claude feels better in Codex. Things like that appear because models behave differently under different harnesses!