Agent, harness, harness engineering

The previous lesson ended on a claim. What separates a prototype that stalls from software that holds is the environment around the model. This lesson gives that environment its name and draws its edges.

What a model does

A language model takes text and produces more text. That is the whole interface.

Two properties matter for us. A model keeps nothing between two calls. If a conversation seems to have a memory, it is because the application sends the whole conversation again each time. And a model cannot act. It cannot open a file, run swift build or look at a failing test. It can only write text that describes what it would do.

In a chat window, you fill both gaps. You paste the file in, you copy the answer out, you run the build and paste the error back. You are the memory and you are the hands.

What an agent adds

An agent is a program that takes over those two jobs. It keeps the conversation, and it carries out actions on the model’s behalf.

Along with your request, the program tells the model which actions exist, such as reading a file, editing a file or running a shell command. The model can answer with text for you, or with a request for one of those actions. When it asks for an action, the program performs it, sends the result back as text, and calls the model again. The model sees what happened and decides what to do next.

That cycle is the agent loop. The next lesson takes one turn of it apart.

Three words

The vocabulary around this is loose, and three words are used for three different things. This course keeps them apart.

Word	What it names
Agent	The model-driven process that interprets a goal, chooses actions and reacts to what it observes.
Harness	Everything around that process. The runtime, the tools, the context it receives, the permissions it works under, the environment where commands run, the feedback it gets and the way several agents are coordinated.
Harness engineering	The design, extension, evaluation and governance of that environment.

When a run goes wrong, the first two words tell you where to look. A model that cannot infer your conventions is an agent problem, and it is the one you can do least about. A repository that never stated those conventions is a harness problem, and it is yours to fix.

None of this is new

Tool execution, permissions, sandboxes, context management, feedback loops, test automation and orchestration were all part of software engineering before coding agents existed. Continuous integration is a feedback loop. A merge queue is orchestration. Least privilege is governance.

What changed is who sits in the loop. When a language model can inspect a repository, choose a tool, run a command, read the result and continue for dozens of steps, those familiar mechanisms take on a new role. They stop being conveniences for people and become the limits within which an autonomous process does engineering work.

So this course does not present harness engineering as a new discipline with an agreed architecture. There is no mandatory shape. It presents it as a way of applying practices you already know to a new kind of worker. The thesis of the whole course fits in one sentence. A useful harness is not defined by how many features it has, but by whether it lets an agent complete the intended missions within explicit boundaries, with results you can verify.

Build, customize or extend

A tempting reading of “engineer the environment” is that you should write your own agent runtime. For almost every iOS team that would be a mistake. Claude Code and Codex already provide the loop, the model integration, tool execution, a permission system and a sandbox. Rebuilding them would cost months and give you something you then have to maintain.

There are three honest options, and the course leans on the last two.

Approach	What you build	When it makes sense
Build a harness	The runtime itself. Model integration, tool execution, state, permissions, the loop.	A product that needs custom runtime behavior, or a platform that others will build on.
Customize an existing one	Instructions, repository conventions, skills, workflows, hooks, agent definitions.	The runtime already offers what you need, and the gaps are about your project.
Extend an existing one	Custom tools, MCP servers, analyzers, policy checks, validation services.	A capability or a control is missing, and no configuration gives it to you.

Module 2 and module 3 are customization. Modules 4 to 6 are extension. Module 4 builds a tool and an MCP server in Swift, where it adds something the products do not have, such as understanding the structure of an Xcode project. Nothing in this course asks you to recreate Claude Code.

The same model in two harnesses

Two public accounts show what the environment is worth.

The author of an Anthropic engineering article gave one prompt, a request for a 2D retro game maker, to the same model twice. Alone, the model ran for 20 minutes and cost 9 dollars. Inside a harness built around a generator and an evaluator, it ran for 6 hours and cost 200 dollars. The author reports that the difference in the quality of the result was visible at once.

OpenAI describes a product built over five months with nobody writing code by hand. The repository reached about a million lines through roughly 1,500 merged pull requests, with a team that began at three engineers. The job left to the engineers, in their words, was to “design environments, specify intent, and build feedback loops”.

Neither account is a controlled experiment, and both come from companies that sell the models. I read them for what they agree on. The effort that changed the outcome went into what surrounds the model, and that effort has a price in time and tokens.

Sources

• Harness design for long-running apps, Anthropic. The two runs of the game maker.
• Harness engineering, leveraging Codex in an agent-first world, OpenAI. The product built by agents.