Server-Authoritative AI Agents in MMORPGs

Why ordinary tool calling is not enough

Tool calling gives a model a structured way to request an operation. It does not automatically make that operation safe for a live game. A tool schema may still expose excessive authority, accept invented identifiers, reuse stale context or apply the same mutation twice after a retry.

Security guidance on prompt injection makes the broader point that model behavior can be influenced by untrusted content and that restrictions must exist outside the model. In a game, untrusted content includes player speech, chat, item names, NPC dialogue, memories, retrieved knowledge and even model-generated observations. None of those strings should be able to expand permissions.

A server-authoritative architecture therefore treats every model response as data. Strict parsing is necessary, but the decisive question is not “does this JSON match the schema?” It is “is this exact action legal for this exact actor in the current authoritative state?”

The planner–binder–executor pattern

The architecture becomes easier to reason about when responsibility is split into three named layers.

Planner

The planner receives bounded context and a current capability slice. It may interpret “keep me alive while we cross the bridge” as a support goal, select a semantic healing or defensive capability, choose an opaque candidate and produce short companion speech.

The planner should not author a raw skill ID, database key, arbitrary Java method, shell command or unrestricted world coordinate. It chooses among meanings and candidates that the server exposed for this turn.

Binder

The binder is deterministic code. It resolves opaque candidate handles to internal identifiers and checks that the candidate still belongs to the current actor, catalog version, target and revision. A model cannot turn an invented string into an executable capability.

This layer is essential because a valid plan can become stale. The target may move, a cooldown may begin, an item may leave inventory or a newer player command may supersede the turn. The binder converts semantic intent into a current, inspectable execution request—or rejects it.

Executor

The executor is the existing authoritative game logic. It rechecks ownership, actor state, target legality, distance, resources, cooldown, inventory, concurrency and policy. Only this layer may change the shared world. Its result becomes the source of truth for delivery, memory and the next observation.

This is a practical extension of the agentic NPC loop: reasoning and acting are connected, but action is mediated by the system that already owns game rules.

A complete turn

One safe turn can be traced end to end:

1. The player sends text or completes a push-to-talk utterance.
2. Java assigns owner, session, turn, deadline, command epoch and the relevant state revisions.
3. The server exposes bounded state, opaque candidates and only the capabilities legal for this turn.
4. One party-level planner returns a strict decision with zero or more ordered semantic action proposals.
5. The binder resolves those proposals against the original envelope and the newest relevant state.
6. The executor applies only proposals that still satisfy game rules.
7. Java publishes a typed authoritative result for every proposal.
8. Companion speech, memory and optional TTS finalize from accepted results.
9. Late output for a cancelled or superseded turn is discarded.

The language model never becomes a shadow GameServer. It does not maintain an independent canonical copy of the world and it cannot talk a failed action into success.

State drift and stale actions

MMORPG state changes while a model is thinking. A single global version number is often too coarse because unrelated activity would invalidate everything. A practical envelope can carry scoped revisions: owner command epoch, actor state revision, target revision, inventory revision, party revision and capability-catalog digest.

The exact fields differ by game, but the rule is stable. The proposal must be bound to the state assumptions under which it was made, and the executor must check the assumptions that matter to the side effect. If the target revision changed, reject or replan. Do not silently apply an old decision to a new world.

Retries without duplicate side effects

Networks retry. Providers time out. A gateway may deliver the same body twice. Without idempotency, “use this item” or “transfer this object” can become two mutations.

A robust turn uses a stable request or action key and records the terminal outcome. An exact replay returns the existing result rather than executing again. A request that reuses an identifier with changed content is rejected. Deadlines and tombstones prevent a late provider response from reviving a cancelled action.

This property must be tested with side-effect counts, not inferred from logs that merely look similar. Zero duplicate side effects is a hard invariant.

Speak after the result

Generated speech is part of the trust boundary. If a companion says “I healed you” before execution, a cooldown or state change can make the sentence false. The safer sequence is proposal, execution result, then terminal delivery.

The result may support different outcomes: success confirmation, a concise reason for legal failure, a clarification request or intentional silence. A late result should not speak into a newer session. Authoritative-result speech is therefore an architectural control, not only a dialogue style preference.

The Lineage2AI boundary

Lineage2AI’s public server-authoritative AI overview uses this division between language intelligence and game authority. The clean-slate Agentic Engine V1 documents a strict structured decision, opaque candidates, deterministic Java binding, revision checks, idempotency and terminal delivery policy. The model can help a companion understand and express intent; Java remains the only authority that can make gameplay happen.

Repository tests and offline harness results support specific contract-level claims. They do not prove every planned capability in live gameplay. The project keeps SOURCE, OFFLINE, BOOT, IN_GAME and SOAK evidence distinct so an architecture document cannot be mistaken for production acceptance.

Design checklist

Before connecting an LLM agent to a shared world, verify:

• Does the model receive only a current, bounded capability set?
• Are world objects represented by opaque server-issued candidates?
• Can any free-form string become a method name, query or internal ID?
• Which revisions bind the plan to current state?
• Which checks are repeated at execution time?
• What idempotency key protects each mutation?
• What happens to late, duplicated and superseded turns?
• Does speech wait for authoritative results?
• Can memory writes occur only after a permitted final outcome?
• Can the runtime boot only a reviewed, immutable policy release?
• Are authority, cross-player isolation and duplicates hard evaluation gates?

If the model is removed or behaves adversarially, the server should still protect game truth. That is the defining property of server-authoritative AI: model intelligence can improve the experience, but model correctness is never the final security boundary.