Turn the Problem Case into a plan the coding agent can actually execute.
The Build is the implementation contract. It takes the current grounded Problem Case and turns it into structured scope, architecture, documents, and tasks that can be reviewed, versioned, approved, and worked through.
Before generating a Build
A project should have a ready Problem Case first. The Build is intentionally downstream of Analysis so implementation decisions remain tied to the problem evidence instead of drifting into an unrelated feature list.
Build through MCP
Like Analysis, MCP Build generation uses the connected host model for reasoning while Immensity supplies the grounded project context and enforces the output contract.
generate_build_workspace() → host model designs the structured Build save_build_workspace(problem_case_version, build) → review / update approve_build_workspace() → get_next_task()
1. Generate from the current Problem Case
generate_build_workspace returns the current grounded Problem Case, Build instructions, exact Build schema, request context, and the Problem Case version the generated Build must reference.
2. Save a validated version
save_build_workspace validates the structured output and its traceability back to the Problem Case. If the Problem Case changed while the host was designing the Build, Immensity rejects the stale save.
Saving a new Build creates a new version, resets approval to draft, and clears task progress that belonged to an older Build so execution state cannot silently cross versions.
3. Review before approval
Use the Build workspace and document tools to inspect and refine the plan before approval. The point of this stage is to catch scope or implementation problems while they are still cheap to change.
get_build_workspace— inspect the current Build.update_build_section— change a structured section.list_build_documents/get_build_document— inspect implementation documents.update_build_document— revise a document before approval.
4. Approve the implementation contract
Approval marks the Build as the version the coding workflow should execute against. Agents can then use get_build_contract, get_next_task, and project context tools without reconstructing the plan from chat history.
5. Track execution
| Tool | Purpose |
|---|---|
get_next_task | Return the next incomplete task whose dependencies are complete. |
update_task_progress | Record progress against the current Build task. |
report_blocker | Record a blocker instead of pretending the task is complete. |
submit_verification | Submit completion with a summary and the checks actually run. |
get_project_status | Read the project's current overall implementation state. |
The important boundary
Immensity does not need to be the model that writes your code. Its job is to keep the problem evidence, Analysis, Build, task state, validation, and version history coherent while the coding agent does the implementation work.