The obvious instinct with AI is to give it more specifics. The operators getting compounding results from Claude, ChatGPT and Copilot are doing the opposite, and the mistake is what keeps most rollouts stuck.
The reflex is to tighten the brief, add guardrails, write longer instructions, and add more rules to the context and prompt steering AI. The result is a model performing worse than when the prompt was one sentence because the model is being constrained in a way that it's architecture wasn't designed for.
There is a better mental model, and it's emerging at the frontier which most NZ businesses driving AI transformation aren't aware of.
A new vocabulary, but the underlying pattern is what's important
A small group of practitioners are quietly building the language for the next phase of AI work. Harrison Chase at LangChain, Birgitta Böckeler at Thoughtworks, Ankur Bhatt writing on Substack. Different angles, same underlying argument, which is that Claude is no longer the interesting part. The system around Claude is.
They call this harness engineering, and the term is current enough that it might shift in six months. It's less about the label and more about the pattern underneath, which keeps compounding regardless of what it ends up being called.
The intern analogy
An AI agent is a new-hire intern. The moment it shifts from a tool a person prompts for answers to a worker that completes tasks across days, the output depends almost entirely on the onboarding system built around it. Whoever owns that system owns the memory, the compounding, and the lock-in that follows.
Three shifts are creating urgency around this topic right now:
Agentic work is arriving, so a tool that completes tasks needs more than a good prompt.
Memory lock-in is crystallising, because Managed Agents, the Responses API and Codex summaries all introduced longterm memory layers this quarter, and every one is vendor-owned by default (even if your markdown files are portable).
The default capabilities are good enough to continue with, which means businesses that do nothing will fall behind without noticing.
Most readers have rolled out Copilot or ChatGPT Enterprise and are now being asked by a board or exec team what the actual AI strategy is. To be super clear, this piece is the bridge from that question to the frame those practitioners are already working in.
The step past context
Most of the AI enthusiasts have caught up to the importance of context engineering(the evolution beyond prompt engineering). Give Claude or ChatGPT the right information, prime it well, and the output improves. That's not wrong, it's just incomplete for scaling AI at both an individual and enterprise level.
Context is the briefing on day one. Whereas the harness is the full book, and the difference shows up over months, not in the minutes of showcasing a demo.
The brief, the tools, the memory of what worked and what did not, the feedback loops, what gets written down for the next task, what gets thrown away. Context is how a person tells an intern what to do on Monday morning. The harness sits above this, and explains how that intern becomes a senior operator over twelve months.
Here's a visual from Harrison Chase's write up:
See content credentials
The harness is five things wrapped around Claude, and each one is a deliberate design choice. Think of Claude as the new-hire intern sitting at the desk. The harness is everything else in the room.
What goes in. The brief, the notes on past work, the examples of what good looks like, the running conversation. This is what Claude sees before it starts, and most people only think about this layer, which they call it the "prompt".
Who supervises the work. Someone has to break a big task into steps, tell Claude when to stop, restart when it goes off track, and keep the intern from running forever. On a laptop that is Claude Code or a Ralph-style loop. In a business that is a team lead.
What Claude is allowed to touch. A browser, a file, the accounting system, a database, an email inbox. The more Claude can reach, the more it can actually do. A model that can only talk is an advisor. A model with hands is a worker.
How Claude checks its own work. Screenshots of what it produced, test results, error logs, a second look at the output. Without this, Claude confidently hands back rubbish and nobody notices until a client does.
What gets kept for next time. Notes saved to a file. A record of what was tried and what worked. The intern who writes everything down gets better every week. The intern who forgets by Friday starts from zero on Monday.
Miss any one of the five and the harness is thin. Claude with a great brief but no way to check its work produces confident nonsense. Claude with strong tools but nothing saved between tasks forgets everything by Monday. The compounding sits in having all five working together.
Pillar 1: Guardrails, not rules
A new hire with a 200-page script performs worse than a new hire with a clear job objectives and success measures, good tools and feedback when they go off track. AI is identical in that respect.
Non-deterministic judgement is AI's superpower. A system that micromanages a non-deterministic worker strips out the judgement, and what is left is a worse version of the rules-engine the team could have built without Claude at all.
Garry Tan, who runs Y Combinator (the world’s most influential startup accelerator, founded in 2005 to help founders create high-growth tech companies) and builds with Claude Code daily, let his master instruction file grow to 20,000 lines. He was adding rules the way a worried manager adds policies and how the industry has built traditional software. Claude Code itself eventually told him to cut it back, and he slimmed it to roughly 200 lines of pointers. The output quality improved immediately.
The shape of the lesson for me is that the instruction file is a routing table, not an encyclopaedia. All of my CLAUDE.md files at the global and project layer are designed this way. The challenge is that more rules feel like more safety, when the opposite is true when it comes to AI.
Böckeler's work at Thoughtworks arrives at the same idea from the engineering side. She splits AI quality systems in two:
feedforward (guides that steer Claude before it acts), and
feedback (sensors that catch what slips through).
Good harnesses do both, and the feedforward layer steers rather than prescribes.
The challenge is that "context equals training the intern" is the framing most senior operators have internalised, and it is the half-truth that keeps them stuck. Context is the briefing, and the briefing is important, but it is not the onboarding system.
The onboarding system is the briefing via context, plus...
the tools they can use
plus what gets written down for the next hire
plus the feedback mechanism when they drift
plus the rule that says when to ask
and when to proceed.
Not one chapter, it's the whole book. What's outlined above isn't covered by context engineering or prompting alone.
Pillar 2: Memory is the harness
Harrison Chase, spent 18 months arguing in public that the hardest problem in agentic AI is not prompting, not context windows, not model capability. It's Memory. What Claude remembers between tasks, how, and who decides.
The same pattern played out with CRM ten years ago. Salesforce did not win on features, it won on the customer data the customer could not easily extract. Zendesk did the same with support transcripts, and HubSpot did it with marketing history. The vendors who owned the memory owned the switching costs, and customers who did not design their own memory architecture inherited the vendor's by default.
AI memory is the next version of that moat, and the ownership decisions are being made right now inside every business that has not looked at the setting. That isn't a theoretical risk, it's a present one that is crystallising behind the scenes of every Claude, ChatGPT and Copilot rollout.
This is a leading indicator, not a trailing one. The businesses that will be hurt are not the ones noticing the cost today. They are the ones who will notice it in eighteen months, when the migration cost is prohibitive and the vendor has an unbreakable hold on accumulated operational knowledge.
Chase splits memory into three kinds for ease of framing:
Episodic memory, meaning what happened. The log of specific tasks, conversations and decisions the business runs through Claude.
Semantic memory, meaning what it means. The patterns extracted from that log, plus preferences and team conventions.
Procedural memory, meaning how we do it here. The skills, the playbooks, the standard operating procedures Claude can invoke.
Each of the three needs to be designed, not defaulted. When an intern finishes a project, a manager decides what gets filed, what gets shared with the next hire, and what gets thrown away. AI memory works identically, and if the business does not design that filing system, the vendor will.
Pillar 3: Fat and thin harnesses
The technical literature calls this open vs closed (Chase's framing) or builder harness vs user harness (Böckeler's). The version that lands with most is the differentiation of fat vs thin, and it works because it describes what the harness feels like to use, not how it is built.
A fat harness is heavy scaffolding. Thick onboarding manual, chaperone at every meeting, checklist for every conversation, script for every decision. The intern's output is predictable in month one, and the intern's judgement never develops in month twelve. The harness itself becomes the bottleneck.
A thin harness is light scaffolding. Clear job description, good tools, honest feedback when the work drifts, room to think. Month one is slower, month twelve looks completely different, because the intern has grown into the role rather than being constrained by it.
Anthropic's Claude Code is roughly 512,000 lines of thin harness around Claude. Minimal scaffolding, maximum freedom, with feedback loops that catch drift. LangChain's Deep Agents jumped from 52.8 to 66.5 on Terminal Bench, a standard agentic benchmark, by thinning the harness rather than thickening it. Thing is, the compounding pattern is visible in the numbers.
Enterprise instinct is to start fat. More rules, more checkpoints, more approvals, because fat feels safer in the board meeting. The compounding pattern runs the other direction, and the businesses that start thin are the ones building a system the team will still be using in three years, and one that adapts as models change, and enables AI to do what it is great at = produce non-deterministic, creative results.
Most boards are debating the wrong layer of the stack. The conversation is GPT vs Claude vs Gemini vs open source, which of them codes better, which is cheaper per token, which benchmark went up this month. The trap is that entire companies are built around comparing that stuff, and none of it matters as much as what sits on top.
The layer above is where compounding actually happens. Shared skills, shared commands, shared memory, shared automations, all version controlled. Call it a your Business OS if it helps. Claude or ChatGPT or Gemini underneath can swap every six months. The institutional knowledge layer persists and is the most important part as models increasingly commoditise.
Google rewrote its search infrastructure three times over two decades. The engineers who did it left, joined startups, retired. The systems they built still run. That is what a Business OS does for AI workflows, and it decouples the knowledge from the person who created it.
The open frontier sits right here for businesses. Chase writes about individual operator harnesses, Böckeler writes about builder and user harnesses, Bhatt writes about a single intern. None of the three fully addresses the question every business has, which is whether everyone gets the same harness, their own harness, or some layered combination of both. Maybe we're early to market, or maybe the technology is moving to quick to land on how best to navigate this enterprise challenge.
Böckeler's greenfield/legacy paradox points to the problem that the harness is most needed in exactly the organisations where it is hardest to build, because more operators means more coordination, and individual workflows diverge the most where they matter the most.
Although early, patterns are emerging online in AI circles that the shape is a layered harness, meaning shared foundations (role definitions, tool access, memory architecture, naming conventions) at the bottom with individual skills and habits on top, and the pattern is not settled yet, nor written down in any framework the practitioner crowd has published.
The harder truth is the tradeoffs of the architecture:
Individual harness, meaning each operator builds their own. Matches how people work, iterates fast, low coordination cost, but knowledge does not accumulate across the team, memory silos, and the vendor ends up owning the cross-team memory by default.
Shared team harness, meaning the business owns the architecture and individuals plug into it. Institutional memory compounds, new hires onboard faster, the business owns the compounding, but coordination cost is high, the risk of sliding into fat-harness bureaucracy runs high, and someone has to own the architecture as a role.
Layered (the early emerging pattern), meaning shared foundations plus individual skills on top. The best of both in theory, unproven at scale in practice.
Right now the gap between a team using Claude Code individually and a team with a mature shared skill system is roughly more****productive. In twelve months that gap will be closer to 50x, because the learning flywheel rewards early investment exponentially. Every shared skill makes the next one faster to build. Every automation removes a bottleneck that was quietly slowing three other automations.
Teams that treat AI tooling as a personal productivity hack will plateau. Teams that treat it as shared infrastructure will compound, and compound always wins on a long enough timeline. The sharpest operators are asking this question inside their business right now, but most senior teams have not asked it yet because they're not across the benefits this offers, which is the point of this piece.
What my own harness looks like
In six months of building inside Claude Code, the single clearest proof of the harness argument is the article being read right now, which was drafted inside a ten-component system. Useful as a worked example, and the proof of the Pillar 4 problem.
The system has ten rough components to quickly explain:
A foundations folder with around ten markdown files covering voice, structure, persuasion, funnel strategy, and the common failure modes.
A Python content linter that checks every draft for eight classes of violation before anything ships.
A fix dictionary logging every correction ever made, because the same mistake showing up three times becomes a rule.
A few 100 skills (pre-packaged workflows with access to context, tools etc.), each a small procedure for a repeatable task.
A Ralph loop, where Claude drafts, the linter catches issues, Claude redrafts, the linter rechecks.
A common-issues log, which is the sensor output feeding back into the foundations files when the same failure fires three times.
A Fireflies capture layer, pulling conversations and turning them into source material.
A wiki of concepts, entities and syntheses, so every draft can reach for a real number or a named person rather than making them up.
A weekly report, which is the feedback loop the human reads.
A health check running daily at 22:00, because the harness needs a sensor checking that the sensors still work.
Two months into building it, the master instruction file had grown to hundreds of lines. my output quality started dropping, the same experience Tan described. Slimming it to around 200 lines of pointers fixed it immediately. To be super clear, the lesson is not more rules, it is better routing with context files available for the agent to review as needed.
The honest limitation is that this harness works because one person runs it. The moment a second marketer, or a sales team of four, or a content squad tries to share it, the architecture changes. Individual skills step on each other, memory fragments, skills get duplicated. Which is exactly the Pillar 4 problem, and the place the frontier is struggling with.
What this means on a Monday for AI teams
Four moves, in order, starting with the two that cost nothing.
Notice the memory. Open whichever of Claude, ChatGPT or Copilot gets used most in the business, find the memory setting, ask who owns it. If the answer is the vendor, a strategic decision has just been made by default.
Ask the shared-harness question. At the next leadership meeting, ask who in the business owns harness architecture, meaning the way memory, tools and skills accumulate across the team. If the answer is "nobody" or "every person for themselves", the next architectural decision is visible.
Stop micromanaging one workflow. Pick one failing workflow, strip the prompt back to a role plus tools plus a feedback mechanism. Most failures are over-specification, not under-specification.
Pick fat or thin, consciously. Pick one workflow, ask whether the current setup is fat (many rules, many checkpoints) or thin (clear role, good tools, light touch), and whether that is the right choice for this task.
The first two cost no money and no tooling. The second two become natural once the first two surface the answer that might be uncomfortable.
The harness is the strategy
A year from now, the businesses doing serious AI work will not look different because they picked Claude over ChatGPT. Their foundations will be roughly the same. The gap will come from who built the onboarding system around them, who owns the memory the system writes, and who decided whether everyone gets the same harness or a different one.
The vocabulary will probably shift. Context engineering already sounds like a 2025 word, and harness engineering might be next quarter's. The pattern underneath keeps compounding regardless of what it gets called.
Passionate about all things AI, emerging tech and start-ups, Mike is the Founder of The AI Corner.
Subscribe to The AI Corner
