Most AI demos ask one question: can the model do the task once?
Production systems ask a harder question: can the work happen repeatedly, with the right context, the right tools, visible failures, scoped permissions, and a recovery path when the model gets something wrong?
That second question is where the real engineering work starts.
The model still matters. But the model is only one part of the system. The harness is the part that turns a model response into controlled work: tools, state, permissions, traces, approvals, recovery, and evals.
In real enterprise workflows, the harness decides what the agent can see, what it can do, how its work can be inspected, and how failure gets handled.
If that sounds like ordinary software engineering, that is the point. Agents do not remove the need for production discipline. They move more of that discipline into the layer around the model.
Where the demo breaks
A demo can hide missing control surfaces.
The model gets a clean prompt. The context is curated by hand. The tool call is obvious. The user watches the whole run. If something looks wrong, the person running the demo quietly adjusts the prompt or reruns it.
That is useful for exploration. It is weak evidence for production.
Now put the same capability inside a support workflow. The agent drafts a refund response. It checks account history, reads the current policy, calls a customer record tool, and decides whether the refund needs manager approval.
The risk is not that the model writes an awkward sentence. The risk is that the system cannot answer basic operating questions:
- Which policy did it use?
- Was that policy current?
- Which customer fields did it read?
- What approval threshold applied?
- What did it do when policy and customer history conflicted?
- How would the team replay the run if the customer escalated?
Those questions are harness questions.
What the harness needs
First, it needs tool contracts. The agent should know what each tool does, what inputs are allowed, what outputs mean, and what failure looks like. Tool access without a contract is a permission problem waiting to happen.
Tools are capabilities, not magic
A model does not usually use a tool directly. The application exposes a tool definition. The model proposes a call and arguments. The runtime validates those arguments, decides whether the call is allowed, and sends the request to the real API, function, file operation, search index, ticketing system, or workflow. The result comes back to the model and belongs in the trace.
That distinction matters: the model can propose an action. The harness should decide whether that action is allowed.
The contract needs more than a name and description. It should state allowed inputs, expected outputs, error and retry behavior, the identity used, permission scope, approval and audit requirements, and the rollback or compensation path when one exists.
I find it useful to separate tools by verb: read, write, execute, send, spend, deploy, and delete. Each verb deserves a different boundary. “Read customer policy” and “issue refund” are not the same kind of capability. One is a read; the other is a financial action, with different permissions, approvals, logs, and recovery paths.
State is the working record
State is the record the workflow carries forward: the task, context used, decisions made, actions attempted, pending approvals, retries, and handoffs. A chat transcript is not enough when work crosses systems, people, and time.
For a refund case, state might include the policy version, amount, customer history, approval status, and escalation reason. That gives the next person or system a record to continue from rather than a conversation to reconstruct.
Approvals make boundaries visible
Approvals are not a general pause button. They mark decisions that cross a financial, external, production, regulated, or irreversible boundary. Escalation is what happens when the agent cannot resolve a conflict safely.
An agent may prepare a refund recommendation, but a threshold or policy conflict should route the decision to a person with the relevant evidence attached. The goal is not to slow every action. It is to make the boundary explicit before an action is taken.
Traces are the evidence
A trace is more than an application log. It is the execution record: model calls, sources retrieved, tool calls and results, retries, approvals, and human interventions. The final answer tells you what happened. The trace gives the team a way to inspect how it happened.
That makes debugging, audit, replay, and review possible. Without the path, a plausible answer is thin evidence.
Evals turn failures into improvements
Evals turn expected behavior and past failures into repeatable checks. They should look beyond the final answer: did the agent select the right tool, use the right source, honor an approval rule, stay within a latency or cost budget, and recover appropriately?
If an agent once used an expired policy, that miss should become a replayable regression case. The team can then see whether a model, prompt, tool, or policy change fixes the workflow without creating a new failure elsewhere.
This is the work that makes autonomy reviewable and recoverable.
What leaders should fund
The practical funding question is not only “which model should we use?” It is “which parts of the harness are currently unowned?”
If the answer is unclear, the agent program is probably still in demo mode.
At scale, the harness becomes a platform charter: shared capabilities, clear boundaries, quality gates, operating metrics, and ownership when the agent is wrong or blocked.
I would start with a simple inventory:
- What tools can the agent call?
- What data can it read?
- What can it write, send, deploy, spend, or delete?
- Which actions require approval?
- Where are traces stored?
- Which failures become eval cases?
- Who owns recovery when the agent is blocked or wrong?
That inventory often exposes the real gap. The team may have a model integration, but no approval model. Or good retrieval, but no trace replay. Or a clever prompt, but no rollback plan. Or a workflow that works only because a human is silently babysitting every run.
It also gives leaders a cleaner way to assign ownership. Platform teams may own tool contracts and traces. Product teams may own acceptance criteria. Security may own permission boundaries. Operations may own escalation and recovery. The agent itself is rarely owned by one group in practice, so the harness has to make those boundaries visible.
Write that ownership map before the agent moves into a real workflow. Otherwise the first serious failure becomes a meeting about responsibility. Product thought platform owned quality. Platform thought the business owner accepted the risk. Security thought the action needed approval. The harness should make those assumptions explicit while the stakes are low.
That is the map, not the whole territory. The rest of this series is about the parts of that harness leaders need to own: the trace, the context path, the access map, the routing table, the skill package, the review gate, and the workflow edges where people remain accountable.
A lot of the failures leaders can actually fix are in the system around the model.
That is good news for leaders. It means the next improvement may not require waiting for a better model. It may require making the current system inspectable, constrained, and recoverable.
Before you fund another agent pilot, ask where the system currently makes decisions that no human, log, eval, or permission model can inspect. Here are a few practical ways to start finding out.
A few things to try
- Start with a harness inventory. Pick one agent workflow and write down what it can read, what it can write, which tools it can call, which actions require approval, where traces are stored, and who owns recovery when it gets blocked.
- Write one tool contract. This is the part I am spending more time on now. It is easy to let an agent use whatever tools the environment exposes. Pick one tool and document what it does, its allowed inputs and outputs, its errors, the identity it runs as, and which calls require approval. “Read repository file” and “edit deployment configuration” should not live behind the same generic file-access permission.
- Add one approval rule before another capability. Choose a risky action, such as sending an external message, changing a customer record, opening or merging a pull request, spending money, or touching production configuration. The point is not to slow everything down. It is to make the boundary visible.
- Turn one failure into a regression case. Take a recent agent miss and ask what the harness should have captured: the source used, tool called, retry attempted, approval skipped, or recovery path needed. Then make that failure replayable.
- Draw the ownership map. For one workflow, label what product, platform, security, operations, and the human reviewer own. If every box points back to “the agent,” the operating model is not ready yet.
Where does your AI system currently make decisions that no human, log, eval, or permission model can inspect?