> ## Content Index
> Fetch the complete content index at: https://www.anup.io/llms.txt
> Use this file to discover other available public pages before exploring further.

# The Next Wave of AI Engineering Is About Everything Around the Model
- URL: https://www.anup.io/the-next-wave-of-ai-engineering-is-about-everything-around-the-model/
- Published: 2026-10-19T15:37:30.000Z
- Updated: 2026-10-19T15:37:30.000Z
- Description: As AI models improve, the engineering challenge shifts to agent harnesses, data quality, evaluations, memory and security. Here's what it takes to build reliable AI systems.
- Author: Anup Jadhav
- Tags: Agentic Architecture, AI Agents, AI Engineering

*Why agent harnesses, data, evaluations and deployment are becoming more important than the models themselves.*

There’s a question I’ve been thinking about recently:

**If a significantly better AI model comes out next month, does your product get better or worse?**

It's a remarkably useful way of thinking about the current generation of AI companies. If your product is in essence just a model with a good interface, a better model could render much of what you've built redundant. If, however, you've built a system that can benefit from improvements in the underlying models, you may in fact become more valuable.

We've spent the last few years looking at models. Which model is best? What's the inference cost? Should we be doing fine-tuning or using prompting? What should the context window be? Those questions still matter, but I think the more interesting engineering problems are now to be found outside the model.

## The model is becoming one component of a much larger system

One analogy I find helpful is to think of the model as the **CPU**, the agent harness as the **OS** and *skills, tools and plugins* as the **applications**. It's not a perfect analogy, but it helps illustrate where a lot of the engineering opportunity may lie.

The model has the general capabilities. The harness determines how those capabilities are employed. It manages context, invokes tools, maintains state, coordinates execution, deals with errors and decides when human intervention is required.

Now imagine the underlying model suddenly becomes twice as capable. If you've designed your system properly, you should be able to benefit from that improvement without rebuilding everything around it. That's quite different from an architecture in which every workflow depends on one particular model.

Of course, the models aren't all the same. They differ in tool calling, adherence to instructions, latency, context handling and reliability. You still need to test when you're swapping models. But that's exactly why the harness is becoming such an interesting engineering layer.

![](https://storage.ghost.io/c/b1/a4/b1a432f8-3f63-4839-8020-97b63b6056f7/content/images/2026/10/01-the-agent-stack.png)

> **The engineering challenge is no longer simply about getting a model to do a job. It's about building a system that continues to work as the models underneath it change.**

## Vertical agent harnesses could become the next big software category

Lots of early AI products were described as GPT wrappers, often dismissively. I suspect agent harnesses will follow a similar pattern, just with a lot more substance. The most interesting ones are probably the vertical ones.

Think of an agent that assists an accounts payable analyst. The base model may well understand payment terms, read invoices and reason about discrepancies. But that doesn't mean you have a useful accounts payable system. It still needs access to supplier records, purchase orders, invoice history and approval rules, and it needs to know whether an invoice has already been paid.

I'd break a useful vertical harness into four parts:

1. **Connectors and context:** Reliable access to the systems, documents and business state needed to do the job.
2. **Domain evaluations:** Tests created by people who know what a valid outcome should look like, including the tricky edge cases.
3. **Execution and control:** Rules defining which tools the agent can use, what it can change and when it must stop.
4. **Human interaction:** A sensible interface for reviewing evidence, correcting errors and approving the work.

![](https://storage.ghost.io/c/b1/a4/b1a432f8-3f63-4839-8020-97b63b6056f7/content/images/2026/10/02-accounts-payable-agent-harness.png)

The model is important, but it's just one element of the product. Different jobs in the same workflow could also benefit from different models. You could use a cheaper, faster model for document classification, a more capable reasoning model for resolving invoice discrepancies (the tricky bit), and deterministic code for calculations where you don't want the output to be probabilistic at all. The routing decision itself could be incorporated into the harness.

But I'd steer well clear of building a complex multi-model architecture just because it's possible. Start with a baseline and use your evaluations to see whether routing actually improves cost, reliability or latency. **It's all about achieving a better outcome with the minimum amount of complexity.**

## Enterprise data is becoming more valuable, but also more problematic

There's increasing interest in giving agents access to all the information in an organisation. The proposed architecture sounds simple: connect the databases, documents and internal apps, expose capabilities via tools or MCP servers, and let agents get what they need.

Then you come to the actual data: five customer records relating to the same individual, contracts with inconsistent version histories, old decisions buried in Slack, PDFs without useful metadata and business definitions that mean different things to different departments.

None of this is new. Enterprises have been grappling with data quality and integration issues for decades. What's changing is the extent to which those problems affect the behaviour of AI systems. Access to more information does not necessarily mean access to better information.

This is a massive engineering opportunity in data preparation, entity resolution, provenance, access control and knowledge maintenance. But we need to be careful about assuming the answer is to build one massive, monolithic enterprise data layer before anyone can use AI.

Some groundwork is essential. You need reliable identifiers, authoritative sources, permissions and version histories. Other work might be better done incrementally, around actual business workflows. We can start with the information and controls a particular workflow actually needs, rather than trying to model the entire organisation upfront.

I think a lot of successful AI engineering projects will involve considerably more data engineering than prompt engineering.

## The most valuable datasets might be records of agents failing

There's a massive amount of focus on training data. Stories are circulating about data brokers making a fortune licensing specialised datasets to AI labs. The figures are hard to verify, and it's not clear how viable that market will be.

But another category of data interests me more: **real examples of AI agents failing in actual business workflows.**

Consider an agent processing a supplier invoice. It pulls the wrong purchase order, misses a mismatch in the amounts, calls the right API with the wrong parameters or suggests a payment that an experienced accounts payable analyst would reject. Or it goes into a loop because the procurement and finance systems contain conflicting information.

Each failure tells us something about the agent, the model, the tools available to it and the architecture around it. Now imagine systematically collecting those failures, including the task, relevant context, tool calls, intermediate decisions, final output, human corrections and eventual business outcome.

You could turn those examples into regression tests, work out which failure modes need better retrieval or different tools, and assess new model releases against the failures that actually matter to your users. You could also gauge whether the system is getting better over time.

Important privacy, confidentiality and data retention constraints apply. Enterprise traces often contain sensitive information, so collecting them indiscriminately would be a mistake. But with the right controls, **production failure traces could become one of the most valuable assets an AI engineering team possesses.**

![](https://storage.ghost.io/c/b1/a4/b1a432f8-3f63-4839-8020-97b63b6056f7/content/images/2026/10/03-production-failure-evaluation-loop.png)

## Evaluation is becoming a core engineering discipline

One thing that strikes me is the increasing need for people with good judgement who can turn that judgement into evaluations. Models are getting better at producing plausible answers, ideas, designs and plans. But a convincing output isn't necessarily a useful one. For many applications, the real difficulty is working out what good actually looks like.

Let's say you've built an agent that produces an invoice exception summary. You could compare it with a reference answer and measure semantic similarity. That's useful, but it doesn't tell you whether the accounts payable analyst trusts the summary, whether important evidence was left out, how long the analyst spends correcting it or whether the exception gets resolved any faster.

I'd want several levels of evaluation:

- **Component level:** Retrieval accuracy, tool selection and correctness of structured output.
- **Workflow level:** Whether the agent carries out the task, respects constraints and deals with failures.
- **Business level:** What happens when people actually use the output? Do they accept it, edit it, spend less time checking it or end up with additional downstream work?

Those signals are often more useful than whether the generated text looks like the ideal answer. They also change how we should think about model selection. If a cheaper model gives you the same accepted outcomes, go with it. If a more expensive model reduces the error rate enough to justify the cost, go with that one.

The key metric becomes **cost per accepted outcome**, rather than cost per token or cost per model invocation, provided those outcomes meet the required quality and safety standards.

## Memory could become one of the most important parts of agent architecture

A capable model can answer questions. A useful agent has to understand what has happened previously. It needs to remember decisions, preferences, unresolved problems and previous actions, especially for long-running work.

Imagine an agent working with a financial analyst over several weeks. On Monday it looks at a company and flags issues around revenue recognition. On Wednesday it reviews management commentary that addresses some of those issues. On Friday it puts together an investment summary. Without real memory, it treats each interaction as a standalone task.

But good memory is far more complicated than storing every conversation in a vector database. You have to decide what's worth remembering, separate observations from verified facts, track when information becomes stale and update memories when new evidence contradicts old conclusions. You also need deletion, privacy and access controls.

There's an important difference between remembering the user and remembering the work. A personal assistant might benefit from knowing your preferences. An enterprise agent needs to maintain task state, decisions, evidence and unresolved dependencies. These are different problems and are likely to require different memory architectures.

Some people are predicting agents that can watch someone working for a week and then replicate a large part of their job. Observation-based learning is an interesting area, especially combined with screen understanding, persistent memory and tool access. But a week of observation capturing everything required to do a complex job is a much stronger claim.

A screen recording doesn't tell you why someone made a decision, what exceptions they considered or which organisational constraints they were working within. The engineering challenge is turning those observations into a reliable model of the work, then verifying that the agent can perform it safely.

## Agent security is going to be a much bigger problem than many teams expect

Every new tool we give an agent increases what it can potentially do. An assistant that reads documents is one thing. An agent that can query customer databases, update financial records, send emails and change production systems is a different ball game altogether. The repercussions of a mistake are much greater.

The security issues aren't limited to traditional authentication and authorisation. An agent can encounter malicious instructions in documents, emails, web pages and tool outputs. It can be coerced into revealing information or invoking tools in ways the original user never intended.

Agent security has to be part of the architecture rather than something bolted on at deployment. I'd expect serious production systems to invest in scoped permissions, tool-level authorisation, sandboxing, audit trails and clear boundaries between trusted instructions and untrusted data. Sensitive actions may also require human approval, transactional safeguards or independent policy checks.

![](https://storage.ghost.io/c/b1/a4/b1a432f8-3f63-4839-8020-97b63b6056f7/content/images/2026/10/04-agent-trust-boundaries-enterprise.png)

This leads into another emerging concept: insurance for agent-operated processes. If an autonomous agent makes a mistake that costs a business millions, who is responsible? And what evidence would an insurer require before agreeing to cover that risk?

I think the answer will involve a lot more than a benchmark score. Insurers and auditors will want evidence of testing, controls, incident management and traceability. **The ability to explain and audit what an agent did may become just as important as the ability to get it to do the job.**

## Software is getting easier to reproduce. Does that shift the value?

One interesting development is how quickly agents can help recreate existing software functionality. This doesn't mean a production SaaS company can be replaced in an afternoon. Building the interface is often the easy bit compared with achieving reliability, security, scale and operational maturity.

But it does challenge our concept of software value. If the cost of reproducing an application's functionality continues to fall, what are customers actually paying for?

In some cases the answer may be the data, processes and integrations that have built up around it. A legacy SaaS company could have spent 15 years becoming part of the way its customers work. It has records, relationships, audit trails and domain knowledge that can't be recreated simply by writing code.

That could make some established SaaS businesses worth more than their interfaces suggest. But historical data isn't automatically a competitive advantage. It has to be useful, accessible, reliable and legally available for the intended purpose. Some customer data may be non-transferable or non-licensable.

If I were evaluating a legacy SaaS platform in an agent world, I'd want to know how much of its value is in the software, how much is in the workflows and data it manages, and how difficult those would be to replace.

There's an engineering opportunity here too. Traditional applications often involve people clicking through dozens of screens to complete a process. An agent could interact directly with the underlying systems via APIs. A good human interface still matters, but applications may increasingly be designed for two users: the human and the agent. That creates demand for reliable APIs, well-defined contracts, transactional operations and machine-readable documentation. It also creates room for companies whose product is a specialised capability that other agents call.

![](https://storage.ghost.io/c/b1/a4/b1a432f8-3f63-4839-8020-97b63b6056f7/content/images/2026/10/05-human-and-agent-interfaces.png)

## Physical AI reminds us that deployment is still the hard part

The difficulty of making AI work reliably outside a demo becomes even clearer in robotics and physical AI. Models are making progress in spatial reasoning, visual understanding, CAD workflows and control of physical systems. But getting a robot to perform a task in a controlled demonstration is a very different engineering problem from getting it to work reliably in the real world.

Real environments are unpredictable. Hardware fails, objects aren't where they should be and sensors produce imperfect readings. Sometimes the robot has to stop and ask for assistance.

What I find interesting is the feedback loop. Imagine a robot that handles routine operations but calls a human when it encounters something it can't deal with. You can record what happened, understand why it failed, create a new evaluation case and improve the next version. This is pretty much what we should be doing with software agents.

I wouldn't go so far as to say that all the remaining problems in AI are deployment problems. There are still significant open research problems. But as models become more capable, the engineering required to make that capability work reliably becomes more apparent.

## Building something useful isn’t the same as building something valuable

The AI market is moving lightning fast. Companies can grow revenue at a phenomenal rate, but that doesn't mean customers will stay. A product can be exciting enough to try and still fail to become part of someone's workflow. If a new model release removes the reason people were paying for it, that revenue can disappear just as quickly as it arrived.

Meanwhile, distribution is getting increasingly competitive. Companies are spending big to get attention, and a lot of technically impressive products are still struggling to find customers.

For engineers there are two lessons. First, pay attention to retention and actual usage. A technically impressive product doesn't necessarily solve a problem people return to. Second, don't confuse technical complexity with defensibility. The most sophisticated agent architecture isn't necessarily the best product. Sometimes a straightforward workflow using a good model, solid retrieval and a well-thought-out approval process is precisely what the customer wants.

The aim isn't to build the most sophisticated agent. It's to build something people can rely on and would notice if it was gone.

## What I’d focus on as an AI engineer

A few practical priorities emerge:

- **Build model-independent systems where it makes sense.** Keep model-specific behaviour isolated and maintain evaluation suites so an upgrade doesn't require a complete rewrite.
- **Invest in domain-specific evaluations.** Generic benchmarks won't tell you whether your agent is actually doing the work.
- **Treat data quality and provenance as product features.** An agent needs to know where information came from, whether it's current and whether the user is allowed to see it.
- **Design for failure from the outset.** Capture useful traces, establish recovery paths and provide appropriate human intervention.
- **Measure outcomes, not activity.** Tokens generated and tool calls completed are engineering metrics. Time saved, error rates and repeat usage tell you more about value.

And perhaps most importantly, **spend more time understanding the work you’re trying to automate.** People who understand a domain well enough to identify failure modes, define good outcomes and design the right constraints have an advantage over those who only know how to connect a model to tools.

---

Models will continue to improve and some of today's difficult tasks will become straightforward, and techniques that currently require elaborate prompting or orchestration may become unnecessary. That's a risk for anyone whose product depends on the limitations of current models, but an opportunity for those building systems that can take on more meaningful work.

Those systems will still need trustworthy data, domain knowledge, memory, evaluations, security, reliable execution and well-designed human interaction.

**The real opportunity is to build systems that get more useful as AI improves, rather than systems that become obsolete every time a better model arrives.**