AI agents feel new because the model in the middle is new. The architecture around it is not. Strip away the vocabulary, and the pattern is familiar: instruction in, outside help when needed, result out.
In the database era, a query went to the database. It did the work, called out to a stored procedure when it needed something extra, and sent back a result. This is where I began my career writing VC++ and MS-SQL code.
In the internet era, a request went to an application server. It did the work, called out to APIs when it needed something extra, and sent back a response. By then I had moved into project and program management, but the architecture still had the same basic shape as the database-era pipeline.
Today, a prompt goes to a model. The model does the work, calls out to tools when it needs something extra, and sends back a result.
The shape is the same across all three eras. What changed is the engine in the middle, and that change matters because the new engine does not behave like the old ones.
The old engines kept their promises and were deterministic. You knew what would come back and in what form. If it came back wrong, that was a bug and someone had to fix it. A model makes no such promise. Ask it the same question twice and you can get two different answers. An answer can look perfect and be wrong. A new version of the model can get better at most things and simultaneously be worse at the one thing your business depends on.
Almost everything being sold as new AI architecture is really the work you now have to do because the engine stopped keeping its promises. That work shows up in three places.
First, the harness
People argue endlessly about what a harness is. To explain it in the language of the old world, I have seen it called an operating system, a kernel, a runtime and a driver layer, sometimes in the same conversation. When something attracts that many labels, it usually means the thing itself is simpler than the words around it.
At the most fundamental level, a harness is a loop. Ask the model what it wants to do. Do it. Tell the model what happened. Repeat until finished.
The engineering is everything you wrap around that loop, because you cannot trust the answer. Check the format. Retry when it fails. Block the tool calls that make no sense. Run the code somewhere it cannot cause damage. Stop and ask a human before anything that spends money or deletes data.
The hardest case is the one that looks fine. The answer is well formed, the system runs it happily, and it is still the wrong action. No amount of format checking catches that. Only someone who knows the business can tell. So the harness ends up carrying business rules that nobody planned to put there.
We used to call all of this plumbing, and nobody wrote about it. It matters now only because the engine on the other side became unreliable, or, more precisely, probabilistic.
Second, the context
Everyone worries about what comes out of the model. What goes in is the harder problem.
People compare the context window to memory in a computer. It does not behave like that. Everything you put in affects everything else. Where you put it matters. How you word it matters. You can add something completely accurate and get a worse answer than before.
A database never did that. Adding one more correct row did not change the meaning of the other rows.
So deciding what to put in front of the model becomes real work. What to include. What to shorten. What to leave out. What order to put it in. What to do when two documents disagree. Teams that just fill the window until it is full find out late, usually when real users arrive and the thing that worked in the demo starts drifting.
There is a security problem hiding in here too. Everything we ever built kept instructions separate from data. That separation is why so much of security worked at all. A model gets one stream of text. A document your own system fetched sits right next to your instructions, and the model has to read both.
So you cannot fix this by telling the model to ignore bad instructions. You fix it by limiting what the agent is allowed to do, no matter what it is talked into asking for.
Third, the evals, or testing put simply
This is the part most companies are least ready for. Old testing was pass or fail, and the engine sat still while you tested it.
Now the same input can give different answers, and the model itself changes underneath you. A new version reasons better and follows instructions worse. A prompt fix helps the normal case and breaks the odd one. A bigger context window remembers more and gets distracted more.
So testing becomes a numbers game. You run many cases many times and ask what percentage came out right, and you keep watching that number over time. It is closer to quality control in a factory than to software testing. Nobody asks whether one item was good. They ask whether the line is still running within limits.
That changes what a demo is worth. One good run proves very little, and one bad run proves almost as little. What matters is how the system behaves across a real spread of cases, including the rare ones that cost the most.
Most companies are trying to handle this with their normal build pipeline and good intentions, and it does not work. Without proper evals, you cannot change the system safely. And a system you cannot change safely is one people eventually stop touching.
A real example
Consider a financial services agent that triages real-time credit card fraud. It scores each payment as it arrives, flags suspicious transactions, and recommends whether to block, hold, or require step-up authentication.
Harness: the scaffolding around the model. This includes the streaming pipeline that scores payments in flight, the feature layer that turns raw transactions into fraud signals, and the hooks into card processing and the case queue. Guardrails matter most here: the agent can auto-block and open a case, but reversing a charge or closing an account still stays with a human.
Context: what the model sees for a transaction. The payment itself matters: amount, merchant, and geography. But so does the setup that gives it meaning: the customer’s normal spend, device history, location history, and velocity across cards. A $4,000 charge is routine for one customer and a screaming anomaly for another. The right context is the line between catching fraud and drowning people in false declines.
Evals: how you know the system is safe to act on. Offline, you measure precision and recall against labeled fraud, weighted by dollars at risk. Online, you track fraud losses prevented, false-positive rate, analyst acceptance, and the cost of each error, and you watch those numbers for drift over time. A false positive blocks a good customer. A false negative becomes realized loss.
The point for a financial services client is simple: the model is the least differentiated piece. The value is in the harness, the context, and the evals, especially when precision and recall are tuned to real dollar costs.
Where this leaves me
One piece (the model) changed, but it was the important one.
Selling this as an entirely new discipline overstates it. The pipeline is the same pipeline, and dressing it in new words creates more vocabulary than clarity. But waving it away as old plumbing with new labels misses just as badly, because that view assumes we still have guarantees we no longer have.
The job in front of us is not to invent a new architecture from scratch. It is to rebuild, at real cost, the certainty that earlier systems appeared to give us for free.