Lou Bichard Software Factory Primitives Framework
Diagnose exactly which infrastructure primitive is blocking your agentic coding pipeline and prescribe the right coordination layer to move humans out of the SDLC loop.
// TL;DR
The Lou Bichard Software Factory Primitives Framework is a diagnostic method for building systems of coding agents that move humans out of the software development lifecycle. It audits four infrastructure primitives — Runtime, Orchestration, Triggers, and Coordination — and identifies Coordination as the almost-always-missing layer. Use it when designing, auditing, or scaling agent swarms across an SDLC, especially when agents lose context, skip steps, or can't hand off work. It decomposes coarse SDLC stages into gated micro-steps, prescribes swarm/fleet/event patterns by scale, and uses Harness Engineering to fight context rot.
// When should you use the Software Factory Primitives Framework?
Use this skill when designing, auditing, or scaling a system of coding agents across a software development lifecycle — especially when agents are losing context, skipping steps, or there is no clear mechanism for agents to hand off work, gate progress, or coordinate across tasks and repositories.
// What information do you need before applying this framework?
- current_agent_setuprequired
Describe what coding agents you are running today (e.g. Claude Code, Cursor, custom agents) and how they are triggered. - sdlc_scoperequired
Which stages of the SDLC are you trying to automate — plan, build, test, review, deploy, or a subset? - scale_targetrequired
Are you automating across a single repo, multiple repos, or thousands of repositories (fleet scale)? - human_involvement_todayrequired
Describe where and how frequently humans are currently intervening in the pipeline. - coordination_tooling
What tools are you currently using to coordinate agents — GitHub, Linear, custom dashboards, etc.? - runtime_environment
Are agents running in threads, containers, VMs, or dev environments?
// What are the core principles behind building a software factory?
Software Factory Definition
A software factory is the commitment to incrementally moving the human out of the loop within the SDLC, such that the human is not proactively interacting with a computer. Work flows from development into production in an automated fashion. Parallel agents with a human still orchestrating each one is NOT a software factory.
The Four Primitives
Every software factory requires four infrastructure primitives in order: Runtime (somewhere for the agent to run), Orchestration (scale up/scale down agents horizontally), Triggers (events that bring agents online), and Coordination (how agents interact, pick up tasks from each other, and collaborate). The first three are largely solved; Coordination is the missing primitive.
Coarse-Grained SDLC Is a Trap
The canonical five-step SDLC (plan, build, test, review, deploy) is too coarse for agents. Each stage contains a large number of micro-steps. Agents don't respect or understand the coarse boxes — they skip steps, lose context, and fail to proceed deterministically unless the SDLC is decomposed into explicit micro-steps that can be gated.
Context Rot
As a context window fills, the agent degrades — it loses track of goals, skips steps, and becomes less effective. Context management is by far the hardest part of building a software factory. Harness Engineering is the practice of encoding everything possible back into the repository (skills, agents.md, unit tests, context files) to keep agents on track.
Harness Engineering
An extension of context engineering: everything in your repository — from skills to agents.md to unit tests — that could possibly give feedback to an agent is harness material. The loop is: let the agent run, identify where it gets lost, encode that knowledge back into the repository or context to keep it flowing through the software factory.
Swarm vs Fleet vs Events
Three distinct scale patterns exist. Swarm: one intent fans out to multiple sub-agents that funnel results back into a single PR or task. Fleet: agents fan out across multiple repositories simultaneously inside an organisation. Events: webhook-style triggers (PR raised, ticket created) that bring agents online without human initiation.
VM Isolation Principle
For proper development tasks, agents must run inside virtual machines, not just containers. Containers are not a bulletproof isolation boundary for security; they also create noisy-neighbour compute contention on Kubernetes. Only full VM isolation enables secure, reliable agent execution at scale.
Reusing Human Tools for Agents Is a Poor Solution
Tools like GitHub and Linear were designed for human coordination. Using them as an agent coordination layer produces overwhelming noise and makes it nearly impossible for humans to know when and where to intervene. A purpose-built coordination layer is required.
// How do you apply the Software Factory Primitives Framework step by step?
- 1
Audit the four primitives against the current setup
For each primitive — Runtime, Orchestration, Triggers, Coordination — assess whether it is solved, partial, or missing. Runtime is usually solved (threads, containers, VMs, dev environments). Orchestration is usually solved (horizontal scale, spin up/down). Triggers are usually solved (webhooks, PR events, ticket creation). Coordination is almost always the gap. Mark the gap clearly before proceeding.
- 2
Define the software factory boundary
Confirm whether the goal is true software factory (human removed from the loop, work flows to production autonomously) or parallel-agent assistance (human still orchestrating). Do not conflate the two. If the goal is true software factory, scope which SDLC stages are in play.
- 3
Decompose each SDLC stage into micro-steps
Take each coarse stage in scope (e.g. 'Plan') and list every discrete micro-step an agent must execute within it. Agents will skip steps if micro-steps are not explicit. Write these down as a sequence, not a box. This decomposition becomes the backbone of your coordination layer.
- 4
Select the swarm pattern appropriate to scale target
Single repo, single task → Swarm pattern (one intent, sub-agents, results funnel back to one PR). Cross-repo at org scale → Fleet pattern (agents fan across repositories on schedules or triggers). Event-driven background work → Events pattern (webhooks trigger agents without human initiation). A setup may use all three.
- 5
Choose a runtime isolation level
For simple, stateless tasks: threads or work trees may suffice. For real development tasks with security requirements or compute-intensive workloads: VMs or dev environments are required. Do not use containers as the isolation boundary for secure agent execution — noisy-neighbour problems and insufficient isolation will cause failures at scale.
- 6
Design the coordination layer for the micro-step sequence
This is the missing primitive — build it explicitly. Three viable form factors: (1) State machine / workflow graph — define the SDLC micro-steps as a graph (e.g. N8N-style workflow diagrams, Mermaid-compatible), with gates between steps. (2) CLI gateway — a CLI tool that a local running agent (Claude Code, etc.) can invoke as a tool call to ask 'Have I completed this SDLC stage? May I proceed to the next?' (3) Durable execution — borrow durable execution patterns to ensure the process survives interruptions. Avoid reusing GitHub or Linear as the coordination layer.
- 7
Implement gates and compliance checkpoints
At each micro-step boundary, define what constitutes a pass/fail gate before the agent proceeds. This is how you prevent step-skipping and sycophantic behaviour (agents claiming completion without actually finishing). Gates should be machine-checkable where possible (e.g. tests pass, lint clean, spec validated) rather than relying on agent self-report.
- 8
Apply Harness Engineering to encode process back into the repository
Run agents through the pipeline. Identify exactly where context rot causes the agent to lose track or skip steps. Encode fixes back into agents.md, context files, skills, and unit tests inside the repository. Repeat. The goal is that the repository itself continuously improves the agent's ability to flow through the software factory without human intervention.
- 9
Design the UX for human oversight without human bottlenecking
Humans should be on-the-loop (able to see state, intervene when needed) but not in-the-loop (not required to drive each step). Build visibility into sub-agent activity (parent agent + sub-agent status, task lists) but resist routing all coordination noise back through human-facing tools. The UX must show where to intervene, not everything that is happening.
- 10
Identify and address the security surface
Automation at scale increases the security attack surface. VM isolation is the baseline. Additionally audit: what permissions do agents have, what repositories can the fleet touch, what happens if an agent is compromised. Security is a prerequisite for moving the human further out of the loop, not an afterthought.
// What does this framework look like in real scenarios?
A platform engineering team wants agents to automatically remediate CVEs across 500 repositories whenever a new vulnerability is published.
This is a Fleet pattern triggered by an Events primitive (CVE feed webhook). Runtime must be VM-isolated to handle the security sensitivity of CVE patches. The coordination layer needs a state machine that gates each micro-step: (1) identify affected repo, (2) locate vulnerable dependency, (3) bump version, (4) run tests, (5) raise PR. Without explicit micro-step gates, agents will skip test verification and raise broken PRs at scale. Harness Engineer the repo by encoding CVE remediation procedures into agents.md and adding automated test gates at step 4.
A startup is trying to build a software factory for a single product repo — they want agents to take a spec, implement it, write tests, and get it to a reviewable PR with minimal human involvement.
This is a Swarm pattern. Decompose the SDLC into micro-steps within each stage: Plan has sub-steps (parse spec, identify components, write task list); Build has sub-steps (scaffold, implement each component, integration); Test has sub-steps (unit, integration, edge cases). Design a CLI gateway tool that the agent calls at each micro-step boundary to confirm completion before proceeding. Context rot will be the primary failure mode — when it occurs, identify the specific micro-step where the agent drifts and encode guardrails back into the repository via Harness Engineering.
An organisation is using GitHub and Linear to try to coordinate a group of coding agents and finding it chaotic — humans don't know when to intervene and the signal-to-noise ratio is terrible.
This is the 'reusing human tools for agents' antipattern. GitHub and Linear are not coordination layers for agents. Audit the four primitives: Runtime ✓, Orchestration ✓, Triggers ✓, Coordination ✗. The fix is to build a purpose-built coordination layer — either a workflow graph defining SDLC micro-steps with machine-checkable gates, or a CLI gateway that agents query to validate stage completion. Human visibility should come from the coordination layer's state, not from GitHub PR noise.
// What mistakes should you avoid when building agent swarms?
- Confusing 'parallel agents with a human orchestrating' with a true software factory. A software factory requires incrementally removing the human from the loop — not just running more agents simultaneously.
- Treating the five-step SDLC as sufficient for agent instruction. Agents do not respect coarse-grained SDLC boxes and will skip steps. You must decompose every stage into explicit micro-steps.
- Using GitHub or Linear as the agent coordination layer. These are human tools and produce overwhelming noise that makes it impossible to know when to intervene.
- Running agents in containers and assuming that is sufficient isolation. Containers are not a bulletproof security boundary and create noisy-neighbour compute contention at scale. Use VMs for proper development tasks.
- Ignoring context rot. As context windows fill, agents degrade and skip steps. Failing to identify and encode fixes back into the repository via Harness Engineering means the same failures repeat.
- Agent sycophancy causing false completion signals. Agents will claim to have completed steps (e.g. written all tests) when they have skipped some. Gates must be machine-checkable, not based on agent self-report.
- Skipping the security surface when scaling automation. Increasing agent autonomy and fleet scale without addressing security is a prerequisite failure — it will block further automation or create unacceptable risk.
- Confusing the sandbox/container conversation with proper dev environments. For agent-driven development tasks, the runtime must be a full virtual machine, not merely a sandbox or container.
// What are the key terms in the software factory framework?
- Software Factory
- The commitment to incrementally moving the human out of the loop within the SDLC, such that the human is not proactively interacting with a computer and work flows from development into production in an automated fashion.
- The Four Primitives
- The four infrastructure components every software factory requires: Runtime, Orchestration, Triggers, and Coordination. The first three are largely solved; Coordination is the missing primitive.
- Coordination Layer
- The missing primitive — the infrastructure that enables agents to interact with each other, pick up tasks from each other, gate progress through SDLC micro-steps, and collaborate. Distinct from runtime, orchestration, and triggers.
- Swarm Pattern
- Starting with a single intent, fanning it out to multiple sub-agents, and funneling results back into a single output (e.g. one PR or one task). A parent agent governs sub-agents via message passing.
- Fleet Pattern
- Fanning agents out across multiple repositories simultaneously inside an organisation, driven by schedules or triggers. Use cases include CVE remediation, test coverage enforcement, or policy application at org scale.
- Events Pattern
- Webhook-style triggers (PR raised, ticket created, CVE published) that bring agents online without human initiation, enabling background autonomous operation.
- Harness Engineering
- An extension of context engineering: encoding everything in a repository — agents.md, skills, context files, unit tests — that could give feedback to an agent, in order to keep it flowing through the software factory. The loop is: run agent, identify where it gets lost, encode fixes back into the repository.
- Context Rot
- The degradation of agent performance as the context window fills — the agent loses track of goals, skips steps, and becomes less effective. Identified as the hardest part of building a software factory.
- Micro-Steps
- The granular, discrete sub-actions within each coarse SDLC stage that agents must explicitly follow. Agents skip steps without these being defined; they are the backbone of any coordination layer.
- CLI Gateway
- A proposed coordination layer form factor: a CLI tool that a locally running agent can invoke as a tool call to verify 'Have I completed this SDLC micro-step?' and receive a gate signal to proceed or not.
- Background Agents
- Agents running autonomously without active human interaction, triggered by events and operating within a software factory infrastructure.
- Dev Environment (as runtime)
- Owner's term for a full virtual machine used as the agent runtime, providing proper security isolation and eliminating noisy-neighbour compute contention — contrasted with containers or sandboxes.
// FREQUENTLY ASKED QUESTIONS
What is a software factory in AI agent engineering?
A software factory is the commitment to incrementally moving the human out of the loop within the SDLC, so work flows from development into production automatically without a human proactively driving each step. Running many parallel agents while a human still orchestrates each one is NOT a software factory — that's parallel-agent assistance. The distinction matters because a true factory requires purpose-built coordination infrastructure, not just more agents.
What are the four primitives of a software factory?
The four infrastructure primitives are Runtime (somewhere for the agent to run), Orchestration (scaling agents up and down horizontally), Triggers (events that bring agents online), and Coordination (how agents interact, hand off tasks, and collaborate). The first three are largely solved by existing tooling. Coordination is the missing primitive — the one almost every agent pipeline lacks and the most common bottleneck when scaling.
How do I know if coordination is what's blocking my agent pipeline?
Audit each of the four primitives as solved, partial, or missing. If your agents run fine, scale up and down, and are triggered by events but still skip steps, lose context, can't hand off work, or produce chaotic signal when coordinated through GitHub or Linear — coordination is your gap. It's missing in almost every setup, so if you haven't explicitly built a coordination layer, you likely don't have one.
How do I stop agents from skipping steps in the SDLC?
Decompose each coarse SDLC stage (plan, build, test, review, deploy) into explicit micro-steps and put machine-checkable gates between them. Agents don't respect coarse boxes — they skip steps and lose context. Define pass/fail gates (tests pass, lint clean, spec validated) that don't rely on agent self-report, since agent sycophancy causes false completion signals. This micro-step sequence becomes the backbone of your coordination layer.
How does this framework compare to just running parallel agents?
Parallel agents keep a human orchestrating each one, which the framework explicitly says is NOT a software factory. This framework instead builds a coordination layer that lets agents hand off work, gate progress, and coordinate without a human driving each step. The goal is human on-the-loop (able to intervene) rather than in-the-loop (required to drive), which parallel-agent setups never achieve.
When should I use the Software Factory Primitives Framework?
Use it when designing, auditing, or scaling a system of coding agents across a software development lifecycle. It's especially valuable when agents are losing context, skipping steps, or when there's no clear mechanism for agents to hand off work, gate progress, or coordinate across tasks and repositories. It applies whether you're automating a single repo or thousands of repositories at fleet scale.
What is context rot and why does it break agent pipelines?
Context rot is the degradation of agent performance as the context window fills — the agent loses track of goals, skips steps, and becomes less effective. It's identified as the hardest part of building a software factory. The fix is Harness Engineering: run the agent, find where it drifts, and encode that knowledge back into the repository via agents.md, skills, context files, and unit tests to keep the agent flowing.
Should I run coding agents in containers or virtual machines?
Use full virtual machines for proper development tasks, not just containers. Containers aren't a bulletproof security isolation boundary and create noisy-neighbour compute contention on Kubernetes at scale. Threads or work trees may suffice for simple stateless tasks, but real development work with security requirements or heavy compute needs VM isolation to run securely and reliably at scale.
Why is using GitHub and Linear to coordinate agents a bad idea?
GitHub and Linear were designed for human coordination, so using them as an agent coordination layer produces overwhelming noise that makes it nearly impossible for humans to know when and where to intervene. You need a purpose-built coordination layer — a workflow graph with gated micro-steps, a CLI gateway agents query, or durable execution — where human visibility comes from the coordination layer's state, not PR noise.
What results can I expect after building a proper coordination layer?
You get agents that flow through SDLC micro-steps deterministically, stop skipping steps, and hand off work without a human driving each stage. Machine-checkable gates prevent false completion signals from agent sycophancy. Humans move from in-the-loop to on-the-loop — seeing state and intervening only when needed. At scale, you can run swarms, fleets, and event-driven agents that move work toward production autonomously.
What is the difference between swarm, fleet, and event patterns?
Swarm fans one intent out to multiple sub-agents that funnel results back into a single PR or task. Fleet fans agents across multiple repositories simultaneously inside an organisation, driven by schedules or triggers — good for CVE remediation or policy enforcement. Events use webhook-style triggers (PR raised, ticket created) to bring agents online without human initiation. A single system may use all three patterns together.