The idea in one page

• A harness needs four values from you. The server's address, the model's exact name, the model's context window (how much text it can hold at once, counted in tokens) and the output limit (how much it may write in one answer). If any of them disagrees with the server, runs fail, sometimes only halfway through a task.
• Agents need a big context window. Before it reads a single file, a harness sends its own instructions and tool list. We measured the first request: about 5,600 tokens for DeepSeek Harness, 7,500 for OpenCode and 13,600 for OpenHands. Files, test output and the history come on top. Plan on at least 32,000 tokens; 64,000 or more is comfortable.
• The model must be able to call tools. A harness works by letting the model ask for "read this file" or "run this command" in a fixed format. Models trained for that do it; many small chat models don't, and then nothing happens, however friendly the reply looks.
• Test the model before you hand it out. One small task with a known answer shows within minutes whether the model can do the job.
• Local and gateway look the same to the harness. Both are an address that speaks the OpenAI-compatible format. A gateway adds one key per person, a budget and a list of approved models.

Set up (steps 1 to 3, once per model)

Step 1: Load the model with a large context window. In LM Studio, on the Developer tab with the server switched on (as in T11-L02), open the model loader, choose your agent model and set Context Length to at least 32768 before loading. Then open http://localhost:1234/v1/models in your browser and copy the model's identifier. You should see: the model's identifier in the list, and the model shown as loaded with the context length you set.

Step 2: Tell OpenCode about the server. Open opencode.json in your home folder's .config/opencode folder, which applies to all your projects (create it if it's missing), and add the server as a provider. For one project only, put the same lines in that project's opencode.json, as in T08-L04 · Use OpenCode Desktop on Your Organisation's Real Repositories. Replace your-model-id with the identifier from step 1 and adjust the two numbers to match what you loaded:

Restart OpenCode Desktop and pick My agent model under the message box. You should see: My agent model in OpenCode's model list, and an answer when you ask it "Which files are in this folder?" in a project.

Step 3: Tell DeepSeek Harness about the server. Start DeepSeek Harness as in T20-L02, open Settings → Models → Add model provider → Custom model API, and enter Provider ID local, base URL http://localhost:1234/v1, API protocol OpenAI Chat Completions, any text as the key, and your model's identifier. Under Customized settings, open the model's options and set the context window and maximum output tokens to the same two numbers as in step 2. Save and pick the model. You should see: your model selected in DeepSeek Harness, and an answer to the same question.

Worked example: a sequencing-run helper that stays inside

Structure it

The request: "Our run scripts may only be changed with a model that runs inside the institute. Before we tell anyone to use a coding agent, find out which of our models can do the job." The data rule comes from T12-L01: unpublished run files are red, so every request must go to a model the institute runs.

Understand it

The group has two candidates: the large model on the group's shared server (35 billion parameters, 3 billion active per token, 128,000-token context) and a small model that fits every laptop (4 billion parameters, 8,192-token context). The small one answers chat questions well. The question is whether either can act.

The measured first requests settle part of it on paper. An 8,192-token window holds DeepSeek Harness's instructions with a little room to spare, OpenCode's with almost none, and OpenHands's not at all.

Choose tools

Both harnesses from T20-L02, each connected to both models through the same address, with context window and output limit set to match each model: 128,000 and 32,000 for the large one, 8,192 and 2,048 for the small one. The test task is the bug fix from T20-L01 · Same Model, Different Harness: See What the Program Around the AI Changes, with its known answer kept outside the folder.

Build it

The large model passed the task in both harnesses (T20-L01 and T20-L02 used it for all their runs). The small model, Gemma 3 4B, never got going, and the two harnesses failed in very different ways:

Understand it, again

The second row is the dangerous one. A colleague who only watched OpenCode finish would think the task was done. The lesson for the set-up you hand out: approve only models that passed a known-answer task in the harness your colleagues use, and teach them to check the folder, not the "finished" message.

The group's decision: the shared-server model for agent work, the laptop model for chat only, and a note in the team's set-up guide saying why.

Build it: hand it over

The set-up guide the builder wrote fits on half a page. It names the approved model and where it runs, lists the four values for OpenCode and for DeepSeek Harness, and shows the practice task's known answer so any colleague can check their own set-up in ten minutes. It also says, in one line each, what the small model did in both harnesses, so nobody "tries the fast one" on a real run file. The guide lives next to the scripts it's for, where the next person will look. Before it goes out, one colleague follows it without help. The gaps such a test finds are usually small, like a missing restart after editing opencode.json, and each goes into the guide straight away.

Company: the reconciliation scripts

Finance already has a team gateway (T11-L04 · Put Your Team's Assistant on a Server Colleagues Can Reach). The builder asks for one key per person with a monthly budget, and allows only the two models that passed the known-answer task. In both harnesses the address is the gateway's, the key is the person's own, and the four values are copied from the gateway's model list. A model the gateway doesn't list can't be picked by accident.

Sharing one model server

A single agent task sends the model many requests, one after another: 9 to 28 per task in our runs, each carrying the whole conversation so far. Three things follow once colleagues share a server.

• Parallel slots decide how many agents run at once. A model server handles a fixed number of requests at the same time, called slots. With one slot, the second colleague's agent waits for the first one's request to finish. More slots help only as far as the hardware allows: on our two servers, running two requests at once gave about 1.9 times the total throughput on one machine and only 1.2 times on the other, because each request slowed down.
• Agent tasks take minutes, not seconds. Our five practice tasks took 2 to 10 minutes each with a 35B model. Tell colleagues what to expect, and plan the server for the busiest hour, not the average.
• An abandoned request keeps the server busy. When a harness gives up waiting and retries, the server may still be working on the first request, so load piles up. If the server feels slow, look at how many requests it is processing before you add more.

For a group, this is where a gateway earns its place: one key per person shows who is using how much, a budget stops a runaway loop, and the list of allowed models keeps the too-small model out of agent work.

What goes wrong

• Context window too small. Symptom: the harness refuses to start, or forgets files it read a few steps ago. Fix: load the model with at least 32,768 tokens and write the same number into both harnesses.
• The model can't call tools. Symptom: replies contain things like tool_code or JSON that look like commands, and nothing in the folder changes. Fix: pick a model trained for tool use; test it with a known-answer task before anyone relies on it.
• The chat format rejects agent messages. Symptom: an immediate error mentioning roles or the template. Fix: use another model, or another build of the same model with a different chat template.
• The harness believes a bigger window than the server has. Symptom: long tasks fail near the end with a context error, short ones work. Fix: the number in the harness must never be larger than the context length you loaded.
• Output limit too large. Symptom: every request fails at once. Fix: keep the output limit at a quarter of the context window or less.
• Thinking models time out. Symptom: long silences, then a timeout, on a model that "reasons" before answering. Fix: give it time on the first try; if it keeps timing out, choose a lower reasoning level where the harness offers one.
• "Finished" taken at its word. Symptom: a colleague reports the agent "did nothing" days later. Fix: the set-up guide says: check the changed files every time.

Do it yourself (90 minutes)

Step 4 · Structure it (10 minutes). Write two lines: which data your scripts touch and which route it may take (T12-L01), and which models you may use for it. You should see: one or two approved models, each with the place it runs.

Step 5 · Build it (20 minutes). Do steps 1 to 3 for your first approved model. You should see: both harnesses answering a simple question about a project folder.

Step 6 · Understand it (30 minutes). Unzip the practice folder twice, one copy per harness. Outside both copies, save this as check.csv:

Give each harness the text of BUG-REPORT.txt in its own copy. When both have finished, run python3 -m labtools check.csv inside each copy (or ask the harness to run it and read the output yourself). You should see: 2.000 from a copy where the fix worked. Anything else, or no change to labtools/plate.py, is a failed run, whatever the harness says.

Step 7 · Understand it (15 minutes). Provoke one failure on purpose: in one harness, set the context window to 8192 and reload the model with that length, then run the task again on a fresh copy. Note what happens and how the harness tells you. You should see: either an error or a run that stops early. Write down which.

Step 8 · Choose tools (15 minutes). Put your results in a short set-up guide for colleagues: approved model, the four values, the result of the practice task per harness, and the failure you provoked. You should see: half a page someone else could follow without you.

Exit check

Hand in the set-up guide: model and where it runs, the four values for each harness, pass or fail on the practice task per harness with the printed number, and one provoked failure with how each harness reported it.

It passes when a colleague can connect a harness from the guide alone, the practice task shows 2.000 for every harness you approve, and the guide says which model must not be used for agent work and why.

Rule to remember

A model becomes an agent model only after it passes a known-answer task in the harness your colleagues use; until then, it's a chat model.

Details for experts

Checked on 30 September 2026. You don't need this to follow the book; it's for setting things up or answering a colleague.

Further reading and tools

• T11-L02 · A Local Model Your Tools Can Call
• T11-L04 · Put Your Team's Assistant on a Server Colleagues Can Reach
• T12-L01 · Decide What You May Paste Into AI at Work
• T20-L02 · Choose a Harness by Testing It on Five of Your Own Tasks
• T20-L04 · Set Up a Harness So a Mistake Stays Small: Container, Rules, Keys and Network
• DeepSeek Harness: Taught
• OpenCode: Taught
• LM Studio: Taught
• LiteLLM: Catalogued
• Ollama: Catalogued