In the previous episode, we explored the theory, fuzzy logic, and what the skeleton of an AI Agent looks like. Now we put the technical brochures aside and start taking apart an agent’s internal engine, piece by piece: the connection between the model’s reasoning and rigid execution.

“Enough with the general theory from the Matrix. It’s time to understand how a real tool gets into the hands of the model and how the model can decide when and how to use it. How do you turn simple text into a software command capable of running on your machine?”

Welcome to the second chapter of our applied AI engineering guide. Today, we tear down the barrier of technical misconceptions. There is a widespread myth that AI Agents have huge databases stored in their memory, or that a Cloud-based model can directly run code to access your infrastructure. False. The architecture behind autonomy relies on an elegant, structured communication mechanism that clearly separates the territory between reasoning and execution.

🔹Tool Design and the JSON Data Myth

Remember what we established in the first chapter: an AI Agent is a language model that we give rigid (crisp) tools. But how does a remote text model know which tools are available in your application? The answer is Function Calling.

This is where the first major misconception appears: the tendency to associate the JSON sent to the AI with a massive database where we put all the items, products, or prices so that the model can search through them. Completely false. If you had 10,000 hardware components in your warehouse, such a JSON payload would be enormous, would unnecessarily consume the model’s context window, and would cost you a fortune with every query.

We do not give the model the data or the executable code directly. Instead, we send it a schema (a structural description in JSON format). We are giving it only the user manual for the remote control.

Let’s assume we want to give our agent a tool that can check the actual stock available in a warehouse. In the code, we will define the tool by describing only its technical interface:

{
  "name": "check_hardware_stock",
  "description": "Checks the available stock in the warehouse for a specific PC component.",
  "parameters": {
    "type": "object",
    "properties": {
      "component": {
        "type": "string",
        "description": "The exact name of the component (e.g., 'DDR3L RAM', 'Intel NUC')."
      }
    },
    "required": ["component"]
  }
}

The model in the Cloud reads this short structure and understands only this: “Aha! I have a tool available called check_hardware_stock. To use it, I need to extract a single parameter from the user’s text called component.” If you want your agent to gain new capabilities (for example, checking software licenses or sending emails), you do not modify this schema; instead, you add new tools to the list, each with its own parameter schema.

🔹The Relay (The ReAct Loop in Action)

Forget about classic chatbots that receive text and generate a response. When you start an AI Agent, execution becomes a tight exchange of information between your local application and the Cloud, called the ReAct Loop, divided into very clear steps:

Step 1: The Fuzzy Request and Passing the Context
The user enters the chat and throws in a question in natural language:

“Hi! I want to upgrade my memory and I need a 1600MHz DDR3L RAM kit. Do we have any in stock at the warehouse, or do I need to order it from somewhere else?”

Your application receives the text. Since your code cannot understand the nuances of language, it packages the user’s question together with the stock tool schema (the one defined above) and sends them to the Cloud through the API.

Step 2: Reasoning in the Cloud and Filling in the “Arguments”
The model in the Cloud (Gemini, Llama 3, etc.) receives the package. The model interprets the user’s intent (“They want DDR3L RAM”) and scans the attached list of tools. Because its weights are frozen and it is completely isolated on the AI provider’s servers, the LLM cannot physically access your real warehouse.

Instead, it interprets the request in the context of the available tool and sends a rigid command back to your application in JSON format (a Tool Call). It fills in the “arguments” key, extracting the relevant value from the client’s text:

{
  "tool_calls": [
    {
      "name": "check_hardware_stock",
      "arguments": {
        "component": "DDR3L RAM"
      }
    }
  ]
}

Step 3: Local Rigid Execution and Result Delivery
The JSON command lands back in your application (written in Python, C#, or Java). Your code receives the command from the Cloud, opens your real database containing 10,000 parts, and retrieves the actual data: the stock is `0`, but there is an alternative available at `1333MHz`.

Your application packages this raw database result and sends it back to the Cloud as the tool’s response:

{
  "tool_name": "check_hardware_stock",
  "output": {
    "stock": 0,
    "alternative": "DDR3 1333MHz"
  }
}

Step 4: Human-Friendly Response
The LLM in the Cloud reads this fresh data (`output`) and once again uses the flexibility of language to turn it into a polite and helpful response, displaying the final text on the user’s screen:
“Unfortunately, the specific 1600MHz DDR3L RAM kit is out of stock. I checked the database, and we have a 1333MHz kit available in the warehouse that might be compatible…”

Think about what happened here: the AI did not simply generate a response. It analyzed the request, asked for code to be executed in the real world, received the rigid result from your application, interpreted it, and only then generated the final response. That is what Agent architecture means.

🔹From a Rigid Query to Sci-Fi Autonomy (The 3 Levels of AI Agents)

If you follow technology news, the concept of an “AI Agent” can seem straight out of a sci-fi movie — an independent digital entity with a personality that “thinks for itself”. But when you open the hood, the Silicon Valley marketing disappears.

You might say: “Okay, but in the end, the agent just extracted a parameter and searched for a component in a local database. Where is the great autonomy?”.

The secret lies in extrapolation. What we built in this chapter is the basic atom, the fundamental building block of systemic intelligence. To understand how we move from a simple stock query to software agents that solve complex tasks, we need to look at the evolution of agents across 3 clear levels:

1. The Single-Task Operational Agent (Current Level)

This is the one we took apart today. It has a single tool (such as a database, a calculator, or an email API). It receives a command expressed in natural language from a human, uses Function Calling to request an action on a local resource, interprets the result, and delivers it back. It is the equivalent of an ultra-specialized digital clerk.
2. The Autonomous Multi-Step Agent (The World of Complex Loops)

Imagine that instead of a single tool, we make a list of 10 different tools available to our application: `search_web`, `write_file`, `run_terminal`, `send_email`, and `create_slack_alert`.

At that point, you can give it an abstract, high-level command: “Check the system and, if you find errors in the logs, fix them and let me know.” The Agent can start running the ReAct loop repeatedly and autonomously:

* **Step A:** Calls the log-reading tool → Observes a blocked port.
* **Step B:** Evaluates the next step: “The port is blocked, which may prevent the database from functioning. I’ll use the terminal tool.” → Executes the Linux command to unblock it.
* **Step C:** Checks whether the fix worked → Calls the Slack tool to send you the final report to your phone.

3. Agent Teams (Swarm Architectures)

This is an advanced level of software architecture, used in certain enterprise applications. Instead of a single agent, you deploy multiple specialized software agents that communicate with one another, passing information and results from one to another:

* One agent takes on the role of Manager (receives the client’s request and breaks it down into tasks).
* One agent takes on the role of Programmer (its tool is a code-writing environment).
* One agent takes on the role of Tester (its tool is an isolated execution terminal).
They can collaborate autonomously through Function Calling, coordinating successive stages of work and, in certain scenarios, generating, testing, and delivering entire applications with minimal human intervention.

Once you understand how a model in the Cloud can learn to correctly fill in the `{ “arguments”: { … } }` key for a single, basic stock-checking function, you understand the fundamental principle behind building systems with multiple tools and autonomous agents.

🧠 The Illusion of Control: The Brain and the Hands Are Thousands of Miles Apart

In modern agent architectures, the “brain” and the “hands” can be in two completely different locations, separated by thousands of miles, and understanding this topology is crucial to understanding how such a system works:

  • 1. Where Is the LLM (The Brain)? It is often in the Cloud (Google, OpenAI, Anthropic, Groq, etc.). It receives requests through an API and sends back responses or structured commands in JSON format. It interprets the request, evaluates the context, and chooses the appropriate tool from the menu you have made available to it, but simply being in the Cloud does not give it direct access to your network, nor can it directly run code on your machine.
  • 2. Where Are the “Hands” (The Application and Tools)? In your local infrastructure or in an environment you control. This is where your backend (Python, C#, or Java) runs. Your application is the one that has access to the database containing the components, receives the decision sent from the Cloud, executes the function according to the conditions you have defined, and sends the result back to the Cloud.

💡 The Hardware Takeaway: We let the Cloud infrastructure provide the resources needed to run the model and interpret the request, while we receive the command and execute the rigid code (`output`) in the environment we control. Your private data can remain local, while actual control over execution remains in the hands of your application.

🛠️ What’s Coming in Episode 3?

We have seen the theoretical mechanics of how an agent interprets requests, communicates through JSON structures, and executes actions through the ReAct loop. But a system that has only executive arms and cannot plan its steps is just an impulsive automaton.

In the next episode, we go one level deeper into the architecture of AI systems: Chain of Thought (CoT). We will examine why certain modern reasoning models, such as the o1/o3 series and other systems with thinking mechanisms, allocate additional time and resources to analyze a problem before formulating the final answer.

We will understand how the two components can work together — the model’s internal reasoning (CoT) and the executive arms provided by your infrastructure (ReAct) — to build systems capable of breaking down complex objectives, executing successive steps, and verifying results along the way.

Get ready to understand how the machine thinks when it talks to itself. We’re moving to the next level!

Stay Free! Stay Hidden! Stay Autonomous!

⚙️ Appendix: AI Engineering Mini-Course (Technical Clarifications)

  • JSON (JavaScript Object Notation): A lightweight, standardized text format used to exchange data between software applications. It does not contain executable code, only data structures organized as label-value pairs.
  • Function Calling: A mechanism through which an LLM can identify that a user needs an external action and return a rigid structure, usually in JSON format, containing the function name and the parameters extracted from the conversation.
  • JSON Schema: The structural blueprint or “technical interface” of a tool, sent to the LLM to describe what the function does, which parameters it accepts, and which of them are required. It contains descriptions and structural rules, not the actual data from the application.

    🧠 The Big Confusion: The JSON Schema Is Not Your Database! There is a huge mental barrier for those coming from the world of traditional software: If I give the Agent a tool to check hardware stock, how do I send it my database in JSON so it can search through it?

    The answer is simple: You do not send it the database! A JSON containing all the products, prices, or logistics data could become enormous, unnecessarily consume the model’s context window, and significantly increase the cost of every query.

    In agent engineering, we send a schema to the brain in the Cloud (a user manual for the tool’s interface). The Cloud uses this schema to understand what the tool can do and to extract the required parameter from the user’s sentence (e.g., “DDR3L RAM”).

    Your actual database, whether it contains 10 items or 10 million, remains within the infrastructure you control. Your application receives the parameter extracted by the Cloud, performs the query locally, and can send back only the required result (e.g., “Stock: 0”). JSON is just the envelope, not the warehouse!

    ⏳ History Station: Why JSON and Not the Heavy Protocols of the 2000s?

    If the idea of sending structured commands remotely between different systems (Remote Procedure Call) already existed in the early 2000s and was widely used in major banking systems and enterprise architectures, why has JSON become so important in today’s AI agent architecture?

    The answer lies in efficiency, simplicity, and the way language models process text:

    • 1. The XML Nightmare (SOAP / XML-RPC): In the 2000s, data was frequently packaged in XML. The SOAP protocol used documents with numerous tags, complex headers, and strict validation rules (XSD). It was cumbersome and very “verbose” compared with JSON — it consumed a lot of text to describe the same data structure.
    • 2. JSON and the Explosion of Web APIs: JSON was designed as a simple data format that was easy to use with JavaScript and later became extremely widespread in web applications and APIs. Its structure, based on objects, lists, and key-value pairs, is simple and compact.
    • 3. A Format Well Suited to LLMs: The neural networks underlying LLMs process text. A JSON structure is relatively compact and has clear rules, making it well suited for describing parameters and for generating structured commands by models.

    In short: in the 2000s, we already had the technology to send commands and data remotely, but we often did so through much more verbose protocols and formats such as XML/SOAP. JSON brought simplicity and compactness and became one of the main forms of data exchange in modern applications, including communication between LLMs and the applications that use them.

  • ReAct Loop (Reasoning and Acting): An execution paradigm in which an AI Agent alternates between evaluation and planning stages and concrete actions through tool calls (Action), followed by reading the results from the real world (Observation), until the problem is solved.