The Anatomy of a Harness

A language model is a function. You give it text. It predicts the next piece of that text, then the next, until it stops. It does not have your files. It cannot search the web unless something else searches for it. It cannot send mail, open a pull request, or know that last week's summary already exists on disk. Left alone, it is a very good guesser with no way to reach your files, your mail, or the rest of the machine.

A harness is the software around that guesser. It decides what the model is allowed to see, which actions it is allowed to ask for, when the work is finished, and how you tell whether the result is any good. Chat is you and a model taking turns in a window. A harness is a process: same brief, same tools, same checks, next week.

MAUDE is a harness I built for myself. The models are Nemotron on a DGX Spark, plus cloud models when the job needs them. The harness is everything else: one gateway, a catalog of tools, a loop that can call those tools and come back, a log of what happened, and a stop when the job is done or a budget runs out. You talk to MAUDE from a terminal, a Mac client, a phone, Telegram, or a web dashboard. The model never sees that. It sees a request, a short list of tools, and whatever context the gateway packed for this turn.

Work repeats. Monday you asked a chat box to summarize a folder of notes. You pasted three files, forgot the fourth, got a draft, argued with it, and by Thursday you could not remember which prompt actually helped. Next Monday someone else has the same job. The chat is gone. The method was never written down. That is not a workflow. That is a lucky afternoon.

A harness is useful because it takes the job out of whoever happened to be typing. The brief lives in the system. The tools have names. The checks run whether you are watching or not. You can inspect a bad run instead of reconstructing it from memory.

ChatGPT, Claude, and Gemini are products. They wrap a model in their own harness: memory they choose, tools they choose, logs you do not own. That is fine until you need the model to touch your mail, your repo, your machine, or a local model that never leaves the building. Then you either live inside their product or you build the wrap yourself.

I built MAUDE because I did not want three apps, three bills, and no shared context. I wanted Claude when the job needed it, a local model when the file should not leave the Spark, and the same tools either way. The harness is what makes those models interchangeable. The user asks. The gateway picks a model, clips the tool list, runs the calls, and streams the result back.

Introduction to AI is how you put a live task in front of a model for the first time. A harness is how that task stops depending on a prompt you will not remember.

Say you ask MAUDE to draft a reply to a client thread and attach the latest schedule from Drive. You are not talking to Claude or Nemotron. You are talking to the gateway. The gateway reads the request and does the unglamorous work the model cannot do for itself.

It picks a model for this job. It does not send the full tool catalog. It activates the tools that look relevant: mail, Drive, maybe calendar. It packs a window: standing instructions, this message, those tool descriptions. Then it sends that package to the model.

The model cannot fetch the thread. It can only say, in a format the gateway understands, that it wants to call a mail tool with these arguments. The gateway runs that call, or refuses it, and hands the result back. The model reads the result and maybe asks for a Drive file. Same pattern. When it has enough, it writes the reply. The gateway returns that to you, with a trace you can open if you want to see which tools fired and how long they took.

None of that is the model being clever. The model is still predicting the next token. The harness is what made \"draft a reply and attach the schedule\" possible. Without it you would be pasting the thread into a chat box, downloading the schedule yourself, and hoping you remembered to say who the reader is.

Do not start by cloning MAUDE. MAUDE is a daily driver with 170 tools and five clients. That is years of wrapping. Start with one job. Write the brief. Give the model one or two tools. Check the output against something you wrote down. Log the calls. Run it a second time on a new example. If that works, you have a harness. You can add tools later.

The parts below are the same parts in MAUDE. On a first harness, most of them are a Python script and a folder of files. That is enough.

A first harness might be: a standing prompt, a folder of source files, one function that searches that folder, a second function that writes a draft to disk, and a third that diffs the draft against last week's. Run it twice. If the second run still matches the spec, you have something you can hand to a teammate.

MAUDE grew because the jobs grew. Mail, calendar, GitHub, a phone client, a local model that never leaves the Spark. The anatomy did not change. There is still a job, a brief, a window, tools, a loop, and a check. There is just more of each. If you copy the size and skip the anatomy, you get a chat box with extra buttons.

Read the MAUDE case study if you want the full stack. The lesson here is the wrap, not the hardware.