A multi-agent pipeline for cross-tool game production

The problem

Producing game content normally means context-switching by hand across separate tools: building in the engine, generating sound and music, and authoring 3D assets, each with its own interface and workflow. The manual loop is slow and it breaks concentration.

The goal was a pipeline where one instruction fans out into coordinated work across all three tools automatically, so the operator works at the level of intent rather than tool-by-tool execution. This shipped as part of Drumfire, an RTS roguelite on Steam.

Architecture

A single prompt is decomposed and routed across three tools via MCP servers, with two agent layers sitting on top of the tool layer: a planning layer that refines the request before the tools run, and a verification layer that checks the result after.

Tool layer

Godot is exposed through two MCP variants that deliberately expose different toolsets. Rather than giving one agent access to every engine operation, tool access is scoped per context, which limits the agent’s error surface and reduces token and context confusion — trading a little setup for more predictable behaviour. ElevenLabs MCP handles SFX and music generation; Blender MCP automates the tasks that require Blender.

Planning and translation sub-agents

These convert a loose human request into more specific, executable prompts before the tool agents run. They are the layer that keeps loosely-worded intent from reaching the tools unprocessed.

Verification sub-agents

Multiple sub-agents cross-validate that produced work is functional as intended, with a defined handoff to manual validation for the cases automation cannot judge.

The hard parts

Prompt loops

Manual prompts occasionally sent the agents into non-converging loops. The fix was a layer of sub-agents that translate the original request into more specific prompts. These both converged on the intended result more reliably and reduced wasted token spend, so the planning layer does two jobs at once: better outputs and lower cost.

The verification boundary

Sub-agents cross-validate whether outputs are functional as intended, catching regressions automatically. A class of checks still required manual validation, and that boundary is deliberate. Automated cross-validation handled functional correctness; subjective or out-of-scope judgement stayed with a human. Knowing where automation’s reliability ends is itself a design decision, not a gap.

Heterogeneous orchestration

Coordinating one intent across an engine, an audio service and a 3D tool, each with its own MCP surface, is the core integration challenge. Scoped tool access (the two Godot variants) was part of keeping it tractable.

The numbers

Every figure below is labelled. Measured values come from observed runs; estimated values are modelled from typical agentic-task token volumes and are not instrumented telemetry. Nothing here is invented, and estimates are flagged as such.

Stack and billing Known

The pipeline ran on a flat Claude Max 5× subscription ($100/month; Opus 4.x, mostly High Effort) rather than metered per-token billing, alongside ElevenLabs Creator (about $20/month) and the free Godot MCP. Because the core tools were flat subscriptions, the marginal cost of one additional run was effectively $0 up to rate limits — so the meaningful figures are the flat monthly spend and the equivalent metered cost as a proxy for compute consumed.

Equivalent metered cost per run Estimate

At Opus 4.x API rates ($5 / $25 per million input / output tokens):

Token volumes are estimated, not measured. They are modelled from typical agentic-task volumes and corroborated against published Opus 4.8 benchmarks (about $1.75 for a ~200k / 30k-token edit), which makes them defensible as estimates. The metered-equivalent figure is the one to lead with: it holds regardless of billing plan.

Latency, loops and verification

Latency (measured). 5–40 minutes per run, mostly on High Effort. Variance tracked run complexity: a single-tool asset versus multi-tool work with sub-agent passes.

Loops (measured). About 5% of manual prompts entered non-converging loops. Routing those through the translation layer’s second pass resolved roughly 80% of them, cutting the effective loop rate to about 1% — a roughly five-fold reduction in loop incidence.

Verification (qualitative). Automated cross-validation sub-agents caught functional regressions; a class of subjective checks stayed with manual review. The boundary is the complete claim: automation owned functional correctness, humans owned subjective judgement.

What I’d do differently

Honest forward judgement, drawn from the failure modes above. Not self-criticism — the next iteration.

• Formalise the cross-validation sub-agents into a fixed eval suite with explicit pass/fail assertions and a single quotable reliability number, rather than ad-hoc per-run checks.
• Instrument cost and latency from the start, so the pipeline’s economics are measured rather than estimated after the fact.
• Tighten the automated / manual boundary by promoting the most common manual checks into automated assertions.