Ailo, iFood's food-ordering agent, uses user behavior, conversation state, and food-search workflows to personalize recommendations.
2
The team reduced P95 latency from around 30 seconds to around 10 seconds by simplifying flows, moving context work to asynchronous processes, compressing prompts, and using smaller models when possible.
3
Tool outputs, long conversations, and large tool collections can fill a context window and reduce model performance even when the input still fits.
Summary
Nishikant Dhanuka and Chiara Carateli describe how iFood built Ailo, a conversational agent for food ordering in Brazil. The agent runs in the iFood app and on WhatsApp, interprets vague requests such as "I'm hungry," recommends food using user preferences and order history, and can search, manage the cart, apply coupons, and support checkout flows. Chiara explains how the system combines one main agent with state-dependent prompts, independent food workflows, UI elements, and user context. The team reduced P95 latency from around 30 seconds to around 10 seconds by simplifying common flows, moving context processing to asynchronous jobs, improving tool names, compressing prompts, and using smaller models where possible. They test the agent with production traces and natural-language scenarios that simulate users and inspect both responses and UI. In the discussion, they warn that tool outputs, long conversations, and large MCP tool collections can damage performance through context bloat.
Ailo handles vague food requests and takes actions for the user
Ailo is designed for users who do not know exactly what they want to eat. It can handle direct searches such as "burger" or "pizza," as well as vague requests such as "I'm hungry." The agent uses user behavior to personalize its suggestions and can take actions through connected tools. Those actions include searching for food, applying coupons, adding items to the cart, and making payments in some experiments. The product appears in the iFood app and on WhatsApp, where the team found that users accept longer conversations than they do in the app.
The architecture uses one stateful agent with independent food workflows
Chiara Carateli describes a single-agent design with state-dependent system prompts. The prompt changes based on the current flow and the tool being used. The agent loads user and conversation context, then calls food-related tools for searching, cart management, and ordering. Some tools are intelligent workflows that operate independently from the main task. The workflows also return UI elements such as carousels and buttons, because users generally do not want to type much. This gives the agent a shorter route from a recommendation to a user action.
Personalization combines conversation state with offline user representations
The system builds representations of user preferences from behavior in the app. For a request such as "pizza," the tool uses the conversation, order history, preferred food categories, and the time of day. It turns the request into semantic and exact searches, expands vague requests into queries that reflect the user's preferences, and reranks the results with the user context. The response goes both to the UI and back to the agent, so the agent knows what it showed when the user asks a follow-up question. Different profiles can receive meat-heavy, low-carb, or more sophisticated pizza options.
Latency improved when the team separated simple flows from complex ones
The first version had P95 latency of around 30 seconds. The team brought it down to around 10 seconds by avoiding the full agent flow for simple requests. They created shortcuts for tasks such as food search, preference retrieval, and promotion search. They also moved work such as compacting previous messages and selecting useful behavior information into asynchronous processes. This did not reduce the total tokens processed, but it reduced the tokens handled in the slowest request path. Prompt optimization reduced the total token count as well.
Prompt bloat often points to unclear tool and variable names
The team found it easy to add another rule to the system prompt whenever a production bug, user complaint, or evaluation failure appeared. Over time, this created bloated prompts full of edge cases. Their response was to create an evaluation for each case, then improve the names of tools and variables. Their test is to show the tool list to someone unfamiliar with the agent and ask whether that person can understand what each tool does. Clearer names reduced the need to describe application-specific edge cases in the prompt, which simplified the prompt and reduced tokens.
Natural-language scenarios test agent behavior and UI together
Alongside production-trace evaluations and regular tests, the team defined scenarios in natural language. Each scenario contains setup steps, instructions, and expected agent behavior. An evaluation agent acts as the user, sends requests to the production endpoint, and checks the responses and UI. This makes it possible to test multi-turn behavior and try to evade guardrails across several turns. The natural-language format also makes the scenarios easier for non-developers to maintain. These tests complement, rather than replace, the team's production evaluations.
More context can reduce output quality even when the request fits
In the discussion, the speakers warn that a larger context window is not a reason to include everything. Tool outputs can quickly fill the context, especially when the model is allowed to choose or return large amounts of data. Long conversations with repeated tool calls create the same problem. A large number of tools also adds descriptions and decisions for the model to process. They mention GitHub MCP as an example that exposes 93 tools, which can bloat context immediately. Their approach is to summarize conversations, select relevant context, combine tools that always work together, and keep tool sets focused.
WhatsApp requires authentication and creates product tradeoffs
WhatsApp gives iFood access to users who may not want to install a separate application, and it is an important commerce channel in Brazil. It also has security and UI constraints. When iFood does not know or trust a phone number, the user must authenticate through a browser and validate the number. The current WhatsApp flow is connected to the iFood app, which provides another authorization step. The team is also experimenting with a more standalone WhatsApp experience, while recognizing that this could create more exposure to scams and social engineering.
