AI Harness Is the New Operating System

Two years ago, if you wanted to build an AI agent, you needed a model, a memory system, a knowledge store, and a set of tools, and you had to wire all of it together yourself. Each connection was your problem. Every API handshake, every session summary, every context window - you owned it.

That world is over.

Last Friday, I walked through what has replaced it: the AI harness. It is not a single product. It is an architecture - a layer that sits between you and the underlying model and handles everything the old world made you build from scratch. Claude Code, Co-Work, and OpenClaw are the most visible examples of it today. They are not just tools. They are operating systems for AI.

Anthropic’s revenue crossed $2 billion with this shift. Let me explain why, and what it means for every builder and product manager in this community.

Let me take you back to 2024.

If you were building agents then, your job was to give the model context, give it memory, give it tools, and evaluate whether it did the right thing. These are not small tasks. A customer support agent alone required you to handle knowledge bases, session history, tool routing, failure modes, and cost monitoring - before you could write a single line of business logic.

Companies like Glean and Zendesk saw this and said: let us do all of that for you. Glean became a billion-dollar company by promising enterprises a single AI layer over their internal knowledge. Harvey did the same for legal work. SDR companies did it for sales. Each of them picked a vertical, built the harness specific to that use case, and charged accordingly.

The problem was that models were not commodities yet. Every time you bought Harvey, you got Harvey’s harness and Harvey’s model access, bundled together. You could not separate them. If you wanted to change the underlying model, you could not - because you did not own the harness.

Anthropic looked at that dynamic and made a different bet.

Here is what Cursor, Windsurf, and tools like them showed Anthropic: a company can take your model, build a harness on top of it, charge users $100 per person per month, and give you back a fraction of that in API costs.

Anthropic was getting perhaps a few dollars of every hundred the harness companies were earning. That arithmetic does not work if you are the one funding frontier model research.

So in mid-2025, Anthropic released what they called an Agentic SDK, and with it, Claude Code and Co-Work. The message was simple: we will give you the harness too. Context management, action-taking, memory, evaluations - all of it, built in. You still pay for the model, but now the harness is part of the deal.

Revenue went from $200 million to $2 billion. That is what happens when you stop being a component supplier and become the platform.

Understanding the harness is not optional anymore. In interviews, in product reviews, in architecture discussions - these five concepts are the vocabulary of 2026. Let me walk through each one.

Claude.md: the system prompt made distributable. Every agent needs a system prompt - a set of instructions that defines its role, its constraints, its goals. The old way was to hardcode this. The problem: a legal team and an engineering team and a sales team all need different instructions. Claude.md solves this by letting every team write their own configuration file, stored in their own folder. When a user attaches that folder, the harness automatically loads their Claude.md into the system context. The company writes a global one. Each team writes their own. Both layer together seamlessly. What used to require a developer to change now gets written by the people who actually understand the workflow.

Skills: turning repeated workflows into published capabilities. A skill is a set of instructions - carefully written, tested, and refined - for a specific task. A legal team might build a skill for contract drafting, another for risk identification, and another for redlining. Once those skills exist and work reliably, they can be published for anyone in the company to invoke with a simple command. The insight here is the same one that made software libraries powerful: write it once, use it everywhere. What Harvey charges enterprise licensing fees for, a senior lawyer in your organization can now build, refine, and publish internally.

Plugins: skills with a distribution layer. Once you have skills, you need a way to package and distribute them - inside your company, or to the world. A plugin is that packaging mechanism. Think of it like an app on an operating system. Your legal team builds a plugin. Your sales team installs it. Your developer contributes a pull request with an improvement. The plugin owner reviews and merges it. The ownership model is the same as a software codebase: anyone can contribute, but someone is accountable for quality. This also solves a real governance problem - without plugins, every team builds their own version of the same capability and the prompts diverge.

Hooks: deterministic logic in a probabilistic system. Not everything in a good product is AI. Hooks are rule-based workflows that run before, during, or after an AI interaction - things like “before every session, load the user’s recent activity” or “after every contract is drafted, format it to our standard template and log it in HubSpot.” If you have ever used a workflow automation tool like n8n or Zapier, hooks are that idea brought into the AI harness natively. They are the connective tissue between what the agent decides and what the broader system needs to happen.

Connectors and MCPs: the harness reaching into the world. An agent that only reasons inside a chat window is not very useful. Connectors are how the harness reaches into external systems - your calendar, your CRM, your database, your email. MCP (Model Context Protocol) is the standard that makes this work across providers. Every connector is, at its core, an MCP server exposing a set of actions. When Claude schedules a meeting, updates a HubSpot record, or reads a Snowflake table, that is a connector doing its job.

Watch the session

Here is the implication that matters most, especially for builders thinking about strategy.

When Anthropic released Claude Code as an open harness - one that could technically run with models other than Claude - they made a deliberate challenger’s bet. GLM-5.2, a recent open-source model, is roughly 30x cheaper than Sonnet and performs well on many tasks. Companies are starting to route simpler tasks to cheaper models and reserve Sonnet for work that requires it. The harness stays the same. The model becomes interchangeable.

This is both a risk and an opportunity. The risk for Anthropic is that the harness becomes the commodity and the model becomes replaceable. The opportunity - which they are clearly aware of - is that once your workflows, your Claude.md files, your skills, your plugins, and your hooks are all built on their platform, the switching cost is very high. You are not changing a model. You are changing an operating system.

For you as a PM or builder, the implication is practical: the question is no longer “which model should I use?” The question is “how do I configure my harness to get the best outcomes from whatever model is appropriate for each task?” Model routing - dynamically selecting the right model for the right task - is becoming a first-class product decision.

Across roughly 50 placements our community has made in the last three to five months, one pattern separates the candidates who close offers from the candidates who do not.

It is not the framework they know. It is not the company on their resume.

It is the product they shipped.

The people getting hired walk into interviews with a problem they solved. They can say: here is the issue I identified, here is how I built context management for it, here is how I created a skill that automated the step that was taking my team an hour every day, here is what broke in production and how I fixed it. They are landing concepts inside a story. The interviewer feels like they are talking to someone who already lives in the world they are trying to build for.

The people not getting hired are studying frameworks. They can recite what RAG is. They cannot tell you what happened when their retrieval went wrong at 2am and a customer was on the line.

If you have not shipped something - not built, shipped, with real users - that is the most important thing to change. Not your resume. Not your prep. The project.

I have been working on a plan I will release in detail next week. The concept is this: take one realistic product problem - I have been using an AI-native contract lifecycle manager as the example, and build it end to end over 16 days, one concept at a time.

Day one and two: install the harness, write your Claude.md and design files. Day three: understand context management, compaction, and memory. Days four and five: build your first skill. Then package it with hooks and publish as a plugin. Then add sub-agents to parallelize work. Then build connectors and MCP integrations. Then connect to GitHub so your skills update and distribute properly. Then add security, observability, and dashboards.

By the end, you have not just read about these concepts. You have applied all 16 of them to a real product in a real domain. You have a story. You have something to demo. You have something to talk about in an interview that no one can take away from you - because you built it.

Is the harness replacing tools like Harvey and Glean, or complementing them?

Both are happening simultaneously. For large enterprises with the budget and technical capacity to build in-house - Kirkland & Ellis just made a $500 million investment to do exactly this with Palantir - the harness enables them to replicate much of what Harvey offers and own the result. For the thousands of smaller organizations that cannot make that investment, Harvey and Glean remain the practical answer. Harvey’s own response to this pressure is to build a legal-specific model - moving the moat from the harness layer (where the generic tools can now compete) to the model layer (where they still have domain training data). Whether that bet pays off depends on how quickly general foundation models close the domain gap.

If Claude Code can run non-Claude models, does Anthropic lose pricing power?

Not in the short term, and possibly not in the long term either. Right now, most enterprise customers default to Sonnet because they trust it and do not want to introduce quality risk to save on inference cost. Over time, as model routing becomes standard practice, Anthropic’s pricing power on the model may compress - but their pricing power on the platform will increase, because the harness becomes stickier the more you configure it. The analogy that holds: AWS lost some compute pricing power to Azure and GCP, but the ecosystem of services, integrations, and organizational inertia made switching costs very real. The harness creates that same gravity.

How do teams govern skills and plugins without losing consistency?

The pattern that works is the same one that works in software: ownership at the plugin level, contributions through pull requests. Your legal team owns the legal plugin. Anyone can submit an improvement. The plugin owner - a senior lawyer who understands both the domain and the tool - reviews and merges. If a team has a specific use case that diverges from the canonical plugin, they write their own skill.md in their local folder. The harness loads their version first, overriding the installed plugin for their context. Consistency at the company level, flexibility at the team level.

What is the right mental model for hooks versus skills?

Think of skills as the AI layer - instructions that tell the model what to do and how to reason through a task. Think of hooks as the plumbing - deterministic rules that run before or after the AI does its work. A skill drafts the contract. A hook ensures the draft is logged in your document management system and a notification is sent to the right reviewer. Most real workflows need both. The mistake is assuming the AI should handle everything, including the parts that are better served by reliable rule-based logic.

How does model cost actually play out in practice?

At the consumer tier, the $20 subscription is an entry ticket, not a usage limit. Once you are in production with real enterprise usage, individual contributors burning through complex agent workflows regularly spend $200 to $2,000 per person per month in actual model costs. This is why model routing matters: routing routine summarization tasks to GLM-5.2 while reserving Sonnet for complex reasoning can reduce your monthly bill by 30 to 50 percent with minimal quality impact on the tasks where the cheaper model performs adequately.

Read the Claude Code documentation - not all of it, but the sections on Claude.md, skills, and hooks. These are not long reads. Then open a folder for a problem you actually have and write your first Claude.md. It can be 10 lines. The act of writing it will clarify your thinking about what the agent should and should not do in ways that reading about it will not.

If you are preparing for an interview, start there too. Interviewers are not expecting you to have deployed a multi-agent system with full observability. They are expecting you to know the vocabulary and to have touched the tools. Those are within reach this week.

Keep building,

Mahesh

If this session landed something for you, the next step is to actually build it.

I am running a free three-session series - Build and Ship with Claude Code: The Builder Path - designed for AI PMs and builders who want to go from understanding the harness to having three real portfolio projects by the end.

Session 1 — Spec-Driven Building with Claude Write implementation specs that control Claude Code. This is for AI PMs and growth leaders who want to ship products, not just describe them.

Watch the full session:

Session 2 — Build Data Pipelines with Claude Code From data ingestion all the way to a working dashboard. Hands-on and end-to-end - you leave with something running.

Session 3 — Deploy AI Apps Using Azure AI Foundry & Claude Code Ship real AI agents on Azure. Your third portfolio project in three sessions.

It is free. Three sessions. Three artifacts you can demo, talk about, and build on.

Mahesh Yadav runs the AI PM Community, a free weekly learning session for product managers and builders navigating the age of AI. This article is based on Session #187. Join the community at substack.com/@myaicommunity. Watch past sessions on YouTube. Connect on LinkedIn.