Models reason.
Agents act.
Selected for the exact Work Order by capability and operating constraints.
- Task and complexity fit
- Quality and risk profile
- Latency and availability
- Cost per verified outcome
Reference architecture / 02
Six areas. Explicit boundaries.
An AI software factory is a system of responsibilities. The architecture makes each responsibility visible so teams can decide what to build, buy, govern, verify, and operate.
01IntentDefine what should happen and how success will be judged.02HarnessMake execution durable, bounded, observable, and recoverable.03CapabilityPackage reusable ways for agents to act in a domain.04ModelMatch reasoning capability to the work without provider lock-in.05TrustDecide what may run, what can advance, and what requires judgment.06LearningImprove the factory from validated outcomes under change control.
Trust constrains every area. Learning closes the loop only through governed promotion. The model is replaceable; the control contract is not.
The control boundary
Intelligence can change. Authority cannot be implicit.
Models reason and agents act, but neither should own identity, permission, authoritative state, release policy, or the evidence used to judge its work. Those responsibilities belong to the factory around them.
Models reason.
The factory governs.
Durable controls remain outside the model and apply to every provider, agent, and tool.
- Identity and delegated authority
- Policy, budget, and routing
- State, leases, and recovery
- Evidence, decisions, and audit
Effects stay bounded.
Every Attempt runs inside an explicit, observable, recoverable operating envelope.
- Isolated compute
- Scoped tools and file access
- Short-lived credentials
- Network, time, and resource limits
Authority flows down →Allow intelligence to vary. Always bound authority.← Evidence flows back
Capability supply should evolve as better options emerge.
The operating record must survive every capability substitution.
Every Attempt returns attributable evidence. No producing system may promote its own result.
Capability map
Inspect each area as an operating contract.
Purpose describes why the area exists. Responsibilities and components describe what it owns. Decisions and failure modes reveal what must remain explicit.
01Architecture area
Intent
Define what should happen and how success will be judged.Turn human goals into explicit, reviewable work before execution begins.
Expand areaCollapse area
Architecture area
Intent
Define what should happen and how success will be judged.Responsibilities
- Goals and requirements
- Acceptance criteria
- Planning and decomposition
- Prioritization and specification
Common components
- Intent workspace
- Specification store
- Plan registry
- Dependency graph
Required decisions
- What outcome matters?
- What is out of scope?
- What evidence will prove success?
- Who can approve change?
Failure modes
ExpandCollapse
- Ambiguous outcomes
- Plans that are treated as disposable prompts
- Unmeasurable acceptance criteria
- Scope drift after approval
Maturity progression
ExpandCollapse
- L1Prompt
- L2Template
- L3Versioned Plan
- L4Executable specification
- L5Outcome-linked portfolio
Examples
- Dependency upgrade policy
- API migration specification
- Vulnerability remediation acceptance criteria
RelationshipIntent supplies the frozen contract that Harness executes, Trust verifies, and Learning may propose changing only through governance.
02Architecture area
Harness
Make execution durable, bounded, observable, and recoverable.Control the agent lifecycle outside the model so work survives sessions, failures, and handoffs.
Expand areaCollapse area
Architecture area
Harness
Make execution durable, bounded, observable, and recoverable.Responsibilities
- Execution loop and orchestration
- Durable state and checkpoints
- Scheduling, leases, and handoffs
- Retries, cancellation, and recovery
Common components
- Orchestrator
- Worker runtime
- State machine
- Checkpoint store
- Sandbox adapter
Required decisions
- What owns authoritative state?
- When is a lease valid?
- What may be retried?
- How is abandoned work recovered?
Failure modes
ExpandCollapse
- State trapped in chat
- Duplicate side effects
- Zombie workers
- Retry loops without new evidence
Maturity progression
ExpandCollapse
- L1Interactive session
- L2Scripted runner
- L3Durable Attempt
- L4Recoverable workflow
- L5Fleet control
Examples
- Fenced Work Order lease
- Checkpointed migration
- Restart-safe verification run
RelationshipHarness binds Intent, Capability, Model, and Trust into one exact Attempt and returns observations to Learning.
03Architecture area
Capability
Package reusable ways for agents to act in a domain.Make agents, skills, tools, context services, and interfaces versioned, discoverable, and governable.
Expand areaCollapse area
Architecture area
Capability
Package reusable ways for agents to act in a domain.Responsibilities
- Agent definitions
- Skills and tools
- MCP and APIs
- Reusable domain capability
Common components
- Capability registry
- Agent Factory
- Skill packages
- Tool gateway
- Context adapters
Required decisions
- What should be reusable?
- Which version is admitted?
- What permissions are required?
- How is capability quality evaluated?
Failure modes
ExpandCollapse
- Prompt folders without ownership
- Tool sprawl
- Implicit permissions
- Capabilities promoted without evals
Maturity progression
ExpandCollapse
- L1Ad hoc prompt
- L2Named skill
- L3Versioned package
- L4Evaluated registry
- L5Governed supply chain
Examples
- Repository research skill
- Dependency modernization agent
- Read-only issue tracker tool
RelationshipCapability is selected from Intent, admitted by Trust, run by Harness, and may use one or more Models.
04Architecture area
Model
Match reasoning capability to the work without provider lock-in.Abstract and route models by capability, quality, latency, cost, and policy.
Expand areaCollapse area
Architecture area
Model
Match reasoning capability to the work without provider lock-in.Responsibilities
- Provider abstraction
- Model selection and routing
- Capability matching
- Fallbacks and cost control
Common components
- Model catalog
- Routing policy
- Evaluation profile
- Fallback chain
- Cost ledger
Required decisions
- What capability does this work require?
- What is the risk ceiling?
- When may a fallback run?
- What result justifies the cost?
Failure modes
ExpandCollapse
- One-model monoculture
- Routing by hype
- Silent fallback
- Optimizing token price instead of outcome cost
Maturity progression
ExpandCollapse
- L1Hard-coded model
- L2Manual choice
- L3Policy routing
- L4Evidence-calibrated routing
- L5Outcome-optimized portfolio
Examples
- Low-cost documentation route
- High-reasoning architecture review
- Deterministic fallback for structured checks
RelationshipModel executes inside the Harness, uses Capability and context, and remains constrained by Trust regardless of intelligence.
05Architecture area
Trust
Decide what may run, what can advance, and what requires judgment.Keep authority outside the model and require evidence for consequential state transitions.
Expand areaCollapse area
Architecture area
Trust
Decide what may run, what can advance, and what requires judgment.Responsibilities
- Evaluation and verification
- Policy and security
- Delegated authority
- Evidence, approvals, and oversight
Common components
- Policy engine
- Identity service
- Verification plane
- Evidence store
- Approval control
Required decisions
- Who is acting for whom?
- What exact authority was delegated?
- Is the verifier independent enough?
- Is the evidence current?
Failure modes
ExpandCollapse
- Self-verification
- Permissions inferred from content
- Stale evidence
- Approval theater
Maturity progression
ExpandCollapse
- L1Trust the response
- L2Human review
- L3Policy gates
- L4Independent verification
- L5Risk-calibrated autonomy
Examples
- Exact-head PR gate
- Security scan receipt
- Human approval for production deployment
RelationshipTrust constrains every other area and separates completion, verification, approval, and release.
06Architecture area
Learning
Improve the factory from validated outcomes under change control.Turn real outcomes, failures, cost, and reviewer decisions into bounded improvement proposals.
Expand areaCollapse area
Architecture area
Learning
Improve the factory from validated outcomes under change control.Responsibilities
- Outcome and feedback capture
- Failure taxonomy
- Experiments and baselines
- Controlled improvement
Common components
- Learning-signal store
- Eval datasets
- Experiment registry
- Promotion workflow
Required decisions
- Is the signal attributable?
- What baseline should change?
- How will regression be detected?
- Who approves promotion?
Failure modes
ExpandCollapse
- Treating memory as learning
- Optimizing on model confidence
- Self-modifying production
- Unversioned prompt drift
Maturity progression
ExpandCollapse
- L1No feedback
- L2Manual lessons
- L3Structured signals
- L4Controlled experiments
- L5Governed continuous learning
Examples
- Failure becomes an eval case
- Routing change tested against a baseline
- Skill revision promoted after canary
RelationshipLearning consumes Trust-approved signals and returns proposed changes to Intent, Capability, Model, or policy—not directly to production.
Software factory concept
Authority flows down. Evidence flows back.
HumansIntent + policyOwn goals, judgment, and material risk
Control planePlan · govern · routeIdentity, authority, budget, and state
Capability supplyAgents · models · skills · tools · context
ExecutionHarness + isolated environmentAttempts, leases, checkpoints, recovery
TrustEvidence + independent verificationPolicy and human approval at consequence
OutcomeAccepted, observed valueFeeds governed learning—not direct mutation
Continue