Build the Whole
Town at Once

The Vision

Think about what it takes to build a Workday. Not a feature. Not an API. The whole platform: Finance, HCM, Payroll, Benefits, Time Tracking, Recruiting, Supply Chain, Inventory, Procurement. Each of those is a full application with its own domain model, business rules, workflows, and data. But they all live on one platform. An employee in HCM is the same employee who gets a paycheck from Payroll and submits expenses through Finance. A purchase order in Procurement creates a liability in Finance and updates inventory in Supply Chain.

Today, Context Foundry builds one task at a time through SPID: Scout, Plan, Implement, Doubt. That works for a feature. It does not work for a platform with 8 modules, 200+ domain objects, and cross-cutting concerns like auth, tenancy, audit logging, and workflow orchestration. Serial execution at that scale means your Payroll agent waits months while Finance and HCM are built -- even though they could all be built in parallel with well-defined integration points.

This document describes how to scale Context Foundry from "one task, one loop" to "many modules, one platform" -- where each functional area runs its own build pipeline concurrently, all coordinated by a shared architecture and integration authority.

Why This Is Different from Splitting a Feature

You could split a single task into api/ui/infra lanes and run them in parallel. That is useful, but it is not what we are talking about here. The difference is fundamental:

Feature-level parallelism is a tactic. Module-level parallelism is an architecture. The mechanics overlap -- manifests, contracts, worktrees -- but the shape of the problem is categorically different.

The Architecture

The key insight: modules are not lanes within one task. They are independent sub-projects that share a platform kernel. Each module gets its own TASKS.md, its own scout-report, its own full SPID pipeline. The Architect Agent defines the boundaries and contracts upfront. The Integration Authority merges everything into a coherent platform release.

The Platform Kernel

Before any module starts building, the platform kernel ships first. This is the shared foundation every module depends on -- and it has exactly one owner: the Integration Authority. The kernel and the Integration Authority are not separate roles. The same agent that builds and owns the kernel is the same agent that publishes contracts, merges module output, and runs cross-module verification. One agent, one authority, one source of truth for the platform's shared infrastructure.

The kernel ships as Phase 0. It defines the contracts that modules build against. Once the kernel is stable, modules can start in parallel -- they all depend on the kernel, but they do not depend on each other (at least not at first).

Modules as Sub-Projects

Each module is a self-contained project with its own build loop. This is not "lanes within one task" -- it is genuinely independent projects that share a platform:

platform/
  kernel/                    # Phase 0 -- ships first
    src/auth/
    src/tenancy/
    src/events/
    src/types/               # Employee, Organization, Money, etc.
    migrations/
    TASKS.md
    .buildloop/

  modules/
    finance/                 # Independent SPID pipeline
      src/
      TASKS.md
      .buildloop/
        scout-report.md
        current-plan.md

    hcm/                     # Independent SPID pipeline
      src/
      TASKS.md
      .buildloop/

    payroll/                 # Independent SPID pipeline -- blocks on HCM
      src/
      TASKS.md
      .buildloop/

    supply-chain/            # Independent SPID pipeline
      src/
      TASKS.md
      .buildloop/

  contracts/                 # Versioned API + event schemas
    finance-api.v1.yaml
    hcm-api.v1.yaml
    events/
      pay-run-completed.v1.json
      employee-terminated.v1.json

  integration/               # Merge + verify workspace
    .buildloop/
      merge-log.md
      platform-test-results.md

Each module has its own TASKS.md with module-specific tasks. Each runs through full SPID: a Scout that reads the module directory plus kernel types, a Plan scoped to the module, an Implement that only touches module-owned files, and a Doubt that validates the module against its contracts.

This means you can have 4 agents building 4 modules simultaneously, each in its own worktree, each with its own context window focused entirely on its domain. The Finance agent does not waste context on Payroll code it will never touch.

Contracts at Enterprise Scale

At feature scale, a contract is a TypeScript interface file. At enterprise scale, contracts are versioned artifacts that multiple modules build and test against independently. They are the load-bearing walls of the platform.

Who owns contracts?

One authority: the Integration Authority. Modules do not publish contracts directly. They propose contract schemas, and the Integration Authority reviews, validates, and publishes immutable versions to contracts/. This prevents conflicting schemas, ensures cross-module consistency, and gives one agent the full picture of all platform boundaries.

Contract lifecycle

A contract moves through four states. This resolves the question of when consumers can start building against a contract that is not yet implemented:

This means a dependent module like Payroll can unblock as soon as HCM's API schema reaches schema_published -- it does not have to wait for HCM to finish implementing. Payroll builds against mocks generated from the published schema, and the real integration is verified later.

API contracts

Each module exposes a versioned API defined in OpenAPI or similar. The contract is the schema, not the implementation. When Finance proposes /api/v1/journal-entries, the Integration Authority validates it against the kernel types and publishes the immutable schema. Supply Chain can build against that schema before Finance has implemented it -- using mocks generated from the published spec.

Event contracts

Cross-module workflows are event-driven. When Payroll completes a pay run, it publishes a pay-run-completed.v1 event. Finance consumes that event to create journal entries. The event schema is a contract -- proposed by Payroll, published by the Integration Authority, versioned and immutable once published, validated at both ends.

Shared domain objects

Some objects cross module boundaries: Employee, Organization, Cost Center, Currency. These live in the kernel. Modules reference them but cannot modify them. If Payroll needs a new field on Employee, that is a kernel change -- not a Payroll change. The request goes to the Integration Authority, which owns the kernel.

The Module Manifest

At this scale, the manifest is no longer a lightweight coordination file. It is the platform's bill of materials -- every module, every contract, every dependency, every deployment status:

{
  "version": 2,
  "platform": "acme-erp",
  "kernel_version": "0.3.0",
  "integration_authority": {
    "model": "opus",
    "owns": [
      "kernel/**", "contracts/**", "docker-compose.yaml",
      "package.json", "Cargo.toml", "tsconfig.json"
    ],
    "merge_strategy": "milestone"
  },
  "contracts": {
    "hcm-api.v1":               { "state": "schema_published", "proposed_by": "hcm" },
    "finance-api.v1":            { "state": "schema_published", "proposed_by": "finance" },
    "pay-run-completed.v1":      { "state": "drafted",          "proposed_by": "payroll" },
    "employee-terminated.v1":    { "state": "drafted",          "proposed_by": "hcm" }
  },
  "modules": {
    "finance": {
      "status": "implementing",
      "branch": "foundry/finance",
      "owns": ["modules/finance/**"],
      "proposes": ["finance-api.v1", "journal-entry-created.v1"],
      "consumes": ["employee.kernel", "organization.kernel"],
      "blocks_on_schema": [],
      "blocks_on_impl": ["kernel"],
      "agent_model": "sonnet"
    },
    "hcm": {
      "status": "implementing",
      "branch": "foundry/hcm",
      "owns": ["modules/hcm/**"],
      "proposes": ["hcm-api.v1", "employee-terminated.v1"],
      "consumes": ["employee.kernel", "organization.kernel"],
      "blocks_on_schema": [],
      "blocks_on_impl": ["kernel"],
      "agent_model": "sonnet"
    },
    "payroll": {
      "status": "implementing",
      "branch": "foundry/payroll",
      "owns": ["modules/payroll/**"],
      "proposes": ["payroll-api.v1", "pay-run-completed.v1"],
      "consumes": ["hcm-api.v1", "employee.kernel"],
      "blocks_on_schema": ["hcm-api.v1"],
      "blocks_on_impl": ["kernel"],
      "agent_model": "sonnet"
    },
    "supply-chain": {
      "status": "implementing",
      "branch": "foundry/supply-chain",
      "owns": ["modules/supply-chain/**"],
      "proposes": ["supply-chain-api.v1", "po-approved.v1"],
      "consumes": ["finance-api.v1", "organization.kernel"],
      "blocks_on_schema": ["finance-api.v1"],
      "blocks_on_impl": ["kernel"],
      "agent_model": "sonnet"
    }
  }
}

Key changes from the earlier manifest: publishes is now proposes (modules propose, Integration Authority publishes). Contracts have their own section with lifecycle states. blocks_on is split into blocks_on_schema (can start building against mocks) and blocks_on_impl (needs working implementation). Payroll unblocks as soon as HCM's schema is published, not when HCM finishes building.

Execution Flow

PHASE 0: KERNEL
  Architect Agent designs platform architecture
  Writes module manifest, contract schemas, kernel code
  Full SPID on kernel: Scout -> Plan -> Implement -> Doubt
  Output: stable kernel + published contracts

PHASE 0.5: SCHEMA PUBLISHING
  Integration Authority publishes contract schemas proposed during Phase 0
  Consumers can now start building against mocks
  Dependent modules unblock as schemas reach schema_published

PHASE 1: INDEPENDENT MODULES (parallel)
  For each module where blocks_on_impl is satisfied:
    Spawn agent in module's worktree
    Full SPID: Scout (module + kernel types) -> Plan -> Implement -> Doubt
    On completion: propose contract schema updates if needed
    Integration Authority validates proposed contracts incrementally

  Running concurrently:
    [Finance]      Scout -> Plan -> Implement -> Doubt -> propose contracts
    [HCM]          Scout -> Plan -> Implement -> Doubt -> propose contracts
    [Supply Chain]  Scout -> Plan -> Implement -> Doubt -> propose contracts
    [Payroll]      starts as soon as hcm-api.v1 reaches schema_published
                   builds against mocks until HCM's real impl is ready

PHASE 2: INCREMENTAL CONTRACT VERIFICATION
  As each module completes, Integration Authority:
    - Verifies proposed schemas match implementation
    - Moves contracts from schema_published -> implemented
    - Runs per-contract integration checks (schema compliance, mock parity)
  This happens continuously, not as a big-bang at the end

PHASE 3: CROSS-MODULE INTEGRATION
  Integration agent merges all module branches
  Full platform build + test suite
  Cross-module workflow tests (Payroll -> Finance journal entries)
  System-level Review: fresh-context audit of all boundaries

PHASE 4: PLATFORM RELEASE
  Verified platform commit
  All contracts published and tested
  Integration tests green across module boundaries

Each module runs a full SPID pipeline, not a reduced Plan+Implement. At this scale, each module is large enough to warrant its own Scout (reading module code + kernel types), its own Plan, and its own Doubt. The system-level Review in Phase 3 catches cross-module issues that per-module Doubt cannot see.

The Integration Authority

The Integration Authority is a single agent that wears two hats: it builds the kernel (Phase 0) and then supervises module integration (Phases 1-4). These are not separate roles. The same agent that designed auth and tenancy is the same agent reviewing contract proposals and merging module output. This continuity is intentional -- no other agent has the full platform context.

Its responsibilities:

• Builds and owns the kernel. Auth, tenancy, the event bus, shared types, infrastructure config. It built them, it owns them, it is the only one who can modify them.
• Publishes contracts. Modules propose schemas; the Integration Authority reviews them against kernel types and cross-module consistency, then publishes immutable versions. No module writes to contracts/ directly.
• Verifies contracts incrementally. As modules complete, the Integration Authority checks that implementations match published schemas and runs per-contract integration checks. Schema mismatches surface in hours, not at the end.
• Runs cross-module workflow tests. The workflow "employee joins (HCM) -> gets added to payroll (Payroll) -> first expense submitted (Finance)" spans three modules. Only the Integration Authority has the context to test this end-to-end. This runs in Phase 3 after all modules are merged.
• Manages contract versioning. When HCM proposes a v2 of its API, the Integration Authority ensures Payroll (which consumes v1) still works before publishing. New contract versions are additive, not breaking.
• Handles shared-file requests. When a module needs a change to a root-level file it does not own (Cargo.toml, package.json, workspace config), it submits a formal request to the Integration Authority describing what it needs and why. The Integration Authority makes the change, or rejects the request with an alternative. Modules never edit shared files directly.
• Uses the most capable model. This is the hardest job in the system: reasoning about cross-cutting concerns, resolving semantic conflicts, understanding how domain models interact across boundaries. It gets Opus.

Domain Boundaries

The hardest problem in enterprise software is not building modules. It is deciding where one module ends and another begins. Get the boundaries wrong and you spend forever fixing cross-module coupling.

The Architect Agent's primary job is boundary design. Here is how it should think about a Workday-scale system:

The boundaries follow a rule: each module owns its business logic but depends on other modules through contracts for data it does not own. Payroll calculates paychecks (its logic) but reads employee data from HCM's API (HCM's data). Finance posts journal entries (its logic) but receives pay run totals from Payroll's events (Payroll's data).

Shared Data Model

The most dangerous place in a multi-module platform is the shared data layer. Two modules writing to the same table is how you get data corruption, deadlocks, and impossible-to-debug production incidents.

Rules

1. Each module owns its tables. Finance owns journal_entries. HCM owns employees. Payroll owns pay_runs. No module writes to another module's tables.
2. Cross-module reads go through APIs. Payroll does not query the employees table directly. It calls hcm-api.v1/employees/{id}. This is slower but it preserves module autonomy and makes the dependency explicit.
3. Shared reference data lives in the kernel. Currency codes, country codes, organization hierarchy -- these are kernel-owned lookup tables that all modules can read but none can write.
4. Events carry the data they need. When Payroll publishes pay-run-completed, the event payload includes the GL account codes and amounts. Finance does not need to call back to Payroll to process it.

Dependency Graph

Module dependencies form a directed acyclic graph (DAG). The orchestrator resolves this graph to determine which modules can build in parallel and which must wait:

kernel (Phase 0 -- builds first)
  |
  +-- finance        (depends on kernel only -- Phase 1)
  +-- hcm            (depends on kernel only -- Phase 1)
  |     |
  |     +-- payroll  (depends on kernel + hcm -- Phase 2)
  +-- supply-chain   (depends on kernel only -- Phase 1)
        |
        +-- procurement  (depends on kernel + supply-chain + finance -- Phase 2)

Phase 1 modules (finance, hcm, supply-chain) all start simultaneously after the kernel ships. Phase 2 modules (payroll, procurement) start as their dependencies publish their API contracts.

The orchestrator does not need to understand module semantics. It reads the blocks_on field in the manifest and watches for status transitions. When hcm moves to published, the orchestrator checks which blocked modules now have all dependencies satisfied and spawns them.

When to Use This

This is built for

• Enterprise platforms with 4+ functional modules (ERP, HCM, CRM suites)
• Systems where modules have distinct domain models but share users and infrastructure
• Greenfield builds where you can define boundaries and contracts upfront
• Teams that need to parallelize across domain areas, not just across files

This is not for

• Single-purpose applications (use standard SPID)
• Tightly coupled monoliths where every feature touches every table
• Microservices that are already independently deployable (you already solved this problem)
• Projects under 50 files total (the orchestration overhead exceeds the parallelism benefit)

Open Questions

• Contract negotiation. What happens when the Payroll module discovers it needs a field that HCM's contract does not provide? In human teams, this is a cross-team negotiation. For agents, we need a protocol: Payroll requests a contract amendment, the Architect Agent evaluates it, HCM's contract owner publishes a v2 if approved. This protocol does not exist yet.
• Module-level rollback. If the Finance module's Doubt pass fails, do you re-run just Finance, or re-run everything that depends on Finance? The answer depends on whether Finance published contracts that other modules consumed. Contract versioning helps: downstream modules built against v1, and a failed Finance rebuild does not invalidate v1.
• Cost at scale. Running 4 full SPID pipelines in parallel means 4x the API calls. For a platform with 8 modules, that is 8x. The wall-clock savings are real (8 serial modules could take a full day of agent time; 8 parallel modules finish in hours) but the dollar cost is significant. Granular model selection per role per module (Sonnet for builders, Opus for architect and integration) helps control this.
• TUI at scale. Showing 4+ concurrent SPID pipelines in a terminal interface is a genuinely hard UX problem. Per-module status, dependency resolution progress, contract publication events, integration merge results -- all updating simultaneously. This likely needs a dashboard view, not just a log stream.
• Incremental builds. After the initial platform build, how do you add a feature that touches two modules? The full decomposition is overkill. You need a lighter-weight "cross-module task" mode that creates targeted lanes for just the affected modules, not a full platform rebuild.

v1 Constraints

The first implementation keeps the corral tight:

• Max 4 modules (not counting integration)
• Kernel must ship completely before any module starts
• No circular dependencies between modules
• Contracts are versioned but immutable once published (no mid-build amendments in v1)
• Integration Authority is one agent: builds the kernel, publishes contracts, merges output, runs verification. Always Opus.
• Each module runs full SPID in its own worktree
• Modules propose contracts; only Integration Authority publishes to contracts/
• Modules never write shared files directly; changes go through a request to Integration Authority
• Incremental contract schema checks run as modules complete (v1); full cross-module workflow tests run only after all modules merge (v1 tradeoff -- v2 targets incremental workflow testing)
• No nested modules (a module cannot decompose into sub-modules)

These constraints loosen once the orchestration layer is proven. v2 targets: contract amendment protocol (propose-review-publish cycle for mid-build changes), incremental cross-module workflow testing, and nested decomposition for large modules.

Summary

Building an enterprise platform with AI agents requires thinking at a different scale than building features. The primitives:

1. Platform Kernel -- the shared foundation (auth, tenancy, data layer, event bus, shared types) that ships first and constrains every module. One owner, absolute authority.
2. Modules as Sub-Projects -- each functional area (Finance, HCM, Payroll, Supply Chain) runs its own full SPID pipeline in its own worktree with its own TASKS.md. Genuinely independent, not just "lanes."
3. Versioned Contracts -- APIs, event schemas, and shared domain objects are versioned artifacts that modules build and test against independently. Consumers migrate on their own timeline.
4. Module Manifest -- a versioned JSON document that encodes the dependency DAG, file ownership, contract publishing, and status tracking for the entire platform.
5. Integration Authority -- a dedicated agent that owns the kernel, merges at milestones, runs cross-module workflow tests, and manages contract versioning. The hardest job gets the best model.

This is how you build the whole town at once. Not one building at a time. Not by having every carpenter work on every building. By giving each crew their own blueprints, their own materials, and their own section of town -- with one architect making sure it all connects and one inspector signing off at the end.

The trail drive just got a lot bigger.