An agent demo takes an afternoon. An agent in production takes considerably longer, and the gap is not about model quality.
It is that a demo runs once, watched by the person who built it, on an input they chose. Production runs thousands of times on inputs nobody anticipated, unwatched.
Build the evaluation harness first
This is the discipline that separates teams shipping reliably from teams shipping hopefully.
An eval harness is a curated set of cases with known good answers, run automatically against every change. Change the prompt, the model, the retrieval strategy or the tool definitions, and the harness tells you what got better and what silently got worse.
Without it, the loop is: change a prompt, try it on two examples, ship it. That works until the change you made to fix one category quietly broke three others, which you find out from users.
Building the harness before the product feels slow and is the single highest-leverage thing available. You cannot improve what you cannot measure, and with non-deterministic systems you genuinely cannot eyeball it.
What goes in the golden set
Real cases from your actual domain, not synthetic ones.
Include the easy ones, because regressions on easy cases are the most embarrassing. Include the hard ones you currently fail, so improvement is visible. Include the adversarial ones — malformed input, prompt injection attempts, edge cases that broke something previously.
A few hundred well-chosen cases beats thousands of generic ones. The set grows every time production surprises you, which is the mechanism by which the system actually improves over time.
Cost is an architecture problem
Inference costs scale with usage, and agent loops scale with difficulty in ways that are easy to underestimate.
An agent that cannot solve a problem does not stop. It tries again, with more context, calling more tools, until something halts it. One unsolvable input can cost more than a thousand routine ones.
What controls it:
- Route by difficulty. Most requests do not need your largest model. A classifier deciding which tier handles what cuts cost substantially with little quality loss.
- Cache aggressively. Repeated inputs are far more common than teams expect.
- Cap the loop. A hard maximum on reasoning steps, after which it escalates to a human rather than continuing.
- Measure cost per completed task, not per call. Per-call cost hides the loops.
Bounded autonomy
Decide explicitly what the agent can do without a human, and set the boundary by the cost of its worst plausible mistake.
Low risk: reading, summarising, classifying, drafting. Wrong output is an inconvenience.
Moderate: producing work a human approves before it is used. The human is the control.
High: anything moving money, contacting customers, or changing production state. These need explicit limits, confirmation steps and a rollback path.
The failure pattern is granting broad autonomy because the demo was impressive, then discovering the boundary through an incident. Set it deliberately instead.
Retrieval quality decides output quality
For anything grounded in your own data, the retrieval layer matters more than the model.
An excellent model reasoning over the wrong three documents produces a confident wrong answer, which is worse than an unhelpful one because it is believable.
Chunking strategy, embedding choice, hybrid search combining semantic and keyword matching, and reranking all move accuracy more than upgrading the model does — and they are testable, which the model is not.
Where data goes
For sensitive data this is an architecture decision rather than a policy one.
On-premise or in-region inference where the data cannot leave. Zero-retention arrangements with providers where it can. Explicit handling of what is logged, because prompt logs contain whatever users put in them.
Your team decides what the requirements are. We build to them, and it is much cheaper to build for in-region inference from the start than to move a system into it later.
Common questions
What makes AI agents hard to put into production?
Non-determinism, cost, and the absence of a natural test. The same input can produce different outputs, which breaks conventional testing. Costs scale with usage in ways that surprise teams whose demo ran fifty times. And an agent that is right most of the time needs a defined boundary around what it can do unsupervised, because the failures are what people remember.
What is an evaluation harness for AI?
A curated set of cases with known good answers, run automatically against every change to the prompt, model or pipeline. It is the closest thing to a test suite for a non-deterministic system. Without one, you are changing a prompt and hoping, and you will not notice the regression it caused on the cases you were not looking at.
How do you control AI inference costs?
Route by difficulty rather than sending everything to the largest model, cache aggressively where inputs repeat, cap the number of reasoning steps an agent can take, and measure cost per completed task rather than per call. Agent loops are where costs run away, because an agent that cannot solve something will happily try twenty times.
How much autonomy should an AI agent have?
As much as the cost of its worst plausible mistake allows. Reading and summarising is low risk. Drafting for human approval is moderate. Taking actions that move money or contact customers should be bounded explicitly, with defined limits and a human in the loop. The boundary is a product decision, and it should be set deliberately rather than discovered.
Does Corum8 build AI products?
Yes - agents, retrieval systems, document processing pipelines and the evaluation infrastructure underneath them. We build the eval harness alongside the product rather than after, because without it you cannot tell whether a change improved anything.
