JX Ops Agent

An AI agent that operates a real legacy MMORPG server fleet — reading live logs, diagnosing incidents, writing fix specs, and validating fixes on headless clones.

Comment

Inspiration

I run seven private servers for an MMORPG that's about as old as YouTube. Just me, nobody else. The core is ancient C++ and Lua 4.0, and honestly nobody fully understands it anymore, including me some days. When something broke, my evening disappeared into game-engine logs, an MSSQL database, a MySQL database, and the occasional crash dump.

Over the years I taught an AI agent to help me run this thing. Every server folder carries its own little _AGENT context (rules, memory, runbook), the agent reads logs and writes root-cause specs, and no fix touches production before a headless clone proves it works. The setup is genuinely good. It's also completely unshareable: hardcoded paths, credentials, proprietary game assets everywhere.

So that was my Build Week idea. Take the operating pattern I actually use, and rebuild it as a clean tool anyone can run. These servers have been my personal passion project for years. This week is the first time any of it exists outside my own machine.

What it does

jx-ops-agent is a small Python CLI called jxops. It walks through the whole AI-operator loop on a simulated game world, so you don't need a game server (or the game) to try it:

  • jxops routes --demo builds a map with trap tiles and validates routes across it. You see the bad route cross three traps and get rejected, and the clean detour pass. This is a real bug from my fleet: bots kept "teleporting" because their route clipped trap tiles.
  • jxops incident --analyze reads a server log, finds warp loops and region churn, and writes a Markdown root-cause report. Same format my production agent uses.
  • jxops bots --sim runs a swarm of bots as little state machines (idle, route, engage, regroup) on the validated route, animated right in the terminal, logging AOI enter/leave events as they move.
  • jxops boot --mock plays back the headless boot sequence I use to validate fixes: config, database check, world spawn, ready.

How we built it

All of it was written this week by Codex with GPT-5.6, from scratch, in one session. My job was the domain knowledge and the spec. I've hit these bugs in production (the trap-warp one, and an AOI flicker caused by blanket NPC removal on region change), so I described the problems and the boundaries, then reviewed what came back. Codex wrote the code.

The part that actually surprised me: before writing anything, Codex declared which folders it was allowed to touch, ran git init before the first file existed, and wrote tests before each commit. I never asked for any of that. At the end it installed everything into a fresh venv and saved the smoke-test output as evidence, which made my review job embarrassingly easy.

Prior work vs. this week: my server fleet and its internal manager existed long before Build Week. They are not part of this submission, they just provided the war stories. Everything in the repo (four commands, map/route engine, bot simulator, incident analyzer, docs) is new code from the Submission Period. The dated commit history and the Codex session ID back this up.

Challenges we ran into

  • My real tooling is full of credentials and private paths, so the rule was strict: not one line copied. Codex rebuilt every concept from a written spec instead. Slower to start, much cleaner result.
  • The game itself is copyrighted, so it can't appear anywhere. The whole demo had to work through terminal output, logs, and SVGs we render ourselves.
  • Judges should see exactly what the video shows, so everything runs deterministic: fixed seed for the bot swarm, a crafted log fixture for the incident demo. Making it deterministic without making it look dead took a few iterations.

Accomplishments that we're proud of

  • Four working commands built from scratch in a single Codex session, tests included.
  • Zero lines reused from my private tooling, and it still reproduces my actual production failures faithfully.
  • The bot simulator: a real production architecture (state-machine bots on validated routes, AOI tracking) shrunk down to something that runs on plain Python anywhere.

What we learned

A 20-year-old system is not too old for an AI operator. The trick is making the infrastructure describe itself, so the agent can find its own way around. Also, the split I use at home (I write bounded specs, the coding agent implements) is the fastest I have ever shipped anything.

What's next for JX Ops Agent

Hook jxops incident up to live log streams, grow the bot simulator toward the full production behavior (duel, party, trade), and turn the _AGENT self-describing-server convention into something any legacy fleet can drop in.

Built With

Share this project:

Updates