Precision AI: Agentic AI Where Accuracy Matters

Earlier this month, we had the pleasure of hosting a breakout session at the DIGIT.FYI AI Business Summit 2026 in Glasgow to talk about a question we often hear whenever customers see one of our agents in action, or use the output they produce:

"How did you get it to do that?"

It’s a revealing question that goes to the heart of building Enterprise Agents, because the answer is rarely “we picked the right model.” Most organisations have now seen an impressive agent demo. Many, though, struggle to deploy agents that survive contact with real work, real edge cases, and real consequences.

In our experience, production agents win on two things: the environment you build around the model, and the data you accumulate to optimise it.

In the session, we shared four rules we use on every agent we ship, and what this looks like in practice. This post shares the core of that talk, and why we believe models are commodities, but precision is engineered.

First, What Is an AI Agent?

“Agent” is one of those terms that now means different things depending on who is using it. For some, it means a chatbot with tool access. For others, it means a workflow with an LLM step somewhere in the middle. For us, the important distinction is whether the model is deciding what happens next.

Strip away the hype, and an AI agent is a loop. It receives a query, thinks about what to do, acts using the tools it has been given, observes the result, and then either finishes or goes around again. That is the agentic loop: think, act, observe, repeat.

This matters because the model is not simply filling in a template or producing one output. It is making decisions inside an environment. It is deciding whether it has enough information, which tool to call, whether an action worked, whether to continue, and when to stop.

Model choice still matters. The base model needs the reasoning, language, tool-use, domain, and sometimes multimodal capabilities required for the job. But model choice is only the starting point. The loop is only as good as the information, tools, constraints, and feedback wrapped around it.

Three things determine whether that loop produces reliable work or expensive noise:

• Context and memory: What the agent knows shapes what it does. Context is what the agent needs right now: the task, inputs, objective, and reference material for this call. Short-term memory is the working memory for the run: previous steps, tool outputs, decisions made, and scratch working. Long-term memory is what carries across runs: patterns, corrections, key facts, and examples of good and bad. Too much, too little, stale, or ungoverned memory can be as harmful as none at all. Good agents remember the right things. Great ones curate what the right things are.
• Tools: Tools are how the agent interacts with its environment. They come in three flavours: tools that reach into the environment to read from it, tools that act to change it, and tools that reflect so the agent can check its own work. Reach tools fetch, search, look up, or call specialist models. Act tools write, edit, send, execute, or otherwise create side effects. Reflect tools validate, verify, score, test, or critique. A good tool gives a clear signal back. A bad tool makes the agent guess.
• The harness: Everything wrapped around the model that determines what it sees, what it can do, what guardrails apply, and what it learns. The difference between a well-engineered agent and a fragile demo is often whether the agentic loop has been turned into a true environment for the task.

With that foundation in place, let’s look at the four rules.

Rule 1: Build a mental model of the task(s)

For precision, you can’t outsource understanding of the job to be done.

When people learn a task, they build a mental model of how it works. They learn the steps, the resources, the shortcuts, the edge cases, and the signs that something has gone wrong. They refine that mental model through success and failure, and eventually they use it to teach others.

Agents need the same kind of task model. You cannot assume an LLM knows how your organisation does the job just because it has read the internet or been trained on generic traces. The model may know the vocabulary of the domain, but it does not know your workflow, your preferences, your failure modes, or the tacit knowledge experienced colleagues use every day.

Before writing a single line of code, we ask:

• How would you teach a new hire to do this?
• What are the steps, the resources, and the failure modes?
• What unwritten knowledge do experienced colleagues rely on to do this well?
• Where does the job decompose into sub-tasks - and do any warrant their own agent?

This is not documentation for documentation’s sake. It tells you how to compose the harness: what context the agent needs, what tools it should have, where specialist models might help, what should become memory, and what needs to become an evaluation case.

Consider our Transcription Review Agent. Before development began, we wrote down the sub-tasks, the tacit knowledge, and the known failure modes.

That exercise directly shaped the build. Two of the sub-tasks became their own sub-agents. The tacit knowledge came from our reviewers, not from the internet. Every failure mode became an evaluation case in Rule 3.

The underlying point is simple: LLMs have read the internet, or been fed generic training traces. They haven’t done your job. Write the mental model down before you write the code, because the harness, the evals, and the flywheel all start here.

Rule 2: Craft a harness for your environment

The harness is the environment around the model. It defines what the agent sees, what it can interact with, which actions are allowed, which actions are gated, and what “act” really means.

This is where much of the production engineering lives. A weak harness gives the model a vague instruction, a large blob of context, and a few loosely defined tools. A strong harness turns the task into an environment with structured state, controlled actions, clear feedback, and enforceable rules.

When designing the harness, use the mental model from Rule 1. The task model should tell you which facts matter, what sequence of decisions the agent needs to make, what it must never do, and where the loop needs specialist help.

It answers questions like:

• What state should the agent see at each step?
• What tools does it need to act in the environment - and which of those are better served by specialist models?
• What memory should carry across runs?
• What must the agent never do - and how do you enforce that, rather than merely hope for it?
• Does the model you are using fit the loop you have designed?

That last question matters. Models are trained using different curricula, product goals, safety policies, and tool-use patterns. They have different strengths, weaknesses, and quirks. The loop and tools need to fit the model you are actually using, not an abstract ideal agent. Sometimes the right answer is a stronger spine, or orchestrating, LLM. Sometimes it is a smaller specialist model behind a tool. Sometimes it is changing the tool so the model receives a clearer signal.

A practical example is our automated editing capability for Adobe After Effects and Premiere. The same underlying LLM went from unusable to production-grade once we engineered the three ingredients every agent needs:

Same model, very different outcomes. Now it sees the composition, uses controlled tools, and remembers what works for each video family.

Rule 3: Define evaluation approach and dataset

Public benchmarks can be useful signals when developing models. They can show whether a model is trending towards a behaviour, whether a capability is improving, or whether a model family is becoming more useful for a class of problems. However, these benchmarks do not tell you whether an agent will work in your environment.

There are three common problems with public evaluation datasets:

• Contamination: Many benchmarks are present in the model’s training data, or training data is shaped towards them, so models can achieve high scores without demonstrating the capability you think they are demonstrating.
• Broken translation: Multilingual benchmarks are often machine translated for speed or cost, losing or distorting the semantics that made the original examples useful.
• Not your workloads: Generic tasks are designed to test broad capabilities. They do not reflect the distribution, constraints, interfaces, and consequences of your work.

This is why a model can score well on a medical multiple-choice benchmark and still be a poor fit for a clinical workflow. Doctors don’t pick between four labelled options. Neither does your agent.

For production agents, you need your own evals. That means defining success at the level of the job, but also at the level of the loop. If quality drops, you need to know whether the failure came from missing context, bad retrieval, an unsafe action, a weak tool response, the model’s reasoning, memory pollution, or the final generation step.

Instead, we recommend:

• Define what “good” and “bad” look like for your specific task. If you can’t articulate it, you can’t measure it.
• Measure the component parts of the loop, not just the end-to-end result. When quality drops, you need to know which step is responsible.
• Make your evals re-runnable. When the next model drops, you should be able to answer “should we switch?” in hours, not weeks.
• Ensure your dataset reflects real work, not just the happy path. The edge cases are where production agents earn their keep.

Thousands of representative examples beat hundreds of thousands from a benchmark you didn’t write. There is also a compounding benefit: a well-engineered harness generates continuous eval data for free, simply by running. Tool calls, intermediate decisions, validation results, corrections, and final outcomes can all become measurement points if you instrument them from the start.

Rule 4: Construct a data flywheel for improvement

Frontier labs and hyperscalers would like you to believe that general-purpose models will simply generalise to your task. Sometimes they do, at least enough for a prototype. Differentiated production AI, however, is still dominated by customisation: task-specific data, domain-specific feedback, specialist models, curated memory, and workflows that improve through use.

Every run of your agent - successful or not - should leave a signal behind. In this rule, we explore:

• What signal does every successful run leave behind?
• What signal does every failure leave behind?
• Where is the spine/orchestrating LLM doing work a specialist model could do better?
• What context lives in memory that should eventually live in weights?

What you instrument determines what you can improve:

Whilst we often look to build custom models for efficiency and cost reasons, not everything needs to be a bespoke model or a fine-tune.

Reflective learning also unlocks customised skills and memory: some improvements live as curated memories, reusable recipes, tool changes, or sub-agents the agent can reach for at run-time, encoding good practice without touching the weights.

The guiding principle is to pick the technique your data supports: instrument first, fine-tune second. Build the harness so that simply running the agent makes the next version better, while also giving you the evidence to diagnose edge cases when it fails.

In this framing, the spine, or orchestrating, LLM controls the agent’s path through the loop, while specialist models, whether LLMs or more classical ML models, can sit behind tool calls where they are a better fit for a specific task.

What does this mean?

For organisations moving agents from pilot to production, the implications of the four rules are clear:

• Precision starts with task understanding, not model choice. If you can’t explain the real job - its steps, failure modes, and tacit knowledge - you can’t build a reliable agent for it.
• Reliability comes from harness design. Structured state, controlled actions, and curated memory are what make the same LLM production-ready. Invest your engineering effort here.
• Sustainable advantage comes from instrumented feedback loops. Evals plus run-time signals turn each run into training data, so quality compounds over time - and becomes difficult for competitors to replicate.

If you’d like to learn more about our Precision Agent work, or want to discuss how these rules apply to your own agent initiatives, get in touch - we’d love to help.

To stay up to date on our latest blog posts, you can subscribe to our mailing list and/or follow us on LinkedIn.