Transcription
AI harnesses are the thing shaping your working life that none of us are talking about enough. When you use an AI coding agent like Claude code, like codeex, like cursor, or when you use a chat window like chat GPT, you're interacting with two things at once. There's the model, which is the intelligence, the part that understands your request, the part that generates the response, and that's the part that everyone tends to compare, right? That's what the headlines are fighting about.
Then there's everything else. Where does the AI actually do its work? Does it do its work on your computer? Does it do its work on a server somewhere? When you close your laptop and come back tomorrow, does the AI remember what you were building, or does it start over like you've never met? Can it reach into your project management tools, your design files, your test systems, or is it all sealed off? When you needed to do five things at once, does the AI coordinate those tasks like a team, or run each one in a separate room with no communication?
All of what I've just described, the everything else, that's the harness. And it matters much, much more than the model these days because the model determines how smart your AI is, but the harness determines how it fits into your work. And it matters much, much more than the model because the model only determines how good your AI is at predicting the next token. The harness determines how usefully it fits into your work, how it collaborates with you, what it can touch, what it remembers, how it fails, what happens when you want to switch to a different tool in 6 months. The harness is what you have a relationship with, whether it's a personal relationship, which some people have, or a working relationship. The model is like a brain in a jar, and it's not getting a lot done without the harness.
Nobody compares harnesses. Every comparison you've read this month, I'm willing to bet, whether it's about Claude versus Chat GPT or Gemini 3.1 Pro versus the previous version of Gemini, they're all just comparing sort of those brains in a jar. And that's because it's really hard to test harnesses. It's rare to test them. It's rare to talk about them. And it's easier to talk about the total package and to attribute all of the value and the work product that you get as if that little brain in a jar is doing the work.
Now, this would be a really minor blind spot if all of the harnesses in AI were roughly the same. And a lot of people assume that's basically what happens. I think that people have this mental image that it's like this special brain crafted by OpenAI or Clawude and then the the body quote unquote is just like a Frankenstein and it doesn't matter. That's not how harnesses actually work. Harnesses are diverging really fast and they're diverging on purpose. Claude Code and Codeex, for example, are not two flavors of the same thing. And that's not just because of the models. They actually embody fundamentally different ideas about how humans and AI work together. One will sit in your actual workspace with access to everything on your machine and build up memory of your project over time and the other will work in a sealed room with a copy of your code. Think privately and slide finished results under the door. One is a collaborator at the desk next to yours and the other is a contractor in a clean room. Those aren't really about your preferences. is those are architectures for what the model makers think is an effective solution long term. And the thing about architectures is that your team consciously or unconsciously builds around them. The habits, the processes, the verification steps, the integration, plumbing, all of it accumulates around whichever harness you choose and it gains value every month. If you switch harnesses, it's not just your team learning a new model, it's your team rejigging their entire process. everything resets to zero. That's the lock in nobody is pricing into their decisions today. It's not really vendor subscription lockin. It's lockin to a model makaker's philosophy of how work should happen as expressed through a harness.
On February 5th, Enthropic and OpenAI both released new flagship coding models on the same day. Claude Opus 4.6 for Anthropic and GPT 5.3 codecs for OpenAI. I've been tracking the developer community's response for the last few weeks and the models are converging on capability. The problem is the harnesses are not the harnesses are diverging and that matters. The divergence is the real story in this comparison and everyone's talking about the model. So what does harness diversion actually look like? What does it cost when you see it? And why is this one of the more interesting tool decisions that we're not talking about?
Before we go any further, one number makes this thesis really pop out because you might think, "Oh, Nate's just talking, right? Like the brain in a jar is what matters. This isn't really a thing." But at the AI Engineer Summit just this January in 2026, Enthropic presented results from the core benchmark, which tests agents ability to reproduce published scientific results. The same Clawude model, identical weights, identical training, scored 78% on that benchmark when running inside Claude codes harness, but it scored 42% when running inside small agents, which is a different harness built by another startup. Same brain, different body, nearly double the performance. That's not a marginal difference explained by prompt engineering. It's a structural difference explained by everything that the harness does. how it manages context, how it hands off state between sessions, how it connects tools, how it verifies results. The harness is not an optimization layer on top of a model. It's a performance multiplier that determines whether the model's intelligence actually translates into useful work.
Now, the two harnesses that matter most right now are making very, very different bets about what that body should look like. First, Anthropics engineering team published a detailed account of the problem their harness was built to solve. They framed it really vividly. Imagine a software project staffed by engineers working in shifts where each new engineer arrives with zero memory of what happened on the last shift. That's what happens when an AI agent works across multiple context windows. The model is smart, but it starts each session really truly from a blank page. Enthropic solution was structural, not just prompting. Claude codes harness uses a two-part pattern. An initializer agent that runs first to set up the project which it creates a structured feature list, an initiation script, a progress log, and a clean commit. And then in addition, a coding agent that runs in every subsequent session, making incremental progress on one feature at a time and leaving structured artifacts for the next session. If you're wondering as a non-coder why you should care, this is basically what's inside co-work from Anthropic today. Same thing. The progress file and git history become the agent's institutional memory. Every session begins the same way. You read the progress log. You check the git history. You run the basic test to confirm nothing is broken. And then you pick the next feature and start. The key design choice is that the harness forces incrementalism. If left to its own devices, the model tries to build everything at once. Enthropic calls this oneshotting and runs out of context mid-implementation, leaving the next session to guess at half-finished work. The harness prevents this by structuring the task list into a single JSON. Ironically, not markdown because apparently the model is less likely to corrupt a structured data format like JSON as a task list and then prompting the agent to work on exactly one feature per session. The harness also forces verification. The agent uses browser automation tools like the Puppeteer MCP server to test features end to end the way a human would catching bugs that unit tests miss. If you're not a coder, you can see this obsession with planning in co-work publishes a sequential series of tasks and then goes after those tasks with sub aents. So this is the architecture beneath the surface of cloud code. It runs in your actual terminal in your shell, your environment variables, your SSH keys. Anthropics engineers describe this philosophy as bash is all you need. If you're an engineer, you'll chuckle here. Rather than building dozens of specialized tools, the agent uses composable Unix primitives like GP and get and npm and chains them together to make netnet very useful tools on the fly. This keeps the context window super lean because tool descriptions are expensive and it gives the agent access to everything a human engineer would have. The tradeoff is that the trust boundary is your entire workstation. You have to trust it with your computer.
Now, OpenAI's harness engineering team arrived at a different architecture from a different starting point. They published a detailed account of building a million line internal product over five months using only codeex agents. zero lines of manually written code, roughly 1,500 pull requests, initially driven by just three engineers. Their central insight was almost the opposite of what you'd expect. Early progress was slower than anticipated, not because Codeex couldn't write the code, but because the environment was underspecified. The agent lacked the structure, the tools, and the feedback mechanisms to make progress toward highle goals. OpenAI's response was to make the repository the system of record for everything. Architecture decisions live there. Alignment threads live there. Product principles live there. Anything not in the repo was illeible to the agent and therefore did not exist. They tried the one big agents.mmarkdown approach and it really failed when everything is marked as important. Really nothing is. And the file rots immediately in a graveyard of rules. Instead, OpenAI decided to build a progressive disclosure system of focused cross-lin documentation that the agent could navigate. They enforced a rigid layered architecture with a lot of validated dependency directions and limited permissible edges and checked everything with a bunch of llinters which were themselves written by codecs. The llinter error messages handily doubled as remediation instructions. So when the agent violated an architectural rule, the error told it how to fix the violation. So this is the structure that's underneath the surface of codec. And we know this because they've told us, right? I'm not telling you something secret. It's out there. It runs tasks in isolated cloud containers. Your code is cloned into that container. Internet access is disabled by default. And the agent works independently. Where cloud code gives the agent full access to your environment and manages the risk through incrementalism and human oversight. Codeex constrains the agents environment and manages the risk through isolation and really mechanical enforcement. Where anthropics harness makes the agent remember, open AIS makes the codebase remember. Both are interested in solving the same problem. How do you get reliable work from an AI across many sessions, but they solve this problem through genuinely different theories of where institutional knowledge ought to live?
Calvin French Owen, who helped launch the Codeex web product and now uses both tools extensively, describes the practical result. He picks his coding agent as a function of how much time he has and how long he wants it to run autonomously. He uses claude code for planning, orchestrating his terminal, and explaining how parts of the codebase work. Opus will spin up sub aents simultaneously, delegate exploration to very fast haiku instances, and in Calvin's words is more creative in terms of suggesting things the developer forgot to mention. Codeex is for the actual code because according to Calvin, the Codeex code just straight up has fewer bugs. So he starts with Claude code and keeps it open and then flips to Codeex when he's ready to implement. Every so often he has Codex review Claude's work and it catches mistakes that Claude missed. So Calvin doesn't view these as interchangeable tools at all. Instead, he views these as complimentary architectures that reward different kinds of investment. The harnesses shape how he can use these products.
So, what is inside these harnesses that diverges that makes them so different for work? I have not found anyone talking about this simply and plainly. And so, I'm just going to say it. The architectural gap between these platforms isn't just one thing. It's at least five things, all compounding simultaneously in different directions. And the primary sources from both companies reveal how deliberate and differently motivated these choices are.
First, we're going to talk about how execution philosophy is diverging. Enthropic's position is very deliberately bashes all you need. Then building a lot of specialized tools with long descriptions. Claude code gives the agent access to just Unix primitives like GP and get and lets it chain them together with pipes. So a single line of bash can query a database or filter results or write them to a file. This is much cheaper in tokens than writing three separate tools and much more flexible. The ML6 team's analysis showed that the GitHub MCP servers 38 tools consume 15,000 tokens worth of tool descriptions. The GitHub command line interface achieves the same functionality with far fewer tokens in the context window. In other words, the GitHub command line enables a creative tool using agent to get so much done with just the Unix primitives that it can work around many of the specialized tools that enterprises and even other hyperscalers tend to think an AI needs. And that's just the execution philosophy anthropic brings to the table.
On the other hand, OpenAI wired Chrome DevTools protocol directly into the codeex agent. at runtime which gives it access to DOM snapshots to screenshots to navigation capabilities so it can reproduce UI bugs and validate fixes by actually driving the application. They also gave every codeex agent its own ephemeral observability stack. Victoria logs and Victoria metrics spin up per Git work tree and disappear when the work is done, letting the agent query logs and metrics right in session. A prompt like make the service start in under 800 milliseconds becomes a testable acceptance criterion because the agent can actually measure startup time. And if the agent can't measure it, it can't improve it. Both of these philosophies give the agent hands, but one gives it your hands full access to your actual environment, composable, powerful, and exactly as dangerous as that sounds. and the other builds it custom hands in a controlled room which is safer by default but less able to reach the tools you already use. This is part of why I think codeex has to have more tools built by default because codeex doesn't have access to your local system.
What about state and memory? How does that diverge? The enthropic harness solves the cross- session memory problem with structured artifacts. So their engineering report describes a progress file like cloudprogress.ext text that every coding agent reads at the start of a session and updates at the end, plus a feature list stored as JSON. These files combined with respective git commits create a trail that any new agent instance can follow to figure out where the project stands and what's next to do. Developers who invest in artifacts like claw.md files end up building a compounding asset. The more context accumulates, the better every subsequent cloud session works. OpenAI's approach pushes institutional memory into the repo. Anything not in the repo is illeible and doesn't exist because remember the agent is operating in the sandbox. So architectural decisions, bug principles, all of it gets encoded as documentation. Interestingly enough, OpenAI discovered an entropy problem unique to agent generated code. Codeex replicates whatever patterns exist in the repo, including uneven or suboptimal ones, and this inevitably leads to drift. Their initial response was spending every Friday manually cleaning up what they called AI slop that didn't scale. To address this more scalably, they encoded golden principles into the repo and built automated cleanup processes where background codeex tasks scan for deviations and open targeted refactoring PRs. This enables the repo eventually to police itself. So, one harness makes the agent remember, the other makes the codebase remember. Both can work, but neither one transfers very cleanly to the other because all the investment your team made in a claw.markdown file is not very helpful to codeex, which was trained to look at the repo.
Context management, that's another place these harnesses diverge. Both companies learned the same lesson about context. More isn't better if it's not curated. Open AAI tried the one big agents.mmarkdown approach and it failed. Anthropic arrived at a similar principle from a different direction. Rather than loading all available tool descriptions into the system prompt at the start, Claude stores tools and skills as files on the file system because it has access to your local computer and it lets the agents retrieve them just in time. And so a tool search tool lets the agent semantically search available capabilities instead of having them preloaded. The practical difference here is that cloud code tends to manage context through compacting the context window and through delegating to sub aents. So that means it will automatically summarize older contexts and it will spin up parallel agents that each get their own window to keep things clean. Codeex has more isolation. So each task runs in a nice clean sandbox and tasks don't compete for space. This implies that cloud is often better when one task needs deep understanding of a codebase and codeex is better when you're running very independent tasks in parallel and you want to be able to burn tokens against those tasks without polluting a central context window.
What about tool integration? Anthropic created the model context protocol or MCP which is the fundamental open standard for connecting AI agents to external tools. It's backed now by OpenAI, by Google, by Microsoft, by by everybody. It's governed by the Linux Foundation. Claude Code was built around MCP from the get-go. But the more interesting harness insight is how both companies handle the cost of tool integration inside the context window. Enthropic introduced skills, which are really just markdown files and scripts stored on the file system. The agent only sees the short names and descriptions of the skill, basically the first 50 or 100 tokens, not the full instructions, which can stretch into the thousands of tokens. That means the agent reads the full skill definition only when it decides to use one. This is context management as harness design. The tool integration layer is deliberately architected to be stingy about tokens. OpenAI's Codeex app server takes a very different approach. It's a birectional JSON RPC harness that runs alongside your stack and exposes tools like get or testr runners or Chrome dev tools or app logs or metrics as RPC endpoints. The agent then calls into those tools programmatically. The harness can spin up per workree instances and capture screenshots and DOM snapshots and use those signals to validate fixes. The integration is deep but the architecture assumes the agent is working in that server mediated environment in the cloud not on your machine. So both tools speak MCP but the integration philosophies are super different. In fact they're so different that Composio's testing team had to build a custom proxy adapter to get codecs working with Figma and Jira MCPs. When you're integrating AI coding agents into enterprise tool chains where the agent needs to read from Jira and push to GitHub and update Slack, the implementation depth beneath the protocol matters as much as the protocol itself.
Finally, I want to talk about multi-agent architecture. Claude Code's agent teams spawn multiple sub aents that each get a dedicated context window with shared task lists and dependency tracking. One sub agent builds the API while another one builds the front end while a third one writes tests and they can message each other along the way. The explore subtool uses a very fast cheap model haiku to process large volumes of code and hand that all back to opus for decision-making. This is very much an orchestrated collaboration model. A coordinator manages the workflow and the system is designed to keep a human in the loop as the strategic overseer. Codeex's multi-agent approach runs each task in its own isolated sandbox. So coordination happens through the codebase itself, typically via get branches that get merged. OpenAI's experimental sub aent support is getting better, but Calvin French Owen notes that parallelism still isn't quite there yet compared to how Claude Code handles delegation. The trade-off is that Codeex's isolation model is inherently much much safer for autonomous operation. agents can't interfere with each other and they can't access each other's state and they cannot cascade failures.
The one-year retrospective from Emergent Minds, one of the most detailed practitioner accounts of Claude Code's evolution, documents this divergence in real time. The author describes five distinct eras of the tool over the last year, each making the previous approach look primitive. Community workarounds like roadmap.mmarkdown or ultrathink or scratchpad were systematically absorbed into native harness features in cloud code over the course of the year or making cloud code better guys. His meta observation is that quote the CLI tooling layer doesn't have a moat. Any good pattern gets absorbed into the product. So the harness is evolving fast and on all sides. The question isn't which harness is better today. It's which harness's evolution trajectory matches where your team is headed.
Here's where this stops being just like a tool comparison and now this becomes a strategy problem. Calvin French Owen skill evolution tells you a lot about how harness lockin actually compounds and affects teams. He started by just adding a slash commit skill just telling the model to commit and push in a consistent way. But then he needed agents working in separate work trees. So he added slashworkree. And then he noticed he always planned first. So he added /implement when he wanted to get started. Then he started chaining implement calls. And eventually he added implement all to make implementation easier. You can see he's just building out his environment. He had multiple layers of workflow automation, at least six. Each one built on the previous one. Each one specific to Claude Code's harness architecture, its skill system, its context forking, its sub agent model. Moving to a different harness then didn't just mean learning new commands. It meant rebuilding the entire compounding chain of automation from scratch in an architecture that may not even support the same abstractions. Now multiply that small challenge times every engineer on the team, every project they touch, all of the markdown files they've accumulated, all the MCP connectors they've deployed. That's the lock in that people aren't pricing when they talk about models. And that's why it's so important to understand harnesses. The organization's building workflows around these tools. They're not just adopting a subscription, right? They're building institutional knowledge and process documentation and verification protocols around a specific agent architecture.
This is somewhat analogous to the early cloud wars. In 2010, you could have told an enterprise that AWS and Azure were basically the same because they both offered virtual machines and object storage. You would have been technically correct and strategically incorrect. the organizations that understood the differences between those architectures that grasped how AWS Lambda would reshape application design differently than Azure functions. Those organizations understood enough to make the correct decisions and that is why I'm talking about harnesses today because we need the same level of fluency around AI. We are in the 2010 era of AI coding tools. The models look similar in benchmarks. The architectures are separating and diverging along lines that will determine what's possible with a given architecture in 2 years in 2028 and procurement decisions are being made by people who are looking at benchmark scores or think that the models are all it takes.
So what does this mean for you? If you write code for a living, the era of picking one tool is ending. The developers who are extracting the most value today are using both platforms and routing work based on what the task needs and how much time you have. I talked about Calvin French Owen's workflow. There's lots of other workflows that include both codeex and claude code. The skill isn't in using either one of those tools. It's actually knowing which harness's disposition matches the kind of work you're doing today. And that's why I've spent so much time in this video talking about in detail how these harnesses work.
If you lead an engineering team right now, the decision you're making is not which tool do you standardize on. It's which architectural philosophy are you going to organize the team around? And if you're going to build a hybrid workflow, how do you intelligently hand off work across that boundary? That is very much a process design problem, not a procurement problem. How does your team handle task routing right now? Do you use one agent to check another's work? Are you investing in cloud.mmarkdown files? How do you handle the security implications of claude code's full access local execution versus codeex's sandbox isolation? These questions don't appear on any vendor comparison chart, but they should be in the back of your mind as an engineering leader. The organizations that get this right will not only treat the harness decision as an architectural commitment, but I'm just going to tell you, you're going to be making decisions that will shape how the rest of us non-technical knowledge workers will experience the world in the second half of 2026 because these harnesses are leaking into the rest of knowledge work. That's why I made the reference to co-work in this video. Claude code was the foundation for co-work. Co-work is basically a skin over clawed code for knowledge work and it's becoming hugely popular for a reason. So we should expect these harnesses and these fundamentally different architectural approaches to leak into the rest of marketing and product and customer success going into the rest of 2026.
If you're a non-technical senior leader and you're making budget decisions about these tools, you got to understand your team is not asking you to buy a wrench. They're asking you to commit to a workbench, one or two of them, and really a way of organizing the relationship between humans and AI agents that will shape your velocity across the business, that will shape your security posture, that will shape your ability to hire and your switching costs for years to come. So, the right question cannot be which tools the cheapest. It needs to be which architectural philosophy matches how the team works and how much does it cost us to change our mind. The answer to the second question is typically a lot and it goes up every quarter because every quarter your team is building more infrastructure around the current architecture that you've chosen.
Look, the question everyone has been asking which model is best. I keep saying it's a 2022 or 2023 question. It has such a short shelf life. The models keep improving all the time. Yes, the advantages that any models gain on a given release are temporary. Yes. But the real question that's underneath just isn't getting asked enough. We're watching two of the most important companies in AI make genuinely different bets about how humans and AI agents should work together. And they believe in them so strongly, they are literally training their models to work within those specific harnesses. You should treat a harness decision as a strategic commitment because it is one. And we're all going to discover harness lock in the hard way if we don't dig in and take the time to understand harnesses the easy way. And that's why I made this video. And I have a lot more over on the substack for this one, guys. I think it's really important to understand harnesses. I'm going to put a lot more in there to give yourself a chance to understand which harness works for you in your workflow. And yes, even if you're a non-coder or a non-technical person, we're going to make sure that there's pieces of that guide there for you. Everyone else is going to discover lock in the hard way. I want you to discover it the easy way. And that's why I made this video. I have a Substack with more detail up there on how to understand which harness works for you. And if you're a non-coder, I've got detail on that, too. I know this has felt like a technical video. You have to understand a little bit of the technical details of the harness because that is what is shaping all of our work heading into the second half of 2026. These models require a little bit more technical fluency than we had to have from about 1980 to 2018. And there's no way to sugarcoat that. Understanding LLM takes a willingness to dig in just a little bit more than we're comfortable with. And that's something that every non-technical worker in tech is wrestling with right now. And I just want to tell you, I got you. We're going to keep explaining this stuff. This will not be the last video that explains technical stuff in a way that you can figure out because that's the reason why I used all of these analogies all the way through. That's the reason we talked about the brain in the jar. That's the reason we talked about the hands and the feet and the Frankenstein monster. I want you to not feel like something like a harness is too abstract, too difficult to understand. It's really not. It's just giving the model hands and feet. And it turns out that matters way more than anybody's talking about. And so that's why we covered it today. Best of luck.