Frequently Asked Questions About Lou Bichard Software Factory Primitives Framework
22 answers covering everything from basics to advanced usage.
// Basics
What exactly makes something a software factory versus just automation?
A software factory is defined by the commitment to incrementally moving the human out of the loop within the SDLC, such that work flows from development into production without a human proactively interacting with a computer. Generic automation might speed up individual tasks, but a software factory is about the human not being required to drive each step. If a human still orchestrates every agent, it's not a factory.
What is the coordination layer and why is it called the missing primitive?
The coordination layer is the infrastructure that enables agents to interact, pick up tasks from each other, gate progress through SDLC micro-steps, and collaborate. It's the missing primitive because Runtime, Orchestration, and Triggers are largely solved by existing tooling, but almost no one has built a purpose-built layer for agent-to-agent coordination. Most teams try to bolt this onto human tools like GitHub, which fails.
What are micro-steps and why do agents need them?
Micro-steps are the granular, discrete sub-actions within each coarse SDLC stage that agents must explicitly follow. The canonical five-step SDLC (plan, build, test, review, deploy) is too coarse — agents don't respect or understand the coarse boxes, so they skip steps and fail to proceed deterministically. Micro-steps make each stage explicit and gate-able, and they form the backbone of any coordination layer.
What is Harness Engineering?
Harness Engineering is 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 the agent, identify where it gets lost, and encode that knowledge back into the repository so the same failure doesn't repeat and the repo continuously improves the agent.
// How To
How do I audit my current agent setup against the four primitives?
For each primitive — Runtime, Orchestration, Triggers, Coordination — mark it 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 designing anything, because building the wrong primitive wastes effort.
How do I decompose an SDLC stage into micro-steps?
Take each coarse stage in scope, for example 'Plan', and list every discrete action an agent must execute within it — parse spec, identify components, write task list. Write these as a sequence, not a box. Do this for every stage: Build (scaffold, implement each component, integration), Test (unit, integration, edge cases). This decomposition becomes the sequence your coordination layer gates against.
How do I build a coordination layer in practice?
There are three viable form factors. Build a state machine or workflow graph defining SDLC micro-steps with gates (N8N-style or Mermaid-compatible). Or build a CLI gateway — a CLI tool a local agent like Claude Code invokes as a tool call to ask 'Have I completed this stage? May I proceed?' Or borrow durable execution patterns so the process survives interruptions. Avoid reusing GitHub or Linear.
How do I implement gates that agents can't cheat?
At each micro-step boundary, define a pass/fail gate that is machine-checkable rather than based on agent self-report — tests pass, lint clean, spec validated. This is critical because agent sycophancy causes false completion signals: agents will claim they've written all tests when they've skipped some. Machine-checkable gates prevent step-skipping and stop broken work from flowing downstream at scale.
How do I choose between swarm, fleet, and event patterns for my scale?
Single repo, single task points to Swarm — one intent, sub-agents, results funnel to one PR. Cross-repo at org scale points to Fleet — agents fan across repositories on schedules or triggers, good for CVE remediation or coverage enforcement. Event-driven background work points to Events — webhooks trigger agents without human initiation. Your setup may use all three simultaneously depending on the workload.
// Troubleshooting
My agents keep skipping the test step — how do I fix it?
This is coarse-grained SDLC and missing gates. Decompose the test stage into explicit micro-steps (unit, integration, edge cases) and add a machine-checkable gate that blocks the agent from proceeding until tests actually pass — don't trust the agent's self-report. Then apply Harness Engineering: identify where the agent drifts and encode the requirement into agents.md and unit tests inside the repository.
My agents lose track of goals partway through tasks — what's wrong?
That's context rot — as the context window fills, the agent loses track of goals, skips steps, and degrades. It's the hardest part of building a software factory. The fix isn't a bigger context window; it's Harness Engineering. Run the agent, find the exact micro-step where it drifts, and encode guardrails back into the repository via context files, skills, and unit tests so it stays on track.
Coordinating my agents through GitHub is chaotic — how do I fix the noise?
You're hitting the reusing-human-tools antipattern. GitHub and Linear were built for human coordination and produce overwhelming noise as an agent coordination layer, making it impossible to know when to intervene. Audit the primitives (Runtime, Orchestration, Triggers likely fine; Coordination broken), then build a purpose-built layer — a workflow graph with gates or a CLI gateway. Human visibility should come from that layer's state, not PR noise.
My agents fail unpredictably at scale — could it be the runtime?
Likely, if you're running containers. Containers aren't a bulletproof isolation boundary and create noisy-neighbour compute contention on Kubernetes, causing intermittent failures at scale. For proper development tasks with security requirements, move to full VM isolation or dev environments. Containers or work trees are fine for simple stateless tasks, but real dev work needs VMs to be reliable and secure.
// Comparisons
How does this framework compare to a generic multi-agent orchestration setup?
Generic multi-agent orchestration focuses on spinning up and coordinating agents, but usually keeps a human orchestrating and treats the SDLC as coarse boxes. This framework explicitly separates the four primitives, names Coordination as the missing one, and demands micro-step decomposition with machine-checkable gates. It targets true human-out-of-the-loop flow, not just parallelism, and treats context rot and Harness Engineering as first-class problems.
How is Harness Engineering different from prompt engineering?
Prompt engineering optimizes the instructions you give an agent in a single interaction. Harness Engineering is broader — it encodes everything in the repository that could give feedback to an agent (agents.md, skills, context files, unit tests) as a continuous loop: run the agent, find where it gets lost, encode the fix back into the repo. It's about the repository itself continuously improving agent performance, not one-off prompts.
Is a software factory the same as CI/CD?
No. CI/CD automates build, test, and deploy pipelines that humans still author and trigger through code and configuration. A software factory goes further — it incrementally removes the human from authoring and driving the SDLC itself, so agents plan, build, test, and progress work autonomously through gated micro-steps. CI/CD gates can be part of a software factory's coordination layer, but the factory encompasses the whole agentic lifecycle.
How does the swarm pattern differ from the fleet pattern?
Swarm starts with a single intent, fans it to multiple sub-agents, and funnels results back into a single output like one PR — a parent agent governs sub-agents via message passing within one task. Fleet fans agents out across multiple repositories simultaneously inside an organisation, driven by schedules or triggers. Swarm is depth within a task; Fleet is breadth across repos. Use cases like CVE remediation are fleet-scale.
// Advanced
How do I design UX for human oversight without becoming a bottleneck?
Put humans on-the-loop, not in-the-loop — able to see state and intervene when needed, but not required to drive each step. Build visibility into sub-agent activity (parent plus 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's happening. Otherwise you recreate the GitHub noise problem and re-bottleneck the human.
What durable execution patterns apply to a coordination layer?
Durable execution ensures the coordination process survives interruptions — if an agent crashes or a step fails mid-flight, the workflow resumes from its last committed state rather than restarting. Borrowing these patterns for your coordination layer makes long-running, multi-step SDLC flows reliable across failures. It's one of three viable coordination form factors alongside a state machine/workflow graph and a CLI gateway.
How do I address the security surface when scaling to fleet automation?
Security is a prerequisite for moving the human further out of the loop, not an afterthought. VM isolation is the baseline. Then audit what permissions agents have, which repositories the fleet can touch, and what happens if an agent is compromised. Automation at scale increases the attack surface, so unaddressed security will either block further automation or create unacceptable risk. Treat it during design, not after incidents.
Can I use all three scale patterns in one system?
Yes. A setup may combine all three. For example, a CVE feed webhook (Events) triggers agents that fan across 500 repositories (Fleet), and within each repo a single remediation intent fans to sub-agents that funnel a fix into one PR (Swarm). The patterns are composable — Events initiate, Fleet distributes breadth, and Swarm handles depth within each task, all coordinated by the same gated micro-step layer.
What's the right order to build the four primitives?
Assess them in order — Runtime, Orchestration, Triggers, Coordination — but you rarely build the first three from scratch since they're largely solved. Confirm Runtime (choose VM vs container based on security needs), verify Orchestration and Triggers exist, then invest almost all your design effort in Coordination, since that's the gap. Building Coordination without settled Runtime and Triggers means you'll gate steps that can't reliably execute.