Harness Engineering
An agent is a model plus a harness — the software around it that supplies its tools, its information, its memory, its limits and its record. A model on its own is like a brilliant new hire on day one: it has read almost everything and knows nothing about your business. Harness engineering is what you build around it before you let it near anything that matters.
We did not write this up and hope. Our R&D wing is running it on our own HR and finance systems first, in public, and will publish what it cost and where we were wrong.
See what we are actually testing →Would you give a new hire the payroll keys on day one?
Of course not. On day one you give someone a job, the rules, a login that only opens what they need, and you expect a record of what they did. Nobody argues about this. It is how every organisation has always worked.
Then AI arrives, and all four go out of the window. The model is given a broad brief instead of a job. The rules live in a prompt that anyone can edit. It is handed a password that never expires. And when it gets something wrong, there is nothing to look at.
That is not an AI problem. It is a missing-harness problem — and it is the reason so many AI pilots stall the moment somebody in risk, legal or audit asks a normal question.
- It answers things it should notThere is no list of what it must refuse, so it does its best — confidently, and sometimes about a person’s health, pay or protected characteristics.
- It sees more than the person askingFiltering the answer afterwards is not permission control. It is luck.
- It has a key to everythingOne long-lived password, shared, never expiring. If it is wrong at 3am, nobody can tell you what it touched.
- Nobody can say what it didNo record of the question, the information used, or who allowed it. So the honest answer to “why did it do that?” is that nobody knows.
What is harness engineering?
Harness engineering is the work of building the software around an AI model that lets it act as a reliable agent. That means the tools it can call, the information it is given, what it remembers between steps, the place it runs, the permissions it holds, the checks that catch it when it goes wrong, and the record of what it did. The usual shorthand is agent = model + harness.
The term is also written AI harness engineering or building an agent harness, and the harness is often called the scaffolding around a model. Much of what makes one agent better than another lives in the harness rather than the model — though model capability still matters, and anyone telling you it does not is selling something.
Where we put our emphasis. Every part of that list is real work. Ours concentrates on one end of it — permissions, boundaries and proof — because that is the end where AI stops being allowed anywhere near the systems a business actually runs on. The other parts are on this page too: what it remembers is the three groups, and the checks that catch it are the other half. The five layers we describe below are our design rules, not standard vocabulary — a sensible way to build one, not the field’s official parts list.
If you arrived here about coding assistants — harnesses for tools like Cursor or Copilot — that is where most of the writing on this subject sits, and it covers the same ground: instruction files, tool permissions, sandboxing, context loading, and tests and linters that check the result. This page is about applying it to the systems your business runs on, where the hard parts become permissions, data residency and proving afterwards what happened. That application is less charted than the coding case, and this is our extension of it rather than settled practice.
Prompt, context and harness engineering are three different jobs.
These get used interchangeably and they are not the same. Each one answers a different question, and they arrived in that order as people discovered the previous one was not enough on its own.
Prompt engineering
“How do I ask this well?”Wording the request so the model does what you meant. Real skill, and where everybody started.
Runs out when the same prompt gives a different answer next month, and nobody can say why.Context engineering
“What should it know when it answers?”Getting the right information in front of the model at the right moment — the retrieval, the history, the documents.
Runs out when the model has good information and still does something it should not have been allowed to do.Harness engineering
“What is it allowed to do, and how do we know what it did?”The job, the rules, the one door, the expiring permission and the receipt. Everything around the model, including the two above.
This is the one that makes the difference once real systems and real permissions are involved.Put simply: prompt engineering is what you say, context engineering is what it knows, harness engineering is what it may do and what it leaves behind. The first two sit inside the third.
A model with five things put around it.
Same four things you would give a new hire, plus a written job description. Built from the inside out — the numbers are the order the work happens in, and each layer shows what it makes impossible. The plain words are on top; the engineering name is underneath, for anyone who wants it.
Steering it is only half a harness. The other half is catching it.
Martin Fowler, writing about this discipline, splits a harness into two kinds of part: the ones that steer before it acts, and the ones that catch it afterwards. Everything above this point steers. On its own that is not enough — steering only stops what you thought of in advance, and the trouble is always the thing you did not think of.
So the second half of the harness watches the thing work and tells you when it changes. It is the same job, not a different service, and we say that plainly because we used to describe it as separate and that was wrong. Fowler’s article is the clearest short read on the split.
Know what is live
Which version of the instructions, the model and the rules is actually running — written down rather than remembered. Ask most teams this and you get a pause.
How we do itTest before release
A set of real questions with agreed right answers, plus the ones that broke it before, plus what it must refuse. Run on every change, and able to stop a release rather than produce a report.
How we do itNotice when it drifts
Real answers sampled and scored the same way every week, so you hear about a change from your own dashboard rather than from a customer.
How we do itBe able to go back
Release to a few people first and undo automatically if the numbers get worse. A change nobody can reverse is a change nobody will make.
How we do it“If my two best engineers leave, what does that cost me?”
An ordinary question from an ordinary manager, and almost no company can answer it quickly. HR knows who might leave. Finance knows what they cost. The two systems barely speak. We picked this on purpose as the first real test of the harness, on our own platform, because every organisation has this exact pair.
- A file copied overnightHR data lands in finance once a day. Ask in the morning and you are working from yesterday.
- The rules are buried in the HR softwareWhat finance is allowed to see is written inside one application, where no other system can find it or check it.
- So the manager asks two teamsTwo requests, a few days, a spreadsheet, and no record of who decided what could be shared.
- Each side offers one clear jobHR offers “who is at risk of leaving, and why”. Finance offers “what this person costs”. Each has its own rules attached.
- Each side decides what it will shareNames are removed on the way out; role and tenure stay. Neither side has to trust the other — the rules are enforced at the door.
- The manager gets an answer, with its reasoningIn seconds rather than days, with the workings shown and a receipt an auditor can read afterwards.
Honest status: this is running now and we do not have the numbers yet. The question we most want to answer is the one a finance director would ask first — is this actually cheaper to change than the overnight file copy it replaces, or is it a second system on top of the first? We will publish the answer either way, including where we turn out to have been wrong. The findings paper is where it will appear.
Four to eight weeks to the first one. After that it gets quick.
The first job costs the most, because the shape of the job description, the rules, the record and the receipt are all decided once and then reused.
Find out what is already running
Which AI is live, who owns it, and what it can currently reach. We usually find something with its own private notes and something holding a password that should have expired months ago.
Write the job down
Pick the first job and describe it properly — what it does, what it costs, and the hardest part, what it must refuse. Done with the people who own the outcome, not only the developers.
Build the layers
The job, then the rules outside the job, then the one door, then the expiring pass and the receipt. In that order, because each one limits the next.
Prove it on one, then repeat
Run it end to end with a real person asking a real question. Publish the job description where other systems can find it. Switch off the old route once nothing is using it.
Six things, and they are yours whether or not we build the rest.
A list of what you are running
Every AI system and connection in the business, who owns it, what it can reach today, and which of the four basics it is currently missing.
A written job description for each one
Two to four pages: what it does, in words a machine can act on, what goes in and out, what it costs, how fast it is, where it may run, and what it refuses.
The rules, as something you can check
Not a paragraph in a prompt. A versioned list, enforced at the door, with every time a rule stops something written down.
A record format and a receipt
One shape for every answer: the question, what information was used, which version answered, what it cost, and who allowed it.
A shared dictionary
So one system’s “employee” and another’s “staff member” are known to mean the same thing, and nobody has to guess.
A way off the old route
The order of changes from what you have now to what you want, in steps that each stand on their own, with nothing switched off until nothing needs it.
Three groups: the ones that think, remember, and do.
The harness above is for one job. A platform has dozens, and they do not all belong in the same place. Keeping thinking, remembering and doing apart is what stops one of them quietly becoming all three. Our R&D wing calls this AIM — Agents, Intelligence, MCP — where MCP is the Model Context Protocol, the standard way a tool describes itself so an agent can use it without being told how.
Two rules do the work. Something that thinks may not keep its own private notes, because notes nobody else can see are how a system starts telling two different stories. And something that does things may not think, because a tool that makes its own judgement calls is a decision happening where nobody is looking.
We did not invent the word. Here is our work against somebody else’s checklist.
“Harness” is not our coinage — it is an established term, and the people who named it are worth reading. Databricks lists eight parts of a production harness. Rather than claim our own scorecard, here is every one of their eight and exactly where it sits in what we build, including the two we handle at platform level instead of per job.
The job — the one thing a capability is asked to do, and the instructions that shape how it does it.
The one door — every action arrives through a described tool, and the doing group is where those tools live.
Platform level, not per job: each capability’s work runs in its own isolated runtime, so one misbehaving job cannot reach another. We treat this as something the platform provides once, rather than something each capability carries.
The remembering group, plus the record of every answer. Nothing is kept inside the thinking part, which is the rule that makes the rest checkable.
The remembering group — three kinds of memory, because an agent asks three different questions: have we seen this, how do these relate, what is actually true.
The other half, below — testing before release, sampling after it, and undoing automatically. This is the part we used to send elsewhere.
The rules ring, checked outside the job so it cannot be talked out of them — with approvals themselves being tools that leave a record.
The receipt — who asked, on whose permission, what was used, what it cost. One shape for every answer.
The canonical definition is broader than any single vendor’s list: the software around a model that manages its tool use, memory, state, execution environment and feedback loops. Sources worth your time: Databricks on the agent harness, Martin Fowler on harness engineering and the Wikipedia entry on agent harnesses.
Where we agree
The model is the replaceable part. The interesting engineering is everything around it. A harness needs both steering and catching. Permissions and a paper trail are not features you add later — they are what makes the thing usable at all. None of that is controversial, and we are not going to pretend we discovered it.
Where we are different
Most writing on harnesses is about coding assistants — the tools developers use, and it covers the same ground we do. Ours is about the systems your business actually runs on: the HR platform, the ledger, the student record. That changes the hard part from code quality to permissions, residency and evidence. Being straight about it: the coding case is well established and this business-systems application is much less charted — we are extending the idea, not reporting a consensus. The platform vendors also describe their own runtime; we wrap what you already own and stay able to move.
Our R&D wing published every step, in order.
We did not invent a framework for a sales page. The Software Lens is Aitina Tech’s research wing, and the harness was worked out one paper at a time and published as it went — so you can read the reasoning, and the dates, before you hire anybody.
Browse the lot in The Software Lens — research articles, video episodes and the work in progress.
Find out where you actually stand — and only pay if the report tells you something.
Four to six weeks. An independent evaluation of your process, your technology, your AI readiness, your security posture and the distance between the strategy at the top and the work being done. Delivered as a written report with the evidence and the reasoning attached.
- Process, documentation and productivity gaps
- AI readiness, and how AI tools are really being used
- How competitive your tech stack actually is
- Security posture and how far you are from ISO certification
- CEO vision drift — strategy at the top versus work on the ground
- Silos, flywheel, Big Rocks, OKRs, PMO and micro-management
- Architecture advice, with the reasoning shown
- We audit our own delivery work on the same terms
Questions we get asked
What is harness engineering?▼
It is the work of building the software around an AI model that lets it act as a reliable agent: the tools it can call, the information it is given, what it remembers between steps, where it runs, the permissions it holds, the checks that catch it when it goes wrong, and the record of what it did. The shorthand is agent = model + harness. Much of the difference between a demo and something you can put in front of customers sits in the harness rather than in the model.
Is harness engineering the same as prompt engineering?▼
No. Prompt engineering is how you word the request. Context engineering is what information the model has when it answers. Harness engineering is what it is allowed to do at all, and how you know afterwards what it did — and the first two sit inside it.
What do the five layers on this page correspond to?▼
They are how we build a harness, not the field’s official parts list: one clear job, rules it cannot break, one way in, a permission that expires, and a receipt for every answer. They cover the control-and-evidence end of the canonical definition. The tools, context, memory and feedback-loop parts are handled in the other sections of this page.
Why does this matter more than which AI we choose?▼
Because your competitor can buy the same model on the same afternoon. What they cannot buy quickly is a system where the AI physically cannot reach your payroll without a written job description and a permission that expires. Two companies using the same model get very different results, and nearly all of the difference is in what surrounds it.
We already have AI running. Can this be added afterwards?▼
Usually, and it starts with a list rather than a rebuild. The common finding is that two of the four basics are already missing — something keeping its own private notes, and something holding a password that should have expired. Both are fixable without starting again.
Is keeping track of versions part of the harness, or separate?▼
Part of it. Steering the AI and catching it afterwards are two halves of the same harness, which is why the catching half is on this page rather than filed under something else. What is separate is the depth: the tooling for versions, release tests and drift alerts has a page of its own at MLOps and model governance. Same job, more detail.
Does this slow us down?▼
The first job is slower. Everything after it is faster, because the shape of the job description, the rules and the receipt are already decided. The teams that experience this as friction are usually the ones that skipped writing the job down.
Who needs to be involved from our side?▼
Fewer people than you would think, but not only developers. Writing down what a job must refuse needs whoever owns the outcome — the HR director, the finance lead — because that is a business decision wearing technical clothes.
Why publish your own architecture if it is your advantage?▼
Because the advantage is in building it, not in knowing about it. Publishing also keeps us honest: a paper with a date on it can be checked against what we actually shipped, and the findings paper will say where we were wrong.
Can you do this with software we have already bought?▼
Often, at the edges. A system you cannot change is treated as something to wrap rather than rewrite — you put the job description, the door and the rules in front of it. That is the normal case, not the exception.
One free hour. No pitch, no obligation.
Bring the problem you are stuck on — an integration that keeps breaking, a cloud bill nobody can explain, an AI project that is all demo and no product, or a platform you are about to invest in. You will leave with a straight answer and a written summary, whether or not you ever work with us.
- Architecture and integration review
- AI feasibility — what will actually work, and what will not
- AWS, Azure and Google Cloud cost and design
- Business process audit and ISO readiness
- Technical due diligence before you invest or acquire