Raising an Agent

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 realize that building an agent is, in a strange way, also about rediscovering how humans already work. We use context before we act. We choose tools. We check our work. We remember what happened before. We ask other people when we need expertise. And when no known procedure works, we experiment and learn.

First: What Is an Agent?

After many intense interactions with agents, I gradually formed a simple definition of what an agent actually is.

The LLM provides reasoning and proposes the next action. The surrounding workflow controls what can actually happen: validation, permissions, execution, observation, and feedback.

Once I started looking at agents this way, their evolution became much clearer to me. The question is no longer simply whether the model is smarter. The question is how the whole system around that intelligence evolves.

And interestingly, each additional layer looks increasingly familiar because humans already use similar patterns in everyday work.

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.

But this is also very human. Before doing a task, we first understand the situation, think about what to do, and pick up the tools we need.

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.

Humans do this too. We check our work, obey policies, ask for approval, stop when risk becomes too high, and escalate when something is beyond our authority.

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.

Again, this looks surprisingly similar to human work. We remember experience, divide work across a team, ask specialists, revisit earlier decisions, and choose different paths depending on what we discover.

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.

This may be the most human pattern of all: when routine work stops working, we stop following procedure and start doing research.

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 Human Behavior to Agent Architecture

Looking back at the four levels, I increasingly see them not only as an agent maturity model, but as a reconstruction of patterns humans already use every day.

We did not invent these patterns for AI. Humans have been using them for a very long time. What agent engineering is doing is turning them into explicit software architecture.

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.

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 understand the human patterns behind good work, then build the environment in which an agent can reproduce — and eventually extend — those patterns safely.