Agent harness
An agent harness is the software around the AI model. It gives your agent its instructions, tools, access, limits, memory and logbook, and it decides what the agent may do. We build the harness for your agents, so each agent reads your rules, reaches only what its job needs, and stops where a person approves.
This is for you if
- You tried an AI agent, and it did not know what your words and accounts mean.
- You would let an agent prepare entries, but nobody can say what it is able to change.
- When someone questions an AI answer, nobody can show where it came from or what the agent did.
What you leave with
- The result
- A harness your agents work inside. Its rules, tools and settings are files and code in your repository. The tools and data stay in your own cloud, and the model runs at the provider you chose.
- Rules it reads
- Your company dictionary, a written list of what your words and figures mean, and the rules for each job. Your agents read both before they work.
- Its own access
- Each agent reaches your systems through tools, often MCP servers, under its own access with only the rights its job needs. The guardrails sit in that access and in code, outside the model.
- The logbook
- Each step, tool call and result is written to the logbook, so you can see what the agent did and how. It is the audit trail when a result is questioned.
What we do, what you do
| We | You |
|---|---|
| Write your company dictionary and the rules for each job with you, as files in your repository. | Tell us what your words, accounts and approvals mean. |
| Build the tools your agents use and give each agent its own access, with only the rights its job needs. | Control the access: grant it, narrow it or withdraw it at any time. |
| Enforce the guardrails in access rights and code, and set where each job stops for approval, in the system where the work happens. | Approve prepared work where you already work. |
| Run evals, repeatable tests on known cases, before repeated work runs on its own, and rerun them on a schedule once it does. | Decide what counts as right, and check the results of what runs on its own. |
Worth knowing
The model decides how well an agent reasons. The harness decides what it sees, which systems it reaches, what it may do alone and what it can never do. Put a model in a chat window with no access and ask about this month's supplier invoices: it can explain how to post an invoice, but it has never seen yours. Give the same model a harness with read access to your invoices and your accounting system, and it can propose each posting with the invoice as its source, for a person to approve. Each job sits at one of three stages: "You ask, the agent helps", "The agent prepares, you approve", or "It runs on its own, and you check the results". The harness holds the work at its stage.
Your questions
- What does it look like in practice?
- At DuffBeauty, a beauty brand, the accounting agent reaches the accounting system through one connection that can write drafts and can never book. The external bookkeeper reviews the drafts and books them. Every call through the connection is logged, and if the log entry cannot be written, no answer goes out.
- Is this a product we have to license?
- No. The harness is code, rules and settings in your repository, and its tools run in your own cloud. You own it and can change it without us. You pay the providers of your AI tools and models directly. For our part, you pay a fixed price for the result, never for the hours our agents work; ongoing work is a fixed monthly fee.
- Does it tie us to one model provider?
- The harness decides which models an agent can use: Claude Code runs Claude models, and other harnesses offer models from several providers. Your dictionary and rules are plain files, and your tools connect through MCP, an open standard many harnesses support, so they can move with you to another harness.
- Where does the agent run, and where is the logbook kept?
- It depends on what we build and on your provider. An agent built for your company runs its code in your own cloud; an agent inside a vendor's product runs in the vendor's service; a coding agent runs on a person's computer. In every case the model runs at the provider you chose, and you decide where the logbook must live.
- How do we know it works?
- Evals run the agent on known cases, including the cases it must refuse, before repeated work runs on its own and again after every change of model, rules or access. Once the work runs, the evals are rerun on a schedule, and the logbook shows every step.
- Who changes the rules?
- Your team. When someone corrects the agent's work, the correction goes into the rules and the dictionary, so the same mistake is not proposed again. If something changes in a job that runs on its own, it comes back to you for approval.