Understanding AI Agents: What AI Agents Really Are

From Language Model to Agent

A large language model initially generates outputs solely based on its inputs.

Simply put:

For example, the model can explain how to add an appointment to a calendar. However, it cannot actually create the appointment itself yet.

The application needs access to a tool for this.

The tool acts as the controlled connection between the language model and an external system.

This is the foundation of many agent-based systems.

Understanding Tool Calling

With tool calling, the language model usually does not execute arbitrary program code itself.

Instead, the application provides the model with a description of the available functions.

Simplified, a tool might look like this:

def get_customer(customer_id: int) -> dict:
    """Return customer information for a given customer ID."""
    ...

The model is informed that a tool get_customer exists and expects a customer_id.

With a corresponding request, the model can then decide:

Tool:
get_customer

Arguments:
customer_id = 4711

The actual application executes the function call and returns the result back to the model.

The process thus looks like this:

The language model therefore decides which tool to use with which arguments. The application retains control over its actual execution.

What Makes This an Agent?

A single tool call does not automatically create a complex agent system.

It becomes more interesting when the model can select further steps depending on intermediate results.

Suppose an employee asks:

What outstanding invoices does client 4711 have, and has he already been reminded by email?

The system could then:

1. Retrieve customer data
2. Search for outstanding invoices
3. Search emails
4. Evaluate results
5. Generate an answer

The next step to take can only be decided during processing.

The model is thus in a loop of deciding, acting, and observing.

This loop is a key characteristic of agent-based systems.

Agent and Workflow Are Not the Same

A classic workflow has a largely predefined sequence.

The order is defined by the software.

In contrast, an agent allows the model to decide which action is meaningful next.

Workflow

A → B → C → D → E
Ablauf vorgegeben


Agent

Aufgabe
   ↓
LLM entscheidet
   ↓
Tool
   ↓
Ergebnis
   ↓
LLM entscheidet erneut
   ↓
...

This brings flexibility but reduces predictability.

When Is a Workflow Better?

The term “agent” initially sounds like the more modern solution. However, technically a deterministic workflow is often superior.

For example, if every incoming invoice must always be processed according to the same rules, there is little reason to let a language model decide the next step.

An agent becomes more interesting when the solution path is not completely known in advance.

Agent-Based Systems Are Often Hybrid Systems

In productive applications, you often find neither a fully deterministic workflow nor a fully autonomous agent.

Instead, both approaches are combined.

The software determines, for example:

• Which tools are available
• Which data may be used
• Which actions require confirmation
• How results are validated
• When the process terminates

Within these boundaries, the model can make decisions.

This is usually much more realistic for enterprise applications than the idea of a fully autonomous AI agent.

A Minimal Agent Principle in Python

Without a concrete agent framework, the basic principle can be represented roughly as follows:

while True:
    result = llm.generate(
        messages=messages,
        tools=available_tools,
    )

    if result.tool_call is None:
        return result.text

    tool_result = execute_tool(
        result.tool_call.name,
        result.tool_call.arguments,
    )

    messages.append(result.tool_call)
    messages.append(tool_result)

The crucial part is the loop.

The model receives the task and the available tools. If it chooses a tool call, the application executes it and returns the result.

Then the model decides again.

Frameworks abstract this process, but the fundamental architectural principle remains similar.

Where Do Frameworks Like Pydantic AI Come In?

Numerous frameworks now exist for such systems.

In the Python environment, Pydantic AI, LangGraph, or the SDKs from various model providers are among the possible components.

They can take on tasks such as:

• Tool definitions
• Structured input and output
• Agent loops
• Validation
• Model communication
• State management
• Error handling

However, the order of understanding is important:

LLM
 ↓
Tool Calling
 ↓
Agent Loop
 ↓
Orchestrierung
 ↓
Framework

A framework is not the agent. It only helps implement the required architecture.

Where Does MCP Fit In?

The Model Context Protocol, or MCP, now often comes up in connection with agents.

However, MCP solves a different problem.

If every AI application must individually integrate every data source and every tool, numerous proprietary connections arise.

Simply put:

KI-Anwendung → GitHub API
KI-Anwendung → Datenbank
KI-Anwendung → Dateisystem
KI-Anwendung → CRM
KI-Anwendung → internes Tool

MCP defines a standardized way to provide such capabilities for AI applications.

It thus does not replace the language model or the agent logic.

We will cover MCP in more detail in a dedicated article.

Security Becomes More Important with Agents

As soon as a language model no longer just generates text but can trigger actions, the risk profile changes significantly.

A chatbot giving a wrong answer is problematic.

An agent with access to email, CRM, databases, or production systems can actually make changes.

Therefore, tools should have as narrowly defined capabilities as possible.

Not:

execute_arbitrary_sql(query)

but, for example:

get_customer(customer_id)
get_open_invoices(customer_id)

The clearer the allowed actions are defined, the better the system can be controlled.

Especially critical actions can additionally require explicit human approval.

Conclusion

AI agents are not a new form of language model.

They emerge when a language model is embedded in a software architecture where it can select tools, observe results, and based on those make further decisions.

The key principle is therefore not “autonomy” but controlled freedom of decision.

LLM
  ↓
Entscheidung
  ↓
Tool
  ↓
Ergebnis
  ↓
neue Entscheidung

And precisely for this reason, not every process is a good candidate for an agent.

Where the sequence is known and reliably definable, a classic workflow often remains the better architecture. Agent-based approaches become interesting where tasks are variable and the solution path emerges during processing.

Would you like to understand these topics systematically and classify them for use in your company? In the three-day seminar AI in the Enterprise: From ChatGPT to RAG, Workflows, and AI Agents the most important concepts and architectures are conveyed in a practical manner.