Recently, I sat in on a talk at StartSe AI Festival 2026 that stayed with me for days. On stage was Isabella Piratininga, iFood's Director of Technology and Innovation, and the subject was building agentic products at scale, told through the case of Ailo, iFood's conversational assistant. Let me be upfront from the start: this is my reading of what I heard, not coverage and not a transcript. It's what I, as a developer, wrote down and decided to dig into for other developers. I'm writing about it for one simple reason. iFood probably runs one of the largest agent operations in production in Brazil today, and hearing from someone who keeps that running every day, with real users and SLAs to meet, is worth more than most of what gets said about agents out there. To set the scale: iFood already runs more than 10,000 active agents internally, has more than 200,000 agents in customer support, processes more than 180 million orders a month, serves more than 65 million active users, and connects more than 500,000 partner businesses. At that scale, agents stop being an experiment and become production infrastructure. That's why the principles below deserve a developer's attention, whatever your stack.
It starts with one question
It started with a provocation that, for me, was the best part: how much of your product, today, was actually designed to change user behavior? Notice that the provocation is about behavior, not about the interface and not about the model. And behavior takes time to change. Almost everyone is building agents, but almost no one is building the sense of what this kind of product is. Technology stopped being the bottleneck, because the models already deliver plenty. The hard problem moved. It's now about changing the behavior of the people who use the product, and of the teams that build it. The practical consequence for developers is immediate: stop measuring progress by how many AI features you ship, and start measuring it by the behavior change those features actually produce.
Generative vs. agentic products
Before the principles, one distinction is worth making. I consider it the starting point for any architecture decision in this space. A generative product is one where you give an input, ask for something, and wait for a response. The flow is request–response, user-driven, synchronous. Most chatbots and prompt interfaces work this way. An agentic product is one that acts on its own, based on context, to reach a goal. The flow is continuous, proactive, and often asynchronous. It doesn't just answer—it decides, executes, and reacts. This distinction matters because the architecture, the infrastructure, and the expectations are completely different. A generative product needs good latency and a well-tuned model. An agentic product needs orchestration, fallback, observability, and a model that can handle partial failures.
The six principles
The principles shared by Piratininga are not a recipe. They are product design guidelines for anyone building agentic products in production, with real users, real scale, and real constraints. Each of them deserves a deeper dive, but the overview already changes how you think about what you're building.
1. The AI is the interface
When AI becomes the main interaction point, everything else becomes supporting structure. The screen, the buttons, the menus—they become fallback, not default. This has direct consequences for frontend architecture. Design for voice and text as primary inputs, not as additions. Rethink navigation when there is no navigation.
2. The experience is the product
It's not about features. It's not about coverage. It's about what the user feels when using the product. For developers, this means observability needs to extend beyond logs. You need to track satisfaction, friction, abandonment—and feed that back into the system. If you're building agents, you're building experiences, not endpoints.
3. Design for behavior change
This is the hardest one. Users don't change behavior overnight. If your agent introduces a new way of doing something, expect resistance, confusion, and slow adoption—even if your solution is better. Build for the transition, not just the end state. Provide scaffolding, fallback, and progressive disclosure.
4. Orchestrate, don't monolith
At scale, a single model doing everything doesn't work. You need routing, you need specialist agents, you need human escalation. The orchestration layer becomes the real product. This is where most demos fall apart. They show one agent doing one thing well. Production requires dozens of agents coordinated in real time.
5. Fail gracefully, always
Agents will fail. Models will hallucinate. APIs will timeout. What happens then? At iFood's scale, the answer is: the user should never notice. Fallback isn't optional. It's the product. Build circuits, retries, and escalation paths. Test failure more than you test success.
6. Measure behavior, not usage
Pageviews, sessions, API calls—none of these matter if the user didn't change behavior. Did the user accomplish the goal? Did they come back? Did they do it faster? These are the metrics that matter for agentic products.
Closing thoughts
Hearing this talk reminded me that the hard part of building with AI is not the AI. It's the product. It's understanding what users need, designing for behavior change, and building infrastructure that doesn't collapse under real-world load.
If you're building agents, take these principles seriously. They come from one of the largest agent deployments in Latin America, running in production, every day, for millions of users.