Why Your AI Agent Works in English but Fails in Igbo | Odella Blog

Why Your AI Agent Works Great in English and Falls Apart in Igbo

If you've deployed an AI agent that works beautifully in English demos and then quietly underperforms once real customers start typing in Hindi, Arabic, or Yoruba, you're not imagining it — and now there's research that explains exactly where it breaks.

A new paper from Fujitsu Research of Europe, Fujitsu Research, and Cohere — An Actionable Diagnosis of Multilingual, Multi-Agent Planning Failures (Vikas Pahuja and Jonathan Brokman, equal contribution; with Omer Hofman, Tamir Nizri, Daniel Vishna, Seraphina Goldfarb-Tarrant, Kelly Marchisio, Hisashi Kojima, and Roman Vainshtein), published August 4, 2026 — pinpoints exactly where multilingual AI agents go wrong, and demonstrates a fix that measurably improves accuracy.

The problem: it's not the model, it's the plan

Most multi-agent systems work the same way: a user sends a request, a planner breaks that request into a sequence of steps, and specialized sub-agents (web search, document processing, coding, etc.) carry out those steps. It's well known that these systems perform worse in non-English languages — prior research has already shown degradation in structured tool-calling and web navigation tasks. What hadn't been clearly mapped is where inside the system that degradation actually happens.

This paper's core insight is that the damage is often done at the very first step — the moment a user's request gets converted into an executable plan. The authors call this a planning-grounding failure: a mismatch between what the user asked for and what the plan says to do, such that even if every downstream step executes perfectly, the final answer still won't satisfy the original request.

Think of it as a translation problem that happens inside the agent's reasoning, not just at the language layer. A user asks about a specific report from a specific agency published in a specific month — and by the time that request becomes a plan, the agency has become a different (but plausible-sounding) organization, or the date range silently vanished, or the plan starts pulling data in the wrong order.

Five ways plans quietly go wrong

Through careful analysis of real failed task executions, the researchers identified five recurring failure types — each one a different kind of detail the plan fails to preserve:

Entity grounding — the plan substitutes, drops, or hallucinates a key entity (a person, document, place, or object named in the request).
Source grounding — the plan changes or omits a required source (the wrong file, webpage, or citation — including pulling the right page but the wrong section of it).
Temporal grounding — a required date, date range, or "as of" condition gets dropped or misapplied.
Operation grounding — the plan follows a technically-valid-looking but wrong sequence of steps, searches for the wrong kind of evidence, or subtly shifts the task's actual objective.
Answer-format grounding — the substance is right, but the response ignores the requested output shape (a paragraph when the user wanted just a number, for instance).

The team then quantified how often these show up across 11 languages, using an LLM judge whose labels matched human annotators closely (macro-F1 of 0.906 on a validated subset). The pattern was clear and consistent: as a language's available training data shrinks, planning-grounding failures — especially operation and entity grounding — make up a bigger and bigger share of what goes wrong. In other words, this isn't a minor edge case for a handful of rare languages; it's a predictable gradient tied directly to how much text a language has on the open web.

The fix: make the agent write down what it can't afford to forget

Having named the disease, the researchers tested a fairly simple, practical treatment: TART (Taxonomy-guided Actionable Task Representation). Before the planner ever sees the user's request, a model converts that request — regardless of language — into a compact, structured summary covering exactly the five things that tend to get lost: the entities involved, time constraints, source constraints, the type of operations required, and the expected answer format. That structured summary travels alongside the original request through the entire agent pipeline — planner, coordinator, and worker agents alike — acting like a checklist the system can't quietly drop partway through.

The results, tested across three different LLM backbones (GPT-5-mini, Mistral Large 3, and Qwen3-VL-235B-A22B), two benchmarks (GAIA-MAPS and MULTITAT), and two different agent-team configurations, were consistently positive:

On GAIA-MAPS with GPT-5-mini across 11 languages, average accuracy rose from 24.9% to 30.5% — a 5.6-point gain, improving in 10 of 11 languages tested (Yoruba and Igbo, two of the lowest-resource languages, gained roughly 8–11 points each).
With Mistral Large 3, accuracy rose from 19.6% to 25.5% (+6.0 points, a 30% relative improvement), improving in all seven tested languages.
On the simpler MULTITAT benchmark, Mistral Large 3 improved from 21.0% to 31.0% — a 10-point, nearly 48% relative gain.

The gains were largest on easier tasks and shrank to roughly zero on the hardest, longest-running tasks — the authors' honest read is that fixing the plan can't undo damage from the many additional tool calls and retrieval steps a long task still has to get right downstream. It's a targeted fix for one specific failure point, not a cure-all for agent reliability.

The honest limitations

To their credit, the authors are upfront about where this research doesn't (yet) reach:

The added non-English test queries were machine-translated, not natively authored — real user phrasing in the wild may behave somewhat differently.
The taxonomy itself was derived from a relatively small set of 80 cases where English succeeded and another language failed, which could miss failure types that don't show up in that specific comparison.
Large-scale failure counting relied on an LLM judge (Claude Opus 4.8), spot-checked against humans but not exhaustively verified across every language and model.
Multiple-run stability testing was only done for one of the three backbones.

None of this undermines the core finding, but it's a reminder that "planning-grounding failure" is one well-evidenced piece of the multilingual-agent-reliability puzzle, not the whole picture.

Why this matters if you're deploying AI agents

If your team is building or evaluating agentic AI for a global user base — customer support, internal operations, research assistance, anything where non-English requests are a real percentage of volume — this paper gives you a concrete, testable hypothesis for where quality problems are likely hiding: not necessarily in the underlying model's language fluency, but in the handoff between "what the user asked for" and "what the system decided to do about it."

That's a genuinely useful, actionable finding rather than another "agents are unreliable" headline. The fix costs relatively little — it's an extra structured-representation step, not a full re-architecture — and it improved results across every model and language combination the team tried it on (bar a couple of near-zero-change edge cases).

At Odella, this lines up with a principle we build around directly: an AI employee is only as trustworthy as its ability to preserve the actual intent of a request as it moves through multiple steps and systems. Explicit, inspectable task representations — the kind of "show your work" structure TART introduces — are exactly the sort of transparency layer that makes agentic automation something a business can actually rely on, in whatever language its customers or employees happen to be using. Better engineering discipline at the planning layer, not just bigger models, is what closes gaps like this.

This is our summary of the authors' published research, not our own study. Full credit to Vikas Pahuja, Jonathan Brokman, Omer Hofman, Tamir Nizri, Daniel Vishna, Seraphina Goldfarb-Tarrant, Kelly Marchisio, Hisashi Kojima, and Roman Vainshtein (Fujitsu Research of Europe, Fujitsu Research, and Cohere). Read the full paper on arXiv (arXiv:2608.03735, submitted August 4, 2026).