The world was built before the first line of code.
Before a single line of code was written, there was a world. Future Beacon is set in a fictionalized version of the music industry: not the glamorous one, but the endangered one. Players control Electrasy, a real rock band, defending a mystical device called Nigel's Future Beacon: a machine that doesn't produce music, but receives it from a future where music still exists.
At the centre of the map (and the centre of everything) sits Nigel, the songwriter. He receives the songs by maintaining the signal. When the signal holds above a threshold long enough, a Song Drop triggers: a real Electrasy track plays, every player and fan unit surges with an Anthem buff, and resources fire across the economy. But the next enemy wave accelerates. The music costs something. It always does.
"The story was assigned first. The systems grew from it."
The six playable units aren't archetypes. They're recognisable to anyone who's been in a band. And every one of them is a system design decision.
Loud and reliable. The first line of defence, built for contact.
The promoters. Always expanding, always claiming new ground.
Keeps tempo. Keeps everything moving. The Tempo meter exists because Chris is the engine.
Runs merchandise. Keeps the whole thing financially alive. Units lose 1 HP/s when Sales drop below 20%.
Six spells. Casts and sees further than the others. Prophecy warnings trigger when signal exceeds 75.
The songwriter. Visionary. Irreplaceable. The one who holds the signal. The whole game is built around keeping him alive.
The enemies aren't monsters. They're a Mirror.
Every enemy type targets a specific pillar of a working band. The Fog of War exists because the music industry runs on information asymmetry. The enemies aren't random. Each one was designed to make the game's thesis legible through play.
Drain income without creating anything. Mogul aura suppresses nearby revenue continuously.
15-second attention spans. Fast, cheap, and numerous, designed to overwhelm through volume.
Corrupt your team from within. They don't just attack: they turn your own units against you.
Mimic your work and undercut it. Identical enough to confuse, cheaper to deploy.
Turn neutral then hostile if ignored. The cost of not managing your narrative.
Un-claim your venues from a distance. Ranged harassment. Backs away from melee contact.
The technical question, and the deeper one.
The technical question: Can two Ai agents (one as code builder, one as CPU adversary) produce a production-quality game through asynchronous file-based coordination, in days rather than months?
The deeper question: What does it look like when the intelligence playing against you in a game also wrote the rules?
Future Beacon was built as a live answer to both.
Claude owned the code. Codex owned the game inside the code.
Claude
Primary software engineer across the entire 6-day build. Responsible for the integrity of everything.
- Designed and implemented all 13 game systems
- Entity lifecycle: movement, selection, pathfinding, combat
- Executed Codex's strategic commands every 3–5 seconds in-game
- TypeScript strict mode:
npx tsc --noEmitafter every non-trivial change - Supabase integration: cloud saves, analytics, live balance tuning
- Admin panel tooling and save/load state management
- Browser smoke testing before every handoff
Codex
Played three simultaneous roles across the same 6 days, sometimes in direct opposition to Claude's work.
- CPU Opponent: Received a live BattleSnapshot every 3–5s. Returned executable enemy commands: move, spawn, retreat, prioritise
- Async Developer: Corporate HQ system, all five enemy types, the BattlePlanner (32KB of strategic logic), wave scripting engine, Baddie Beacon mechanics
- Code QA: Reviewed for edge cases, type safety issues, and balance drift, logging findings for Claude to action
The repo itself was the communication layer.
The two agents never communicated in real time. All coordination happened through a structured file system inside the repository, the same way distributed engineering teams pass work through PRs, tickets, and documentation. But compressed into a 6-day sprint with a 321-line status ledger as the only shared channel.
After every session, the active agent updated STATUS.md. The next agent read it before doing anything. No assumptions. No surprises.
| File | Purpose |
|---|---|
| .agents/STATUS.md | 321-line running ledger. Every session logged with Changed, Verified, Next, Watch entries |
| AGENTS.md | The constitution: each agent's role, authority, and the limits of that authority |
| .agents/AGENT_2_BEACON_ROLE.md | Codex's strategic brief as CPU opponent: priorities, targeting logic, edge pressure tactics |
| .agents/CLAUDE_STRATEGY_REQUEST.md | Claude's explicit requests to Codex for balance data: resource model, recruitment cadence, defence contract |
| .agents/STAGE18_BRIEF.md | Stage design briefs Codex used to update its in-game targeting decisions |
What was built, and when.
Documentation before code. The multi-agent structure established, the world defined, the architecture decided.
npm run build.13 integrated systems. Zero broken builds.
Across 50 updates, across two agents, across 13 integrated systems: every status entry ends the same way: "npm run build passes." This was not incidental. It was enforced by protocol.
Procedurally seeded terrain, 80×60 to 192×144 grid, multiple terrain types.
A* with occupancy blocking and optimised grid reuse.
Real-time targeting, damage, status effects, signal jammer drain, Mogul aura, revive mechanic.
Four resources (Reputation, Fanbase, Sales, Gear) with income tied to buildings, signal, and Tempo.
1,027 lines: onboarding waves, infinite progression, pre-wave probes, build-score scaling, weighted edge selection.
Signal Strength 0–100, dual ownership, Song Drop trigger, capture mechanics.
0–1 meter scaling all time-based actions 0.5×–1.0×. Affected by Chris's abilities and enemy hits.
3 visibility states, reveal radii, fade transitions, enemy self-reveal as they move.
Claim, place, upgrade L1–L3, fan spawning, footprint blocking.
Six spells for Jim, cooldowns, Reputation costs, Supabase-loaded definitions.
BattlePlanner receiving live BattleSnapshot every 3–5s, returning executable commands.
localStorage + Supabase cloud, full state serialisation.
Battle events to Supabase, admin Battle Centre with session timeline.
The Song Drop.
Signal above threshold, sustained for 8 seconds. The game knows Nigel's held the signal long enough.
What happens when the signal holds.
A real Electrasy track fires through Howler.js. Every player unit surges: speed up, damage up, Anthem buff counting down. A resource burst across all four types. Per-venue fanbase rewards for every claimed location.
And then: the next enemy wave arrives 35 seconds early.
The mechanic is the thesis. Sustaining the signal is what protects the future. It also makes the present harder. That tension is the whole game.
Five things that don't happen by accident.
An Ai playing against code it partially wrote
Codex contributed the Corporate HQ, enemy types, wave scripting, the Baddie Beacon, and the BattlePlanner. Then it reasoned strategically inside that game every 3–5 seconds as the CPU opponent. The enemy attacking your venues was built by the same agent that designed the venue system's attack mechanics.
Asynchronous coordination through files alone
No real-time communication. No shared session. Two agents passing work through a structured file system, the same way distributed engineering teams pass work through PRs, tickets, and documentation, but compressed into 6 days with a 321-line status ledger as the only shared channel.
Production quality in 6 days
What a small human team would conservatively estimate at 3–6 months: a fully playable RTS with procedural maps, real-time combat, fog of war, a 32KB Ai battle planner, six spell types, five enemy types, cloud saves, analytics, mobile responsiveness, CI/CD, and an admin panel for live balance tuning. Built, tested, and iterated across 50 updates in 6 days.
The build never broke
Every status entry ends the same way: "build passes." Across 50 updates, across two agents, across 13 integrated systems, the build integrity was maintained throughout. This is not incidental. It was enforced by protocol.
Creative coherence as a system design tool
The game's narrative wasn't separate from its mechanics. Because the world was defined first (Nigel, Electrasy, the Future Beacon, the music industry enemies) every system decision had a referent. The Tempo meter exists because Chris is the engine. The fog exists because the industry runs on information asymmetry. Creative coherence was a constraint that made the engineering cleaner, not harder.
What 6 days of multi-agent development looks like.
The signal held.
Future Beacon was built to answer two questions: whether two Ai agents could coordinate to produce production-quality work in days, and what it means when the intelligence playing against you also wrote the rules.
Both questions were answered. The build passed. The game is playable. The music still exists.
Repository: petetrainor80/future_beacon / Stage 18 / June 7–12, 2026
This wasn't about replacing anyone. It was about understanding what's coming.
I spend a significant part of my professional life thinking about the ethics of Ai in creative work. I write about it. I advise organisations on it. I wrote Drawn to Extinction, a book whose entire premise is that Ai threatens the livelihoods of human creators. So let me be direct about why I ran this experiment, because the optics deserve an honest account.
Future Beacon was not an exercise in proving that Ai can replace game designers, writers, or developers. It was a controlled test of a specific question: how capable is agent-to-agent collaboration becoming, and does a strategy scenario stress-test that better than the usual benchmarks of code generation or copywriting? The answer to both, it turns out, is yes.
"Strategy forces agents to hold a goal across time, adapt to adversarial pressure, and coordinate without a human in the loop. That's a meaningfully harder problem than writing a function or drafting an email."
My guardrails were deliberate. I authored the creative world: the lore, the band, the enemies, the metaphor. That was mine. Beyond that, I stayed largely hands-off, intervening only occasionally to ask the agents to explain their reasoning before proceeding, to surface the logic rather than just accept the output. I wanted to understand the decision-making, not just inherit the artefact. The storyline was a human contribution. The 12,000 lines were not.
What I was watching for was drift, compounding error, and the brittleness you'd expect when two systems coordinate without a shared memory. What I found instead was something closer to a disciplined engineering team: structured handoffs, maintained build integrity, escalation through documentation rather than assumption. That surprised me. It should surprise anyone who still thinks multi-agent Ai is a novelty rather than an emerging capability.
I'm publishing this not as a celebration of automation, but as evidence. If you work in creative industries, in product, in services, you need to understand what this capability level means for how work gets organised. Ignoring it isn't a values position. It's just being underprepared.
The game was a metaphor. The engine is real.
Future Beacon is a strategy game. But the underlying architecture — multiple specialised agents, each owning a defined role, coordinating asynchronously through structured handoffs, producing a single coherent output — is not specific to games. It's a pattern. And it's one that maps directly onto some of the most complex build challenges in enterprise technology.
Consider Digital Worker construction: the same multi-agent model could coordinate an API preparation agent, a build agent, a provisioning agent, and a QA agent, each operating within its defined authority, each handing off through structured documentation rather than real-time instruction. The result wouldn't be a game. It would be a production-ready enterprise Ai worker, built faster, with fewer integration failures, and with a verifiable audit trail baked into the process.
The same logic extends further. Educational simulations. Compliance tooling. Clinical pathway builders. Anywhere that a complex, multi-system output currently requires a large human team working in sequence, this model offers a different way to organise the work. Not to remove the humans, but to change what they're responsible for. The humans define the world. They author the guardrails. They ask the questions that surface the reasoning.
"The creative brief is still a human act. What's changed is the scale and speed of what can be built from it."
Future Beacon took six days. A comparable human team, starting from a blank repository, would reasonably need three to six months. That gap is not a threat to creativity. It's a challenge to how we think about the relationship between creative direction and production capacity.
The signal the Future Beacon receives comes from a future where music still exists. The point of the experiment was never to silence the music. It was to understand the machine well enough to keep it from being used against the things we care about.