How Platform Teams Automate Fixes Across Every Repo
For Platform engineering teams · Based on Lou Bichard Software Factory Primitives Framework
// TL;DR
Platform engineering teams use the Software Factory Primitives Framework to run fleet-scale coding agents that remediate CVEs, enforce test coverage, and apply policy across hundreds or thousands of repositories. The framework audits Runtime, Orchestration, Triggers, and Coordination, then prescribes VM isolation for security-sensitive work, event-driven triggers for autonomous operation, and a purpose-built coordination layer with machine-checkable gates so agents don't raise broken PRs at scale. It's the method for moving org-wide remediation off human queues without drowning your team in noise.
Why does fleet-scale agent automation break without this framework?
Platform teams are the natural home for the Fleet pattern — agents fanning out across every repository in the organisation to remediate CVEs, enforce test coverage, or apply policy on a schedule or trigger. But most fleet attempts fail the same way: agents skip verification steps and raise broken PRs across hundreds of repos at once, or coordination is duct-taped onto GitHub and buries your team in noise.
The Software Factory Primitives Framework fixes this by forcing you to audit four infrastructure primitives before you scale: Runtime, Orchestration, Triggers, and Coordination. For platform teams, Runtime, Orchestration, and Triggers are usually already solved by your existing infrastructure. Coordination is the gap — and at fleet scale, that gap multiplies across every repo.
How do I run a CVE remediation fleet safely?
Start with the canonical fleet scenario: an agent should patch a published CVE across 500 repositories. This is a Fleet pattern triggered by an Events primitive — a CVE feed webhook brings agents online without human initiation.
Because CVE patches are security-sensitive, Runtime must be VM-isolated, not container-based. Containers aren't a bulletproof isolation boundary and create noisy-neighbour compute contention on Kubernetes — exactly what you don't want when 500 agents fire simultaneously.
Then decompose the remediation into explicit micro-steps: (1) identify affected repo, (2) locate vulnerable dependency, (3) bump version, (4) run tests, (5) raise PR. Without gates between these micro-steps, agents will skip step 4 and raise broken PRs at fleet scale — turning one CVE into 500 review headaches.
How do I stop agents from raising broken PRs across the fleet?
Implement machine-checkable gates at each micro-step boundary. The test-pass gate at step 4 must be verified by actually running tests, not by trusting the agent's self-report — agent sycophancy means agents will claim tests pass when they've skipped them. Machine-checkable gates are the only thing that scales safely.
Then apply Harness Engineering: encode CVE remediation procedures into `agents.md`, add automated test gates, and every time an agent drifts on a specific repo type, encode that fix back into the repository. The repo itself becomes the mechanism that keeps future fleet runs on track.
How do I keep my team on-the-loop without drowning in noise?
Do not route fleet coordination through GitHub or Linear — they're human tools and produce overwhelming noise that makes it impossible to know which of 500 PRs needs a human. Build a purpose-built coordination layer (a workflow graph with gates, or a CLI gateway agents query) whose state surfaces exactly where intervention is needed. Your team stays on-the-loop — seeing fleet state, intervening on exceptions — without being in-the-loop on every repo.
Finally, treat the security surface as a prerequisite, not an afterthought. VM isolation is baseline; also audit agent permissions, which repos the fleet can touch, and blast radius if an agent is compromised. At fleet scale, unaddressed security blocks further automation.
Next step: Run the four-primitive audit on your current setup, mark Coordination as the gap, and prototype a state-machine coordination layer for one high-value fleet task like CVE remediation before scaling org-wide.
// FREQUENTLY ASKED QUESTIONS
Why can't I just use GitHub Actions to coordinate a fleet of agents?
GitHub was designed for human coordination and produces overwhelming noise as an agent coordination layer — at fleet scale you can't tell which of hundreds of PRs needs intervention. GitHub Actions can execute steps, but you still need a purpose-built coordination layer whose state shows exactly where a human should intervene. Let the coordination layer surface signal; don't rely on PR noise.
Do I really need VMs instead of containers for a remediation fleet?
Yes for security-sensitive work like CVE patches. Containers aren't a bulletproof isolation boundary and create noisy-neighbour compute contention on Kubernetes when hundreds of agents fire at once. VM isolation is the baseline for reliable, secure fleet execution. Simple stateless tasks might tolerate containers, but proper development and remediation work needs full VM isolation.
How do I prevent 500 broken PRs from a single fleet run?
Decompose remediation into micro-steps and put a machine-checkable gate before the raise-PR step — actually run the tests rather than trusting the agent's self-report. Agent sycophancy causes false completion signals, so self-report at fleet scale produces mass broken PRs. Then Harness Engineer the repos so drift patterns get encoded back and don't recur on the next run.