A year ago, a conversation about an agent started with the question of which model to use. Now that question barely comes up for me: the difference between good models is smaller than the difference between what's built around them.
The scheme everyone started with fit on one line. Prompt, model, tool, answer. It works exactly until the task no longer fits in one step.
Where it breaks
The first time this shows is when the agent needs to take three actions in a row. It does the first, then the second, and by the third it no longer remembers why it started. Not because the model is bad, but because no one decided what exactly to show it at each step.
The second time it breaks is on an error. The tool returned the wrong thing, the model didn't notice, and confidently moved on. There was no one to check the result.
The third time it breaks is on permissions. The agent can do anything, so permission is asked for every action, and by the end of the day the person is tired of clicking "yes."
None of these breakdowns are fixed by switching models. They're fixed by adding a layer around the model that decides: what to show, what to remember, what to allow, who checks.
What this layer consists of
In my experience, the set turns out to be roughly the same no matter what you call it.
What the model sees right now. Not everything that has accumulated, but what's needed at this step. Separate work that usually falls to no one.
What it remembers between steps. Memory isn't a single database with vectors. Working memory for a step, session history, domain knowledge, and task structure all live by different rules and update at different rates. Putting them in one place is convenient right up until the first time you have to figure out why the agent recalled the wrong thing.
What it's able to do. Tools, access, boundaries. What matters here is not the list itself but what lies outside it.
Who checks the result. Tests, a second agent tasked with finding the hole, comparison against source data. Without this, the system confidently produces something plausible.
What's allowed without asking. What's allowed runs on its own, what's forbidden is technically impossible, and a person is called in only where a decision is genuinely needed. This is very different from an endless "allow this action?"
What this changes in practice
Improving a system used to mean "get a stronger model." Now it more often means "figure out exactly where it loses context, and fix that spot."
The difference is that the first costs money and ends once there are no better models left. The second costs work and never ends, but the result survives a model change.
There's an unpleasant consequence for planning here. This kind of work is hard to sell as "adopting AI": from the outside it looks like fiddling with settings. What you have to show isn't a demo but the change in the percentage of tasks that reach completion without a human.
Where this is going
This year's research shows the next step emerging: an environment that looks at its own execution logs and rearranges its own workflow to fit the task. It changes which tools to connect, what to put in memory, how to break the task down.
In other words, it's not just the model that starts learning. The structure around it starts to change too.
I'm calm about this, without much enthusiasm. Most systems still haven't settled the basics: it's unclear what the agent saw at the moment of a decision, its step can't be replayed, and no one is counting how many attempts ended in nothing. An adaptive environment on top of an unmeasured system will just produce more inventive ways to fail.
So the first question I ask is a boring one: what gets logged, and can you replay yesterday's run. If there's no answer, a conversation about agent architecture is premature.