Agent Evaluation · Multilingual Workflows

Your workflows mix languages.
Your benchmarks don't.

Most agent benchmarks assume the world speaks one language. When researchers at Beijing Jiaotong University and Tencent's Weixin AI team broke that assumption across 67 real workplace tasks, state-of-the-art agents fell apart in a specific and predictable way: errors made early in the workflow didn't stay local. They cascaded.

Core finding
A linguistic misunderstanding at step 2 changes what step 3 sees, which changes step 4's output, and so on. By step 10, the cascade is complete. Monolingual benchmarks can't see this failure mode at all.

First surfaced in Tandemly Briefing — 2026-07-18.

scroll to explore

Two research traditions
that never spoke.

The field has excellent multilingual benchmarks. It also has excellent agent benchmarks. Neither one tests what happens when language variation hits a running workflow.

Multilingual benchmarks like XGLUE and M-MMLU have been refining their craft for years. They test whether a model can understand, reason about, and generate text across dozens of languages. But the format is almost always static: give the model a sentence or a document, ask a question, score the answer. There is no sequence of steps. There is no tool use. The model acts once and the evaluation is complete.

Agent benchmarks like SWE-bench and WebArena have a different focus. They test whether an agent can complete a long, tool-heavy task, often requiring dozens of steps, sub-goals, and tool calls. But the assumption embedded in most of them is that the whole workflow happens in one language. The instruction is in English. The tool outputs are in English. The expected answer is in English.

Real workplaces don't work this way. A commerce team handles orders from multiple markets. A legal team reviews documents that arrive in the client's language and must be summarized in the firm's working language. A localization workflow might receive a source document in French, apply translation tools, verify quality using a Japanese-language style guide, and produce output in Korean. Language switching is not an edge case in these workflows. It is the workflow.

The question this paper asks

What happens when an LLM agent must manage language variation not as a single translation step but as a property of the entire workflow? Do existing models hold up, and if not, where exactly do they break?

Sixty-seven workflows,
ten languages, five domains.

PolyWorkBench constructs real workplace workflows where language is woven through every step, not isolated to a single translation action.

The benchmark includes 67 tasks drawn from five workplace domains: commerce, knowledge work, legal analysis, localization, and manufacturing. Each task is a multi-step workflow requiring the agent to process inputs, invoke tools, reason across steps, and produce a structured output. Tasks are split into 29 baseline tasks (6 to 8 steps each) and 38 stress tasks (8 to 12 steps each), with an average of 8.5 steps per task.

Ten languages appear across the benchmark: English, Mandarin, Japanese, Korean, Vietnamese, Russian, French, Spanish, German, and Arabic. The key design choice is that language variation is placed at different points in each workflow. An instruction might arrive in German. The source document might be in Japanese. The required output format might specify French. In 88% of tasks, the agent must work in three or more languages within a single workflow execution.

1
Executable verification
Pytest-based tests check that any code or structured output produced during the task is functionally correct: it runs, produces the right type of result, and satisfies schema constraints. This is the hardest grading layer to inflate because the code either works or it doesn't.
2
Weighted structural rubric
A step-by-step scoring rubric gives partial credit for multi-step tasks where the agent completed some sub-goals correctly but failed others. This captures the difference between an agent that failed at step 9 versus one that failed at step 2.
3
LLM semantic judge
An LLM evaluates whether multilingual outputs are semantically consistent: does the French summary accurately represent the Japanese source? Does the Korean output preserve the legal meaning of the German original? This catches failure modes that deterministic checks miss entirely.
Why three layers?

No single grading approach is sufficient for multilingual long-horizon tasks. Executable verification is precise but blind to meaning. Structural rubrics reward progress but can't assess whether the French output is actually correct French. The LLM judge catches semantic problems but, as the paper's results show, has reliability limits of its own. The three together cover more of the failure surface than any one alone.

The harness moves scores
as much as the model.

The headline numbers are high. The story underneath them is about variance that doesn't come from the model at all.

Best Pass@1 (top model + harness)
0.921
Claude Opus 4.8 + ClaudeCode harness
Harness-driven swing (same model)
0.21
Max Pass@1 gap across harnesses, same model weights
LLM judge correlation with structural score
0.18
r = -0.04 when judge expresses high confidence
Finding 1: The harness is a first-class variable

The same model, switched between agent harnesses, swings 0.08 to 0.21 Pass@1 points on PolyWorkBench tasks. DeepSeek-v4-Flash reaches 0.796 inside the ClaudeCode harness. The same model in a different harness can sit measurably lower. GPT-5.5 paired with OpenClaw reaches 0.776. These are not small differences. They represent the harness layer accounting for as much outcome variance as model capability does on many tasks.

The benchmark is explicit about this: "Without disclosing the harness, benchmark scores lack meaning." A reported Pass@1 number attached to a model name, without a harness name, is incomplete information.

Finding 2: Errors compound across steps

The paper's clearest finding is the compounding effect. A linguistic misunderstanding at step 2 does not stay local. It changes what the agent passes to step 3, which changes step 4's input, and so on through the workflow. By the end of a 10-step task, a single language-switch error can propagate into every downstream output.

Agents that handle isolated translation tasks well still degrade on PolyWorkBench, because the failure mode is a workflow property, not a single-step property. The error is not "this model cannot translate Japanese." It is "this model's translation error at step 3 corrupts the reasoning context for steps 4 through 10."

What monolingual evals measure
Each step in isolation. Did the model answer the question correctly? Did the code pass the test? Does the output match the schema? These checks pass even when linguistic errors in earlier steps have poisoned the context for later ones.
What PolyWorkBench reveals
Error propagation across the workflow. A step-3 language mistake shows up in step-7 output degradation. A mistranslated instruction colors every downstream tool call. The failure is visible only when you grade the whole chain, not individual nodes.
Finding 3: The LLM judge is unreliable as a primary grade

The semantic LLM judge, across all tasks, correlates with structural correctness at r=0.18. Within the regime where the judge expresses high confidence in its assessment, that correlation drops to r=-0.04. A more certain judge is no more accurate than an uncertain one. The paper recommends treating the LLM judge as a supplement for failure modes that deterministic checks miss, not as the primary scoring mechanism.

Scope and limitations

67 tasks across five domains is enough to surface systematic patterns, but the domain coverage reflects the team's available expertise and may not generalize to all multilingual workflow types. The benchmark is static: task difficulty is fixed at construction time rather than adjusted dynamically. The LLM judge's unreliability limits what the paper can conclude about semantic quality specifically, as opposed to structural correctness.

What to change
before the workflow ships.

The findings here are actionable for teams building agents that will touch multilingual data, whether they know it or not.

1
For teams evaluating agents for multilingual deployment
Standard monolingual evals do not tell you whether your agent can handle a workflow that switches languages across steps. Passing SWE-bench does not predict behavior on a German-to-Japanese-to-Korean legal review workflow. Before deploying into multilingual production, add a multilingual variant of an existing internal eval. Pick a task the agent currently passes in English. Introduce language variation at the instruction, source document, and output requirement levels. Measure the pass-rate delta. If it is significant, you have a real gap that more monolingual fine-tuning will not close.
2
For teams selecting models and frameworks
The 0.08 to 0.21 Pass@1 harness variance means published benchmark scores are incomplete without a harness name attached. Before concluding a model is insufficient for your multilingual workflow, run it inside the harness you actually plan to deploy. A model that looks marginal in a reference harness may perform adequately in yours, or vice versa. The harness is not a neutral container. It is a variable that needs to be held constant in fair comparisons.
3
For teams building evaluation infrastructure
The LLM judge result is a direct warning. A semantic judge with r=0.18 correlation to task outcome is not a reliable primary grade, and the r=-0.04 high-confidence finding means higher judge certainty provides no additional signal. Use LLM semantic judges as a supplement layer, not a replacement for executable verification and structural rubrics. Report all three scores separately. If they diverge, that divergence is itself informative: the agent may be producing semantically plausible output that fails functional tests, or functionally correct output that is semantically incoherent.
4
For teams that believe their workflows are monolingual
The benchmark's finding that 88% of realistic workplace tasks require three or more languages within a single workflow is a prompt to audit your assumptions. Data arrives from vendors, customers, and tools in the language they use. If your agent summarizes that data, it is operating in a multilingual context whether or not your prompt was in English. Log which steps in your workflow receive non-English inputs. That log will likely reveal a multilingual surface that your evaluation currently ignores.

Where to go
from here.

Concrete next steps if you want to act on this research.

1
Read the paper
Li, H., Liu, Y., Zhang, Z., et al. (2026). PolyWorkBench: Benchmarking Multilingual Long-Horizon LLM Agents. Beijing Jiaotong University & Tencent Weixin AI. arXiv:2607.06008v2.
2
Add a multilingual variant to your next agent eval
Choose one task your agent handles reliably in English. Construct a version where the instruction is in one language, the source document is in a second, and the expected output is in a third. Run the same agent unchanged and record the pass-rate delta. This single experiment will tell you more about your multilingual exposure than any benchmark score.
3
Run your model inside the harness you will actually deploy
Before comparing models on multilingual tasks, pin the harness. Identify the agent framework you plan to use in production and run all candidate models through it. Harness-normalized comparisons give you information. Harness-varied comparisons give you noise.
4
Audit your workflow for language switching points
Log every step in your agent's workflow that receives an external input. Flag any step where the input language may differ from the instruction language. These are your compounding-error risk points. Even a single off-language input early in a long workflow can propagate into every downstream step.
5
Pair deterministic and semantic evaluation in your grading stack
If you use an LLM to grade multilingual outputs, validate it against a structural rubric before trusting it. Measure the correlation between your judge's scores and deterministic correctness checks on a held-out set. If that correlation is below 0.5, treat judge scores as annotation data, not as the primary grade. Report both numbers together in any evaluation summary.