Drumfire: Agentic Production Pipeline

Section 01

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 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.

Section 02

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.

Scoped engine toolset Human-in-the-loop Shipped output

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/context confusion, trading a little setup for more predictable behaviour. ElevenLabs MCP handles SFX and music generation; Blender MCP automates tasks that require Blender.

Planning / 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 can't judge.

Section 03

The hard parts

Failure mode 01

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. The planning layer does two jobs at once: better outputs and lower cost.

Failure mode 02

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.

Failure mode 03

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.

Section 04

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; estimates are flagged as such.

Stack & 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 (~$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 cost 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):

Run type	Tokens (in / out)	Equivalent cost
Light	~80k / 15k	~$0.80
Typical	~250k / 40k	~$2.25
Heavy (loops + sub-agents)	~1M / 120k	~$8.00

Token volumes are estimated, not measured. They are modelled from typical agentic-task volumes and corroborated against published Opus 4.8 benchmarks (~$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 & verification

5–40 min

Per run · measured

~5×

Loop reduction · measured

~1%

Effective loop rate · measured

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 (only ~20% still looped), cutting the effective loop rate to ~1%. The planning layer reduced loop incidence roughly 5×, from 5% to ~1%.

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.

Section 05

What I'd do differently

Honest forward judgement, drawn from the failure modes above. Not self-criticism, but 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.