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 starts with five specialist roles. They are the initial roster in an extensible system, not a permanent product limit.

• Maestro: Coordinates specialist work, checks its verification, and decides when independent testing is useful.
• Prototyper: Builds the first playable slice.
• Juicer: Improves feel, feedback, and presentation.
• Systems Smith: Builds durable systems, UI, and persistence.
• Playtester: Runs the game and verifies behavior from evidence.

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 with the relevant context and acceptance criteria. 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 Prototyper to bring the mechanic into a playable state. Prototyper 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. Once the dash is ready to verify, Maestro may call Playtester to exercise it in the running game and return evidence that it can be triggered, moves the player as intended, and respects the configured cooldown. The developer can then review the resulting changes and runtime evidence. 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 acceptance results, checks, artifacts, blockers, 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.
• Specialist tool calls are serial, and specialists cannot delegate further.
• Every specialist result returns to Maestro before another step is considered.
• Applicable project actions still require developer approval.
• The five launch roles are the initial roster, not a permanent limit.
• Specialist coordination does not guarantee correctness; developer review remains necessary.