Lou Bichard Software Factory Primitives Framework

// When should I 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 I need before applying the Software Factory Primitives 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 the Software Factory Primitives Framework?

// How do you apply the Software Factory Primitives Framework step by step?

1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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 are real-world examples of the Software Factory Primitives Framework in action?

// What are the common mistakes when building a software factory with coding agents?

• 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 Primitives 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