Chef, Kitchen, Restaurant: Demystifying the Harness Behind AI Agents

What is Harness?

The article clarifies the concept of Harness, which has sparked discussion alongside AI coding assistants like Claude Code and Cursor. It uses a chef, kitchen, and restaurant analogy to dissect the boundaries and relationships among Interface, Harness, MCP, and Agent.

Human Interface

Humans do not use computers by writing code directly; they use interfaces such as terminals, websites, or apps. Examples include Chrome, Claude Code, and ChatGPT App (formerly Codex). Humans typically cannot see the underlying code; they only see the interface.

LLM Uses Harness

By default, LLMs only generate text. To do more, they need tools. Most LLMs are trained to work with tools like read_file, edit_file, bash, and search. However, LLMs still only send text; they cannot click buttons. A custom text format is needed to signal external code execution. For example: <read_file name="README.md"> The LLM knows it can respond in this format, but the text itself does nothing. Something must parse these responses and run the corresponding code. To let an LLM actually accomplish tasks, it needs:

Tools that perform concrete actions (read_file, edit_file, bash, search, etc.)

A dedicated syntax for invoking those tools via text

A system that parses messages, recognizes the syntax, and executes the code

A method to feed tool results back to the LLM

A list of available tools with usage instructions

That is the Harness.

Is Claude Code a Harness?

Half. Claude Code contains two parts: an interface and a Harness. Running claude in a terminal opens the Claude TUI; the desktop client's "code" tab opens the Claude Code GUI. Neither is the Harness. Under the hood, Claude Code uses the Anthropic Agent SDK to interact with the Agent. Similarly, ChatGPT interacts via the ChatGPT/Codex App and the Codex App Server (built into the CLI).

The confusion arises because Claude Code and Codex bundle the Harness inside their own apps. However, the same Harness can be embedded in other apps. Examples:

Cursor's Harness adopted by Grok Bot

Anthropic Agents SDK and Codex App Server adopted by T3 Code

Pi adopted by OpenClaw

Harness is an independent component almost never exposed directly to human users of these apps.

Who Owns the Tools?

Think of Harness as a kitchen . It contains many tools: pots, pans, knives, spatulas, blenders. No kitchen can hold every tool a chef might need. Good Harnesses are built with this in mind, allowing users to bring their own tools. Notably, most important tools are provided directly by the Harness . Codex and Claude Code include many built-in tools, while others like Pi are more minimal.

The orange box in the diagram represents what Claude Code (specifically the Agents SDK) contains. You can add custom tools, such as a TypeScript plugin for linting or a CUA plugin for computer control. Note the dividing line between the tool plane and the human/LLM layer: neither humans nor LLMs can directly see or touch these tools. The Harness exposes them to both the LLM and the interface (which is how we see them).

MCP Adds Complexity

MCP (Model Context Protocol) is a standard to let Harnesses access external resources more easily. Simply put: tools are "run code here to do something", while MCP is "send an API request elsewhere to do something". Tools provide executable code directly; MCP lets code live elsewhere but the LLM can still invoke it via requests.

Common MCP use cases include exposing data to the LLM: letting ChatGPT read email, or Claude analyze website metrics. Chrome extensions resemble tools (run code locally), whereas MCP resembles websites (no install, just a URL).

The diagram shows where T3 Code (https://github.com/pingdotgg/t3code) fits. T3 Code exposes custom capabilities to the LLM to do things the Harness cannot, such as spawning sub-agents in Codex from a Claude Code thread. Other tools like Herdr, Orca, and Cursor do similar things.

Why expose this as MCP? Recalling the earlier distinction: tools provide code directly; MCP lets code live elsewhere but be invoked via requests. T3 Code contains substantial code for features like multi-Harness sub-agents. Technically, they could refactor those features as plugins for each Harness (Claude Code, Codex, Antigravity, Pi, Cursor, Muse...). Instead, they keep all code inside T3 Code and expose a simple MCP service for the LLM to use.

In the kitchen analogy, MCP is like a recipe book . It is a method for doing things but not a tool entity itself. T3 Code provides a cookbook to the kitchen without changing how the kitchen operates. Chefs may choose to consult it or ignore it.

What is an Agent?

The author avoided the undefined term "Agent" until this point. TL;DR: An Agent is the combination of Harness and LLM. LLMs only generate text and cannot act alone. Harnesses are just kitchens that cannot cook alone. Only when LLM and Harness combine does an Agent emerge. Different Agents are often just different Harness configurations (custom tools, prompt instructions, MCP services, etc.).

Is T3 Code a Harness?

No. Without a Harness, T3 Code cannot work. Returning to the analogy:

Chef = LLM

Kitchen = Harness

T3 Code = Restaurant

T3 Code is a restaurant that lets you bring any kitchen. It has its own exclusive recipes (MCP services) and offers the cookbook to every kitchen, but chefs won't open it unless explicitly told.

Further Reading

For a deeper top-down principles analysis, see T3 Code (https://github.com/pingdotgg/t3code). It is fully open source, so you can ask your Agent to explain how it works. Original post: https://x.com/theo/status/2113424203345265053