Software Factory Stack Boundaries
Give every component one clear responsibility and replacement boundary.
A rapid review of the chapter’s existing Quick Read, principles, definitions, lessons, and review material.
The chapter in one pass.
- Purpose: Give every component one clear responsibility and replacement boundary.
- Best for: Executives, architects, platform teams, and anyone comparing agent products.
- Prerequisites: AI Software Factory and Mission Control.
- Reading time: 14 minutes.
- You will learn: How Agent Factory, control plane, orchestrator, outer harness, inner harness, development environment, and compute fit together.
Keep three ideas: commercial product boundaries are not authority boundaries; interfaces require versioned contracts; and composability is proven through behavioral compatibility rather than a generic adapter label.
Reconstruct and defend this chapter’s architecture.
Reconstruct the architecture, name each boundary, and defend the tradeoffs.
Open the source exercise
Draw a composed stack in which the organization owns the control plane and development environment, buys an inner harness, and uses managed compute. Mark every identity, contract, event stream, credential, policy decision, fallback, and failure owner. Then replace the inner harness without changing acceptance authority.
3. Enduring Principle
Name a layer by the responsibility it owns
Use the following canonical boundaries:
| Concept | Owned responsibility | Does not prove or own |
|---|---|---|
| AI Coding Agent | Pursue a bounded repository outcome through reasoning and tools | Business authority, acceptance, merge, or release |
| Inner Harness | Run the model-tool-observation loop and manage one coding session | Durable cross-run workflow state or organizational approval |
| Outer Harness | Adapt, supervise, and operationalize an inner harness through lifecycle events, skills, budgets, retries, and completion contracts | Mission authority or acceptance of its own output |
| Development Environment | Supply the checkout, toolchains, dependencies, services, identity bindings, and previews required to build and test | Permission to widen scope or publish |
| Compute Infrastructure | Supply machines, containers, VMs, storage, network, and capacity | A trustworthy environment or authorized execution |
| Orchestrator | Sequence authorized work, dispatch Attempts, react to events, and reconcile state | Approval of its own plan or evidence |
| Control Plane | Own intent, policy, authority, durable state, approvals, evidence requirements, and governance decisions | The implementation work performed by executors |
| Agent Platform | Provide reusable runtime services for agents, including tools, context, identity, routing, memory, and telemetry | End-to-end software-delivery governance |
| Agent Factory | Create, package, version, evaluate, publish, discover, admit, deprecate, and revoke reusable agent capabilities | Delivery of a particular business outcome |
| AI Software Factory | Compose people, policies, capabilities, execution, assurance, delivery, and learning from intent through validated production value | A single agent, model, harness, or control-plane product |
Mission Control is the guide's concrete control-plane implementation and case study. It is not the definition of the AI Software Factory and should not absorb every execution or delivery responsibility into one service.
Separate the control path from the execution stack
The downward path delegates capability. The upward path reports observations. Neither path permits an executor to mint new authority.
Treat the interfaces as products
Each boundary requires a versioned contract:
- control plane to outer harness: Attempt identity, manifest, scope, budgets, cancellation, completion schema, and event contract;
- outer to inner harness: session lifecycle, instructions, tools, approvals, environment, structured output, and stop behavior;
- harness to development environment: filesystem, command, process, preview, service, secret, and network interfaces;
- development environment to compute: provision, start, suspend, snapshot, measure, terminate, and reconcile; and
- Agent Factory to consumers: capability identity, version, provenance, compatibility, evaluation, policy, ownership, and lifecycle status.
Composition is valuable only when these contracts preserve the capabilities and controls the factory needs. A lowest-common-denominator adapter that drops hooks, cancellation, provenance, or tool events creates apparent portability and real operational blindness.
Distinguish build, buy, and bring-your-own boundaries
Build-versus-buy is not one decision for the whole stack. A team may buy an inner harness, build its control plane, bring its own development environment, and use managed compute. Evaluate each layer by differentiation, security, integration depth, operability, portability, cost, and exit difficulty.
8. Notes and lessons learned
- A product boundary is a commercial choice; an authority boundary is a safety and operability choice.
- The Agent Factory supplies reusable capabilities. The AI Software Factory turns governed intent into validated value using those capabilities.
- Swappability must be proven at the contract level. A generic adapter name is not evidence of behavioral parity.
9. Interview and discussion questions
- What is the difference between an AI coding agent and an AI Software Factory?
- Which responsibilities belong in the inner and outer harnesses?
- Why is the development environment separate from compute infrastructure?
- When is a vertically integrated stack the better choice?
- What evidence would demonstrate that two harnesses are safely replaceable?
- Why must an Agent Factory remain distinct from delivery authority?
Review this chapter.
Challenge a claim, boundary, missing failure mode, unclear term, or unsupported evidence statement.
- Claim
- Boundary
- Failure
- Evidence