How Coding Agents Work: Models, Tools and the Harness Loop

What is an agent harness, and why does it matter for coding? Claude Code, Codex and Cursor include harnesses that connect models to tools and manage their work. T3 Code, the app I build, is primarily a UI around existing harnesses. I will explain the loop and build a small example.

I cite a benchmark by Matt Mower where Opus scored about 77% in Claude Code and 93% in Cursor on a particular feature-implementation test. That comparison suggests the surrounding setup can matter; it does not establish a universal ranking or isolate every possible configuration difference.

A harness is the software environment and set of tools through which an agent works. A language model generates a response from its inputs; it does not independently run commands on your computer. The surrounding program has to provide an interface to actions such as reading files or running a shell.

For illustration I invent a bash-call tag. The model emits a request in the agreed format, the harness recognizes it, and ordinary code executes the command if allowed. Real providers often use structured tool-call fields rather than this invented text syntax.

If I ask what files are in a directory, the agent can request a listing and then describe the result. When I ask it to edit a file, the harness may ask for permission before executing the write. The permission decision and execution are responsibilities of the surrounding software.

After the tool runs, its output is added to the conversation and another model request can continue the task. The model may call another tool, such as reading one file, and the cycle repeats until it has enough information to answer. Some systems batch or parallelize calls; the example illustrates the basic pattern.

The harness decides which tools exist, how they are described, how results are passed back and what permissions apply. These choices affect the model's options and its context. The model works with information provided in the request and tools, alongside knowledge learned during training.

Opening an agent in a project does not magically give it the contents of every file. In my example it searches the directory, reads package.json and relevant application files, and uses the returned text to explain the project. Each search or read supplies evidence that was not previously available in the conversation.

A project instruction file such as CLAUDE.md can put useful context into a session early, depending on the harness's loading rules. In my demonstration an instruction file answers the question without the same exploration. These files are context, not an automatic guarantee that their information is accurate or current.

Conversation history can save repeated searches: the agent can reuse information already returned in the same thread. When I point it toward package.json explicitly, it starts with a read and makes a more focused search. That is one example, not a promise that every prompt will halve the number of calls.

Should you always tell the model to read a pile of files up front? I generally prefer letting a capable agent search for what the task needs, while giving it relevant hints when I know them. Tool calls have costs and latency too, so the right balance depends on the task and environment.

Older workflows sometimes packed an entire repository into one file for a model to read. That can be useful in constrained settings, but it can also create a large amount of irrelevant context. Targeted search lets an agent select evidence incrementally instead of assuming the whole repository must fit in one prompt.

I show a long-context retrieval chart as an illustration of context degradation. Performance can depend on model, task and where information appears; the chart does not prove that every longer context makes every model less capable. The practical lesson is to measure the workload and supply relevant information deliberately.

To make the loop concrete, I use articles from the Amp team and Mihail Eric as references for a small coding agent. A user gives a task, the model proposes one or more tool calls, the program executes them, and results go back to the model. This core loop is much smaller than a production coding product.

The simple implementation has functions to list files, read a file and edit a file. A read resolves a path and returns its content; listing returns names and types. The edit example replaces an old string with new text or writes a new file. Real systems need to handle paths, errors and permissions carefully.

A tool registry maps names to functions. The model also needs descriptions and argument information so it can request them. In this teaching example the system prompt lists the tools and asks for a specific text format with JSON arguments; the harness parses that response and dispatches the selected function.

The program sends the system content and conversation to the API. After a response, it checks for tool invocations: if there are none it displays the answer; otherwise it runs the requested functions, appends their results and asks the model again. This is the loop that turns a text response into an interactive workflow.

I use another agent to build a minimal version, then run it against its own Python code. It lists and reads files to answer. The first generated version landed in an unexpected directory, a reminder that even a demonstration needs its working directory and outputs checked.

A shell tool can stand in for several specialized tools because it can run commands that list, read and modify files. That makes a compact demonstration possible, not a safe production design by itself: unrestricted shell execution gives the program broad powers, so real harnesses need appropriate permissions and safeguards.

Many model APIs expose a dedicated structured tool interface. A provider or routing service translates the tool definitions into the format expected by the model. The toy prompt-based syntax helps teach the idea, but it should not be confused with the actual protocol of every model provider.

In another turn, I ask the simple agent to simplify its own environment-loading code. It reads the relevant files and makes a change using shell commands. A model can modify the program driving it when the harness permits that, but the result still needs inspection and testing.

Why might the same model behave differently in another harness? Tool availability, descriptions, system instructions and returned outputs all shape its choices. In my small example, I alter a read-tool description to suggest bash; the model initially continues to use the read tool anyway.

When I mark the read tool as deprecated, a later run chooses bash instead. Changing a description can steer behavior without changing the tool's implementation, but an individual run does not establish how reliably a model will follow it. Different models may respond differently to the same wording.

I then make the read tool return a fabricated string rather than the real file. The model summarizes that string as though it were the code. This illustrates a trust boundary: tool outputs are observations supplied to the model, and incorrect or malicious output can mislead it.

I try a different model with the same deprecated-tool description and observe another choice of tools. I believe Cursor spends substantial effort testing and tuning prompts and tools for different models. The benchmark and my demonstrations support investigating harness design, but they do not establish the internal practices of every competitor.

T3 Code itself supplies the interface and delegates to the locally installed Claude Code or Codex harness when those providers are selected. It does not implement the same tool loop as the small example for those backends. Building a basic loop is accessible; making a reliable, usable product around it is a much larger task.

The point of the exercise is to make the moving parts visible: model requests, context, tool descriptions, execution and returned results. Once you understand that loop, you can ask more useful questions about why an agent chose a tool, what it knew and how its environment shaped the result.