I’ve been thinking a lot about the hidden complexity in what seems like a straightforward idea: using AI agents to handle customer support. On the surface, it’s obvious why companies want this. But after learning about Ahmad Al-Dahle’s work at Airbnb, I realize the engineering challenges here are far deeper than most people realize.
The conventional wisdom is that you throw an LLM at a problem and it handles customer inquiries. Airbnb’s reality is messier. They’re deploying multi-party AI agents, which means multiple specialized models working in coordination to solve support issues. This isn’t just a scaling problem; it’s an architectural problem.
The Moving Target of Evaluation
What grabbed my attention most was how Ahmad describes evaluations as a “moving target.” This phrase stuck with me because it captures something real that developers often miss when building AI systems.
When you’re building traditional software, you have fixed requirements. You know what success looks like. With AI systems, especially in customer support, the problem evolves. What constitutes a good response shifts based on new policies, seasonal patterns, or user feedback. The moment you optimize for one metric, the landscape changes.
This means engineers can’t just set up evaluations once and move on. You need a living evaluation framework that continuously reflects reality. That’s a different kind of engineering discipline. I’d compare it to the shift that happened when companies moved from waterfall to continuous deployment, except now you’re continuously evaluating the intelligence of your system, not just its correctness.
For developers building AI-powered features, this is crucial. Your test suite needs to be adaptive. You need stakeholders who understand that a 95% accuracy score today might mean 87% accuracy next month if the problem definition shifted. That’s not regression; that’s realism.
Balancing Latency Against Accuracy
Here’s where it gets interesting from an engineering standpoint: customer support has hard latency constraints. A user waiting for a response on Airbnb isn’t going to wait 10 seconds while multiple agents deliberate. But a wrong response is worse than a slow one.
This forces a choice that pure ML research papers rarely address. You can’t always pick the most accurate model. You need the most accurate model that responds within your latency budget. And that budget isn’t static; it changes based on the severity of the issue, the time of day, and how many users are waiting.
I think this is where experienced engineering judgment becomes non-negotiable. Junior engineers might optimize for accuracy alone or latency alone. Senior engineers, especially those working on AI systems at scale, understand that you’re always negotiating these tensions. The evaluation framework has to make those tradeoffs visible and measurable.
What AI Coding Tools Teach Us
Ahmad’s point about AI coding tools is subtle but important. These tools demand a higher level of judgment from engineers, not less. I think many people got this backwards when tools like GitHub Copilot emerged. Some thought automation would reduce the need for expertise. It’s actually the opposite.
When you’re reviewing code suggestions from an AI, you need stronger fundamentals to know whether it’s right. The tool moved the bottleneck from implementation to evaluation. That’s true for customer support agents too. The system might generate a response that sounds plausible but is factually wrong in a way that only someone with domain expertise would catch.
This has implications for how we hire, train, and structure engineering teams. Judgment becomes the scarce resource. And judgment can’t be trained in a few weeks. It comes from understanding the intersection of product requirements, system constraints, and real-world failure modes.
Airbnb is evolving its engineering organization specifically to handle this. They’re not just deploying AI; they’re building teams that can govern AI at scale. That’s a different organizational structure than the one many companies have today.
The lesson here extends beyond customer support. Every team building AI-powered systems needs to think about how to build evaluations that reflect reality, how to make latency-accuracy tradeoffs explicit, and how to ensure their engineers have the judgment to deploy systems responsibly. The technology is just the beginning of the problem.