Ryanair
12 AI agents into one, 80% contained

Europe’s largest low-cost airline handles 120,000 customer chats a day across seven languages, and it used to route them through twelve agents, each owning a slice of the problem. In February 2026 that architecture was replaced by a single agent. Since then, 80% of conversations are finished inside the bot without a human, and customer service contacts per passenger carried are down 70%. From launch in October 2024 the system has produced ten million answers at a reported 94% accuracy. The figures come from an AWS case study with customer attribution — published jointly, with no independent audit.

The same question, answered in opposite directions

Another case from the same week runs the other way. Crocs built its shopping and service assistant as several specialised agents sitting under a single orchestrator, and took five months from concept to customer-ready. When it wanted a phone channel, it shipped voice in seven weeks by reusing the actions and instructions already built for chat rather than rebuilding them.

Both went into production, and the two architectures point in opposite directions. The useful question is not which one is better. It is where each team drew the boundary.

What consolidation saves is every hop

In a topic-split architecture the cost hides in the hand-offs. Every route is a round trip, an added failure point and one more context hand-off, and context loses information each time it moves. When all intents share one entry point and read the same backend, that cost buys nothing back: a baggage question and a refund question are both lookups against the same booking.

The model change makes the same point. Bringing response time from 18 seconds down to 2.9 seconds added no reasoning capability at all. It moved the wait inside what a customer will tolerate. Containment is a function of waiting: a correct answer that takes 18 seconds arrives after the customer has left.

In other words, containment looks like a capability number but is decided by three things at once — how accurate the answer is, how fast the system responds, and where the hand-off threshold sits. Optimising one of them alone leaves the number flat.

Split or merge: follow the backend, not the topic

Put the two cases side by side and the test is short: do the use cases share a backend and a set of intents? If they do, merge. If one needs live data from a different system, split along that data source. Crocs drew its boundary at the order management system, not at business nouns like shopping and service. Nouns are how people sort work; data sources are how systems are actually divided.

A second lesson comes from that voice launch. Seven weeks was enough because the actions and instructions were reused, not rewritten for the phone. The same standard applies to consolidation: whether the next channel can reuse the actions matters more than how many boxes the architecture diagram has.

How the model was picked: 12,000 of your own questions

The selection step here is worth copying regardless of the outcome. Five foundation models were compared against 12,000 real production customer questions; the chosen model improved response latency by 84% and accuracy by 25%. Those are vendor-side figures, but the method stands on its own.

The test set has to be your own historical tickets, because it carries your vocabulary, your sentence fragments, your typo distribution and your language mix. A public leaderboard measures someone else’s distribution, and leading there says nothing about whether a model clears your bar. Only after that step does a selection decision become something another person can check.

Guardrails belong on the send path

One line in the case study is easy to skim past: every answer is scored by a multi-model, multi-dimensional guardrail system before it reaches the customer. Quality control sits on the send path rather than in an after-the-fact sample.

The two approaches have different cost structures. Sampling after the fact means the customer already saw the bad answer. Blocking before sending costs a little latency instead. Support work usually accepts that trade, because one wrong answer carries payouts, complaints and lost trust that cost more than a few hundred milliseconds. Where latency tolerance is genuinely tight, the interception needs a defined fallback rather than letting requests sit in the checker.

Three bills that come with consolidation

Merging twelve agents into one shows up as gains in latency and operations, and the costs appear elsewhere. The first bill is context: each small agent used to carry its own instructions, so a merged agent needs a shared context structure or the intents contaminate each other. The second is policy: when blocks are split by topic, each can carry its own rules, but once merged, rule conflicts have to be resolved in one place. The third is rollback: a failing slice could once be taken offline on its own, while a merged agent has to be rolled out and pulled back as a whole.

None of these is an argument against consolidating; they are the entry fee. Teams that skip them tend to patch the merged agent with more prompt text, and end up with a single agent that behaves like an uncoordinated crowd.

Where the limit of this story sits

• The denominator. Eighty per cent is the share of bot-received conversations that avoid a hand-off, not a share of total support contacts. Refund disputes and flight disruptions still reach people. Staff did not vanish; the contact point moved earlier.
• Single-point exposure. One agent now serves seven languages and every intent, so a model or dependency failure has a wider blast radius than it did across twelve agents. That calls for staged rollout, rollback and a defined degradation path.
• Provenance. Every figure was published jointly by vendor and customer with no independent audit. Say that when quoting, and do not treat it as an industry benchmark.
• Channel behaviour. Voice and text have different tolerances for latency and interruption. Reusing the same actions is not the same as reusing the timeout and barge-in handling, which still needs tuning.

What the case does not answer

The case study does not say over what window the 70% contact reduction was achieved, what happened to satisfaction after a hand-off, or whether the consolidated agent has had a single-point outage. All three are measurable inside your own programme, and none of them should be replaced by one flattering snapshot number.

What a 70% contact reduction looks like on the cost sheet

Contacts measured per passenger carried is the load-bearing detail. It means the saving is not seven out of ten jobs; it is that customer service no longer has to grow in step with volume. The case study makes the same point in its own words: under the old model, capacity scaled linearly with enquiries, and this system decoupled capacity growth from headcount.

Which is why the number to evaluate is not this year’s saving but the slope of unit cost: how many additional support people each extra million passengers requires. If the slope changed, the return compounds as the business grows. If it did not, the airline simply spent less in one budget year.

What the move from twelve agents to one should look like

The case says the consolidation completed in February 2026 and stops there. The reusable engineering sequence usually runs in three steps: merge the logs and intent labels from the twelve agents into one evaluation set; run the single agent in shadow mode, receiving requests but not answering customers; compare containment, latency and hand-off rate, and only then shift traffic in slices. The point of the sequence is that every step can be reversed, instead of handing the support channel over in one move.

Shadow mode only covers what can be observed. Long-tail intents in real conversations, interruption behaviour in the voice channel, and the habits of the support staff themselves only become visible after traffic moves. Skipping the staged rollout because offline numbers looked good is the standard way this kind of project fails.

Our read

Agent count is a latency and operations decision, not a capability tier. Twelve agents becoming one makes a case study because the gain landed on metrics — latency, containment, contacts per passenger — rather than on the architecture diagram.

Second: split by data source, merge by topic. Topics are how people sort work. Data sources are how systems divide, and requests that follow data sources usually fetch once instead of bouncing between agents.

Third: keep model selection out of the leaderboard. The only portable evidence is your own ticket sample, one comparison run per candidate, with the result filed where an acceptance review can find it.

Four decisions to settle before launch

• Count intent coverage and backend sharing first. Same backend and same channel argues for a single agent; live data from separate systems argues for splitting along those systems.
• Put a response-time percentile into the launch gate instead of leaving it in a performance report. In this kind of work, latency is conversion.
• Select models against the last 30 days of tickets, and require a reproducible result on your own sample per candidate.
• Put the guardrail on the send path and decide the fallback in advance: hand off to a person, switch models, or refuse to answer.

Agree on metric definitions before arguing about automation rates

In support work the same metric means different things at different companies: whether the denominator is bot-received conversations or all inbound calls, whether a hand-off counts as a failure, how repeat contacts are counted. With definitions left loose, figures from two projects cannot be compared, and teams quietly push the hard cases toward the human queue to make their number look better. Fixing the definitions costs less time than the arguments they prevent.

A workable approach is to watch both sides at once: containment on the bot side, and time per contact on the human side. Watch only the first and the boundary slides toward people. Watch only the second and intents that should never have been automated get forced into the bot. Reading them together is what tells you whether a change solved the problem or just moved it.

Wiring the change into your own budget model

Support automation budgets usually get stuck at the accounting boundary: headcount sits in operations, platforms and evaluation sit in technology, and the two never appear on the same sheet. The result is that the most necessary spending — evaluation sets, guardrails, people during the staged rollout — is the hardest to approve, because its return shows up in the headcount table a year later.

Putting the unit-cost slope into the financial model is one way around that. Treat contacts per million passengers as a forecastable line, then ask how much a given automation investment bends it. Cost and return end up speaking the same language instead of waiting for a year-end headcount review.

One expectation belongs in the business case up front: the slope rarely moves in year one. Staged rollout, evaluation and parallel staffing all land early, while the return only starts compounding once volume keeps growing. Judging this class of project on the first year’s settlement almost guarantees the wrong answer.

References

• AWS case study: Agentic AI Handles 120,000 Daily Chats Using Amazon Nova at Ryanair
• PYMNTS: Crocs Puts One AI Agent in Charge of Sales and Service (22 September 2026)
• Salesforce customer story: How Crocs built a retail superagent with Agentforce