Anatomy of an Enterprise Harness: The Pieces an Agent Needs in Production
Anatomy of an enterprise harness: the 12 pieces an AI agent needs in production, explained in business terms so you know exactly what to demand from a vendor.
The problemYou are being pitched AI agent proposals and you are not sure which pieces they should include to actually work.
Wednesday, 11:20 p.m. At an immigration law firm, an agent is processing a batch of case files so they are ready by morning. On document 40, the service that reads PDFs takes too long and stops responding. The agent halts. At 8:30 a.m., the case manager opens the system and has no idea which files are complete, which are half done and which were never touched. She loses the morning checking by hand.
The AI model did not fail. Pieces of the enterprise harness were missing: the infrastructure around the model that lets it work reliably. This article is a map of those pieces, explained in business terms, so you know what to demand in any proposal.
First, the principle
In 2026 the formula Agent = Model + Harness took hold. The model reasons; the harness decides what it sees, what it can do, which rules it follows, who approves and how everything is logged. If this concept is new to you, start with what harness engineering is and come back here for the details.
A harness is not a single piece of software. It is a set of components working together, the same way a company is not just its people but also its processes, controls and records.
The 12 pieces of an enterprise harness
The table below summarizes each component, the business question it answers and what happens when it is missing.
| Piece | What it does, in business terms | If it's missing… |
|---|---|---|
| Context assembly | Builds, for each task, the exact package of information the agent needs | The agent works blind or with data it shouldn't have |
| Agent loop | Defines how the agent thinks, acts, checks and decides it is done | It stops halfway or goes in circles without finishing |
| Tool registry | Lists which systems the agent can use and with what permissions | It can touch what it shouldn't, or can't reach what it needs |
| Memory | Stores what the business knows about each client, case or project | Every task starts from zero |
| Policy engine | Enforces rules the agent cannot break | Unauthorized promises, discounts or actions |
| Session and state | Tracks which step each task is on | You don't know what got done and what didn't |
| Retries and recovery | Retries, switches providers or resumes from the last checkpoint | A minor failure stops the whole process |
| Human approval | Requests sign-off from the right role before key decisions | Something reaches the client that nobody reviewed |
| Multi-agent routing | Decides which specialized agent handles each part of the work | One agent tries to do everything and does it poorly |
| Traces and telemetry | Records what each agent did, with which data, cost and time | You can't explain an error or control spending |
| Sandboxed execution | Runs risky actions in a closed, controlled space | An error or an attack reaches critical systems |
| Evals | Tests that measure the agent's quality before and after every change | You find out about errors from your client |
Now, the pieces grouped by the function they serve.
What the agent knows: context, memory and state
Context assembly prepares the "folder" for each task: the client profile, the relevant document, the applicable rule. It does not hand over everything; it hands over what is needed. Memory is the business's permanent record, shared by all agents. Session and state is the day's notebook: which step each case file is on.
What the agent can do: loop, tools and sandboxed execution
The agent loop is its working method: understand, plan, act, verify. The tool registry works like an access list: this agent can read the CRM but cannot delete records. Sandboxed execution is a closed room where the agent runs risky tasks without being able to affect the rest of your systems.
What the agent cannot do alone: policies and human approval
The policy engine is the list of "nevers" that gets checked automatically: never send one client's documents to another, never quote a deadline shorter than the legal one. Human approval is the sign-off of a person in a defined role before anything important leaves the company.
What keeps the system running: retries, routing, traces and evals
Retries and recovery matter more than they seem to. Datadog's State of AI Engineering 2026 report found that 5% of model calls in production returned an error, and that capacity limits, rate limits and timeouts accounted for 60% of those errors. A harness that resumes from the last checkpoint turns those failures into a pause of a few seconds.
Multi-agent routing splits the work among specialists, like a team lead. Traces and telemetry are the system's black box; we cover them in observability for AI agents. Evals are continuous quality control: a set of real cases the agent is measured against every time something changes.
Illustrative example: the same night, with the full harness
Back to the firm from the opening, now with every piece in place.
- Routing assigns each case file to a specialized agent: one classifies documents, another checks requirements, another drafts the letter to the client.
- Context assembly gives each one only the case file and the applicable regulations.
- On document 40, the reading service does not respond. The retries component waits, tries again and, if it keeps failing, switches to an alternative provider.
- Session and state marks exactly which files are complete.
- The policy engine blocks a letter that mentions an incorrect deadline.
- Valid letters wait for human approval from the responsible case manager.
- Traces record everything, with cost and time per case file.
At 8:30 a.m., the case manager opens a clear list: 58 files ready to sign, 2 blocked with the exact reason. Those numbers are illustrative, but the pattern is what allowed an immigration law firm we work with to go from 15–20 to 80–100 active cases per case manager. We tell that story in the AI-native law firm.
How to use this map in a proposal
When an internal team or a vendor pitches you an agent project, walk through the table and ask about each row:
- Does this piece exist in the proposal, or is it assumed?
- Who maintains it once the system is in production?
- Is it shared across agents, or built once for each one?
- What does it look like when it fails?
If more than three rows come back without a clear answer, what you are being offered is a pilot, not a system.
Common mistakes
- Investing everything in the model and nothing in the pieces. The model is one row out of twelve.
- Adding the pieces later. Retries, traces and approvals are far more expensive to bolt on once the system is in use.
- A different harness for every agent. It multiplies maintenance and produces contradictory rules.
- Evals nobody updates. If the test cases do not reflect current operations, they are measuring a business that no longer exists.
What to do on Monday
Print the table and bring it to your next AI meeting. Mark which pieces you have today, which are half built and which do not exist. That half-hour exercise usually clarifies more than any demo.
At Addabra, we do not start each project from scratch: we build each company's system on our own proven harness, which already includes these pieces, and adapt it to your processes, roles and rules. That way the effort goes into what makes your business unique.
Frequently asked questions
Does every company need all 12 pieces of an enterprise harness?
In production, almost all of them show up in one form or another; what changes is how deep each one goes. A low-risk internal agent can get by with a simple policy and occasional approval, while one that touches money or clients needs every piece done rigorously.
Which piece gets forgotten most often?
Retries and recovery, along with traceability. They are invisible in a demo, but in real operations they determine whether a provider outage becomes a minor hiccup or an entire morning spent reconstructing what happened.
Do I have to build the harness from scratch for every agent?
You should not. Ideally there is one shared harness on which each process's agents are built, sharing memory, policies, approvals and observability. That way every new agent costs less and behaves consistently with the rest.
