From search to agent: using the Algolia MCP to turn retrieval into action
For a long time, the central question in AI was whether models were good enough. Could they reason effectively? Could they follow instructions? Could they be trusted to produce useful outputs?
That question has changed.
Today, the more interesting question is what we can build around these models. The shift toward agents comes from this change in perspective. Instead of focusing on generating a single response, we are now designing systems that retrieve context, decide what to do next, and take action.
Note: this blog is based on a presentation I gave at Algolia DevBit. You can watch the video of my presentation below. The demo I showed in the presentation starts at around 09:00 minutes into the video.
The shift from answers to systems
There are three important shifts that explain why this transition is happening now.
First, we are moving from chat to workflow. Previously, interaction with models was mostly about asking a question and receiving an answer. Now, we can design systems that retrieve the right information, determine the next step, and act through tools. The model becomes part of a sequence, not the entire experience.
Second, we are moving from prompt to system. Instead of focusing on crafting the perfect prompt, we think more broadly about architecture. This includes the instructions we give the model, the tools it can access, how execution is handled, and what outputs should look like. The prompt is still important, but it is no longer the center of the design.
Third, we are moving from demo to production. With the right structure in place, these systems are no longer experiments. They can be deployed and used in real applications.
Taken together, these shifts point to a new reality: the limiting factor is no longer model capability. It is how we design the system around it.
A practical mental model: build and run
One way to make agents less abstract is to think about them in two parts: build and run.
The build phase is where you define what the agent is supposed to do. This includes writing clear instructions, deciding which tools it can use, and specifying the format of the output. In other words, you are defining the behavior of the system.
The run phase is what happens when the agent is actually executing a task. It involves maintaining state, making tool calls, and retrying when necessary. This is where the system comes to life.
This separation is useful because it makes agents easier to reason about. You are not dealing with something mysterious. You are designing behavior on one side and execution on the other.
Agents are systems, not just models
It is also helpful to think of agents as a stack with distinct layers.
Caption: Another way to think about the agentic stack.
At the top is the model, whose role is to decide what to do next. Below that are tools, which allow the agent to take action, whether that means querying a search index, calling an API, or accessing a database. The runtime layer ensures that execution is reliable by handling state and retries. Finally, an operations layer supports iteration over time through tracing, feedback, and versioning.
The important point is that the model is only one part of the system. Its usefulness depends on how well it is connected to tools and how reliably the system executes.
MCP: connecting agents to real systems
The Algolia Model Context Protocol (MCP) provides a simple way to connect agents to existing systems.
Instead of treating systems like search indices or APIs as external dependencies, MCP allows you to expose them as tools that an agent can use directly. This creates a clean interface between the agent and the underlying capability.
For example, you can take an Algolia index and expose it through a public MCP server. The agent can then query that index as part of its workflow, just like it would use any other tool.
This approach brings a few important advantages. It standardizes how inputs and outputs are handled, makes capabilities reusable across different agents, and simplifies debugging. More importantly, it allows you to build on top of systems you already have, rather than replacing them.
From search to agent: a concrete example
To illustrate this, I presented a simple example called Pokédex, an OpenAI Pokemon agent built on top of an Algolia search index. (scroll to the very bottom of this blog post to find the video of my presentation)
In a traditional setup, you would query the index and retrieve matching results. That is where the interaction ends. With an agent layered on top, the same system becomes more capable.
A user might ask for details about a Pokémon. The agent begins by querying the index to find the relevant entry. It then fetches the full set of attributes associated with that Pokémon and returns a structured response, such as a formatted card with an image and statistics.
The interaction can go further. A user might ask to compare two Pokémon. The agent retrieves both entities, organizes their attributes, and produces a structured comparison. It can even generate additional outputs, such as a visual representation of the comparison, by calling other tools.
One of the more interesting behaviors appears when something goes wrong. If a query does not return results—for example, because a Pokémon name is provided in a different language—the agent can infer the issue, reformulate the query, and try again. This is where reasoning and retrieval start to work together.
The system has not replaced search. It has extended it into a multi-step process that can adapt and act.
What actually changes
Adding an agent on top of search does not change the importance of retrieval. If anything, it makes it more critical. What changes is how retrieval is used.
Instead of being the final step, retrieval becomes part of a broader workflow. Results are no longer just lists of documents; they are inputs into structured outputs. Queries are no longer static; they can be refined and retried as needed. And the interaction model shifts from simple keyword matching to something more dynamic and task-oriented.
In this context, strong retrieval is not enough on its own, but it becomes significantly more valuable when combined with an agent that can orchestrate it.
Applying this pattern with Algolia
If you already have a system like Algolia in place, the path to building agent-driven workflows is relatively straightforward.
By exposing your indices through MCP, you make them available as tools that an agent can use. From there, you define the agent’s instructions, specify how outputs should be structured, and allow it to combine retrieval with other capabilities.
The result is not a completely new system. It is an evolution of what you already have, where search becomes a foundation for more complex and interactive behaviors.
Three takeaways
There are three ideas worth keeping in mind.
If you want to explore how to apply these ideas in practice, you can learn more about Algolia’s support for MCP and agent-based architectures.
Watch the whole presentation below.
