How the EngineForge Crew Delegates Game-Development Work

Game-development work rarely benefits from treating every task as the same kind of problem. EngineForge Crew routes bounded work to specialists with different instructions, context, tools, and stopping conditions—without turning every request into a five-agent operation. Maestro remains the coordinator, and the developer stays in control of approvals, resulting changes, and the evidence used to review them.

Why one generic agent is not always enough

Planning a feature, building its first playable slice, improving feel, designing a durable system, and verifying runtime behavior are different jobs. They reward different instructions, context, and stopping rules. Crew makes those differences explicit so Maestro can call the specialist best suited to each bounded part of the task.

That does not mean every request starts the whole Crew. A task may stay with one specialist result from beginning to end. Another specialist becomes involved only when Maestro identifies a useful, bounded next step.

Meet the initial Crew

EngineForge's Crew is Maestro and four specialists. They are the current roster in an extensible system, not a permanent product limit.

• Maestro: Reads your request, sends each part to the right specialist one at a time, checks what comes back, and reports the result to you.
• Builder: Builds the game itself: mechanics, controls, scenes and the order they come together in. Builder also exports the finished game as a desktop build.
• Juicer: Game feel and atmosphere: impact, motion, effects, sound effects, music and character voice lines (synthetic voices), lighting, weather and mood, once a mechanic works.
• Systems Smith: Owns game state and the screens that show it: versioned save and load, settings, inventory, progression, menus and HUD, including measuring and clicking through game UI.
• Playtester: Runs the game on request, reproduces what it observes, finds the root cause and makes the minimal fix. It plays only when you choose to send it, or when Auto Playtest is on.

The public Crew overview and Crew documentation describe how these roles fit into the broader product workflow.

Maestro chooses the right specialist for the work

Maestro owns coordination for the current task. It interprets the objective, identifies work that benefits from a specialist role, and sends that specialist a bounded brief carrying the facts it needs. Selecting the Crew does not automatically run every role.

Plan mode is read-only: it can inspect the project and reason about the work without changing project or engine state. Forge mode gives a called specialist only the actions appropriate to its role, while applicable approval boundaries remain in effect.

Delegate a bounded part of the task

Maestro can ask a Crew specialist to handle a specific, self-contained part of the work. The specialist works separately within its role and applicable approval boundaries, then returns its result and verification evidence to Maestro.

For example, a developer asks EngineForge to add a dash ability to an existing player controller. Maestro first calls Builder to bring the mechanic into a playable state. Builder inspects the controller, implements the playable slice, and reports that the project already has a structured movement and state system. Maestro can then call Systems Smith with the bounded task of fitting the cooldown and state integration into that architecture instead of leaving a prototype-only workaround.

Systems Smith completes that specific piece and returns the result to Maestro. Because the dash changes how the game plays, Maestro then offers a playtest: the developer can try it themselves with a short checklist, send the Playtester to exercise it in the running game and return evidence that it triggers, moves the player as intended and respects the cooldown, or skip it. With Auto Playtest on, the Playtester goes straight away. This is an illustrative workflow, not a mandatory pipeline for every task or feature.

Maestro remains the coordinator

A specialist tool call gives one Crew member a bounded sub-task. Its structured result returns to Maestro, including checks, artifacts, blockers, caveats and verification evidence where available.

Specialists do not call additional specialists from inside their bounded runs. Maestro uses one specialist tool at a time and reviews the returned result before deciding whether another step is useful. See Maestro coordination for the complete product behavior.

Review what the Crew did

Crew coordination remains inspectable. The developer can review the result of delegated work, respond to approvals where required, inspect project changes and diffs, and use checkpoints for captured code changes. When runtime behavior matters, the relevant specialist can return runtime evidencescoped to the condition that was exercised.

Specialist results, blockers, approvals, and Maestro sanity checks remain visible for review. Coordination does not make specialist work correct by default; the resulting changes and evidence still require review.

Current boundaries

• Delegated work is bounded rather than an unlimited chain of specialists.
• Maestro brings in one specialist at a time, and specialists cannot bring in others.
• Every specialist result returns to Maestro before another step is considered.
• Actions you have not auto-approved still wait for your approval.
• Specialist coordination does not guarantee correctness; developer review remains necessary.