# Build your Software Agent Factory A software agent factory turns a backlog into pull requests with no one at the keyboard. Each ticket gets its own disposable workspace and its own headless agent. The factory, not the agent, runs the tests, sends failures back, and gives up after a fixed number of tries. The only thing that reaches a person is a verified pull request to review. You manage the work instead of steering it. This talk covers the two building blocks, headless agents and sandboxes, and the orchestration that joins them. Fife, an open-source demo, is the worked example. By Mathew Mathew ยท Claramap Presentation: https://presentations.claramap.com/agentsandboxes/ ## Questions and answers ### What is a software agent factory? A software agent factory turns a backlog into pull requests with no one at the keyboard. Each ticket gets its own disposable workspace and its own headless agent. The factory, not the agent, runs the tests, sends failures back, and gives up after a fixed number of tries. The only thing that reaches a person is a verified pull request to review. You manage the work instead of steering it. ### What is a headless coding agent? A coding agent started by a program instead of a person. The program supplies the task, the context, the tools, the permissions and the limits, then collects the result. The agent still plans, edits files and runs tools. Headless describes how the run starts and ends, not what the agent can do. ### Why does a coding agent need a sandbox? Because it runs commands. A sandbox gives each run its own files, processes and network policy, so concurrent jobs cannot touch each other or your machine. How strong the boundary is depends on the mechanism. A sandbox limits what a bad run can reach; it says nothing about whether the code is right. ### What does Fife demonstrate? Fife is a GitHub-issue-to-pull-request line. Label an issue `agent`; Fife clones the repository into a fresh Modal sandbox, runs Claude Code headless with the issue text, runs the test script itself, feeds failures back to the same session for up to three rounds, and opens a pull request. The sandbox receives a Claude credential and never the GitHub token. Agents never merge. ## 01. Build your Software Agent Factory Tickets in, pull requests out. Delegating a bounded piece of work means you stop watching every step. The rest of the talk is what it takes to make that safe: a worker a program can start, a place it can run, and a gate it has to pass. ## 02. Evolution of AI development From chat to terminal to parallel agents to factories. - Chat: ask, copy, paste. - Terminal: one agent, you steer every step. - Parallel local agents: worktrees and YOLO mode, several agents sharing your machine. - Agent factory: a separate workspace per ticket, pull requests out. - Swarms: agents that divide and coordinate work. Not built here; it is where this goes next. Each step hands the agent more of the loop and keeps you for the review. The jump that matters is the fourth. Once a program can both start the agent and provision its workspace, every ticket can become a run. ## 03. Two concepts for your agent factory Headless agents are how a program starts the worker. Sandboxes are where the worker runs. The next four slides take each in turn, then join them. ## 04. Sandboxes The boundary you get depends on the mechanism. | Mechanism | What isolates | Shares | | --- | --- | --- | | Bubblewrap | Unprivileged Linux namespaces, no daemon | The host kernel | | Docker | Namespaces and cgroups, images, seccomp defaults | The host kernel | | MicroVMs (Firecracker) | KVM with a minimal device model | The hypervisor only | | Traditional VMs | A full guest OS under a hypervisor | The hypervisor only | Namespaces are cheap and fast and share the kernel, so a kernel bug is a shared bug. MicroVMs put a hardware boundary under each run and still boot in under a second. Pick by what the agent is allowed to do, then set the network policy, because the mechanism is only part of the boundary. - [Bubblewrap](https://github.com/containers/bubblewrap) - [Docker containers](https://docs.docker.com/get-started/docker-concepts/the-basics/what-is-a-container/) - [Firecracker](https://firecracker-microvm.github.io/) ## 05. Sandboxes as a Service Sandboxes on Steroids. Modal, Daytona and E2B sell the sandbox as an API call: create one, hand it a task and a credential, collect the result, throw it away. - Programmable: an SDK call, not a provisioning ticket. - Fast start: sub-second from a prepared image or snapshot. - Ephemeral by default, with storage you can attach when a job needs to remember. - Elastic within your quota. - Metered by the second, usually alongside minimums or storage charges. - Snapshots and cloning, so a warmed environment can be stamped out per job. These are capabilities to check per provider, not a shared guarantee. Fife uses Modal. - [Modal Sandboxes](https://modal.com/docs/guide/sandboxes) - [Daytona](https://www.daytona.io/) - [E2B](https://e2b.dev/) ## 06. Headless Agents Decompose the work. Automate the runs. ```sh claude -p "Fix the failing test in auth/" --output-format json ``` `-p` runs Claude Code with a prompt and exits. Structured output lets a caller parse the result; the caller still owns errors and validation. - Decompose: one job per agent, only the context that job needs. A lead splits the schema, the route and the tests into three runs over three directories. - Automate: CI, cron or a webhook starts the run and collects the result. - Configure: context, tools, permissions, timeouts, turn and budget limits. Decomposition needs an orchestrator to draw the boundaries, fix the interfaces and merge the outputs. `-p` gives you a worker, not a team. - [Claude Code programmatic usage](https://code.claude.com/docs/en/headless) - [Claude Code CLI reference](https://code.claude.com/docs/en/cli-reference) ## 07. Orchestrate Same agent, many entry points, one sandbox per task. The orchestrator owns what the agent never should: the job's context and tools, its lifecycle and limits, the credentials, and the output contract. GitHub issue to pull request is the lane Fife implements. A Slack mention to a thread reply, or a support ticket to a triage note, is the same loop with a different entry and exit. Dispatch, verify, retry within limits, hand off. In Fife the orchestrator runs the test script itself, returns failures to the same session, and stops after three rounds. Agents never merge. Every change arrives as a pull request a person approves. ## 08. Demo github.com/mathaix/fife. Watch one issue go in: the label, the sandbox, the agent's steps, the verify rounds, the diff, the pull request. - [Fife repository](https://github.com/mathaix/fife) ## 09. Let's Connect - [LinkedIn](https://www.linkedin.com/in/mathewma) - [Email Mathew](mailto:mmathew@claramap.com) - [Claramap](https://claramap.com) - [Fife repository](https://github.com/mathaix/fife) - [These slides](https://presentations.claramap.com/agentsandboxes/)