Intent-Driven Surgical Pipeline

We want to liberate human from confirming the trival things, but concentrationg on the WHY & intent, and AI to do the work with bounded intent zone & allocated token.

Comment

Intent-Driven Surgical Pipeline — Technical Design

Version: 1.3 Status: Active
Last Updated: 2026-03-25

Table of Contents

  1. Executive Summary
  2. Problem Statement
  3. Core Concepts & Terminology
  4. System Architecture Overview
  5. Agent Catalog
  6. Flow Orchestration
  7. Data Contracts
  8. Token Economy Model
  9. Human-in-the-Loop: The Wake-Up Protocol
  10. Comparison with Traditional Approaches
  11. Limitations & Future Work

1. Executive Summary

The Intent-Driven Surgical Pipeline is an orchestrated multi-agent system built on GitLab Duo that transforms how software is analyzed, designed, budgeted, and implemented. Instead of treating AI as a chat-based code generator, it introduces a staged pipeline of specialized agents, each with a narrow mandate, strict data contracts, and a shared token budget.

The key innovation is shifting the unit of work from code to intent. Humans express what and why; agents negotiate how within bounded resource envelopes.

Stage 0 (Surgeon) → Stage 1 (Prototyper) → Stage 2 (Distributed Architects) → Stage 3 (Token Auditor) → Stage 4 (Distributed Programmers)

Each stage produces a well-defined artifact that the next stage consumes. No agent reads the entire codebase; each reads only its contracted inputs.

Agent-Native Software produced by this pipeline is:

  1. Built by agents — the entire pipeline from intent extraction to implementation is autonomous.
  2. Usable by agents — the output includes an Agent Interface Layer (AIL) for programmatic interaction.
  3. Observable by agents — structured logs and intent tracking enable agent-driven operations.

2. Problem Statement

2.1 The AI-Coding Paradox

Problem Description Root Cause
Long-Context Loss AI loses track of the original goal when context grows beyond a few thousand lines. Flat, unpartitioned context windows with no priority hierarchy.
Hallucination Friction AI produces plausible but incorrect implementations. No architectural contract constraining what the AI is allowed to assume.
Boring HITL Human-in-the-loop review degenerates into line-by-line proofreading. No intent-level abstraction; humans review code instead of outcomes.

2.2 The Deeper Cause

These are failures of software architecture, not AI capability. Current codebases were designed for human developers who hold context in their heads. When AI agents enter this environment, they must read more files than their context window can hold, guess at implicit coupling, and interrupt humans for trivial clarifications.

The solution is not a better chatbot. It is a better architecture — one designed for agents.

2.3 The Post-UI World

Software is entering a paradigm shift toward agent-orchestrated workflows with minimal UI:

  • Traditional: UI for humans, manuals for documentation, REST APIs for integration.
  • Agentified: Agent Interface Layer (AIL) as primary interface, minimal human UI for oversight, agents handle 95% of routine tasks.

Every surviving software system needs Agentification Surgery: Extract Intent → Rebuild Architecture → Construct Agent Interface Layer.

3. Core Concepts & Terminology

3.1 Intent

A human desire expressed at the business level, divorced from implementation.

  • ✅ "Customers should be able to see real-time order status."
  • ❌ "Add a WebSocket listener on /api/orders/:id/stream."

Intents are first-class objects: captured, serialized, routed, and tracked.

3.2 Intent Partition (Zone)

A bounded scope within which a single agent is authorized to make autonomous decisions, defined by: a set of files/modules, a token budget, and a contract (input/output schema).

3.3 Surgical Pipeline

The end-to-end flow transforming a legacy codebase (or new idea) into agent-native software via five stages.

3.4 Token Budget

A pre-allocated resource envelope: Read budget (ingesting context), Write budget (generating output), Reserve (error recovery).

3.5 Wake-Up Protocol

The rule set governing when an agent must interrupt the human. Replaces "ask before every step" with batch interruptions triggered only by high-impact events.

3.6 Surgery Report

Stage 0 output mapping a legacy codebase into Rigid Nodes (tightly coupled), Fluid Nodes (loosely coupled), and an Intent Map.

3.7 Software Architecture Document (SAD)

Stage 2 output defining data schemas, intent routing tables, Module Context Index, infrastructure blueprints, observability hooks, and AIL specification.

3.8 Agent Interface Layer (AIL)

A machine-readable API for agent-to-agent interaction, distinct from the human UI.

Human Interface Agent Interface Layer (AIL)
Fill cart → Click "Proceed" → Fill payment → Click "Submit" POST /intent/order {cart_id, payment_method} → {order_id, status}
Navigate dashboard, scan for anomalies GET /intent/anomalies?severity=high → [{anomaly_id, context}]
Read manual to understand capabilities GET /ail/capabilities → machine-readable OpenAPI spec

AIL Design Principles:

  1. Declarative over Imperative: Agents declare what they want, not how.
  2. Strict Schemas: Every endpoint has versioned, validated JSON schemas.
  3. Intent IDs as First-Class Citizens: Every call returns an intent_id for tracking.
  4. Observable Execution: Structured logs queryable by humans and agents.
  5. Versioned Contracts: Semantic versioning; old agents can call old versions.

Software without AIL will be un-composable, forcing agents to resort to screen scraping (fragile and expensive).

3.9 Module Context Index

A pre-built dependency tree in the SAD enabling efficient context navigation.

Example:

handler.py (8KB, 250 lines)
├── models/order.py (4KB, 120 lines)
├── clients/payment_gateway.py (6KB, 180 lines)
│   └── utils/retry.py (2KB, 60 lines)
└── validation/order_rules.py (5KB, 150 lines)
Total Token Estimate: 23,500

This enables Programmer Instances to read only relevant files, Code Integrator to validate cross-task compatibility, and Token Auditor to calculate precise estimates. Built by the Integration Architect (Stage 2C).

4. System Architecture Overview

4.1 High-Level Pipeline

flowchart LR
    subgraph "Human Input"
        H[("👤 Human<br/>Intent + Legacy Code")]
    end

    subgraph "Stage 0"
        S0["🔬 Surgeon Agent<br/>Legacy Intent Extraction"]
    end

    subgraph "Stage 1"
        S1["🎨 UX Prototyper Agent<br/>Intent-Driven Interface"]
    end

    subgraph "Stage 2: Distributed Architecture"
        S2A["📋 Meta-Architect<br/>Module Boundaries"]
        S2B["📐 Contract Architects<br/>(N parallel agents)"]
        S2C["🔗 Integration Architect<br/>SAD Assembly"]

        S2A --> S2B
        S2B --> S2C
    end

    subgraph "Stage 3"
        S3["💰 Token Auditor Agent<br/>Resource Budgeting"]
    end

    subgraph "Stage 4: Distributed Implementation"
        S4A["📋 Task Dispatcher<br/>Dynamic Partitioning"]
        S4B["⚡ Programmer Instances<br/>(N parallel agents)"]
        S4C["🔗 Code Integrator<br/>Merge & Validate"]

        S4A --> S4B
        S4B --> S4C
    end

    H -->|legacy repo + new ideas| S0
    S0 -->|surgery_report.md| S1
    S1 -->|prototype code + intent_fragments.json| S2A
    S2C -->|SAD.md + GitLab Issues| S3
    S3 -->|token_plan.md| S4A
    S4C -->|merged code + MRs| H

4.2 Key Design Principles

  1. Contract Isolation: Each agent reads only its contracted inputs, never the full codebase.
  2. Unidirectional Data Flow: Artifacts flow forward; backward dependencies are prohibited.
  3. Token-Aware Execution: Every stage has a pre-approved token budget.
  4. Asynchronous Human Review: Agents log assumptions and batch-notify at checkpoints.
  5. Dynamic Parallelism: Stages 2B and 4B are designed for N parallel agents. Current reality: sequential due to GitLab Duo Flow limitations.
  6. Hierarchical Decomposition: Complex stages use Decomposer → Parallel Workers → Integrator.

4.3 Entry Points

Mode Starting Stage Description
Legacy Modernization Stage 0 (Surgeon) Existing codebase analyzed first.
Greenfield Project Stage 1 (Prototyper) No legacy code; starts from ideas.

4.4 Long-Context Problem Resolution

Sub-Stage Agent How Long-Context is Avoided
2A Meta-Architect Reads compressed intent summaries, NOT full prototype code
2B Contract Architects (N) Each reads <20% of prototype, bounded by module partition
2C Integration Architect Reads N partial SADs, NOT prototype code

No single agent reads >20% of any artifact.

5. Agent Catalog

5.1 Stage 0 — Surgeon Agent

Attribute Value
Name legacy-software-surgeon
Input Repository path or directory
Output surgery_report.md (Intent Map, Interaction Schema, Rigid/Fluid classification)
Token Profile Read-heavy, light write

Scans entry points, routers, controllers; maps UI actions to business logic; classifies modules as Rigid or Fluid. Does NOT modify code or make architectural recommendations.

5.2 Stage 1 — UX Prototyper Agent

Attribute Value
Name ux-prototyper
Input surgery_report.md (optional) + human feature descriptions
Output Prototype code + prototype_summary.md + intent_fragments.json + MR
Token Profile Balanced read/write

Generates a dual-layer prototype:

  • Layer 01 — Experience Sandbox: Interactive UI for humans.
  • Layer 02 — Agent Interface Kernel: Hidden intent-capture mechanism + AIL prototype endpoints.

Enforces modularity (no file >150 lines), creates feature branch + MR. Does NOT define backend architecture or infrastructure.

5.3 Stage 2 — Distributed Architecture System

5.3.1 Meta-Architect (Stage 2A)

Attribute Value
Name meta-architect
Input prototype_summary.md + file tree (paths and sizes only)
Output module_partition_plan.json — N modules with assigned intents and file scopes

Performs high-level decomposition, domain tagging (frontend/backend/infrastructure/etl/database), file scope assignment, token budget estimation. Does NOT read full prototype code.

5.3.2 Contract Architect (Stage 2B)

Attribute Value
Name contract-architect
Cardinality N modules (1 per module). Design: parallel. Current: sequential.
Input 1 module entry from partition plan + assigned prototype files
Output SAD_{module_id}.md — detailed architecture for this module

Each instance reads ONLY its assigned files. Designs data schemas, intent routing, AIL endpoints, Module Context Index, infrastructure, observability. Defines cross-module contracts (exports/imports). Creates GitLab Issues.

Key Innovation: Single agent definition spawning N runtime instances with different module_partition injections.

5.3.3 Integration Architect (Stage 2C)

Attribute Value
Name integration-architect
Input N partial SADs + module_partition_plan.json
Output Final SAD.md + cross-module validation report + GitLab Issues

Merges partial SADs, generates master Module Context Index, validates cross-module interfaces (no circular dependencies, all intents assigned), resolves minor conflicts automatically (major conflicts invoke Wake-Up Protocol).

5.4 Stage 3 — Token Resource Auditor

Attribute Value
Name token-resource-auditor
Input SAD.md + project scope
Output token_plan.md + resource advisory notes

Uses Module Context Index for precise complexity audit. Allocates budgets (development/maintenance/reserve), identifies Token Death Spiral risks, recommends optimizations. Surgical Threshold Enforcement: if any module requires >20% of total repo, audit FAILS and routes back to Stage 2A.

5.5 Stage 4 — Distributed Programmer System

5.5.1 Task Dispatcher (Stage 4A)

Attribute Value
Name task-dispatcher
Input SAD.md + token_plan.md
Output task_manifest.json + GitLab Issues (one per task)

Recognizes domains, estimates tokens via Module Context Index, decomposes tasks (split if >20% threshold). Assigns each task a context_partition:

"file_scope": {
  "entry_point": "src/services/order/handler.py",
  "dependencies": [
    "models/order.py",
    "clients/payment_gateway.py",
    "utils/retry.py",
    "validation/order_rules.py"
  ]
}

5.5.2 Programmer Agent (Stage 4B)

Attribute Value
Name async-programmer
Cardinality N tasks (1 per task). Design: parallel. Current: sequential.
Input 1 entry from task_manifest.json + assigned GitLab Issue
Output Code in feature/{task_id} branch + pending_confirmation_log.md + MR

Reads ONLY assigned SAD sections + Module Context Index entry + dependency tree files. Executes asynchronously (assume, log, continue). Enforces modularity (no file >150 lines). Batch HITL sync every 3-5 assumptions.

Key Innovation: Single agent definition spawning N instances with different context_partition injections.

5.5.3 Code Integrator (Stage 4C)

Attribute Value
Name code-integrator
Input N feature branches + task_manifest.json + confirmation logs + Module Context Index
Output Merged integration branch + integration_report.md + MR to main

Merges N branches, validates cross-task contracts via Module Context Index, runs integration tests, consolidates assumptions. Minor conflicts auto-resolved; major conflicts invoke Wake-Up Protocol.

6. Flow Orchestration

6.1 Pipeline Flow Definition

flowchart TD
    START(["🚀 Entry Point"])

    START --> MODE_CHECK{"Legacy code<br/>exists?"}

    MODE_CHECK -->|Yes| S0["Stage 0: Surgeon"]
    MODE_CHECK -->|No| S1["Stage 1: Prototyper"]

    S0 --> REVIEW_0{"Human reviews<br/>Surgery Report"}
    REVIEW_0 -->|Approved| S1
    REVIEW_0 -->|Rejected| S0

    S1 --> REVIEW_1{"Human reviews<br/>Prototype MR"}
    REVIEW_1 -->|Approved| S2A["Stage 2A: Meta-Architect"]
    REVIEW_1 -->|Rejected| S1

    S2A --> S2B["Stage 2B: Contract Architects<br/>(N parallel agents)"]

    S2B --> S2C["Stage 2C: Integration Architect"]

    S2C --> S3["Stage 3: Token Auditor"]

    S3 --> AUDIT_CHECK{"Budget<br/>feasible?"}
    AUDIT_CHECK -->|Pass| S4A["Stage 4A: Task Dispatcher"]
    AUDIT_CHECK -->|Fail: re-partition| S2A

    S4A --> S4B["Stage 4B: Programmer Instances<br/>(N parallel agents)"]

    S4B --> S4C["Stage 4C: Code Integrator"]

    S4C --> REVIEW_4{"Human reviews<br/>Integration MR + Assumption Log"}
    REVIEW_4 -->|Approved| DONE(["✅ Merge & Deploy"])
    REVIEW_4 -->|Needs changes| S4B

6.2 Human Review Gates

Gate Location Purpose Blocking?
Surgery Review After Stage 0 Validate intent map captures legacy system's purpose Yes
Prototype Review After Stage 1 Validate UX direction and captured intents via MR Yes
Budget Feasibility After Stage 3 Auto-gate: if audit fails, routes back to Stage 2A Automatic
Implementation Review After Stage 4C Review integration MR + assumption log Yes

6.3 Skip Logic

  • Greenfield projects: Skip Stage 0.
  • Architecture-only changes: Skip Stages 0 and 1, enter at Stage 2A.
  • Bug fixes: Skip Stages 0-2, enter at Stage 4 with pre-existing SAD reference.

6.4 Stage 2 Dynamic Execution

  1. Meta-Architect reads intent_fragments.json + file tree → generates module_partition_plan.json with N modules.
  2. Flow orchestrator invokes contract-architect for each module (sequential currently).
  3. Integration Architect merges N partial SADs into final SAD.md with Module Context Index.

6.5 Stage 4 Dynamic Execution

  1. Task Dispatcher reads SAD.md + token_plan.md → generates task_manifest.json with N tasks + N GitLab Issues.
  2. Flow orchestrator invokes async-programmer for each task (sequential currently).
  3. Code Integrator merges all N feature branches.

7. Data Contracts

7.1 Artifact Flow

surgery_report.md ──→ intent_fragments.json ──→ module_partition_plan.json ──→ N × SAD_MOD-XXX.md ──→ SAD.md ──→ token_plan.md ──→ task_manifest.json ──→ code + MRs
    (Stage 0)            (Stage 1)                  (Stage 2A)                    (Stage 2B)          (Stage 2C)    (Stage 3)          (Stage 4A)           (Stage 4B/4C)

7.2 Contract Summary

Contract Producer Consumer Key Contents
Surgery Report Surgeon (S0) Prototyper (S1) Intent map, interaction schema, rigid/fluid classification
Prototype Summary Prototyper (S1) Meta-Architect (S2A) Project name, prototype branch, AIL endpoints, intent fragments
Intent Fragments Prototyper (S1) Meta-Architect (S2A), Contract Architects (S2B) Fragment IDs, source intents, user actions, feedback, priorities
Module Partition Plan Meta-Architect (S2A) Contract Architects (S2B) N module definitions with IDs, domain tags, intents, file scopes
Partial SAD Contract Architect (S2B) Integration Architect (S2C) Per-module architecture, schemas, AIL endpoints, context index
SAD (Final) Integration Architect (S2C) Token Auditor (S3), Dispatcher (S4A), Programmers (S4B) Complete system architecture with all modules merged
Token Plan Token Auditor (S3) Task Dispatcher (S4A) Budget per module, risk analysis, threshold checks
Task Manifest Task Dispatcher (S4A) Programmers (S4B), Code Integrator (S4C) N task definitions with context partitions and dependencies

8. Token Economy Model

8.1 Why Token Management Matters

In an agent-native world, tokens are labor. Without budgeting, agents read entire repositories for one function, error recovery loops consume unbounded context ("Token Death Spiral"), and costs are invisible.

8.2 The 20% Surgical Threshold

Rule: If a single task requires reading >20% of the repository, the architecture must be re-partitioned.

Modern LLM accuracy degrades sharply beyond ~30% context utilization. The 20% threshold keeps agents in the "high accuracy" zone. The Module Context Index provides exact file sizes for precise threshold checks.

8.3 Budget Categories

Category Description Typical Ratio
Read Budget Tokens for ingesting code, specs, context 40%
Write Budget Tokens for generating code, docs, artifacts 40%
Reserve Buffer for error recovery, clarification loops 20%

8.4 Token Death Spiral

Occurs when a bug in a tightly coupled module requires increasing context to understand, the fix introduces side effects requiring even more context, and each iteration consumes more tokens until budget exhaustion.

Prevention: Design modules with clear boundaries. The Module Context Index makes boundaries explicit.

9. Human-in-the-Loop: The Wake-Up Protocol

9.1 Philosophy

Agents execute autonomously by default and only interrupt humans for high-impact events.

9.2 Wake-Up Triggers

Trigger Description Severity
Intent Shift Implementation contradicts a captured intent 🔴 Critical
Business Logic Pivot Requires changing fundamental business model 🔴 Critical
Context Partition Violation Agent accessed files outside its scope 🔴 Critical
Module Contract Breach Implementation violates declared interface 🔴 Critical
Token Overrun Predicted to exceed budget by >10% 🟡 Warning
External Dependency Failure Required API/service unavailable 🟡 Warning
Assumption Batch 3-5 unconfirmed assumptions accumulated 🟢 Advisory

9.3 Notification Mechanism

  • Critical: Post Issue Note, block execution until human responds.
  • Warning: Post Issue Note, continue but flag output as provisional.
  • Advisory: Log in pending_confirmation_log.md, batch-notify via MR note.

9.4 What Agents Do NOT Interrupt For

Choosing between equivalent approaches, formatting decisions, test case design within SAD scope, routine error handling within budget.

10. Comparison with Traditional Approaches

Dimension Traditional AI Coding Surgical Pipeline
Unit of Work Code (lines, files) Intent (business goals)
Context Strategy Dump entire codebase Partitioned: each agent <20% via Module Context Index
Human Role Line-by-line reviewer Intent validator; reviews outcomes
Error Handling Stop and ask for every ambiguity Assume, log, batch-notify; block only for critical shifts
Resource Management Unlimited/untracked tokens Pre-budgeted with audit gates
Architecture Awareness None; treats code as flat text Deep: contracts, routing, Module Context Index, AIL
Legacy Code Strategy "Explain this code" → manual rewrite Automated surgery → re-architecture → implement
Scalability Degrades with codebase size Stable: hierarchical decomposition keeps tasks bounded
Agent Interoperability None; output is human-centric AIL enables agent-to-agent workflows
Parallelism Single-threaded N-way parallel at Stages 2 and 4
Long-Context Problem Unsolved ✅ Solved: no agent reads >20%

11. Limitations & Future Work

11.1 Current Limitations

  1. Module Boundary Detection: Meta-Architect's decomposition may fail for complex cross-cutting concerns.
  2. Token Estimation Accuracy: Relies on "1 line ≈ 4 tokens" approximation.
  3. No Learning Loop: No feedback from Stage 4 outcomes back into earlier stages.
  4. Human Gate Bottlenecks: Review gates can slow high-velocity environments.
  5. Integration Conflict Resolution: Major conflicts require human review; no AI-powered semantic resolution yet.
  6. Cross-Cutting Concerns: Auth, logging, error handling not explicitly modeled in Module Context Index.
  7. Sequential Execution: GitLab Duo Flow lacks dynamic parallel spawning; Stages 2B/4B run sequentially.
  8. IDE-Only Tools: Some tools only work in IDE context, not Web UI.
  9. No Native Token Counter: Agents estimate using line-count heuristics.

11.2 Future Work

  1. Feedback Loop: Compare predicted vs. actual token consumption; improve partitioning and estimation.
  2. Adaptive Threshold: Dynamic 15-25% threshold based on project complexity and historical accuracy.
  3. Cross-Pipeline Orchestration: Multiple pipelines on same repo with shared Module Context Index.
  4. Intent Versioning & Drift Detection: Track intent evolution, alert on implementation drift.
  5. Hierarchical Task Decomposition: Recursive decomposition maintaining <20% at each level.
  6. AIL Code Generation: Auto-generate AIL boilerplate from SAD specification.
  7. Agent Composition Registry: Global registry of AIL-enabled systems for cross-system workflows.
  8. Cross-Cutting Concerns Module: Special module type for aspects (auth, logging, error handling).
  9. AI-Powered Conflict Resolution: Semantic merge conflict resolution with confidence thresholds.
  10. Module Context Index Evolution: Add runtime performance data and compute budget thresholds.

Appendix A: Glossary

Term Definition
Intent Business-level goal independent of implementation
Intent Partition Bounded scope (files + token budget) for an agent
Surgical Pipeline 5-stage orchestration: Surgeon → Prototyper → Architects → Auditor → Programmers
Token Budget Pre-allocated resource envelope (read + write + reserve)
Wake-Up Protocol Rules for when agents must interrupt humans
Surgery Report Stage 0 output: intent map + node classification
SAD Stage 2C output: complete architecture document
Token Plan Stage 3 output: budget allocation and risk analysis
Task Manifest Stage 4A output: task decomposition with context partitions
AIL Machine-readable API for agent-to-agent interaction
Module Context Index Dependency tree per module for efficient navigation
Token Death Spiral Runaway context growth during error recovery
Rigid Node Tightly coupled legacy module
Fluid Node Loosely coupled, agent-ready module
Post-UI World Future paradigm where agents handle 95% of operations

Appendix B: File & Artifact Map

Agent-Definition Project (this repo):

agent-definition-project/
├── TECHNICAL_DESIGN.md
├── Technical_design_middle_size.md          ← This document
├── README.md
├── agents/                                  ← 9 agent YAML definitions
│   ├── surgeon.agent.yml
│   ├── prototyper.agent.yml
│   ├── meta_architect.agent.yml
│   ├── contract_architect.agent.yml
│   ├── integration_architect.agent.yml
│   ├── token_auditor.agent.yml
│   ├── task_dispatcher.agent.yml
│   ├── async_programmer.agent.yml
│   └── code_integrator.agent.yml
├── contracts/                               ← Contract schemas
│   ├── surgery_report.schema.md
│   ├── prototype_summary.schema.md
│   ├── intent_fragments.schema.json
│   ├── module_partition_plan.schema.json
│   ├── partial_sad.schema.md
│   ├── sad.schema.md
│   ├── token_plan.schema.md
│   └── task_manifest.schema.json
├── flows/                                   ← Flow orchestration
│   ├── surgical_pipeline.flow.yml
│   └── greenfield.flow.yml
└── example/

User's Target Project (runtime artifacts):

user-project/
├── analysis/surgery_report.md               ← Stage 0
├── prototype/                               ← Stage 1
│   ├── src/sandbox/                         ← Experience Sandbox
│   ├── src/kernel/                          ← Agent Interface Kernel
│   └── prototype_summary.md
├── architecture/
│   ├── module_partition_plan.json           ← Stage 2A
│   ├── SAD_MOD-*.md                         ← Stage 2B
│   ├── SAD.md                               ← Stage 2C
│   ├── token_plan.md                        ← Stage 3
│   └── task_manifest.json                   ← Stage 4A
├── src/                                     ← Stage 4B: Implementation
├── infra/                                   ← Stage 4B: Infrastructure
├── tests/                                   ← Stage 4B: Tests
├── logs/pending_confirmation_log_T*.md      ← Stage 4B
└── integration_report.md                    ← Stage 4C

Branch Structure During Stage 4:

main
├── integration/20260324-140000                ← Code Integrator (Stage 4C)
│   ├── feature/T001                           ← Programmer instance 1
│   ├── feature/T002                           ← Programmer instance 2
│   ├── feature/T003                           ← Programmer instance 3
│   ├── feature/T004                           ← Programmer instance 4
│   └── feature/T005                           ← Programmer instance 5

Appendix C: Agent Count Summary

Stage Agent Runtime Instances Parallelism
0 Surgeon 1 No
1 Prototyper 1 No
2A Meta-Architect 1 No
2B Contract Architect N (1 per module) Design: Yes, Current: Sequential
2C Integration Architect 1 No
3 Token Auditor 1 No
4A Task Dispatcher 1 No
4B Async Programmer N (1 per task) Design: Yes, Current: Sequential
4C Code Integrator 1 No
Total 9 definitions 1 to 2N+5 instances Stages 2B & 4B

Key Insight: Dynamic instantiation achieves N-way parallelism with only 9 agent YAML definitions.

Built With

  • cloud-run
  • gitlab
  • terraform
Share this project:

Updates