Theo on Agent Harnesses, Interfaces and Shifting Abstractions

I start with a post arguing that debates about agent harnesses can resemble tabs versus spaces. The author is me: I build T3 Code, but I want to explain what a harness does and why I think most users will increasingly care less about which one they use.

Developers have always cared about details that matter at different levels. Formatting may matter for accessibility or consistency, while the product, the people building it and its architecture can matter more to the outcome.

The boundary moves as abstractions improve. Programmers once had to pay close attention to processor instructions; languages such as C let many developers work at a higher level without eliminating the instructions underneath.

Editors, formatters and linters reduced the need to debate many layout choices. AI-assisted completion then made it easier to name a familiar algorithm and generate an implementation, shifting where I spend effort again.

Engineers are accustomed to caring about details that outsiders dismiss. That habit can be useful, but I think it can also make us keep defending a layer after the practical value of obsessing over it has declined.

I point to attention shifting away from framework releases and say models can help rewrite code in another language. I also think they can help identify architectural problems, although I explicitly do not think their architecture work is perfect.

I recount noticing backend failures and using Claude to set up tracing and produce a report for Cloudflare. This is my account of a particular experience, not a controlled comparison between a model and an engineering organization.

To explain harnesses, I begin with a simplified model: an LLM receives text and generates text. That text alone does not edit a file or run a command; something must interpret it and connect it to actions.

My kitchen analogy is a skilled chef in an empty room. Even with a menu and the ability to describe a dish, the chef cannot cook without utensils and ingredients. A programmer facing a monitor without a keyboard has a similar interface problem.

A harness supplies a model with ways to request actions and receive context. It can interpret a supported tool-call format and arrange for a file read, an edit or a command, then return the result to the model.

I distinguish a human-facing interface from the harness underneath. In my terminology, a product such as Claude Code can bundle an interface and an agent harness; an SDK can expose the underlying agent capabilities to another application.

I argue that T3 Code is primarily an interface rather than a standalone harness, even though it affects how connected harnesses are used. That distinction matters when users switch providers and expect every setting to follow them.

For this explanation, I call an agent the combination of a model and a harness that supplies tools, context and instructions. Different harnesses expose different built-in capabilities, such as shell access, file editing or subagents.

Plugins can add capabilities such as finding a definition, while computer-use integrations can expose actions such as clicking or typing. Adding a tool does not make that tool itself the whole harness.

I draw a separate layer for access to external systems and data. My cookbook analogy is meant to distinguish that connection from a tool built directly into a particular harness, although both can ultimately give an agent useful actions.

For example, an MCP integration can give an agent a way to reach a database or analytics service. A custom tool may be implemented in a particular harness, while an agreed protocol can connect it to functionality hosted elsewhere.

I say T3 Code uses an MCP connection so its own code can broker actions without replacing the built-in tools of each harness. That design is intended to let a connected agent search history or request work through another connected system.

The layer engineers care about can reflect when they entered the field. When I started making videos, framework debates were prominent; later I became interested in infrastructure and then AI agents. That is a personal pattern, not a universal law.

I describe moving from backend work to frontend TypeScript and content about web development. A recent conversation with the creator of Claude Code surprised me because he knew my current AI work but not that earlier web-development background.

I enjoy learning a new abstraction even when that makes familiar expertise feel less central. I use skateboarding to explain why starting over in an unfamiliar stance can be rewarding rather than merely frustrating.

Imagine jumping a hurdle and then mentally swapping the legs. In skateboarding, I say, performing a trick in the opposite stance is a recognizable challenge to experienced skaters even when outsiders see the same movement.

I compare that to an experienced programmer writing in an unfamiliar language: the program may work, but habits from the first language can remain visible. Specialized expertise can be valuable, yet switching layers requires learning again.

Skateboarding taught me to enjoy the uncomfortable process of doing something differently. I worry that deep investment in one tool can make it harder to notice when another approach has become more useful.

I tell the story of adopting TypeScript without years of attachment to older JavaScript habits. My criticism of developers who stayed with those habits reflects my own experience and judgment, not proof that a particular tool determines someone’s career.

I make a provocative prediction about long-term attachment to editors and argue that similar loyalty can form around a single model family or harness. The point I want to make is that the best fit can change.

I had assumed a team deeply invested in a TypeScript abstraction would resist changing layers, but its creator’s remarks about no longer caring which harness was used challenged that assumption.

T3 Code users sometimes switch from one connected harness to another and expect skills configured in the first to appear automatically in the second. I say the apparent model selector is also selecting a harness, with its own configuration.

I compare T3 Code to a food court with several kitchens. Choosing a different kitchen does not automatically move every ingredient or recipe between them; the interface must deal with those differences.

My goal is to make switching feel more like changing a model or API option. I also expect models and their preferred harnesses to become more closely coupled, so the way an interface presents those combinations will continue to matter.

I previously spent substantial effort comparing ways to use different coding models. I now judge many of those differences to be small for my own workflow, while recognizing that other users and tasks can have different needs.

Making harness differences less visible is not necessarily easier for an interface builder: T3 Code still has to manage different subagent and tool behaviors. My argument is that users should not always have to manage that complexity themselves.

I call T3 Code an agentic development environment: it presents work to a person and connects to harnesses, environments and remote machines. The analogy is an IDE, though the center of activity is managing agent work rather than editing every line directly.

I wanted an open, customizable interface for controlling my AI work, not to build another harness. I expect even these interfaces to become less prominent as people interact with agents in more places, but I care about making one useful now.