The enabling environment
What an agent needs before a factory routes work to it, who builds that environment, why the runtime owns security, and how the repo shortens feedback.
Written by
-
Benedikt Stemmildt Founder & Co-CEO
Updated:
Software Factories 5
Our position. We hold that AI adoption was never about the tool but about the environment the agent walks into (The overcorrection trap (opens in a new tab)). That floor under the model does not compress: the model improves on its own schedule, and the floor it stands on is yours to build (Developer experience in the AI era (opens in a new tab)).
The environment runs from isolated machines with a reproducible definition, through a platform that connects them to real services and triggers, down to a repository whose build and tests run without a human.
What does an agent need before a factory routes work?
Before any factory routes a task, the agent needs somewhere to run it, and that turns out to be the gating investment. Ona’s argument from operating background agents at scale is that the teams merging agent PRs in volume did not start with a better model or harness; they standardized their development environments years earlier and are now collecting compound returns: Stripe’s Minions merge over a thousand agent PRs a week, Ramp’s background agent accounts for 57 percent of merged PRs, and Ona itself authored 88.5 percent of the PRs merged on its own main branch. The gap between an agent that “generates a diff” and one that “opens a merge-ready PR” is precisely the environment.
Localhost cannot serve this workload: agents need many isolated, fully provisioned environments at once, and git worktrees on a single laptop collide on ports, caches, and service state. The properties that make an environment agent-ready are VMs rather than containers (a container escape by a tenacious autonomous tenant reaches every other environment on the host), a declarative reproducible definition (devcontainer.json), and an automation layer (automations.yaml) that boots services, installs dependencies, and seeds data with no manual step, so the same infrastructure that makes a human productive on day one makes an agent productive on task one (The Last Year of Localhost (opens in a new tab), Ona, 13 February 2026).
Ona breaks the build-versus-buy decision into four layers a self-built background-agent platform must cover, drawn from Stripe’s and Ramp’s in-house stacks: full development environments (an agent that cannot install packages, run the suite, and execute builds cannot validate its own work, so a container or CI runner is the wrong primitive), scoped isolation and security (ephemeral per-session tokens, RBAC, network isolation that holds under hundreds of concurrent sessions), connectivity and context (databases, internal APIs, staging, on the agent’s network, because output quality tracks what the agent can reach), and automation and parallelism (webhook and cron triggers plus orchestration to run fleets, since agents that only run when prompted are capped by human capacity).
Stripe built its harness on a remote-devbox platform predating GPT-3; Ramp hand-rolled sandboxes on Modal with session state on Cloudflare Durable Objects and a registry rebuilding every repo every thirty minutes, both having platform teams, years of standardization, and budget most organizations lack (The Background Agent Infra Ramp Had to Build (opens in a new tab), 2 April 2026). A walkthrough of Stripe’s own account fills in the Minion anatomy, now at roughly 1,300 agent PRs a week with zero human-written code against hundreds of millions of lines of Ruby: CLI, web, and Slack entry points feed a pool of pre-warmed EC2 devboxes that spin up in about ten seconds with Stripe’s code and services preloaded; the agent harness is a fork of Block’s Goose built around “blueprints”, workflows designed in code that interleave deterministic nodes (lint, commit, run tests) with agent nodes (implement, fix CI); rules files scoped by glob patterns attach context as the agent traverses the tree; a central “tool shed” MCP server exposes 400 to 500 internal tools behind a meta-tool that selects among them; and CI selectively runs a slice of over three million tests, with each Minion capped at two rounds of CI for cost (commentary on Stripe’s Minions (opens in a new tab), 2 March 2026).
Ona productizes the same shape as automations, “proactive background agents running in the cloud that combine AI prompts with deterministic shell scripts in trigger-based, closed-loop workflows”, with templated instances for backlog picking, Sentry triage, dead-code cleanup, CVE remediation that reruns until the scanner is clean, and migrations at scale; the pitch targets the up to 30 percent of engineering time spent on CVE mitigation, dependency updates, and large-scale migrations, and a top-five pharma customer reports 90 to 95 percent of that work done by automations with humans doing the final push (Ona – Ona Automations: Proactive Background Agents (opens in a new tab), 19 February 2026, vendor).
A practitioner conversation on factory stacks argues that the development environment is the layer to own. A vendor sandbox is easy while the need is a base image with the right toolchain. It turns into friction once the agent must reach the shared services a large application depends on, which means opening the company network to someone else’s compute. It also breaks once the sandbox’s nonstandard kernel lacks a system call the toolchain needs. The hosts expect every team to hit that friction unless its work is a small application squarely in the models’ training distribution. They also place identity in this layer rather than in the harness. The environment has the credentials and scopes that open internal services, so the harness never has to provision access (Boundary - How to Build a Software Factory for AI Coding Agents (opens in a new tab), August 2026, practitioner and vendor).
The same conversation covers work that spans many repositories. Submodules pin commits and force every change to be committed in two places. Instead, every agent session runs from one coordination repository or workspace whose agent-config file says where the other repositories sit. The agent then researches across them without their sharing a git tree. On-demand sandboxes make this harder. Cloning every repository per run costs time and disk. Having a human pick the relevant ones breaks down exactly where agents help most, in codebases that human does not know. That tradeoff is the pets-versus-cattle choice applied to agent environments. The hosts treat a few long-lived, hand-maintained machines as a reasonable place for a small team to start (Boundary - How to Build a Software Factory for AI Coding Agents (opens in a new tab), August 2026, practitioner and vendor).
Who builds and owns the environment?
The organizational corollary is that harness engineering is platform engineering reinvented from first principles, so every engineer is becoming a platform engineer: The old headcount ladder in the account (documentation at 15 engineers, an infra specialist at 50, a platform at 150) no longer holds when a single engineer ships at the speed of many and agents follow standards more obediently than a department ever did, and the near-term prediction is that organizations far smaller than before will re-learn the platform-engineering lessons the hard way through tool sprawl and proliferating standards (Ona – Everyone’s Becoming a Platform Engineer (opens in a new tab), 29 April 2026).
Two organizational designs give that platform reinvention shape. One account adapts Team Topologies for the agentic era: agents change cognitive load from a quantity distributed across teams into a throughput problem compressed onto one person, an anticipation burden (“everything the human must foresee before launching the agent”) plus a sustained flow of decisions, because agents “do not ask questions: they produce answers, immediately”, and poorly framed ones produce fast and off target. Its platform-team model offers three pillars as a service (systemic context, systemic guardrails, tooling and skills), and stream-aligned teams can be non-technical because the platform absorbs the technical and operational load.
Three of its rules travel well: a guardrail reimplemented by three or more teams graduates into the platform (the refactoring rule of three transposed); maturity is observable through guardrail coverage, pipeline SLA, self-service share, documentation, and decision traceability (the audit trail of why a deployment was blocked and by which rule); and once non-technical teams ship production apps, “ease of production must be matched by ease of oversight”, or the factory industrializes shadow IT. The shared platform pays off from roughly three to five product teams running agentic apps in parallel, where the cumulative cost of reinvention exceeds the investment (Team Topologies for the Agentic Platform (opens in a new tab), 22 June 2026).
A talk on agent enablement frames the same rollout in four layers mirroring DevOps history (enable the agents, then the team, then the platform, then the org), with an incubation team whose patterns other teams mimic before a shared central layer forms; its registry pattern makes skills, MCP servers, harnesses, and pipelines versioned, discoverable, and self-serve, with the accompanying warning that shared components rot without explicit ownership and budget, and that of the “5 or 6 harnesses being built” in a typical org only a few should survive (The Rise of Agent Enablement (opens in a new tab), 8 July 2026).
Why does the runtime have to own security?
Security in this environment is a layer the runtime owns, not a bolt-on. Ona frames it as defense in depth across a stack it controls (platform hygiene inside the customer network, input/output guardrails, and kernel-level enforcement), noting that guardrails built from AI to guard AI are circular (HiddenLayer broke OpenAI’s Guardrails within days; Cisco found multi-turn attack success averaging 64 percent across eight open-weight models) and that application-level rules see the plan while only the kernel sees the execution. The design principle is that brakes are engineered into the chassis, and the direction is an autonomous-vehicle model of a hard user-defined outer boundary plus a dynamic inner boundary that widens as an agent earns trust and contracts on errors, all resting on kernel-level enforcement as the foundation (Introducing Veto (opens in a new tab), 3 March 2026). The underlying distinction is guardrails versus guarantees: “LLMs are optimizers. Given a task, they will find creative paths to completion. If a guardrail blocks a command, a sufficiently capable model may find an alternative route, including disabling the guardrail itself. Guarantees operate at a level the agent cannot reach”, and the design rule is to stay on the diagonal where agent power and the risk controls grow in lockstep (Ona – The AI-SDLC Framework (opens in a new tab), 14 May 2026).
How does the repository shorten the agent’s feedback loop?
The repository itself is the inner layer of the environment. An agent works in cycles of change, build, read the output and try again, so every broken build, flaky test or unclear failure message widens that cycle. The continuous delivery community puts a price on it: a first attempt that is wrong, reviewed and re-prompted costs roughly three times the tokens of one that is right the first time. Its readiness rubric scores each criterion from 0 to 3, among them build reproducibility, test quality, CI clarity, dependency pinning, modularity, naming, type safety and error handling. Any criterion at 0 blocks agent work, any at 1 makes results unreliable, and every criterion at 2 or above is the bar for effective agent work (MinimumCD.org and DojoConsortium.org - Repository Readiness for Agentic Development (opens in a new tab), as of September 2026).
The guide orders the repair by what blocks first. A single command has to build the project from a clean checkout, and the tests have to give the same result every run, with no external services inside unit tests. Next come failure messages that show expected against actual, and a fast test tier split from the slow one. Only then does documentation for the agent pay off, followed by smaller modules, consistent naming, enforced formatting, dead code removal, types at public boundaries and one error-handling pattern enforced by a linter. Two of its reasons are specific to agents. Every synonym for a domain term spends context budget, and dead code teaches the agent patterns the team has abandoned. The minimum contract is a build command and a test command that run without a human, use working defaults for every environment variable, and exit non-zero on failure (MinimumCD.org and DojoConsortium.org - Repository Readiness for Agentic Development (opens in a new tab), as of September 2026).
Related
- Software Factories and Harness Engineering: the harness that runs on top of this environment.
- Security and Runtime Isolation: why the controls that hold sit below the agent.
- Agent observability: the run record an environment should produce for every agent.
- The Federated Factory at Enterprise Scale: how a platform tier serves environments to many teams.
- Agentic continuous delivery: the pipeline an agent change passes after it leaves the environment.
Resources
Readiness
- Repository Readiness for Agentic Development (opens in a new tab) - Community guide with a 0-to-3 readiness rubric and an ordered upgrade sequence that tightens the agent’s build and test loop, CC BY 4.0.