When an agent pilot never makes it to production, the model is rarely to blame. The culprit is the harness: the scaffolding around the model that decides which tools it can use, with what permissions, what it remembers between steps, what happens when something fails, and how much it can spend before someone stops it.
The model is a component you can swap out in an afternoon. The harness is the product.
What’s inside a harness
Tool definitions. Every action the agent can take — querying the ERP, creating an order, sending an email — is described precisely: what it does, what parameters it accepts, what it returns, and what side effects it has. A vague description produces an agent that confidently uses the wrong tool.
Permissions and scope. Separate read and write access, credentials scoped to the bare minimum, and an explicit list of what the agent can’t touch. It’s the same principle as with any new hire: access to the system, yes; access to the whole system, no.
Memory and context. What gets passed to the model at each step, what gets summarized, what persists between runs, and what gets dropped. An agent that drags its entire history along becomes expensive and confused; one that remembers nothing repeats work and loses the thread.
Retries and recovery. What happens when a tool returns an error, when the model outputs something that can’t be parsed, or when an external call goes down. Retry with exponential backoff, a fallback path, or escalation to a person.
Human approval checkpoints. Irreversible actions — paying, deleting, contacting a customer — pause and wait for confirmation. Everything else flows. Drawing that line well is a business decision, not a technical one.
Spending and step limits. One cap per run and another per day. Without them, a loop nobody anticipated burns through a quarter’s budget overnight.
Traces. Every run records what the agent decided, with what information, and with what result. Without traces, there’s no debugging and no defense in an audit.
Why the harness is where you win or lose
An agent without a harness works in the demo because the demo is driven by whoever built it. In production it meets dirty data, slow systems, cases nobody planned for, and users who ask for strange things. The harness absorbs all of that — or nothing does.
It’s also what lets you change models without redoing the project. With solid scaffolding, swapping the model underneath is one line of configuration and an evaluation run; without it, you start from scratch.
When building your own harness makes sense — and when it doesn’t
It makes sense when:
- The agent will take real actions on company systems, not just draft text
- More than one use case is planned: the harness pays for itself from the second agent on
- The process involves sensitive data or decisions with financial consequences
- You want to keep the freedom to switch model providers
It doesn’t make sense when:
- The use case can be solved with classic automation or an n8n workflow
- It’s a proof of concept to decide whether to continue: validate the value first, then industrialize
- Nobody will maintain the system afterward: a harness without an owner degrades within months
How we approach it
We start with an inventory of the actions the agent will need to take and with the risk boundary: what it can do on its own and what requires a human signature. From there we define the toolset, permissions, spending caps, and error protocol. We build the evaluation before the agent, not after: without a way to measure whether it works, there’s no way to know whether a change makes it better or worse.
As an independent lab, we don’t resell agent platforms. If an off-the-shelf tool solves your case, we’ll tell you.
Frequently asked questions
Is a harness the same as an agent framework? No. A framework provides parts; the harness is the decision on how they fit together for your case: which tools exist, what permissions they have, where the agent stops, and how much it can spend. You can build it on top of a framework or without one.
Can it be reused across different agents? That’s the idea. The first one is the expensive one; from the second agent on, you reuse the tools, permissions, traces, and limits.
How much does it add to the project cost? It’s most of the real work in an agent project. Presenting it as an optional extra is what leads to pilots that never get past the demo.