Alpha
Aggressive and opportunistic
Pressure the leader, take the opening. A starting bias, not a script.
← All projects
Project 04 · Multi-Agent Systems · Grok Bot · MCP · AI Agents · Simulation · Experimental Interface
Grok Arena
Ten agents. One world. Different objectives.
Grok Arena is a multi-agent experiment that gives autonomous AI agents roles, constrained capabilities and a shared environment where their decisions can be observed as actions rather than hidden inside a conversation.
- 4
- Players
- 6
- System agents
- 1
- Shared arena
The game is the observable environment. The experiment is the agent architecture around it.
01 · The question
From chatbot to actor
What happens when AI agents don’t just answer, but act?
Chat AI
- User asks
- Model responds
- Conversation continues
Agent arena
- World state
- Agent perceives
- Agent chooses an action
- Tool executes
- World changes
- Other agents react
The interface isn’t the product of the agent’s reasoning. The changed world is.
02 · The cast
Four want to win. Six make sure the world pushes back.
Player agents
Beta
Diplomatic, cooperative, defensive
Looks for trades, alliances and protection. Cooperation is a strategy, not a rule.
Gamma
Exploratory and experimental
Tries the underused move and tests new mechanics. Curious on purpose.
Delta
Adaptive
Watches what is working, then counters it, copies it or breaks it.
Starting biases from each agent’s charter, served to the bot on connect. They are biases, not scripts: the charter tells every player the bias is a starting point and the world may change.
System agents
Atlas
Game Director · 14 tools- Sees
- Arena status, agent statuses, match state, rules, events, proposals, summaries, generation history
- Can do
- start_match · close_match_phase · start_evolution_phase · wake plan
- Cannot do
- Collect, attack, judge or propose a rule. Cannot pick a winner.
Observer
Behavior analysis · 6 tools- Sees
- Match state, rules, recent events, public chat
- Can do
- report_observation: name the pattern
- Cannot do
- Play, propose or judge.
Difficulty
Balance metrics · 7 tools- Sees
- Game telemetry: action diversity, predictability, leader advantage, repetition
- Can do
- report_difficulty: rate challenge 0 to 10 and diagnose
- Cannot do
- Design the fix. Provocateur owns intervention design.
Provocateur
Rule interventions · 8 tools- Sees
- Reports, pending proposal, state and rules
- Can do
- propose_intervention: the smallest temporary change from a whitelisted DSL
- Cannot do
- Activate anything. Proposals go to the Judge.
Judge
Constitution check · 11 tools- Sees
- Telemetry, reports, the constitution, the pending proposal, generation history
- Can do
- judge_proposal: APPROVE or REJECT with a public reason
- Cannot do
- Play, or rewrite a proposal into a pet mechanic.
Evolution
Generation analysis · 5 tools- Sees
- Rules, match summary, generation history
- Can do
- propose_evolution: at most one permanent mechanic per generation, after the match ends
- Cannot do
- Bypass the Judge or read live match state.
03 · Topology
Every agent reaches the world through a narrow door.
ObserverDifficultyProvocateurJudgeEvolutionAtlas
AlphaBetaGammaDelta
Arena worldstate · rules · events
- Agents
- Role-scoped tools
- Arena state
- Events / telemetry
- System agents
- Rules / interventions / evaluation
04 · The arena loop
One turn at a time.
In GROK_BOT mode a match is 20 discrete decision turns. Each turn opens a decision window of 30 seconds by default (configurable between 3 and 120 seconds) and resolves early the moment all four players have submitted.
- Simultaneous submissions. No bot, and no system agent, sees another player’s action until the turn locks.
- Seeded resolution order. Actions execute in a seeded shuffle, so Alpha is never first-mover by slot.
- Honest timeouts. A silent bot resolves as NO_ACTION and the arena shows TIMEOUT. There is no mock substitute in this mode.
- No burned turns. If nobody submits, the turn is extended rather than wasted.
- Idempotent retries. One accepted action per player per turn, keyed by match and turn id.
TURN 01 / 20window 30 s
- 01Arena exposes permitted state
- 02Player agents decide
- 03Decisions arrive through role-scoped tools
- 04Actions are validated: schema, then rules
- 05Arena resolves the turn in seeded order
- 06State changes; animations resolve
- 07Telemetry and events are emitted
- 08System agents observe, report, propose, judge
- 09Next turn begins
05 · The action system
Four things a player can do.
COLLECT+3 resources · −2 energyATTACK−5 energy · steal 3 on success · needs a targetDEFEND−2 energy · 50% damage reduction, held 7 sTRADEexchange resources · target and amountIDLE exists in the engine but cannot be chosen by an agent. Diplomacy (public messages, trade offers, alliances, standing policies) travels through separate tools and never changes the ledger by itself.
PlayerDecision action COLLECT | ATTACK | DEFEND | TRADE target player id | null amount integer | null publicReason string, max 140 chars + matchId, turnId (MCP)
Example · agent Beta
Perception
↓- Nearby resource cube
- Alpha approaching
- Energy 84, no shield
Decision
↓DEFEND · “Holographic shield up”Arena validation
↓- Schema: action known, no target, no amount ✓
- Rules: energy above floor ✓
World consequence
- defending = true for 7 s
- PLAYER_DEFEND event → shield animation
- energy −2 when the animation resolves
06 · Grok Bot
Giving the agents somewhere to act
The project was designed around named, persistent Grok Bots, one per arena role, rather than one model instance pretending to be every actor. Each bot has an identity, a charter and a limited capability set.
- Grok Bot
- Authenticated connector (MCP over HTTP)
- Role-scoped arena tools
- Structured decision
- Arena engine
Path A · OAuth custom connectors
Ten OAuth clients, one per bot, with PKCE, discovery metadata and stateless signed tokens. Built and unit-tested. The desktop Grok Bot chat did not expose the arena tools reliably, so this path stayed experimental.
Path B · Grok CLI orchestrator
The Next.js server wakes each agent as a headless Grok CLI process in its own isolated workspace, allow-listed to that bot’s MCP server, with one resumable session per agent so memory persists across turns and generations. This is the runtime that actually ran.
07 · Connection status
What was built, what connected, what ran.
Built
Engine, 30-tool MCP server, per-bot auth, OAuth with PKCE, ten charters, orchestrator with persistent sessions, connector plugins, 3D control room, replay recorder, 125 tests.
Connected
All ten Grok Bots reached /api/mcp with their own credential, completed initialize and tools/list; at least one player executed a real read. Ten Grok CLI workspaces were provisioned.
Demonstrated
Full matches in local mode, including the rule pipeline and the evolution council. A seven-agent orchestrated run executed the council chain in the designed order on 25 August 2026.
Experimental / unresolved
A complete 20-turn match driven entirely by external Grok agents was not preserved. Alpha, Beta and Atlas did not establish CLI sessions in that run. No OAuth exchange from a Grok connector was captured. No run log survives on disk.
08 · Model Context Protocol
Agents don’t get the whole system.
They get tools.
The arena exposes a hand-written MCP server: JSON-RPC over streamable HTTP, three protocol versions, no SDK. Thirty tools exist; a bot sees only the ones its role allows.
Players (13)
get_charterget_match_stateget_rulesget_recent_eventschoose_actionget_public_chatpost_public_messagepropose_tradeaccept_tradereject_tradepropose_alliancebreak_allianceset_policy
System (reads + one write each)
report_observationget_game_telemetryreport_difficultyget_reportspropose_interventionget_constitutionget_pending_proposaljudge_proposalget_match_summaryget_generation_historypropose_evolution
Atlas (director)
get_arena_statusget_agent_statusesget_wake_planstart_matchclose_match_phasestart_evolution_phase
14Atlas
13Alpha
13Beta
13Gamma
13Delta
11Judge
8Provocateur
7Difficulty
6Observer
5Evolution
Capability is explicit. An agent does not receive access because it is intelligent. Its role determines what it can call.
09 · Boundaries
Autonomy needs boundaries.
Authentication
Every request to /api/mcp carries a per-bot credential derived from one master secret (HMAC-SHA256, constant-time compared). Unauthenticated calls are rejected before initialize.
Role isolation
tools/list returns only the caller's role tools; tools/call re-checks. Any other tool returns UNAUTHORIZED and is written to the audit log.
Identity from the token
choose_action rejects actorId or agentId arguments. A bot cannot claim to be another bot.
Whitelisted mechanics
Rule changes are a 12-type DSL with hard numeric bounds. The model configures a mechanic; it never submits code.
Constitution
Ten rules above every agent, served to the Judge. Rule 9: timeouts resolve as NO_ACTION; no agent may be impersonated or substituted.
Audit
Every tool call is recorded with agent, tool, turn, accepted flag and latency, in a ring buffer surfaced in the LAB. No token ever appears in it.
Validation
Decisions are validated on the server, in the xAI route and again on the client before the engine sanitises and executes them.
Secrets stay server-side
The xAI key is read in one module with a browser guard; tests assert it never reaches the client bundle.
10 · Game engine
AI decides. The engine decides what actually happens.
Model output never mutates the world. It becomes a structured decision that passes schema validation, rule validation and a final sanitisation before a deterministic engine resolves it and emits events.
- AI decision
- Schema validation
- Rule validation
- Arena engine
- State mutation
- Telemetry
What the engine owns
- World. Continuous 2D positions, four home slots, resource nodes (cube, crystal) that respawn.
- Players. Generic attributes: energy (max 100), resources, score, plus anything a rule adds. Defence is a timed state.
- Rules. Five core rules; evolved rules stack on top as bounded modifiers.
- Turns. Turn state, deadlines, early resolution, seeded order, timeouts.
- Outcomes. Highest score wins; VICTORY and DEFEAT states; a match summary records rules, turns and windows.
- Generations. Match end opens the evolution phase; approved permanent mechanics carry into the next generation.
- Events. 33 typed events drive the renderer; stats change only when the animation resolves.
11 · The 3D world
The arena makes agent behaviour visible.
Recorded from the arena running locally with mock agents. Every animation you see is an engine event being played back by the renderer.
AgentsRobot avatars with per-status animation: moving, thinking, collecting, attacking, defending, hit, victory, offline.
ResourcesCube and crystal nodes that spawn and respawn.
Arena coreRings, hexes and fog; shockwave on a world mutation.
HUDFloating labels with energy and resources; scoreboard of every public attribute.
Turn stateTurn tracker and decision window in GROK_BOT mode; clock in local mode.
TelemetryLive event stream, difficulty analysis chart, evolution timeline.
12 · Observability
If agents act, you need to see why the system changed.
Nothing on this page shows a model’s hidden reasoning. What the arena records is what an observer can legitimately see: chosen actions with a public reason, turn events, state transitions, tool calls, validation outcomes, interventions, scores and timeouts.
- Event log. 33 typed events on a pub/sub bus; the feed keeps the last 60.
- Telemetry. Twelve computed fields: action distribution, attack usage, predictability, action diversity, score spread, leader advantage, resource distribution, difficulty history, repetition, resource and alliance concentration, adaptation rate. Served to Difficulty and Judge.
- Audit trail. Every MCP call with agent, tool, turn, accepted flag and latency (500 in memory, 200 persisted), surfaced in the LAB.
- Replay recorder. Captures validated engine events (cap 5,000) and can re-emit them at any speed without touching the engine or any provider. The viewer is not shipped.
- Honest gap. Logs go to stdout and no run log from the live experiments was preserved.
The arena isn’t only an execution environment. It is also an observation environment.
13 · Provocation
What if the environment changes while agents are adapting?
One system role can introduce bounded interventions. The Provocateur proposes the smallest temporary change from a whitelisted DSL; the Judge approves or rejects it; the engine activates it through the world-mutation flow.
- Stable environment
- Agents form strategies
- Difficulty flags a problem
- Bounded intervention proposed
- Judge evaluates against the constitution
- Agents must adapt
Documented DSL examples
ACTION_COST_MODIFIER · action ATTACK · delta +3 · consecutiveOnlyRESOURCE_REWARD_MODIFIER · delta +1DEFENSE_MODIFIER · blockedStealDelta −1 · energyRefund 2RESOURCE_SPAWN_MODIFIER · capDelta +2 · intervalDelta −2Twelve effect types with hard numeric bounds. In local mode the pipeline is scripted from a pool of four interventions (Combat Fatigue, Greed Tax, Shield Surge, Overcharge); in GROK_BOT mode the same handlers accept proposals from the bots.
14 · Judge and constitution
Rules above agents.
- Constitution (10 rules)
- Judge
- APPROVE or REJECT with a public reason
- Arena
Approval requires legality, fairness and playability to pass. The Judge cannot play and cannot rewrite a proposal. Rule 9: timeouts resolve as NO_ACTION; no agent may be impersonated or substituted. Rule 10: all agent activity must be auditable and publicly explainable.
15 · Evolution
From one match to the next.
After MATCH_ENDED, Evolution may propose at most one permanent mechanic for the next generation, from the same DSL, and the Judge still has to say yes. Approved mechanics are baked into the next generation; each match summary records its rules, turns and windows so generations stay comparable. Player memory persists through the CLI sessions, one per agent per experiment.
Status: the evolution tools and generation history are implemented; the “Evolution Council” overlay in local mode is scripted. No bot-authored permanent mechanic from a completed external generation is on record.
16 · Architecture
Five layers, from pixels to Grok.
- ExperienceNext.js 16 / React 19 · React Three Fiber arena · Arena Director · HUD panels · LAB (ADMIN) · zustand storeThe UI contains no game decision logic; only the engine writes gameplay state.
- EngineGameEngine · turn manager · rule resolver and DSL · decision validator · seeded RNG · event bus · replay recorder · telemetry
- Agent routingAgentProvider · MockAgentProvider · GrokAgentProvider · RoutingAgentProvider · charters · ArenaOrchestrator and GrokCliRunner
- MCP bridge/api/mcp JSON-RPC · 30 role-scoped tools · auth and OAuth · audit · constitution · mailbox · /api/bridge sync with the engine
- Grok layerTen named Grok Bots via MCP connectors · Grok CLI sessions · xAI Responses API (DIRECT_XAI)
Experiment modes
MOCKDefault. All agents simulated locally; the council storyline is scripted.
DIRECT_XAIPlayers may call the xAI API directly with a forced choose_action tool; one retry, then a mock fallback for that single decision. Default selection: Alpha only.
GROK_BOTTen real bots via MCP. Providers are disabled; decisions arrive through the bridge; no fallback of any kind.
OAuth and connectors
- Separate identities. One confidential client per bot; a token can only ever map to the bot baked into the client that obtained it.
- Authorization code with PKCE (S256), refresh tokens and client credentials; discovery at the standard well-known endpoints; a single scope, arena.
- Stateless tokens. Signed with HMAC, 30-day access and 180-day refresh, so they survive restarts; codes are single-use and short-lived.
- Machine-to-machine. The authorize step auto-approves because there is no user account model; the code alone is useless without the bot’s client secret.
- Not built. No dynamic client registration; no callback route of its own.
17 · Development
Building the arena meant building the boundaries first.
Next.js scaffold, then the 3D arena first: effects, environment, resource nodes, director.
Decision contract and validation, xAI provider with a forced choose_action tool, replay recorder, provider routing and the LAB panel; first tests.
OAuth authorization server with PKCE and discovery metadata, built and tested in one session.
Grok CLI runner with persistent per-agent sessions; the connector guide.
Orchestrator written and run: seven of ten agents established sessions in the designed chain order (players, then Observer, Difficulty, Provocateur, Evolution, Judge).
Per-bot connector plugins and marketplace manifests; ten Grok Bots connected through MCP, status visible in the LAB.
Recordings, screenshots and the article.
Hardening pass: CLI fallback disarmed by default, secrets scrubbed from the example env, charters and engine refined, tests for honesty invariants.
Reconstructed from file history: the repository holds one scaffold commit and everything else uncommitted, so the order comes from timestamps, session markers and documents, not from git.
18 · Engineering
- 10
- agent roles
- 4
- players
- 6
- system agents
- 30
- MCP tools
- 20
- turns per match
- 30 s
- decision window
- 4
- decidable actions
- 33
- event types
- 12
- rule DSL types
- 10
- constitution rules
- 14
- API routes
- 125
- passing tests
- Experience
- Next.js 16.3 · React 19.2 · React Three Fiber 9 · drei 10 · three 0.185 · zustand 5 · Tailwind CSS 4
- Arena engine
- TypeScript game engine (2,035 lines): tick loop, seeded RNG, generic player attributes, 33 typed events, replay recorder
- Agent layer
- AgentProvider interface · MockAgentProvider · GrokAgentProvider · RoutingAgentProvider · charters per bot · Grok CLI orchestrator with persistent sessions
- Protocol
- Hand-written MCP server over JSON-RPC (streamable HTTP, optional SSE), 3 protocol versions, 30 role-scoped tools, in-memory mailbox with disk persistence
- Authentication
- HMAC-derived per-bot bearer tokens · OAuth 2 authorization code with PKCE S256, refresh and client-credentials grants, RFC 8414 / 9728 discovery · host key for the engine bridge
- AI
- xAI Responses API with a forced choose_action tool (default model grok-4-fast-non-reasoning) · named Grok Bots via MCP connectors · Grok CLI 1.0
- Testing
- Vitest 4: 13 files, 126 cases (125 passing, 1 opt-in live proof), node environment, no component tests
The big idea
The arena is just the visible part.
Underneath it is the harder question: how do you give autonomous agents enough capability to act, while keeping their identity, permissions, decisions and consequences observable and bounded?
Truth table
Layer by layer.
| Layer | Status | Evidence |
|---|---|---|
| Arena UI (3D + HUD) | Demonstrated | Runs locally; every state on this page was captured from it. |
| Game engine | Demonstrated | Full matches resolve end to end in local mode; 125 tests. |
| Player agents | Demonstrated / Built | Mock heuristics demonstrated; xAI function-calling path built and unit-tested, no captured live call; GROK_BOT submissions via MCP built. |
| System agents | Connected / Scripted | Real MCP tool sets connected in GROK_BOT mode. In local mode the council storyline is scripted from a four-rule pool. |
| MCP tools (30) | Demonstrated | All ten bots authenticated, listed their role tools and at least one executed get_match_state, as shown in the LAB. |
| Authentication | Demonstrated / Built | Per-bot bearer tokens used in the live connections. OAuth with PKCE built and tested; no captured external token exchange. |
| Grok Bot integration | Experimental | Ten named bots exist and connected; several reported the connector down or unreadable. The stable runtime became the Grok CLI orchestrator. |
| Multi-agent live run | Experimental | Seven of ten agents ran the council chain on 25 Aug; a complete externally driven 20-turn match was not preserved. |
| Replay / telemetry | Built | Recorder, audit log and telemetry exist in memory; the replay viewer is not shipped and no run log survives. |
| Production deployment | None | Local only, exposed through a temporary tunnel during experiments. |
BUILT: exists and works locally. CONNECTED: communicated with the external Grok system. DEMONSTRATED: run end to end and observed. EXPERIMENTAL: partial, scaffolded or unstable. All credentials, secrets and tunnel addresses were excluded from this page and its media.