Harness and agent

The harness is the software around the model. It builds the context. It offers the tools. It checks the rules and keeps a limit on what the tools can reach. It keeps the history and shows you the results.

ChatGPT in a browser is a harness. Codex in the ChatGPT app is a harness. The Codex command-line tool is a harness.

The model can be the same in all three. The harness differs, so the abilities differ. Codex can change files in the project folder you open.

The harness is the software around a model. It builds the context, offers the tools, enforces permissions and the sandbox, keeps the history, and shows you the results.

A chat in ChatGPT, Codex in the ChatGPT app and the Codex command-line tool are all harnesses. The same model can sit inside each of them.

Same model, different harness, different abilities. Codex in the ChatGPT app can change files in the project folder you open.

The harness is the runtime that surrounds the model. It assembles the prompt from instructions, history and files, advertises tool definitions, validates and executes tool calls, applies the permission mode, enforces the sandbox, persists the thread and renders the output.

Capability differences between products often come from the harness more than from the weights. The same model with a different tool set, context policy or permission policy behaves like a different system.

On Windows, Codex runs natively in PowerShell inside the Windows sandbox. Other platforms use their own mechanisms: Seatbelt on macOS, and bubblewrap on Linux and WSL.

An agent is a model, a harness and tools that work in a loop toward a goal.

The loop has four moves. Plan the next step. Act by calling a tool. Observe the result. Then repeat.

The loop ends when the work is done or the agent is stuck. Then the agent reports back to you.

An agent is a model, a harness and tools working in a loop toward a goal. The loop is plan, act, observe, repeat.

A chat gives you one answer. An agent keeps going. It reads a file, sees what is in it, decides what to read next, runs a command and checks the result.

It stops when the work is done or when it is stuck. Then it reports. You approve the risky steps along the way.

An agent is a language model driven in a loop by a harness, with tools that let it observe and change an environment. "ReAct: Synergizing Reasoning and Acting in Language Models" (Yao et al., 2022) describes interleaving reasoning steps with actions and observations in this way.

Each iteration appends the model's output and the tool results to the context, so the context grows with every step. Stop criteria are the model's own decision that the task is done, an error it cannot get past, a step or time budget, and a human decision at an approval prompt.

Four failure modes follow from this design. The loop can repeat without progress. The agent can claim that it finished when it did not. It can game a check, for example by editing a test so that it passes. The context can fill up until early instructions drop out. Lesson 09 gives checks for the second and third: ask for evidence, re-run the script and review the diff to the checks. For the first and fourth, stop the run and start a new thread with a narrower brief.

SWE-bench (Jimenez et al., 2023), built from real software issues, is an example of how agents are scored on whole tasks, not on single answers.

Your files and programs are on your laptop. Codex on your laptop can reach them. It can run other programs on your laptop. Some labs use them.

The sandbox centres on the project folder you open.

Your files and programs are on your laptop. A local Codex can read the files in your project folder and run programs there, such as Python and Docker.

The sandbox centres on the project folder. This is why you open CodexWork as the project, and not your whole Documents folder.

Local execution puts the tools next to the data and the toolchain: your files, your Python and your Docker. No upload step is needed for the agent to act on them.

The sandbox centres on the project folder. By default, a folder under git gets workspace-write access with approval on request, and a folder without git is read-only.

Network access is off by default, so commands that need the internet need approval or a settings change.