MTMASON·TOMPKINS
SYS · ONLINE
← BACK TO THE BLOG
BLOG · ENTRY
BUILD LOG

The Deterministic Harness

2026-08-13

For fifty years, software was deterministic.

Either the code compiles or it doesn't. Either it does what you told it to do, or it doesn't. And when it doesn't, you chase the bug, fix the line, and it stays fixed.

That was the whole contract. Deterministic inputs, deterministic outputs. Reliability came from predictability.

LLMs broke that contract completely.

The same prompt, two different outputs

Paste the exact same prompt into the exact same model, with the exact same tools available — and you can get two completely different answers.

This has never been true in software before. Ever.

And part of it is a superpower. That non-determinism is why these models are useful. They can be creative. They can try a different path, make a new connection between two ideas, brute-force a problem until something clicks. Deterministic code can't do that. It can only do what you already told it to do.

So the creativity is real. But so is the cost.

Reliable means right the first time

When you ask an agent to do real work for you — move money, book a calendar, file something, write to your database, email a customer — you need to trust it will be correct the first time.

If you have to double-check every output, it's not a tool. It's a liability.

That’s the tension we’re living in: the thing that makes LLMs powerful (non-determinism) is the exact thing that makes them unreliable for real work.

Why most harnesses get this wrong

When I first started using OpenClaw and the other harnesses — Hermes, Odysseus, Claude Code, Codex — I ran into the same wall every time.

They rely too heavily on the LLM to do the work.

Everything happens in the chat. You ask for something, the LLM writes code to do it, executes it, and hopes it worked. The code it writes is deterministic, but the act of writing it isn't. It can import the wrong token, call the wrong function, hallucinate an API, forget a step, overwrite a file. There are a hundred ways it can go slightly wrong, and because the harness left that decision to the LLM, it will eventually go wrong.

They haven't codified enough of the workflow deterministically. The harness is thin. The brain is doing all the lifting.

And a non-deterministic brain doing deterministic work is how you get unreliable agents.

Shrink the blast radius

The fix isn't to make the LLM deterministic. You can't, and you shouldn't — you'd kill the creativity.

The fix is to make the harness do as much of the work deterministically as possible.

Think of it like a blast radius. Every time you let the LLM make a decision or write code, you expand the radius of things that can go unpredictably wrong. Every time you handle it in the harness — with a hard-coded plugin, a real connection, a tested skill, a typed function — you shrink that radius.

A reliable agent isn't a smarter LLM. It's a dumber blast radius.

Deterministic harness, non-deterministic brain.

Let the model do what only a model can do: reason, generate, connect ideas, make judgment calls. Let the harness do everything else.

How I'm building AYGENT

This is why I built AYGENT the way I did.

AYGENT isn't a chat wrapper that asks the LLM to go figure it out. The harness itself has hard-coded plugins, real connections to GitHub, Google, Notion, Stripe, Supabase — actual typed tools that either work or they don't. It has skills that are codified workflows, not just prompts.

The agent can still do a ton of non-deterministic work inside that harness. It can write, plan, synthesize, and create. But it doesn't have to reimplement how to send an email or move a file or query a database every single time. That path is already paved, deterministically.

The result is simple: it gets the job done correctly the first time way more often. Not because the model is better, but because we're asking the model to do less of the stuff it's bad at being reliable at.

You feel it immediately. You stop babysitting.

The balance to find

This is the whole game for the next few years of building with AI.

Too deterministic and you just have old software — predictable but not intelligent. Too non-deterministic and you have a brilliant intern who you can't trust to send an email without supervision.

The art is finding the balance: pulling as much as you can into the deterministic harness, so you can afford to let the brain be creative where it counts.

We spent fifty years learning how to make deterministic systems reliable. Now we have to learn how to make non-deterministic systems useful without making them unreliable.

The harness is how.