Tool definitions should express an agent's intention, rather than expose a downstream API directly.
2
Production agents need limited choices, short latency, and interfaces that match how users behave in the app.
3
Teams should build and evaluate a working agent first, then layer shared tools and governance on top of proven domain-specific workflows.
Summary
Chiara Caratelli describes an AI food-ordering agent built for iFood, where users can search, refine, and order through the app or WhatsApp. The team found that user experience, latency, adoption, and trust were as difficult as the model itself. Alex Salazar argues that tools are contracts for an agent's intention, while APIs describe how a downstream service works. A sales agent needs a "get brochure" tool, not a general Google Drive interface. Both speakers recommend limiting tool choices, moving deterministic work into workflows, and putting relevant instructions in tool responses. Chiara explains how iFood evaluates regressions, tool selection, user outcomes, and UX through traces, error taxonomies, golden data, simulated users, and product-specific judges. The discussion then moves to fine-tuning, shared tools, governance, versioning, and ownership. Their advice is to solve one real business problem deeply before abstracting tools for reuse across an organization.
The food-ordering agent had to fit the user's interface and habits
Chiara Caratelli explains that iFood built an agent to help users decide what to order when too many options create indecision. It uses user preferences, habits, price range, and questions to recommend food, then supports search, refinement, and ordering. The team built versions for the iFood app and WhatsApp, where voice messages are already familiar in Brazil. The interfaces created different expectations. In the app, users wanted buttons and fast interactions. On WhatsApp, they accepted more conversational behavior. The team added voice, swiping, and clickable actions so users did not have to type requests such as selecting the third item.
Tool definitions became harder to use as production edge cases accumulated
The initial tool definitions made sense to the team, but became difficult for outsiders and agents to understand after production edge cases were added. Instructions such as calling a get information tool whenever an order lacked details turned the definitions into long code-like statements. Chiara says the team tested whether another team could understand and reuse each tool. They revised names and descriptions to make the tools clearer. This reduced tokens, improved latency, and made the system more stable. Alex adds that the hard part is deciding what a tool should encapsulate, because the design must account for the user's intention and the agent's intended action.
An agent tool should express an intention instead of exposing an API
Alex distinguishes an API from a tool. A Google Drive API describes the contract of the Google Drive service, while a tool should describe what the agent needs to accomplish. A sales agent searching for a product brochure does not need to reason through folders, file types, and Google Drive parameters. A get brochure tool can call a Google Drive MCP server, perform much of the work deterministically, and return the needed result in one call. This reduces context, latency, and opportunities for hallucination. Alex describes a tool as a service contract for an agent's intention. Chiara agrees that tool definitions need review by people who did not write them.
Limiting choices pushes work into faster and more predictable workflows
Chiara says limiting the agent's choices reduces hallucinations and context growth. When several tools are always called together, the team can encapsulate them in a workflow tool. The agent does not need to know what is inside that tool, and the implementation can even contain another agent. Alex describes a tension between determinism and generality. Fewer tools make systems faster, cheaper, and more predictable, while more tools let an agent handle a wider range of requests. Their practical advice is to use specific tools based on the agent's current state, while recognizing that future systems may handle larger tool sets intelligently.
Tool outputs can carry context and user-interface elements
The speakers say that tool responses are part of the agent design. Chiara suggests putting instructions for the next step in a tool response instead of bloating the system prompt with rules that only matter after a particular action. Alex describes a layered tool structure similar to application APIs: low-level service APIs, workflow APIs, and application-specific interfaces. A tool can return more than text. It can provide a table or a React component when that is the most useful presentation. In a voice system, a supervisor can also fetch likely-needed context before the conversation reaches that point, so the user does not wait while the agent retrieves it.
Latency and UX now determine whether an agent feels usable
Alex says the production conversation had shifted from accuracy and consistency toward latency by November 2025. A thirty-second wait that once seemed acceptable had become a poor experience. Chiara observes that the same person can have different expectations in the app and on WhatsApp. WhatsApp users can switch to other conversations while waiting and return after a notification, whereas app users expect responsive buttons and immediate feedback. At iFood, much of the work involved presenting recommendations, building trust, and shaping the agent's persona. The speakers argue that the application and the agent can no longer be evaluated as separate parts.
Agent evaluations need product-specific error analysis and UX checks
Chiara describes several evaluation layers. Regression tests check code-level behavior, and a golden data set supports repeatable testing. The team then inspected traces and real user feedback to identify failures and build an error taxonomy. That taxonomy informed test sets and more specific LLM judges. They evaluated whether the agent satisfied a product request, whether it selected the correct tools, and whether complex tools such as catalog search produced good recommendations. They also built scenarios for an agent that impersonated a user, including clickable UI elements, and judged the resulting outcome. Chiara says this helped test UX, although it did not replace A/B testing.
Fine-tuning is useful for repeated, narrow tasks at large scale
Chiara says foundational models are used for most conversational work, while smaller fine-tuned models handle specific steps such as creating user representations. Fine-tuning can make sense when a task must run for many users every day and a general model would be too expensive or slow. It can also help distinguish terms that look similar but have different meanings in food delivery. The team A/B tested a fine-tuned approach and found it better for its application. Traditional machine learning still has a place for numeric patterns, graphs, and collaborative filtering. LLMs help extract less explicit patterns, such as inferring a preference from repeated pizza toppings.
Shared tools create governance obligations after they prove useful
Chiara says teams often build vertically for one use case, then discover that several groups have created similar tools. Shared tools can provide governance when an owning team maintains a capability such as knowledge-base search. Alex warns that reuse immediately raises questions about ownership, access, versioning, and bug fixes. Customer-facing and internal agents may need different permissions. A changed tool definition also changes what downstream agents see, so evaluations must cover both the shared tool and each agent's use of it. The speakers recommend layering a domain-specific tool on top of a shared capability instead of adding every team's requirements to the shared definition.
"If there is a lesson I've learned in this year's building agents, that's this one: limit the agent choices as much as possible."Chiara Caratelli10:39
Who should watch
You are building an agent whose users interact through an app, chat interface, or voice channel, and you need to connect tool design with the actual user experience.
Your team is exposing APIs or MCP servers to agents and wants a concrete way to decide when to wrap them in narrower, intention-based tools.
Your organization has several agents and is starting to face shared-tool ownership, access control, versioning, and evaluation problems.
