What Are AI Agents, Really?

There is a lot of talk about AI agents right now. In the next weeks I will talk more scientific and givig you more details and I will give you the code as well. But for now let’s start with the basics. (you know, i am taking AI classes now :)) )

Sometimes it sounds like an agent is just an LLM with a fancy prompt.

Sometimes it sounds like we are only one framework away from having an AI employee that can do everything for us.

After spending quite a lot of time building my own agent system, I think the reality is somewhere in between.

The interesting part is not really the LLM.

The interesting part is everything you have to build around it.

So, what actually makes an agent?

Let’s start with the simple version.

If I send a prompt to an LLM and get an answer back, that is not what I would call an agent.

It might be a very useful AI application, but it is basically:

input → model → output

An agent adds something important: action and feedback.

It can receive information from an environment, decide what to do, use a tool, observe the result, and then decide what to do next.

So instead of:

input → answer

you get something closer to:

observe → decide → act → observe → decide → act → …

This idea is closely related to approaches such as ReAct, where reasoning and actions are interleaved so that a model can use external information and adjust its behaviour based on what happens.

That loop is, for me, the most important part.

An agent is not interesting because it can generate text.

It is interesting because it can do something with what it generated.

I understood this differently after building one

When I started working on my own personal AI system, I initially focused much more on the model.

Which model should I use?

How good is the prompt?

Should I use a larger model?

Should I add RAG?

Which embedding model should I use?

All of these questions matter.

But after building and testing the system, I started realizing something else.

The model was often not the hardest part.

The harder questions were things like:

What is this agent actually allowed to do?

Can it read my email?

Can it create something?

Can it send an email?

Can it delete something?

Can it change a calendar event?

What happens if the agent misunderstands what I asked?

What happens if a tool returns something unexpected?

And maybe the most important one:

How do I know what actually happened afterwards?

That completely changed how I think about agents.

The moment an agent can act, architecture starts to matter

A chatbot can give me a wrong answer.

That is annoying.

An agent can give me a wrong answer and then do something because of it.

That is a different problem.

Imagine an agent that can access your Gmail, calendar and tasks.

Reading an email is one thing.

Sending an email is another.

Deleting a meeting is another.

Changing something important in an external system is another level again.

So I ended up thinking about agent capabilities almost like permissions in a normal software system.

Not every agent should have access to everything.

Not every action should have the same risk.

And not every action should happen automatically.

This is one of the main ideas behind the architecture I built for my own system: a central governing layer that sits between the agent and the tools it wants to use.

The agent can say:

“I want to do X.”

But that does not automatically mean:

“X is allowed.”

The governance layer checks it first.

That separation became much more important to me than I originally expected.

Modern guidance for agent systems also emphasizes this distinction between agent capabilities and the safeguards around them, including authorization, tool controls, human intervention, and risk-based handling of actions.

The agent does not own the tools

This sounds like a small design decision, but I think it is a very important one.

An agent should not simply have unlimited power because the model decided that it needed it.

Instead, I prefer thinking about tools as capabilities.

The agent can request a capability.

The system decides whether that capability is available.

That means an email-reading tool can be different from an email-sending tool.

A calendar-reading operation can be different from deleting an event.

A read-only database query can be different from changing data.

This sounds like ordinary software engineering.

And that is exactly the point.

Once agents start interacting with real systems, many of the important problems stop being purely “AI problems.”

They become software architecture and security problems.

And then there is memory

Another thing that looked simple at first but became surprisingly complicated was memory.

People often say:

“Give the agent memory.”

Okay.

But what exactly does that mean?

The current conversation?

Something that happened last week?

A fact about the user?

A procedure the agent learned?

These are not really the same thing.

I started thinking about memory in different layers.

There is the immediate context the model is currently looking at.

There can be episodic information about previous interactions.

There can be semantic information that represents useful knowledge.

And there can be procedural information about how certain tasks should be performed.

This distinction matters because simply putting more text into a context window does not magically create good long-term memory.

Research on long-term LLM agents is increasingly treating episodic memory as a separate problem because agents need to retain useful information across interactions and adapt based on previous experiences.

For my own system, this became less about having a giant “memory” and more about asking:

What information is actually worth remembering?

That is a much harder question.

Multi-agent systems sound cooler than they sometimes are

At some point, you also start hearing:

“Why not just use multiple agents?”

One agent for planning.

One for research.

One for coding.

One for verification.

One for deciding what the others should do.

It sounds great on a diagram.

But then you actually have to make them work together.

Who owns the task?

Who has the final say?

What happens when agent A says one thing and agent B says another?

Can agent B undo something that agent A just did?

What happens when both think the other one is responsible?

Suddenly you have a coordination problem.

That is why I became much more interested in clear scopes than simply adding more agents.

Sometimes one well-designed agent with a few good tools is better than five agents arguing with each other.

Even current agent-building guidance recommends starting with a single agent when possible and introducing multi-agent orchestration when complexity actually justifies it.

Testing became a huge part of the project

This is probably one of the least exciting parts of an AI agent project.

And one of the most important.

It is easy to make an agent that works in the happy path.

You ask something reasonable.

The agent understands it.

It chooses the right tool.

The tool works.

Everything is fine.

But real systems do not live in the happy path.

What happens when the user gives an unclear request?

What happens when a tool fails?

What happens when the model calls the wrong tool?

What happens when two actions conflict?

What happens when some text inside an email tries to manipulate the agent?

What happens when the agent is asked to do something it should not be allowed to do?

That is where the system starts becoming an engineering problem instead of a demo.

In my own project, I ended up with a large test suite because I wanted to test not only whether the agent could do things, but also whether it refused to do things when it should.

That distinction is important.

A reliable agent is not simply one that succeeds often.

It is also one that fails safely.

Observability is not optional

There is another lesson I learned the hard way.

When something goes wrong, “the AI made a mistake” is not a useful diagnosis.

I want to know:

What did the model receive?

What did it decide?

Which tool did it select?

What arguments did it send?

What did the tool return?

What happened afterwards?

Was an approval required?

Was something blocked?

Without this information, debugging becomes guessing.

So logging and auditability became part of the architecture rather than something I wanted to add later.

This also fits into the broader idea of trustworthy AI systems: governance, documentation, monitoring, and evaluation are not separate from the AI system itself. They are part of making the system usable in the first place.

The funny thing about building agents

The more I work on agents, the less I think the impressive part is the model.

Of course, the model matters.

A better model can reason better, understand more context and choose better actions.

But a strong model inside a bad system can still be a bad agent.

You can have an amazing model and still have:

bad permissions,

bad tools,

bad memory,

bad error handling,

bad monitoring,

bad security,

and no idea what happened after the agent acted.

So now, when I think about an AI agent, I don’t picture just an LLM.

I picture a whole system.

Model + tools + memory + state + permissions + policies + feedback + monitoring + humans when necessary.

The exact architecture will change depending on the problem.

But the principle stays the same:

The intelligence is only one part of the system.

Maybe agents should be a little boring

I actually think that is a good thing.

The best agent is probably not the one that feels magical all the time.

It is the one that quietly does its job.

It knows what it can do.

It knows what it cannot do.

It asks when it is unsure.

It does not randomly touch things it should not touch.

You can understand what happened after it acts.

And when something fails, you can actually figure out why.

That is probably much less exciting than the demos where an agent is told:

“Go build a company.”

But I think it is much more interesting from an engineering perspective.

The real challenge is not making an agent do everything.

It is making an agent do something useful, repeatedly, safely, and predictably.

And after working on my own system, that is what I now think an AI agent really is.

Not just a smarter chatbot.

Not just an LLM with tools.

But a system that can reason, act, observe, and operate inside a set of rules.

And the more power we give these systems, the more those rules start to matter.

References

Autio, C., Schwartz, R., Dunietz, J., Jain, S., Stanley, M., Tabassi, E., Hall, P., & Roberts, K. (2024). Artificial intelligence risk management framework: Generative artificial intelligence profile (NIST AI 600-1). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.AI.600-1

OpenAI. (2026). A practical guide to building agents. https://openai.com/business/guides-and-resources/a-practical-guide-to-building-ai-agents/

Pink, M., Wu, Q., Vo, V. A., Turek, J., Mu, J., Huth, A., & Toneva, M. (2025). Position: Episodic memory is the missing piece for long-term LLM agents. arXiv. https://arxiv.org/abs/2502.06975

Yao, S., Zhao, J., Yu, D., Du, N., Shafran, I., Narasimhan, K. R., & Cao, Y. (2023). ReAct: Synergizing reasoning and acting in language models. International Conference on Learning Representations (ICLR). https://arxiv.org/abs/2210.03629