The Missing Primitive for Agent Swarms

What would it take for coding agents to carry work from development into production without a person driving every change? That is the infrastructure question behind Lou Bichard’s exploration of subagents and swarms. Bichard introduces himself as Ona’s field CTO, with a background in principal engineering, platform engineering, and product management.

The ambition is a software factory: incrementally remove the human from actively operating each part of the software development life cycle, or SDLC. Bichard initially describes this as something everyone is trying to build, then qualifies that impression: many people he has met are not yet thinking in those terms. His definition is also narrower than one engineer operating many coding agents simultaneously. That engineer still drives the work. In a software factory, work would increasingly flow through development and into production automatically. This remains an early ambition, not a description of routine industry practice.

Bichard’s Background Agents website collects visualizations of several ways to organize coding agents. These patterns answer different questions: how to divide one task, how to distribute a change across an organization, and when to start work.

A swarm resembles the familiar parent-and-subagent pattern. A fleet broadens the scope across repositories; Bichard describes it as an existing Ona capability. Events supply the activation mechanism that a software factory needs once a human is no longer starting every task. Much of that mechanism already exists as webhook infrastructure.

Published internal systems make this infrastructure more concrete. Bichard describes Stripe’s Minions as coding agents plugged into Stripe’s existing infrastructure. Bichard reports that Minions drives thousands of pull requests inside Stripe, without specifying a time interval. He also points to Ramp’s Inspect as another internal system for running background agents. These are examples of organizations building execution infrastructure around agents, rather than treating an agent as an isolated chat session.

Ona approaches the problem through development environments. Bichard describes roughly six years of environment infrastructure, with deeper agent integration during the preceding year or two. Its fleet feature uses schedules or triggers to launch agents across repositories for work such as CVE remediation, increasing test coverage, or enforcing a common change.

The individual task may be relatively simple for current LLMs. The difficulty is applying it across thousands of teams or repositories. In the workflow interface, prompts and scripts become the ingredients for distributing that work across an organization. The scale problem therefore includes both execution and the organizational boundaries through which the change must pass.

Running an agent repeatedly only helps if the system retains what those runs teach you. Bichard points to OpenAI’s harness engineering article, by Ryan Lopopolo, as an expression of this approach: encode development process in the repository, including context files and AGENTS.md.

He treats harness engineering as an extension of context engineering. Skills, instructions, unit tests, and other repository artifacts all contribute either guidance or feedback. The practical loop is:

1. Let the agent attempt the work.
2. Find the point where it loses its way.
3. Encode the missing knowledge or feedback in the repository or context.
4. Let later runs use that feedback to proceed further through the development process.

The repository becomes part of the agent’s operating environment, not merely the code it edits.

At the infrastructure level, the factory needs four distinct capabilities:

• Runtime: somewhere for an agent to execute.
• Orchestration: a way to scale agents horizontally up and down.
• Triggers: a way to start work when an event occurs.
• Coordination: a way for agents to interact, pick up tasks from one another, and collaborate.

Bichard considers the runtime largely solved. The harder question is what happens between running agents: how they exchange responsibility and move shared work forward.

Execution can use separate threads, Git worktrees, containers, VMs, or microVMs. Ona describes its runtime units as development environments. Bichard argues for VM isolation for substantial development tasks on two grounds: security and resource contention. Containers are not, in his account, a sufficient security boundary for this use case; bursty workloads in Kubernetes pods can also compete for compute and create noisy neighbors. These are Ona’s reasons for choosing VMs, rather than guarantees that a VM alone resolves every security or capacity concern.

The Ona demonstration uses a recording made in Bichard’s hotel room the previous day, avoiding dependence on venue Wi-Fi. The interface’s left sidebar contains two tasks. The implementation exercise uses OpenAI Symphony, whose detailed repository specification gives the agent a substantial description of what to build.

The first task asks for process-based subagents: one VM contains the parent agent and the child processes it starts. The second asks the agent to create a fleet of separate VMs through the platform. In the latter arrangement, adding a worker also means provisioning another environment. Bichard describes the potential scale as bounded by spending and cloud-provider capacity.

In the VM variant, the parent spawns three subagents in separate VMs. Each child receives a limited piece of context and an individual task, then passes messages back to the controlling parent. The parent remains responsible for governing the overall implementation. This immediately creates an interface problem: as the task tree grows, users need a way to inspect and control the workers without losing the overall task.

As agents come online, their environments start and their task progress becomes visible. Both demo tasks display seven sub-items, a count Bichard notes without explaining. He describes the intended end of the lifecycle as terminating the VMs and collapsing the task display when the work finishes. The running overview shows delegation in progress; it is not a completed implementation result.

The process-level version exposes a different interaction model. Subagents appear as a stack at the bottom of a single agent window. Clicking a worker opens another chat window, giving the user access to that worker’s context. The execution remains inside the original VM even though the conversations are separated.

Both arrangements divide work among agents. Their distinction is where execution is isolated and how that structure becomes visible to the user.

Bichard’s own software-factory experiment asks whether he can build a project without touching any lines of code while making development as autonomous and self-directed as possible. He connects the experiment to Symphony and OpenAI’s harness-engineering work. His answer is that the technology can support this kind of attempt, but doing so exposes complexity that a conventional lifecycle diagram hides.

A five-stage SDLC is a useful human summary, but it is too coarse to specify everything an agent must do. Planning alone contains many smaller steps. The expanded Plan slide makes that visible through ticket breakdown, dependencies, and scope, each with a corresponding gate. An agent needs more than the name of the stage: it needs the work inside that stage broken into actionable steps.

This decomposition applies throughout the lifecycle. The engineering problem is then to make agents follow those steps reliably and make progression sufficiently deterministic. Starting another worker does not establish that its prerequisites were satisfied, or that the previous worker actually finished the required work.

Context makes that reliability difficult. As the context window fills, Bichard describes agents losing track of their direction and becoming less effective—context rot. They may also skip required steps. His example is an agent asked to write tests that omits some testing while trying to finish the task, behavior he connects to sycophancy and the desire to satisfy the request.

Once runtimes and orchestration exist, these failures become coordination problems. GitHub can hold the pull request, but a human may still need to review it, resolve a merge conflict, and repair CI. Across many agents, those signals become overwhelming: the person supervising the system has to work out where intervention is actually necessary. Bichard therefore argues that GitHub is a poor agent coordination layer.

He makes a similar criticism of using Linear underneath Symphony: tools designed for human work tracking are being stretched into agent coordination systems. The issue is not whether they can record tasks. It is whether they give agents and their supervisors a sufficiently precise way to manage progress through the development process.

Bichard proposes combining several established ideas into a coordination layer:

• State machines represent the workflow and its allowed progression through the SDLC.
• Durable execution contributes mechanisms for maintaining a process over time.
• Gates and compliance checks determine whether work may proceed.
• CLI packaging makes the machinery available both in a local development environment and remotely in CI.

This is a proposed direction, not a demonstration of a finished coordination product. Its purpose is to put the lifecycle’s rules somewhere an agent can invoke them, rather than relying entirely on its current conversation to remember and obey them.

The intended human role is on the loop: able to supervise and intervene without driving every individual change. Bichard identifies context management as the hardest part of building this system. He regards runtime, orchestration, and triggers as effectively solved primitives, with coordination still missing. Security remains a separate obstacle to increasing automation, even after an execution environment has been chosen.

To make these ideas more concrete, Bichard announces a May 6 virtual summit on software factories and background agents, with attendance information and a call for proposals on his Background Agents site. He invites people already experimenting with these systems to contribute. Responding to feedback that software-factory talks are too theoretical, he also announces a plan to build one from scratch in public with Zach from Ona, starting the following week and running for two weeks. These are plans announced at the event, intended to expose the actual workflows and their rough edges.

An audience question asks for a more concrete remedy for coordination and memory problems. Bichard says Ona has several internal prototypes. He describes graph-based workflows, with prompts attached to a structure resembling Mermaid diagrams or n8n workflows, but favors packaging the capability as a CLI.

A local coding agent such as Claude Code would invoke that CLI through its tools. The operation would answer two related questions: has the agent achieved the current part of the SDLC, and may it proceed to the next part? This is the concrete shape of the proposed gateway: advancement becomes a checked operation rather than an agent’s declaration that it is done.

For example, a small TypeScript gate can express the distinction between requesting advancement and being allowed to advance. Here, a test run has been requested but its evidence is still pending, so the state remains test:

type Stage = "test" | "review";
type TestEvidence = "pending" | "failed" | "passed";

type WorkItem = {
  id: string;
  stage: Stage;
  tests: TestEvidence;
};

function requestReview(item: WorkItem): {
  item: WorkItem;
  allowed: boolean;
  reason: string;
} {
  if (item.stage !== "test" || item.tests !== "passed") {
    return {
      item,
      allowed: false,
      reason: "Advancement requires passing test evidence.",
    };
  }

  return {
    item: { ...item, stage: "review" },
    allowed: true,
    reason: "Test gate satisfied.",
  };
}

const work: WorkItem = {
  id: "coverage-change",
  stage: "test",
  tests: "pending",
};

console.log(JSON.stringify(requestReview(work), null, 2));

This illustrates the gateway’s decision boundary, not Bichard’s internal implementation. A real coordinator would also need a trustworthy source of evidence and a way to persist the transition. The agent’s request alone cannot establish that the gate has been satisfied.

Bichard offers to share a full specification after the talk. He places his CLI gateway alongside graph workflows and other interim approaches, rather than presenting one settled design. He tentatively names OpenClaw’s acpx, built on ACP, and mentions a nascent project called Fabro. These references describe the emerging landscape; they do not establish that his prototype uses either project. His response makes the workflow interface more concrete, but does not describe a memory-storage or retrieval mechanism.

The final question asks whether the CLI uses a protocol such as ACP or A2A. Bichard says his implementation does not currently use an agreed protocol. He is still deciding whether to release an implementation or a standard, and is more interested in collaborating on the standard than in the particular implementation. ACP remains a possible future foundation, but the prototype is not built on it at the time of the talk.

Asked explicitly about A2A, he confirms that the prototype does not use that either. He sees the gateway as addressing a somewhat different problem space. The unresolved contract is how an agent establishes that development work has reached a valid state and obtains permission to continue. That is the missing primitive the talk leaves open for collaboration.