The Agentic Software Factory Hierarchy of Needs

The following article originally appeared on the Vanishing Gradients Substack and is being republished here with the authors’ permission. Stripe’s Minions turn engineering requests into candidate pull requests. Ramp’s Inspect puts coding agents to work in the background, with tools to check their changes. Warp Factories takes work from tickets and chat through agents, checks, and human review. Agentic software factories are here. Are you sick and tired of babysitting Codex, Claude Code, or OpenClaw? Do you have agents that can build features, but still leave you responsible for remembering where they stopped, explaining how each feature fits the project and deciding what happens next? You make progress in each conversation, then development waits for you to return. It doesn’t have to be this way. A software factory lets you delegate more of that process! You agree on an outcome, give the system the context and authority it needs, and let it work while you do something else. When you return, there should be a result you can inspect, with evidence of what was checked, or a specific reason the work could not continue. Your next conversation can then focus on the result and the decisions that remain. As we’ll show you, your first software factory doesn’t need to be that complex at all: It can begin with a single agent and an automation. What makes it a factory The defining combination is autonomous and asynchronous execution. Autonomous: The agent chooses and carries out steps towards an agreed goal. It can inspect what happened, adjust its approach and continue within its authority. Asynchronous: That work can proceed without your ongoing attention. You can leave and return to its result. A scheduled job can run without you. A coding agent can choose and revise an approach during an interactive session. A factory combines those capabilities, with enough context, tools and feedback to carry out the delegated work. Software factories have been hypothesized for decades. Now that we have agents, we’re actually able to operate them. The principles apply to software work traditionally carried out by teams of humans, from bespoke tools for teams and individuals to large and complex software systems. To illustrate these principles, we’ll use an invoice tracker throughout this article, an application we’ve needed for our own businesses. The same approach applies to research tools, publishing systems, and software for teams. Suppose you run a small business and want an invoice tracker that fits how you work. Build an app that creates invoices from my template and tracks which are unpaid, paid, or overdue. Keep it local for now. Preserve the records when it restarts, and show me checks that the totals and payment statuses are correct. You can agree on this brief with the agent, leave it to work while you do something else, and return to the app and evidence of what was checked. If a check fails, it can investigate and adjust within its agreed scope. If it encounters a product decision it cannot make, it should bring that question back to you. You might imagine a clean separation: The factory builds the invoice tracker, then the finished app does its job. That’s one way to run it. But agents can also help operate the software they build, and that combination is useful. The tracker can store invoices and calculate outstanding balances. An agent can use those records alongside customer correspondence to prepare follow-ups: One customer has promised to pay on Friday; another is disputing a charge. You don’t need to turn every situation into a new software feature before the agent can help. You give it the relevant context, authority, and a way to check its work. This changes what you need to build! Some behavior belongs in code, such as calculating balances consistently. Other work can be delegated to an agent that responds to the circumstances. If a recurring need emerges, you can ask the factory to build it into the software. The factory builds tools that agents can use, and experience using those tools helps you decide what to build next. You still decide what is worth building, who it should serve and which trade-offs matter. Agents can help you make those decisions too. The practical change is that implementation can proceed between your conversations, including running checks and responding to failures. This makes factories relevant to people with product, business or creative expertise as well as engineers. You might know exactly how you invoice clients, record payments, and chase overdue bills while having little interest in writing software. That knowledge lets you direct the factory toward software that fits your business, including the exceptions and connections that general-purpose tools handle poorly. At every layer: specify what you want and how success will be checked, then verify the result. Monica Rogati’s original AI hierarchy of needs described the foundations beneath successful AI work. We find that dependency framing helpful for factories too, with four different layers. Harness is the environment that exists around the model: tools, a workspace for project files, execution, and feedback. It lets an agent read files, change software and run it. If a check fails, the harness must give the agent enough information to investigate what happened. Personalization is the context and capabilities for your work: project direction, rules, reference material, skills and connections to other systems. The agent needs to know what you are trying to accomplish and which existing decisions it should preserve. Permissions limit access to tools and systems; sandboxing restricts the environment where actions can run. Automation is a way to start and continue work without a fresh instruction from you each time. A schedule or event can trigger a task or the pickup of ready work. It also needs direction about what qualifies as ready and where to leave the result. Continual learning is a process for learning from completed and failed runs, improving the factory and carrying those changes into later work. That might change an instruction, a checking procedure, or a tool the agent uses. Automation needs a harness able to do the work, plus direction about what to do. Continual learning needs runs to inspect and a way to put improvements into use. These capabilities can develop together: A familiar harness, a short brief, and a basic automation are enough to start. You can personalize further as work reveals what is missing. Two practices run through every layer: specification and verification. Specification makes the intended outcome, constraints, and criteria for success explicit. In our invoice brief, that includes preserving records after a restart and calculating payment statuses correctly. Verification checks the software, and the work agents perform against those requirements. Agents can help you refine the specification and perform the checks. Your role is to decide whether the requirements capture what you need and whether the evidence supports accepting the result. As the factory takes on more work, these practices give you a way to direct it and assess what comes back. Let’s now see what’s up in each layer. 1. Agent harness First, you’ll need an agent harness. If you’re using Codex, Claude Code, Hermes, or OpenClaw, you already have one. It gives the model tools to read and edit files, run your software, and see what happened. For our invoice tracker, the agent can build the app, create an invoice, record a payment, and restart it to check that the invoice and payment records survived. If a paid invoice still shows as overdue, it can investigate, fix the problem, and try again. You shouldn’t have to narrate every step. But if it needs a decision about how your business handles partial payments, that’s a question for you. If it lacks access or authority, the agent should stop and name the blocker. You’ll also need somewhere for the harness to run. A cloud machine lets the agent keep working while your laptop is closed or disconnected. You can also run it on your own computer, but the machine needs to stay awake and connected for the work to continue. 2. Personalization Next, give the agent the context it needs to work your way. For our invoice tracker, that means your template, payment terms, and conventions for recording payments. You don’t want to explain all of that again every time you start a new task. Keep it somewhere future workers can find it: Rules: Preserve existing invoice records; ask before changing payment-status calculations References: Your template, payment terms, and example invoices Skills: Repeatable procedures for testing invoice creation, payment updates, and persistence An instruction file such as AGENTS.md can point to this material. OpenAI’s harness-engineering account describes using a short guide that points into maintained project documentation. Give a new or scheduled worker a small task and check that it actually follows the guidance. Be specific about when instructions apply. Eleanor once told an agent to write tests, and it wrote tests for a README. Enthusiasm wasn’t the problem You’ll also need to set permissions and sandboxing to control what the agent can access and execute. Written instructions alone don’t enforce those boundaries. 3. Automation One agent works in the background; you assess what comes back. Now let’s give the factory a way to get started without waiting for you. A schedule or event can launch an agent with its brief, project guidance, and tools. You come back to a result, evidence of what was checked, or a specific blocker that needs your attention. One agent working in the background For our invoice tracker, a morning automation could check a saved task list and pick up the next agreed task, such as adding partial payments. You’ve decided what you want and how success will be checked. The agent gets on with it while you do something else. There are a few practical details to get right. Don’t start the same task twice, leave an empty queue alone, and set limits on time and spending. Save progress so a later session can continue without you having to reconstruct the whole conversation. One worker may be plenty. But perhaps you have independent tasks that could run in parallel, or you’d like another agent to review a change. That’s where coordination comes in. Coordinate ready work, then check the combined result. Coordinated work With several agents, everyone needs somewhere to see what’s ready, what’s underway, and what’s waiting on something else. A shared task list or issue tracker can hold that information. You agree which tasks are ready; a coordinating agent or automation assigns them, supplies the relevant context, and records what happens. Suppose one task adds partial payments, another overdue follow-up emails, and a third PDF exports. Follow-ups need the correct outstanding balance, so they wait for the payment behavior to be checked. PDF exports might proceed independently if the changes don’t overlap. You can also split the roles. One agent builds the feature while another prepares payment scenarios to test it. A third might review the completed change. Assign responsibility for combining the changes and verifying the whole application. Different questions call for different checks. Deterministic tests can establish whether balances are calculated correctly and payments survive a restart. Agent verification can help identify missed requirements or inconsistencies across the changes. Human judgment can assess whether the workflow fits how you actually work. You’ll often want a combination, with more than one kind of check on the same result. Anthropic’s evaluation guide describes these complementary approaches: code-based checks, model-based checks, and human evaluation. Combine deterministic checks, agent verification, and human [truncated for AI cost control]