Autonomous Multi-Agent Roblox Game Studio

Most of the Luau in these two games was written by AI agents, not by me. That is the point, not a footnote. My job was everything the agents could not do for themselves: the specs of record, the frozen contracts between agents, and the verification gates that let a fleet of coding agents check their own work before any of it was accepted. The games are the proof that the method holds up on something real, a two-game portfolio topped by a flagship of about 57,000 lines of Luau across 109 modules, built and tested end to end.

Both games are built-and-tested MVP builds rather than launched live products, and I say so wherever it matters below. What I am claiming is narrower and, I think, more interesting: that a single engineer can specify, orchestrate, and verify game systems at this scale by treating agents as the workforce and treating contracts and gates as the actual engineering.

Why the orchestration is the hard part

A single agent writing a single module is easy now. The failure mode shows up at the seams. Two agents building against the same remote event will silently disagree about its payload. A client controller will invent a field the server never sends. Module 80 will quietly redefine a constant that module 12 already owns. None of these are hard bugs individually, but at 109 modules they compound into a codebase that cannot run.

The fix was to make the seams non-negotiable before any building started. Three mechanisms did most of the work:

Specs of record. Every build round started from a written spec that named the systems, their owners, and their acceptance criteria. Agents built to the spec, not to their own interpretation of a prompt. The flagship went through nine of these spec-driven revision rounds across 45 commits, each round a plan document plus a standard operating procedure the agents had to follow.

Frozen contracts. The interfaces between agents were written first and then locked: shared modules as single sources of truth for economy constants and types, remote event schemas that both server and client agents coded against, and map contracts that told the geometry builders exactly what the gameplay code expected to find. In the flagship, 22 shared modules (the src/shared/Economy tree among them) exist specifically so that no number, no rarity table, and no price appears in two places.

Verification gates. An agent’s work was not accepted because it claimed to be done. It was accepted because a headless test gate said so, and the agent could run that gate itself, locally, without opening Roblox at all. More on this below, because it is the piece I care about most.

Everything ran over a real toolchain, not a toy one: Rojo syncing the filesystem into Roblox Studio, Wally for packages, Selene and StyLua enforcing lint and format, Rokit pinning tool versions, TestEZ and Lune for tests, and a Roblox Studio MCP bridge that let agents drive Studio directly for geometry and in-engine checks. Orchestration itself was Claude Code workflows: sequenced agent teams with defined roles, handoffs, and gates between stages.

Cryptlings, the flagship

Cryptlings is a co-op extraction-horror game crossed with a blind-box trading game. Players descend procedurally generated floors while a monster hunts them by sound, extract loot, unbox it gacha-style, and trade with each other through a server-authoritative economy. It is the larger and more complete of the two builds: roughly 57,000 lines of Luau in 109 modules, split into 54 server services, 33 client controllers, and 22 shared single-sources-of-truth.

The 109 modules by trust zone. Server services own all state that matters, clients only render and request, and the shared layer is the frozen contract both sides code against.

The systems are the ones a live game of this genre actually needs: procedural floor generation, a monster with a hearing-and-search state machine (it investigates noise, escalates to a search pattern, and gives up realistically), server-authoritative trading, a locker economy with daily caps, gacha unboxing, and monetization wired to compliance checks that run at boot. The src/server/Services tree holds the 54 services; the README maps the whole layout.

The gate: agents that verify their own work

The centerpiece is a headless test gate built on Lune that runs the game’s pure logic with no Roblox process anywhere. tests/run.luau executes 35 suites, and because it needs nothing but a terminal, the agent that wrote a system could run the gate against its own output and iterate until it passed. Acceptance stopped being a judgment call and became a command.

The suites are not smoke tests. The gacha odds are checked against a 200,000-roll Monte Carlo simulation (tests/rarity-sim.luau) so the published rarity table and the actual roll behavior cannot drift apart. The 18-item price ladder is verified end to end. The confirm-twice trade state machine is walked through its legal and illegal transitions, including the atomic no-dupe swap at the end. Daily-reset locker math and rotation math each get their own suite.

Published gacha odds versus observed frequencies over 200,000 simulated rolls. The gate fails if the two disagree beyond tolerance, so an agent cannot ship a rarity table that lies.

One honest caveat belongs right here: the 35-passing-suites figure comes from the agents’ own headless runs of this gate, not from an independent CI service. The gate is in the repo and anyone can rerun it, but the numbers on this page are the numbers the pipeline produced about itself.

Built against dupes, not just bugs

Trading games die by duplication exploits, so the specs treated exploit resistance as a first-class requirement and the gates enforce it. Purchase receipts are idempotent with a single owner, so a replayed receipt cannot grant twice. Trades validate everything on both sides before mutating anything, then swap atomically with a conservation check that the total item count across both players is unchanged. Unboxing rolls before it mutates, and refunds cleanly if a race is detected mid-roll. And because gacha is paid-random content, the monetization layer queries Roblox PolicyService at boot and fails closed: if the policy check cannot confirm a player is eligible, paid-random purchases are simply off for that player.

The second game: five workflows and an eight-agent audit

The second build is a slingshot physics-destruction game, and it exists mostly to prove the pipeline generalizes. Where Cryptlings evolved through nine revision rounds, this one was built as five sequential agent workflows run start to finish: a research pass, an architecture pass that froze the contracts, a team of specialist builder agents, a smoke-test harness, and finally an audit by eight QA agents working in parallel.

The five workflow stages. Each stage’s output is the next stage’s frozen input, so a builder agent cannot renegotiate what the architecture stage decided.

The audit stage is the part worth studying. Eight QA agents read the codebase adversarially and surfaced 40 candidate findings. Triage confirmed 26 as real defects and rejected 14 as false positives, which is itself a useful number: agents reviewing agent code over-report by roughly a third, and the triage step is what keeps that from turning into churn. All 26 confirmed defects were fixed before the build was called done.

The QA funnel: 40 raised, 14 rejected as false positives, 26 confirmed, 26 fixed.

The game itself: 10 destructible maps, a 10-ability roster, a server-authoritative slingshot (the client aims, the server owns the launch), destructible materials with per-tier HP, and headroom designed for 40-player servers. Like the flagship, it is a built-and-tested MVP, not a live release.

What I actually did, and what the agents did

The honest division of labor is the strongest part of the story, so here it is plainly. The agents wrote most of the Luau. I wrote the specs the Luau had to satisfy, the contracts that kept dozens of parallel writers coherent, and the gates that decided what got accepted. When a gate failed, the agent that owned the module fixed it; when a spec was wrong, I revised the spec and re-ran the round. The nine revision rounds on Cryptlings were exactly this loop at increasing fidelity.

That division scales in a way solo coding does not. The bottleneck stopped being how fast I could write game code and became how precisely I could specify behavior and how well I could make correctness checkable by a machine. Those are the skills this project was really built to exercise, and the two games are the receipts.