CivBench: A Long-Horizon Benchmark for Tool-Mediated Agents in Civilization VI
Abstract: We present CivBench, an open-source benchmark for evaluating LLM agents in long-horizon, tool-mediated environments through the Model Context Protocol (MCP). A single episode spans 300+ turns and produces thousands of tool calls over a large action space, requiring sustained planning, state monitoring, and execution under partial observability. The environment exposes 76 MCP tools and a narration layer that converts visual game state into structured text. We use CivBench to characterise agent behaviour across four model families in 23 admissible runs. The sample is a pilot, not a model ranking: aggregate outcomes do not reliably discriminate models at this scale. Instead, we introduce two interface-level metrics that the environment makes measurable: Proactive Monitoring Rate (PMR), capturing whether agents actively query latent strategic state, and RAG@10, capturing whether commitments stated in structured planning reflections are executed within ten subsequent turns. Across runs we observe two consistent patterns under a shared playbook protocol. Agents under-monitor strategically relevant state that is available but requires explicit querying: despite playbook guidance to query victory progress every 20 turns, agents do so only every 30 to 75 turns, and in 7 of 20 detectable defeats they failed to query within the 20 turn warning window before game end. Agents also frequently fail to execute near-term commitments stated in their own planning reflections (RAG@10 between 48.2% and 65.8% across models). Both patterns arise despite tool access and explicit guidance, and we interpret them as deviations under instruction rather than absences of capability. We release the environment, scenarios, logs, metrics, and analysis pipeline at https://github.com/lmwilki/civ6-mcp
Paper Prompts
Sign up for free to create and run prompts on this paper.
Top Community Prompts
Explain it Like I'm 14
1. What is this paper about?
This paper introduces CivBench, a test for seeing how well AI agents can make decisions over a long period of time.
The AI agents play Civilization VI, a strategy game where players build cities, research technologies, manage armies, make friends or enemies, and try to win in different ways. A game can last more than 300 turns, so the AI must remember its plans and keep checking what is happening.
The researchers are not mainly asking, โWhich AI wins the most games?โ Instead, they are asking:
- Does the AI remember to look for important information?
- Does it follow through on plans it wrote down?
- Can it keep making sensible decisions over a very long game?
2. What questions did the researchers ask?
The paper focuses on two main problems.
Does the AI monitor important information?
In Civilization VI, important information is not always shown automatically. The AI has to use a tool to ask for it.
For example, the AI might need to ask:
- How close are other players to winning?
- Is another civilization becoming a dangerous military rival?
- How are diplomatic relationships changing?
- Is a rival close to a science or culture victory?
The researchers wanted to know whether the AI would actively check this information, or whether it would become focused on smaller, nearby tasks and forget the bigger picture.
Does the AI carry out its own plans?
The AI writes planning notes such as:
โBuild a campus in the next city.โ
or
โCheck victory progress.โ
The researchers then check whether the AI actually does these things during the next 10 turns.
This tests the difference between saying what should happen and actually making it happen.
3. How was the research carried out?
The game environment
The researchers connected language-model agents to Civilization VI using a system called the Model Context Protocol, or MCP.
In simple terms, MCP works like a set of buttons or tools that the AI can use. The paper provided 76 tools, including tools for:
- Checking the game state
- Moving and controlling units
- Managing cities
- Choosing technologies
- Trading
- Talking to other civilizations
- Checking victory progress
- Ending a turn
A typical turn required between 5 and 15 tool calls. Over a whole game, this created thousands of decisions.
The narration system
The AI did not simply see the whole game screen like a human player. Instead, it received information as organized text when it asked for it.
For example, it could ask for information about:
- Its cities
- Its military units
- Nearby enemies
- Other civilizations
- Technology research
- Victory progress
This is similar to playing a game while wearing a helmet that only shows information when you ask for it. The information exists, but the AI must remember to look for it.
This allowed the researchers to tell the difference between:
- Information the AI could not access
- Information the AI could access but forgot to request
The experiments
The researchers tested four families of LLMs in 23 complete games. The models played against Civilization VIโs built-in computer opponents.
All models received the same general instructions, called a playbook. The playbook encouraged them to:
- Check the game situation
- Look for dangers
- Make decisions
- Take actions
- Write a short diary about their plans
The researchers recorded every tool call, action, and planning note.
The two main measurements
The paper created two special measurements.
Proactive Monitoring Rate, or PMR
PMR measures how often the AI checks important, large-scale information compared with all its other tool uses.
A low PMR means the AI spends most of its time on local tasks, such as moving a unit or choosing something for a city, and rarely checks the overall situation.
RAG@10
RAG@10 measures how often the AI completes a promise or plan within the next 10 turns.
For example, if the AI writes, โFound a new city,โ but does not found one during the next 10 turns, that plan is counted as not completed.
4. What did the researchers find?
Finding 1: The AI often failed to check important information
The models spent very little time checking strategic information.
Their overall monitoring rate was only about 0.96% to 2.13% of their non-essential tool calls. Checking victory progress was especially rare.
Although the playbook suggested checking victory progress every 20 turns, the AI usually checked it only every 30 to 75 turns.
This caused real problems. Among 20 losses where a rivalโs victory could have been detected early:
- The AI checked victory progress in time in 13 cases.
- It failed to check in time in 7 cases.
This means the AI sometimes lost even though the warning information was available. It simply did not ask for the information soon enough.
The researchers call this problem the โsensorium effect.โ Humans naturally notice many things on a game screen, but an AI using tools only notices information that it deliberately requests.
Finding 2: The AI often did not follow its own plans
The AI frequently wrote down reasonable plans but failed to complete them soon afterward.
The RAG@10 scores were between 48.2% and 65.8%. This means a large portion of the AIโs short-term plans were only partly completed or not completed at all.
For example, an AI might write:
- โBuild campuses in new cities.โ
- โFound a second city.โ
- โCheck victory progress.โ
But then it might spend the next turns doing other things instead.
This shows a gap between planning and execution. The AI may understand what it should do, but that does not guarantee it will actually do it.
Finding 3: Winning scores were not enough to compare the models
Only 3 of the 23 games ended in victories for the AI, and all of these were technology victories in one scenario.
Because the sample was small, the researchers could not reliably say that one model was better than another. The results were too varied.
This is why the paper is not presented as a ranking of AI models. Instead, its main purpose is to study how the agents behave during the game.
5. Why are these findings important?
A final score can hide many problems. Two AI systems might receive similar scores even though they make very different decisions along the way.
CivBench records the entire process, including:
- Which information the AI asks for
- Which tools it uses
- Which dangers it notices
- What plans it writes
- Whether it follows those plans
- How quickly it responds to threats
This gives researchers a more detailed picture of AI behavior.
The results suggest that an AI can have access to useful information and still fail because it does not retrieve that information at the right time. It can also produce intelligent-sounding plans without reliably carrying them out.
6. What could this mean for the future?
The paper suggests that making AI smarter at reasoning may not be enough. AI agents may also need better systems for remembering tasks and checking important information.
Possible improvements include:
- Automatically reminding the AI to check critical information
- Showing important warnings without requiring a separate request
- Keeping a permanent task list
- Tracking promises and plans across many turns
- Asking the AI to review unfinished tasks regularly
- Using software that prevents important plans from being forgotten
These ideas could help far beyond video games. Real-world AI agents may need to manage calendars, control computer programs, monitor machines, or make business decisions over long periods.
However, the researchers emphasize that this was a small pilot study, not a final judgment about all AI systems. The experiments used only 23 games, one game environment, and a particular set of instructions. More testing is needed.
Conclusion
CivBench is a new way to test whether AI agents can stay organized during long, complicated tasks. By using Civilization VI, the researchers studied whether AI agents:
- Remember to check important information.
- Keep track of the overall situation.
- Follow through on their own plans.
The main lesson is that AI agents may fail not because they lack all the necessary knowledge, but because they do not always look for the right information or act on what they already planned. Better monitoring tools, memory systems, and task trackers could make future AI agents more reliable.
Knowledge Gaps
Knowledge gaps, limitations, and open questions
The paper leaves the following issues unresolved:
- Generalization beyond Civilization VI is untested. It remains unclear whether under-monitoring and reflectionโaction gaps occur in other long-horizon environments, such as web navigation, software engineering, robotics, or real-world API use.
- The benchmarkโs ecological validity is uncertain. The narration layer selectively highlights threats, actionable options, and state summaries, so agent behaviour may depend heavily on interface design rather than reflect general tool-mediated agency.
- The causal effect of the narration layer has not been isolated. No ablation compares passive observations, raw game-state access, pixel-based input, automatically surfaced alerts, and the current query-only interface.
- The causal role of the shared playbook remains unresolved. Because all reported runs use substantial human-authored guidance, the study cannot determine how much of the observed monitoring and execution behaviour is caused by model limitations versus prompt interpretation, prompt length, or instruction conflicts.
- No playbook ablation establishes a spontaneous baseline. The paper reports that only 21% of pre-harness runs completed naturally, but it does not systematically compare no-playbook, shorter-playbook, adaptive-playbook, and structured-playbook conditions.
- The effect of structured diaries is unknown. It remains unclear whether diaries improve long-horizon performance by preserving state, impair performance through context and token costs, or merely make commitments more explicit and therefore easier to measure.
- The relationship between monitoring and performance is correlational. Low PMR is associated with missed detectable threats, but the study does not establish whether increasing monitoring improves victory rates, survival, score, or other strategic outcomes.
- The optimal monitoring policy is unknown. The prescribed check every 20 turns is not justified empirically, and the paper does not evaluate whether monitoring should be event-triggered, adaptive to game phase, or tailored to specific victory threats.
- PMR does not distinguish useful from redundant monitoring. The metric counts monitoring calls but does not measure whether queries retrieve novel information, alter decisions, prevent errors, or are strategically appropriate.
- The definition of monitoring tools may bias PMR. The selected set of โstrategic monitoringโ calls and the exclusion of infrastructure calls are protocol-dependent; alternative classifications could produce different conclusions.
- The warning-window analysis may overstate missed opportunities. A query within 20 turns is treated as sufficient exposure to a threat, but the analysis does not show whether the returned information was clear, noticed, correctly interpreted, or actionable before the loss.
- The study does not examine false-positive monitoring costs. Querying global state consumes tool calls, context space, latency, and API budget, but the benchmark does not quantify the trade-off between additional monitoring and reduced local action capacity.
- RAG@10 is sensitive to the chosen horizon. Results may change substantially for horizons of 1, 5, 20, or 50 turns; no sensitivity analysis establishes whether the reported gap is specific to ten turns.
- The commitment-extraction pipeline remains partially subjective. Commitments are extracted and labelled with LLM assistance, but the paper does not provide a complete error analysis for ambiguous, conditional, abandoned, superseded, or strategically invalid commitments.
- RAG does not adequately distinguish failure to execute from rational plan revision. A commitment may be appropriately abandoned after new information arrives, yet this can be scored as non-execution; the benchmark lacks a systematic category for justified revision.
- Partial execution receives an arbitrary weight. The value of assigning partial commitments a score of $0.5$ is not theoretically or empirically validated, and alternative weighting schemes may alter model comparisons.
- The benchmark does not measure commitment quality. A model could receive a high RAG score by making conservative or trivial commitments, while a strategically superior but riskier plan may score poorly if circumstances change.
- The link between RAG and actual strategic competence is unresolved. It is unknown whether higher commitment execution predicts better game outcomes, or whether strict execution can be harmful in a dynamic environment.
- Annotation reliability is based on a small validation sample. Agreement was assessed on only 50 commitments, and the sample excludes some model families; larger, independently annotated datasets are needed to estimate reliability across commitment types and scenarios.
- Potential evaluatorโmodel-family bias is not fully excluded. The primary labeller shares a model family with one evaluated agent, and the paper does not report blinded multi-rater annotations across all commitments.
- The model comparison is statistically underpowered. With 23 runs, uneven model coverage, and one exploratory model represented by a single run, differences between models, scenarios, or metric distributions cannot be estimated reliably.
- Run-level dependence and variance are insufficiently characterized. The paper does not report repeated runs under identical model, seed, and configuration combinations in a way that separates stochastic model variation, game variation, and harness variation.
- The reported scenarios cover a narrow part of the environment. Most data come from Ground Control, only four runs come from Snowflake, and Cry Havoc is excluded; conclusions about military play, high difficulty, disadvantageous starts, and alternative victory conditions remain unsupported.
- Victory-condition coverage is severely limited. All observed victories are technology victories on Ground Control, leaving cultural, domination, religious, diplomatic, and score-oriented play largely unevaluated.
- The built-in AI is the only opponent setting studied. The benchmark does not establish whether the observed failures persist against human players, stronger scripted opponents, adaptive agents, or multiple independent LLM agents.
- Multi-agent interaction is not evaluated. The single-connection FireTuner constraint prevents analysis of coordination, negotiation, deception, coalition formation, and adversarial monitoring.
- The effects of map size, game speed, civilization choice, and starting position are unknown. Fixed or limited configurations may conceal behaviours that emerge under larger maps, slower games, different leaders, or more complex spatial constraints.
- Tool-interface complexity is not experimentally decomposed. It remains unclear whether failures arise from the number of tools, argument schemas, tool naming, response length, query latency, action granularity, or the need to chain multiple calls.
- Tool errors and recovery are not systematically analysed. The paper does not quantify invalid calls, API failures, stale observations, misunderstood tool responses, or the agentโs ability to recover from execution errors.
- Context-window and token-budget effects are not isolated. The study does not test whether under-monitoring or commitment failures result from context overflow, diary accumulation, tool-output length, truncation, or deliberate budget conservation.
- The benchmark does not compare memory and planning architectures. Persistent external memory, task queues, retrieval systems, hierarchical planners, reflection mechanisms, and commitment trackers are suggested but not evaluated.
- No intervention demonstrates that the proposed remedies work. Enforced monitoring schedules, surfaced alerts, persistent commitments, and structured task queues are discussed as design implications, but their effects on PMR, RAG, cost, and game success remain unknown.
- Aggregate outcome measures may be too noisy, but alternative outcome metrics are not validated. The paper introduces PMR and RAG, yet does not establish their testโretest reliability, construct validity, or predictive relationship to human judgments of competent play.
- The normalised-score denominator can complicate interpretation. Dividing by the winnerโs final score may make results sensitive to opponent performance, game-ending conditions, and the identity of the winner; alternative outcome normalisations are not compared.
- The distinction between capability and instruction-following failure remains unresolved. The authors interpret violations as deviations under guidance, but the experiments do not test whether agents can perform the same monitoring or execution tasks when explicitly queried in isolated evaluations.
- The paper does not assess whether agents recognized but ignored relevant information. Tool traces reveal whether information was queried, but not whether the model understood it, deliberately deprioritized it, or failed to incorporate it into its decision process.
- Human-agent comparability is not established. The โsensorium effectโ motivates the interface, but the study does not compare human playersโ monitoring frequency, query strategies, planning fidelity, or performance under the same narration constraints.
- Reproducibility across game and software versions remains uncertain. Results depend on Civilization VI versions, DLC, scenario files, FireTuner behaviour, model endpoints, and harness versions, but cross-version robustness is not tested.
- The costโperformance trade-off is unexplored. Full games cost approximately $31โ229 and take 2โ8 hours, yet the paper does not determine whether shorter episodes, sampled turns, surrogate environments, or partial-game tasks preserve the measured phenomena.
- Potential training-data contamination is not empirically assessed. The paper argues that live interaction reduces reliance on memorized strategy, but it does not test models with contamination controls, unfamiliar scenarios, or procedurally altered mechanics.
- The provided manuscript and benchmark scope appear incomplete for independent replication. The appendix is truncated in the supplied text, and the paper does not fully detail all model settings, prompt versions, excluded runs, preprocessing rules, and per-run data needed to reproduce every reported analysis.
Practical Applications
Immediate Applications
The paperโs most deployable contributions are its open-source benchmark artifacts, trace-level metrics, structured narration layer, and monitoring/commitment workflows. These can be used now, although the empirical findings should not be treated as broad model rankings because the study uses only 23 runs.
- Evaluate long-horizon enterprise agents before deployment (software, enterprise automation, customer operations)
- which state-query tools the agent invokes;
- whether it checks global conditions such as deadlines, budgets, permissions, or escalation status;
- whether it executes commitments made in earlier planning steps.
Potential product: an โagent reliability harnessโ that replays fixed scenarios and reports monitoring coverage, missed-warning rates, tool-call composition, and commitment-execution scores. Dependencies: a sufficiently realistic simulator or sandbox, stable tool APIs, complete interaction logs, and domain-specific definitions of โstrategic monitoringโ and โcommitment.โ
- Add proactive monitoring checks to existing agent workflows (software engineering, IT operations, cybersecurity)
- service health and incident status every few minutes;
- budget and quota utilization before submitting jobs;
- security alerts before executing administrative actions;
- deployment state before closing an incident;
- contract or deadline status before making commitments.
Potential tool: a monitoring middleware layer that injects mandatory or prioritized state queries into an MCP or API workflow. Dependencies: the monitored state must be queryable, the schedule must not create excessive latency or API cost, and the system must distinguish genuinely critical signals from routine information.
- Use commitment tracking to reduce the reflectionโaction gap (productivity software, project management, coding assistants) Agents can extract concrete commitments from their own planning notes and place them in a persistent task queue. Each commitment should include a target, deadline or execution window, completion state, and evidence of completion. For example, a coding agent that states โupdate the database migration and run testsโ should automatically create two verifiable tasks and check them before declaring success.
Potential products: structured agent diaries, action checklists, task graphs, and โplan-versus-executionโ dashboards. Dependencies: commitments must be specific enough to evaluate; natural-language extraction can misclassify vague intentions; changing circumstances may legitimately invalidate a plan.
- Improve tool-use observability and debugging (AI engineering, software quality assurance)
- poor reasoning after receiving information;
- failure to retrieve necessary information;
- invalid or inefficient tool calls;
- failure to carry out a previously stated plan.
This is more actionable than using only final task success. Teams can build dashboards showing monitoring-call frequency, warning-response latency, repeated queries, abandoned commitments, and local-action/global-state ratios. Dependencies: logging must comply with privacy and security requirements, and metric definitions must be tailored to each application domain.
- Benchmark MCP and API-compatible agents in realistic sandboxes (software platforms and developer tooling) The released environment, scenarios, logs, and analysis pipeline can serve as a reference implementation for testing agents that use production-style tool protocols rather than fixed action spaces. Developers can reproduce the benchmark, modify the narration layer, or create analogous environments for web, desktop, database, or cloud tasks.
Potential workflow: run a fixed scenario, collect the complete MCP transcript, recompute PMR and RAG-like metrics, and compare agent versions or scaffolds. Dependencies: Civilization VI licensing, pinned game versions, FireTunerโs single-connection limitation, and the cost and duration of full runs. The current benchmark is better suited to research and regression testing than high-volume continuous evaluation.
- Teach agent developers to separate local actions from global-state checks (academia, professional training, AI safety engineering)
- mandatory checkpoint routines;
- escalation policies;
- persistent memory;
- action verification;
- end-of-episode or end-of-task audits.
Dependencies: examples should not be generalized directly from game performance to all real-world agents; instructional use should emphasize the benchmarkโs limited sample and protocol-specific nature.
- Use structured narration for tool interfaces (healthcare administration, finance, logistics, robotics)
- patient-care workflow state and pending tasks;
- financial portfolio exposures and risk thresholds;
- warehouse inventory, robot position, and obstacles;
- fleet status, maintenance alerts, and delivery constraints.
The key design principle is to expose actionable context without automatically surfacing every possible fact, allowing researchers to measure retrieval behavior. Dependencies: summaries must be accurate, uncertainty must be represented, and high-stakes deployments should not depend solely on an agentโs decision about what to query.
- Create policy and governance audits for agent reliability (public policy, AI assurance, regulated industries)
- checks specified safety or compliance states at defined intervals;
- records the information used before consequential actions;
- verifies completion of commitments;
- escalates when required state is unavailable or stale.
CivBenchโs PMR and RAG concepts can be adapted into audit criteria, such as โcritical-state query coverageโ and โcommitment verification rate.โ Dependencies: metrics must be validated against real incidents, thresholds should be domain-specific, and audit logs must be tamper-resistant and privacy-preserving.
- Apply lightweight commitment checklists to daily-life assistants (personal productivity and education) A scheduling or study assistant can turn statements such as โrevise chapters 3โ4 tonightโ or โbook the appointment tomorrowโ into explicit, trackable tasks, then ask for confirmation or provide reminders when the task remains incomplete. The same approach can help users distinguish intentions from completed actions.
Dependencies: user consent, notification fatigue, accurate interpretation of natural language, and safeguards against over-automation of sensitive personal decisions.
Long-Term Applications
The longer-term implications require larger studies, domain transfer, improved infrastructure, or evidence that benchmark-measured behavior predicts real-world reliability.
- Develop a general benchmark suite for long-horizon tool-using agents (AI research and evaluation) CivBench could become one environment in a broader suite covering software engineering, web navigation, robotics, healthcare operations, finance, logistics, and household tasks. Each environment would expose partially observable state, require explicit queries, and generate complete tool traces.
A mature suite could evaluate: - proactive monitoring; - plan revision; - commitment execution; - warning-response latency; - recovery from tool failures; - performance under changing objectives.
Dependencies: domain simulators, standardized APIs, large and balanced test sets, scripted and random baselines, inter-rater validation, and protection against benchmark overfitting.
- Build adaptive monitoring policies for autonomous agents (robotics, energy, industrial control, cloud infrastructure) Rather than using a fixed โcheck every 20 turnsโ rule, future agents could learn when and what to monitor based on risk, uncertainty, state volatility, and proximity to irreversible actions. For example, a warehouse robot might monitor battery and obstacle state more frequently near a charging deadline or in a congested area.
Potential product: a risk-aware observation scheduler that allocates tool calls to the most consequential latent states. Dependencies: reliable risk models, formal safety constraints, real-time latency guarantees, and evidence that adaptive monitoring improves outcomes without excessive computation or API cost.
- Create persistent commitment managers with automatic replanning (enterprise agents, robotics, multi-step assistants)
The reflectionโaction gap motivates architectures in which commitments are stored separately from transient context and linked to executable actions, dependencies, evidence, and cancellation conditions. The manager would:
- extract a proposed commitment;
- test whether it is feasible;
- schedule or execute it;
- verify the result;
- revise or escalate when circumstances change.
Dependencies: robust semantic parsing, conflict resolution, authorization controls, temporal planning, and mechanisms preventing an outdated commitment from overriding new safety information.
- Deploy high-stakes agent systems with formal monitoring and execution guarantees (healthcare, finance, aviation, energy, public administration) In regulated settings, CivBench-like metrics could support assurance cases for agents making or coordinating consequential decisions. A healthcare workflow agent, for instance, might be required to verify allergies, recent laboratory results, medication conflicts, and clinician approval before completing an order.
Potential workflow: combine trace logging, mandatory state checks, commitment verification, human approval gates, and post hoc failure analysis. Dependencies: domain validation, legal accountability, safety certification, calibrated uncertainty, human override, and proof that simulator behavior transfers to operational environments.
- Use interactive benchmarks to train better agent architectures (machine learning research)
- perception or retrieval;
- strategic state estimation;
- planning;
- execution;
- verification.
Future experiments could compare advisory prompts, hard monitoring triggers, persistent task queues, and learned observation policies. Dependencies: substantially larger datasets, carefully controlled ablations, protection from training-test contamination, and metrics that distinguish better planning from merely more frequent querying.
- Extend the framework to cooperative and adversarial multi-agent settings (robotics, defense analysis, negotiation, supply chains) CivBench currently evaluates a single agent against built-in opponents and notes limitations for multi-agent setups. A future version could measure whether several agents maintain shared global state, execute delegated commitments, detect deception, and coordinate under communication constraints.
Potential applications: multi-robot coordination, distributed incident response, negotiation agents, and supply-chain planning systems. Dependencies: multi-connection infrastructure, communication protocols, identity and authorization controls, adversarial testing, and metrics for coordination quality rather than individual execution alone.
- Establish predictive links between benchmark metrics and real-world incidents (policy, AI safety, organizational risk) A major research objective is to determine whether low monitoring rates or low commitment-execution scores predict failures outside games. Longitudinal studies could compare benchmark results with production incidents such as missed alerts, incomplete remediation, or unauthorized actions.
Dependencies: access to high-quality operational data, consistent incident taxonomies, privacy-preserving analysis, and sufficiently diverse environments. Until such validation exists, PMR and RAG should be treated as diagnostic indicators, not universal safety scores.
- Develop human-agent interfaces that preserve critical information without overwhelming context (healthcare, education, professional decision support)
- hierarchical summaries;
- uncertainty and freshness indicators;
- event-triggered alerts;
- user-configurable monitoring priorities;
- explicit distinctions between unknown, queried-negative, and stale information.
Dependencies: human-factors research, reliable prioritization, accessibility, and careful evaluation of whether highlighting information improves decisions rather than creating alert fatigue.
- Create policy standards for auditable autonomous workflows (government and industry regulation) Regulators could eventually require standardized trace formats for consequential agents, including records of queried state, tool calls, commitments, overrides, and verification outcomes. CivBenchโs transcript-centered methodology provides a conceptual foundation for such standards.
Dependencies: international agreement, interoperability across vendors, protection of proprietary information, secure retention of logs, and clear assignment of responsibility when an agent fails to monitor or execute a plan.
Glossary
- 4X strategy game: A strategy-game genre centered on eXploration, eXpansion, eXploitation, and eXtermination. โCivilization~VI is a 4X strategy game in which players explore, expand, exploit resources, and compete with rival civilisations.โ
- Ablation: An experiment that removes or changes one component to measure its effect. โFuture work should test this through ablations, including removing the diary, introducing persistent commitment tracking, and enforcing monitoring schedules.โ
- Attention allocation: The distribution of an agentโs computational or interaction resources across competing information or actions. โThis is therefore an attention-allocation problem rather than a tooling gap.โ
- Bootstrap confidence interval: An uncertainty interval estimated by repeatedly resampling observed data. โError bars show bootstrap confidence intervals.โ
- Cohenโs : A statistic measuring agreement between annotators while correcting for agreement expected by chance. โinter-rater agreement with the LLM labels was 92.0\% (Cohen's ).โ
- Confound: A factor that influences an observed result and makes causal interpretation difficult. โThis introduces a measurement confound: the playbook elicits explicit planning, so RAG measures execution of prompted commitments rather than spontaneous plans.โ
- Controlled observability: An interface property in which access to information is deliberately regulated so that researchers can measure what an agent retrieves. โenabling controlled observability.โ
- Contamination: The possibility that evaluation data or relevant knowledge appeared in a modelโs training data. โStrategy knowledge may appear in training data, but each run requires live adaptation under partial observability, shifting the evaluation towards interaction behaviour rather than memorised strategy.โ
- Eureka boost: An in-game reward that accelerates technological research after a specified achievement. โwith eureka boosts rewarding in-game achievements.โ
- FireTuner protocol: A protocol used to communicate with and control Civilization VI through a network connection. โCivBench connects to Civilization~VI through the FireTuner protocol over TCP.โ
- Fisherโs exact test: A statistical test for association between categorical variables, especially useful with small samples. โFisherรขยยs exact test does not support between-model discrimination (p = 0.488; Fig. 5).โ
- Fog of war: The concealment of map information that a player has not explored or cannot currently observe. โfog of war, district adjacency bonuses, and city spacing constraints.โ
- Gymnasium-style API: An interface convention for reinforcement-learning environments that exposes fixed observation and action spaces. โwhere interaction is typically mediated through fixed observation spaces.โ
- ICC (intraclass correlation coefficient): A statistic measuring the consistency or reliability of quantitative measurements within groups. โAn exploratory ICC analysis on Ground Control runs (Tab.~\ref{tab:icc_table}) finds that of 13 candidate metrics, only exploration at T100 shows clear discriminative power (ICC=0.717).โ
- Inter-rater agreement: The degree to which independent evaluators assign the same labels or judgments. โinter-rater agreement with the LLM labels was 92.0\%.โ
- Latent strategic state: Strategically important information that exists in the environment but is not automatically presented to the agent. โPMR, capturing whether agents actively query latent strategic state.โ
- Long-horizon agent: An agent that must maintain goals, plans, and state over many sequential interactions. โan open-source benchmark for evaluating LLM agents in long-horizon, tool-mediated environments.โ
- MCP (Model Context Protocol): A protocol for connecting language-model agents to external tools and structured context. โWe present CivBench, an open-source benchmark that connects LLM agents to Civilization~VI through the Model Context Protocol (MCP).โ
- Narration layer: An interface component that translates complex environmental state into structured, agent-readable text. โWe also provides a narration layer, which converts visual game state into structured text.โ
- Normalised score: A score divided by a reference score to make results comparable across games or agents. โnormalised_score = agent_raw_score / winner_raw_score_at_game_end.โ
- Partial observability: A setting in which an agent cannot directly access the complete state of its environment. โrequiring sustained planning, state monitoring, and execution under partial observability.โ
- Playbook: A prescribed interaction and planning procedure supplied to an agent. โAll models receive the same versioned playbook, which specifies turn structure, checkpoints, and a five-field diary.โ
- PMR (Proactive Monitoring Rate): The proportion of relevant tool calls devoted to actively querying strategic state. โPMR measures how much of the tool budget is allocated to maintaining a global view rather than reacting to local state.โ
- Procedurally generated terrain: Environment layout produced algorithmically rather than manually designed. โA hex grid of approximately 4,000 tiles with procedurally generated terrain.โ
- RAG@K (Reflection--Action Gap): A metric measuring whether commitments stated in reflections are carried out within the next turns. โRAG@K measures the extent to which stated plans are translated into subsequent actions within a short horizon.โ
- Reproducibility: The ability to obtain comparable results by repeating an experiment under specified conditions. โReproducibility also depends on the game version, DLC configuration, scenario files, model configuration, and playbook version.โ
- Situated behaviour: Behaviour produced through interaction with a particular environment and its current state rather than through abstract reasoning alone. โThis makes Civilization~VI useful for evaluating situated, tool-mediated behaviour rather than static game knowledge.โ
- Sensorium effect: The difference between information humans perceive passively and information an agent must explicitly query. โThe clearest pattern in the traces is the sensorium effect: the gap between passive human perception and active agent queries.โ
- Scaffolding: External structures, prompts, tools, or procedures designed to support an agentโs reasoning and task execution. โCivBench provides long-horizon traces for analysing scaffolds, memory mechanisms, reflection protocols, and commitment tracking.โ
- Strategic monitoring: The active retrieval of globally relevant information about threats, rivals, or victory progress. โstrategic monitoring remains consistently low across models.โ
- Suzerainty: A Civilization VI diplomatic status in which a civilization exercises special influence over a city-state. โDiplomatic standing. Relationship modifiers, grievance accumulation, suzerainty count.โ
- Threat response latency: The time between detecting a threat and taking an appropriate response. โMilitary effectiveness. Kill/loss ratio, territory held, threat response latency.โ
- Tool-mediated interaction: Interaction in which an agent affects or observes an environment through explicit tool calls. โBoth PMR and RAG@K are interface-level metrics capturing monitoring and execution behaviour under tool-mediated interaction.โ
- Tool-call trace: A chronological record of the tools an agent invokes and the returned results. โUnlike prior game-agent benchmarks that primarily score task success or final outcomes, CivBench releases full tool-call traces.โ
- Trajectory: A sequential record of states, actions, and observations across an agentโs interaction with an environment. โThis loop---orient, detect, reason, act, reflect---repeats 5--15 times per turn across 300+ turns, producing a structured trajectory of situated, tool-mediated decision-making.โ
- Victory condition: A rule-defined criterion for winning a game. โThe game has six victory conditionsรขยยScience, Culture, Domination, Religion, Diplomacy, and Scoreรขยยso no single objective dominates.โ
- World Congress: A Civilization VI system in which civilizations vote on resolutions that affect the game. โWorld Congress voting, and formal alliances.โ






