Classic Machine Learning is having a redemption moment that few people saw coming. 😄
With the boom of AI Agents, a lot of folks assumed that day-to-day work in this space would basically involve writing prompts, tweaking instructions, and hoping the LLM would work its magic. The popular narrative said that large language models had made everything before them obsolete, including years of accumulated knowledge in algorithms, features, and data pipelines. It seemed like the future would just be one giant model chatting with the world.
But anyone actually building real agentic platforms knows the story is very different. The daily grind of working with sophisticated agentic systems involves a lot more than adjusting an LLM’s behavior. There is an entire layer of logic, decision-making, and filtering that needs to be carefully built, and that is exactly where classic Machine Learning steps in with full force.
There is a piece that recently made the rounds on Towards Data Science that sums up this shift pretty well. An engineer working on a sophisticated agentic AI platform shared that she spends a good chunk of her time building classifiers with CatBoost and tuning isolation forests, not doing prompt engineering as you might expect. According to her, colleagues are sometimes surprised when they hear she still builds these kinds of models in the middle of such a modern stack. This is not an isolated case — it is a pattern repeating across engineering teams around the world, where the real complexity of agentic systems demands a combination of approaches, not a total replacement of one by another.
This raises a really interesting question: if AI Agents depend so heavily on tools to function, why not give them classic ML models as powerful tools? The short answer is that it makes perfect sense, and the long answer is exactly what we are going to explore here — from what defines an AI Agent to the two main architectural approaches for connecting your models to the agent, along with the concrete reasons that make classic ML still indispensable. 🚀
What is an AI Agent, anyway?
Before diving into architectures and technical combinations, it is worth getting on the same page about the concept. An AI Agent means combining LLMs and other software tools to create workflows with little to no human intervention, orchestrating any number of models or tools. It is not simply a chatbot with memory or a virtual assistant with internet access — it is a system that perceives context, decides what to do, and executes actions to achieve a goal.
Receive the best innovation content in your email.
All the news, tips, trends, and resources you're looking for, delivered to your inbox.
By subscribing to the newsletter, you agree to receive communications from Método Viral. We are committed to always protecting and respecting your privacy.
LLMs like GPT, Claude, or Gemini serve as the central interface for many of these modern agents. They are responsible for translating human prompts into machine language, interpreting the results that tools return, and deciding which tool to call at each step. But here is the crucial point: the LLM alone does not actually execute anything on its own. As we always emphasize, an LLM is just a token-generating model, predicting the next word or phrase in a text based on the context it received. It needs tools to interact with the real world, and those tools can be API calls, scripts, database queries, and increasingly, classic Machine Learning models wrapped as functions accessible to the agent.
This tool-based architecture is what transforms an LLM into a functional agent. And it is worth remembering that even the chatbots we use every day — like ChatGPT, Gemini, and Claude — rely on this kind of chaining, combining the LLM interface with data retrieval, web search, math calculators, and other resources. The language model does not need to know how to do everything on its own — it needs to know when to call what. This opens the door to a much more efficient division of responsibilities, where each component of the system does what it does best, and the LLM orchestrates the symphony based on natural language and contextual reasoning.
Why give your agent classic ML models
A central aspect of the entire agentic AI ecosystem is Tooling. Your agent needs access to tools to complete tasks that go beyond the LLM’s basic capabilities. Many of these tools today, in enterprise environments, handle data retrieval and organization — graph databases, RAG knowledge bases, query construction and validation, and so on. But there is one category of tool that a lot of people overlook: Classical Models themselves.
Think about an agent designed for real estate analysis. If you want to find the fair market price of a property, you just give the agent an address. It can use a retrieval tool via API to fetch property details and then pass that formatted data to a regression model that generates a price estimate. You could, in theory, ask the LLM to estimate the value on its own. But that is questionable and even risky for a number of reasons.
- Number accuracy: an LLM is particularly bad at any task that requires calculating a meaningful number, because it is guessing rather than performing a calculation based on empirical evidence. A well-trained classic model will be far more accurate and reliable.
- Interpretability: with the LLM guessing, you have very little explainability. We know LLMs tend to be a black box, which severely limits your ability to evaluate the path to the estimate. With a classic model, you can identify the decisions made and validate them against domain expertise.
- Cost: running an LLM gets expensive fast because of tokens. If you have a lot of cases to process, pricing becomes a real problem. Running a classifier or regression, on the other hand, is incredibly lightweight and cheap, even at high volumes.
- Control and fine-tuning: you do not control the training or tuning of the LLM unless you fine-tune a foundation model, which requires significantly more data and specialized skills, and still leaves interpretability issues on the table.
- Data control: your data may be leaving your controlled environment and being accessed by a third-party LLM provider, which creates risk.
- Infrastructure control: with an LLM, you have no authority over infrastructure management, so an outage at the third-party provider creates risk for your business.
Of course, building a classic model requires different skills than just throwing an LLM at a task. You need to understand your data well, be prepared to do feature engineering with domain knowledge, and have enough compute and data to train the model. If you do not have labeled data, you will be limited to unsupervised learning or will have to create your own labels. Fortunately, there is plenty of material available on how to build these models, evaluate them rigorously, and monitor them after deployment.
How to connect your model to the agent
Convinced to give this a try? Before you get started, there are a few architectural choices to consider. How will your model and your agent interact? There are basically two main approaches.
Direct calls
Probably the fastest way to get everything up and running is to let the agent have the model as a tool it calls directly. This is the approach from the real estate analysis example: the agent triggers the model for on-demand inference based on a prompt. For this to work, your agent needs to be set up to correctly format requests to the classic model. It needs to understand what that model is for, when to call it, and when to use something else. That means clearly documenting the model’s purpose and capabilities, but if you are already building agentic AI, this is a familiar task.
On the output side, the model’s response needs to be structured so the agent can process it properly. Simply returning a raw number might not cut it, because the agent will need contextual information to interpret it and use it effectively. A good practice is to use f-strings to build text descriptions as part of the inference, indicating, for example, which features were most important to the model, what the probability of the result is, and so on. Returning just a probability limits the agent’s ability to interpret the output and produce a useful response for the end user.
Database access
Another option is to have the model serve not as a direct tool for the agent but as a context data provider. You can pre-compute inferences by running your classic model as a scheduled job and storing those results in the storage solution the agent has access to. Instead of the agent making an initial inference call directly to a model API, it writes a query and passes it to the database.
If you have a finite set of cases for which you might need inference, this is a solid solution. For example, if you have 500 individuals in your database and the agent needs to retrieve financial health information about them, you can use a credit scoring model and pre-compute each person’s creditworthiness, leaving it ready for the agent to fetch at runtime alongside other data. Depending on your infrastructure, this can reduce latency and repetition, essentially functioning as a results cache.
This approach creates different requirements for calling and retrieving compared to direct tool calls. If you pre-compute inferences and make them available via database, the agent needs to know those results exist. If it is not aware of the table or the available content, it will not use them when appropriate. You may already have the infrastructure to inform the agent about what the database contains through your prompt engineering, which saves effort. As for the format of the results, the requirements are similar to direct calls: having a text description is a good choice, because the agent needs to interpret what it retrieves, regardless of the source.
Tooling: the glue that holds it all together
Talking about integration between AI Agents, LLMs, and Classical Models without talking about Tooling is like talking about construction without mentioning the tools on the job site. The tooling ecosystem available today for engineers working with agentic systems has evolved significantly in recent years, and part of that evolution has been specifically aimed at making it easier to integrate heterogeneous models within a single pipeline. Modern frameworks already offer abstractions that let you register any function as a tool available to the agent, which means a serialized ML model can become an agentic tool with just a few lines of code.
The most important point about Tooling in this context is that it is not just a technical matter — it is a design decision that directly affects the system’s ability to evolve. When you build an agentic pipeline with good tool abstractions, adding a new Machine Learning model, swapping a classifier for a newer version, or experimenting with a different architecture becomes an incremental operation rather than a complete refactor. This is especially relevant today, when the pace of evolution for both LLMs and classic algorithms continues to accelerate, and the ability to iterate quickly is what separates teams that deliver value from teams stuck in technical debt. 🛠️
The best of both worlds
Classic ML models were the cutting-edge capability in many industries for over a decade before LLMs entered the scene, giving people insights into data they could not have gotten otherwise. That power should not be discarded — it should be combined with what LLMs bring to the table. We can leverage the LLM’s strengths — converting human language into machine language, chaining different tool calls, and retrieving results from them — while still using classic models within that framework to do the work that an LLM simply is not suited for.
The barrier to entry is the ability to build high-quality classic models, something that unfortunately is not as glamorous as much of the AI-related work these days. But it is worth the effort, for clear advantages: accuracy, interpretability, cost, and control. For anyone looking to reap those benefits in practice, it is worth revisiting tools like XGBoost, LightGBM, and scikit-learn, along with CatBoost itself, and seeing the difference firsthand.
The combination of AI Agents with LLMs and Classical Models is not a contradiction — it is a natural evolution. The field is learning, through practice, that robust artificial intelligence rarely comes from a single approach applied to everything. It comes from the intelligent combination of the right tools for the right problems, orchestrated by systems that know when to use each one.
