Over the past year, I have spent more and more time interacting with AI agents. Interestingly, I increasingly hesitate to say that I work with an agent.
The agent is doing the work.
My role is gradually becoming something different: I observe, give direction, provide context, correct it when necessary, define boundaries, and decide when it is ready for more freedom.
Of course, an AI agent is not a child, and I do not mean this literally. But the interaction pattern is surprisingly familiar.
If I tell the agent exactly what to do at every step, there is little reason to have an agent. If I give it complete freedom without boundaries, the result can become unpredictable.
So the interesting question is somewhere in between: How much should I teach? How much should I control? And when should I simply observe and let it find its own way?
Unexpectedly, these questions have brought me back to many philosophy books I read years ago — about language, knowledge, reasoning, and human thinking. They also remind me strongly of my PhD years.
Research was rarely about following a known workflow. It was about observing something strange, reframing the problem, proposing an explanation, designing an experiment, being wrong, and trying again.
This made me wonder whether agent architecture may evolve through a similar process.
101 — Can the Agent Act?
The first generation is straightforward. Give an LLM some context, connect it to tools, and let it decide what to do next.
This is already a major change from traditional software. In conventional software, we explicitly program most execution paths. With an agent, we place a probabilistic reasoning engine inside the execution path.
I have gradually come to use a simple definition:
The LLM proposes. The workflow executes.
This is Agent 101. The question is simply: Can it act?
301 — Can the Agent Act Reliably?
Very quickly, we discover that being able to act is not enough.
Once an agent touches real infrastructure, code, data, customers, or money, we need something surrounding the intelligence: permissions, logging, timeouts, retries, cost limits, validation, failure handling, and human or specialist handoff.
This surrounding structure is what I think of as the agent harness.
The LLM remains probabilistic, but execution does not need to be uncontrolled.
This is Agent 301. The question changes from Can it act? to Can it act reliably?
501 — Can the Agent Navigate Complexity?
Then another limitation appears. Real problems are rarely linear.
Sometimes we need to branch. Sometimes several tasks should run in parallel. Sometimes one agent should ask another specialist. Sometimes we need to remember something learned yesterday.
Memory becomes important. Collaboration becomes important. State management becomes important.
The agent is no longer merely executing one path. It can navigate among many possible paths and compose existing capabilities depending on what it discovers along the way.
But I think there is an important boundary here. At Agent 501, the problem may be very complicated, but the capability space is still mostly known.
We have the tools. We have the specialists. We have the memory. We roughly understand what kinds of operations can solve the problem. The agent's intelligence lies in finding a good path through them.
So Agent 501 asks: Can it solve complex problems using capabilities it already has?
801 — What If Nobody Knows the Workflow?
This is where the idea becomes much more interesting to me.
What happens when the correct workflow itself is unknown?
This question immediately reminds me of scientific research. During my PhD, if somebody already knew exactly which steps to execute and what answer would come out, it probably was not a very interesting research problem.
Research starts when we do not know the path.
We observe. We reframe the question. We connect knowledge that may initially look unrelated. We form a hypothesis. Then we experiment. And importantly, we allow evidence to tell us that our beautiful idea was wrong.
The agent is no longer simply searching through existing workflows. It is attempting to expand its capability space.
But I think we should be humble and careful with the phrase self-evolving agent.
Changing its own prompt is not necessarily evolution. Generating another piece of code is not necessarily evolution. Even creating a new tool is not necessarily evolution.
For me, the missing ingredient is evidence.
A new approach needs to be tested. The result needs to be evaluated. A failed hypothesis should be rejected or refined. A successful result should be generalized. Only then should it become part of the system's reusable capabilities.
The next time the agent encounters a similar problem, it starts from a slightly richer capability space. That is what I currently mean by Agent 801.
Perhaps the Human Role Is Evolving Too
There is another side of this evolution that I find equally interesting.
As my agents become more capable, I spend less time doing the actual work. But that does not necessarily mean I do less.
I spend more time thinking about what problem should be solved, what context is missing, what boundaries should exist, what result should be trusted, and when I should intervene.
Perhaps this is why interacting deeply with agents keeps bringing me back to philosophy.
When the machine begins to execute more of the how, the human is forced to think much harder about the what and the why.
It also brings me back to scientific research. A good research advisor does not give a student every answer. A good experimental system does not tell the scientist what conclusion to reach. We construct an environment where ideas can be proposed, tested, rejected, refined, and eventually turned into knowledge.
Perhaps advanced agent systems will need something similar.
From Execution to Discovery
So, for now, this is how I see the evolution:
I do not know whether these numbers will still make sense several years from now. This is not intended to be an industry standard or a claim that today's agents have reached some form of autonomous intelligence.
It is simply a map that emerged from my own experience building and interacting with them.
But there is one transition I increasingly believe is important.
The runtime governs.
The system evaluates.
And eventually, the architecture preserves what works.
Maybe that is when an agent stops being merely a worker executing our workflows and starts becoming a system capable of helping us discover new ones.
And perhaps our job, as architects, is not to control every step. It is to build the environment in which that discovery can happen safely.