Today, we're going past surface-level conversation about how tools enable LLMs to take action beyond

just generating text. Instead, we'll dive under the hood to see exactly how the BeeAI framework, which is

an open-source AI agent framework built for developers, actually implements and executes tools

in production. We're going to cover the whole tool lifecycle, from creating the tool to executing it

and observing its actions, to how the tool output is consumed by the LLM. And then at the end, we're

going to see it in action. In the BeeAI framework, a tool is an executable component that extends an

LLM's capabilities. This could be a procedural code function, an API call to an external

service, a database query or a file system operation, or an MCP or a model context protocol

server, or any custom business logic. Each tool has a name, description, and usually an input

schema that an LLM uses to pick the right tool call. The BeeAI framework provides some built-in tools,

so you don't need to recreate the wheel for common tools like internet search, running Python

code in a safe, sandboxed environment and encouraging the agent to think using a react

pattern. But you can also create your own custom tools if needed. There are two primary ways to

create custom tools in BeeAI. For simpler functions, you can add a tool decorator like this.

The framework automatically extracts the function signature to create a Pydantic input schema, uses

the docstring as the description and wraps everything in a proper tool class. But for more

complex tool calls, you can extend the tool class by providing a data model for the tool, setting

the run options, and providing the expected tool output. Once tools are created, they are passed to

the agent as a list. Then the agent passes the allowed tools to the LLM to make a selection on

what tools should be called. So next, the framework executes the tool call, handling input validation,

execution, error handling, result collection, and much more. And lastly, the agent adds the

tool results to memory and loops back to the LLM for the next decision, unless a final answer is

triggered. Next, we have the MCP tool. MCP tools are external services that

expose endpoints following the Model Context Protocol, a standard from Anthropic that allows

language models to call tools. They are handled mostly the same way and follow the same tool

calling pattern. The framework's built-in retry and error handling becomes even more valuable

with MCP tools, since they involve network calls that can fail. So the same retry logic that

handles the local tool errors also handles MCP connection issues, timeouts, and server errors.

So from the agent's perspective, MCP tools are just tools in the list. All in all, the BeeAI

framework includes many features that make it production ready, but some of the most important

ones when it comes to tool calling are the built-in observability, so you can understand and even

log your agent's actions; cycle detection, that prevents infinite tool call loops, built-in retry

logic, and memory persistence, and lastly, type validation. So the entire agent run doesn't

accidentally break from an invalid input. Now, let's walk through a quick demo to see it all in

action. In this scenario, we have a company analysis agent that has access to three tools to

help complete its task.

It has a built-in think tool, which is a reasoning module forcing the agent to follow a ReAct or

reasoning and acting pattern with chain of thought reasoning. It also has an MCP internet

search tool, and we've given it a custom tool that performs retrieval to gather context from an

internal database that we've preceded with some synthetic documents. This process is also known as

RAG or retrieval augmented generation.

So now, I'm going to run the script.

And I'm going to give it the question: When is the next pilot and what

is it on? And it should know what I'm talking about, even though it doesn't have context from

the system prompt. So as the agent runs, we can see that the agent first checks its conditional tools.

And because of the requirement, it forces the think tool call first.

So we can see it thinking there. Then it

goes back to the LLM to make another tool choice based on its allowed tools for this specific

iteration. So the LLM decides to call the internal search tool. So this is a custom RAG tool that

searches a database for relevant internal documents.

It also realizes that it needs to do a more broad internet search. So it calls the MCP internet search

tool, which is running on a local MCP server, with access to the Tavily search tool on

my device. And we can see that's running on standard

IO because it's running locally on my device. And then once the LLM

feels like it's had enough information, it provides the final answer. And the framework is

responsible for returning that to the user. So, what have we learned from going under the

hood of the BeeAI framework? That the LLM is just a small piece of the puzzle. The framework actually

handles a lot of the orchestration and execution logic, so you can focus on the business logic. So

if you're ready to give the BeeAI framework a try for your AI agents, you can find the GitHub and

documentation links in the show notes below. Happy building!