Your Agents Need a Factory, Not a Better Prompt

Guillermo Rauch says the software factory is the product. Here is what an agent factory is actually made of, and when a better prompt still beats one.

Your Agents Need a Factory, Not a Better Prompt

Your Agents Need a Factory, Not a Better Prompt

If your agents produce good work on Monday and quietly regress by Friday, the problem is not your prompt. It is that nothing outside the prompt survives the session. On July 25, 2026, Guillermo Rauch put the alternative in one line: the software factory is the product (Rauch on X). When we put ten coding agents on our own codebase at the same time, the ceiling was never model quality — it was how fast a human could review what came back. That is a factory problem, and you fix factory problems with structure.

The agent factory claim, and why it landed now

An agent factory is the durable system around a model — instructions, prior work, validation and a maintenance loop — that determines output quality more than any single prompt does.

The wording from the CEO of Vercel and creator of Next.js was blunt: "The (software) factory is the product. Your product is only as good as the agents you set up to autonomously maintain it" (Rauch on X). He credited the insight to what Tesla figured out about manufacturing — that the line which builds the car is a harder and more valuable engineering problem than the car.

That would be a nice metaphor if the numbers were not moving with it. He has also stated that AI agents now trigger more than half of all deployments on Vercel's platform (Startup Fortune, July 26, 2026). Once agents are the majority of the traffic into production, the question stops being "how do I phrase this request" and becomes "what does the machine that keeps making these changes look like".

Most teams are still answering the first question. They keep a folder of clever prompts, they iterate on wording, and they treat each session as a fresh negotiation with the model. That holds until the work outlives the session — which is exactly the point where agentic engineering separates from improvisation.

What an agent factory is actually made of

A working agent factory has four parts: a durable instructions file the agent reads every run, a filesystem of prior work it can search, explicit iteration ceilings, and a validation loop that decides what ships.

Strip the metaphor away and the components are unglamorous.

1. A durable instructions file. One place that states how this repository works — build commands, conventions, test rules, and the constraints an agent cannot infer by reading code. This is what AGENTS.md was designed to hold (AGENTS.md spec).

2. A filesystem of prior work. Guillermo Rauch's description of his own setup is a research folder plus an instructions file plus a command-line agent on top — no apps, no knowledge graphs — with the agent correlating knowledge across previous sessions (Guillermo Rauch on X). Plain files, searchable, versioned.

3. Iteration ceilings. A limit on how many attempts an agent gets before it stops and asks. Without one, a confused agent spends your budget proving it is confused.

4. A validation loop. Tests, evaluation gates, and a review step that decides what merges. This is the part almost everyone skips.

None of these are exotic. All of them are boring infrastructure nobody gets credit for building, which is precisely why the prompt keeps getting blamed instead.

The instructions file is load-bearing — and shorter than you think

AGENTS.md is plain markdown with no required fields and no YAML frontmatter; its value comes from stating what an agent cannot infer from the code, not from being comprehensive.

The format is deliberately unremarkable: plain markdown, headings and bullet points, no required fields, no special syntax (AGENTS.md spec). The reference repository shows the canonical sections — dev environment tips, testing instructions, conventions (agents.md repository). What belongs in it is the operational guidance an agent genuinely cannot derive: build commands, coding conventions, testing rules, and hard constraints (Augment Code guide, updated June 18, 2026).

The instinct at this point is to write more. The evidence from July 2026 says the opposite. Anthropic removed roughly 80% of the Claude Code system prompt for its Claude 5 generation models and published what it learned about writing system prompts, skills and instruction files for them (Anthropic engineer on X, July 24, 2026), an analysis unpacked in detail by Developers Digest. More capable models need fewer instructions, not more. A bloated instructions file is a factory that has confused documentation with tooling.

The same discipline shows up in Anthropic's authoring guidance for agent skills: keep the body under 500 lines and push detail into referenced files rather than inlining everything (Anthropic skill-authoring docs). Write the rules that change behaviour. Delete the rest. If you are auditing what you already have, our guide to auditing agent skills covers what to strip first.

A filesystem of prior work beats a bigger context window

Progressive disclosure loads an agent's capability names at startup and full instructions only on match, which is why a searchable filesystem outperforms pushing prior work into the context window.

The reason a research folder matters is mechanical, not aesthetic. Agents load capability names and descriptions at startup — roughly 30 to 50 tokens each — then pull full instructions only when a task matches, and referenced files only at execution (progressive disclosure explained, July 1, 2026). A filesystem is the cheapest possible index: the agent pays for what it opens.

The alternative — pasting the last three months of decisions into every request — costs tokens on every single run and degrades as it grows. Writing to disk costs nothing per run and compounds. That asymmetry is the whole argument for file-first architecture, and it is the same reason orchestrating multiple agents at scale only works when state lives outside the conversation.

There is a second-order effect that gets missed. Once prior work sits on disk in a consistent format, the agent can correlate across sessions: which decisions were made, what was already tried, what failed. A knowledge graph is not required. A directory and a naming convention are.

Without validation, autonomy does not scale

Most teams shipping agents to production in 2026 are not systematically testing them, which turns autonomy into a queue problem rather than a quality gain.

This is the honest gap. One assessment of 2026 practice puts it directly: most teams shipping agents to production are not testing them, and it proposes scoring agent runs on task completion, tool use, cost and safety (eval harness argument, June 8, 2026). The replies under Guillermo Rauch's post made the same point from the other direction — the factory is only as good as its feedback loops, and without reliable validation, autonomy will not scale (Rauch thread).

We hit this from the throughput side. Running ten agents in parallel did not multiply output tenfold; it multiplied the volume of work waiting on a human decision, which is why review turned out to be the real bottleneck. Adding agents to a system with no automated gate does not produce more shipped work. It produces a longer queue.

The industry read is converging here. A June 2026 comparison of coding agents framed the entire category around harness, cost and accuracy rather than model choice alone (Firecrawl, June 10, 2026).

Open Agents, Vercel's reference app, is instructive for the same reason: what it ships is the unglamorous half — web UI, agent runtime, sandbox orchestration and repository integration (Open Agents). Nobody had to build a better model to make that useful. They had to build the room the model works in, which is the pattern we traced through Vercel's 2026 platform shift.

Where ad-hoc prompting still wins, and what to build first

Ad-hoc prompting is the correct choice for one-off, exploratory or throwaway work; an agent factory only pays for itself when a task recurs or when its output must survive the session.

The counter-case is real and should not be argued away. If a task runs once, prompting is faster and an agent factory is overhead. Exploratory work — where you do not yet know the shape of the problem — is actively harmed by rigid instructions, because the constraints encode assumptions you have not tested yet. Small codebases with a single maintainer often lack enough recurrence for the structure to earn its keep. And a stale instructions file is worse than none: it confidently points agents at conventions you abandoned months ago.

The test is recurrence and survival. Will this task happen again, and does its output need to outlive the session? Two noes mean prompt and move on. Two yeses mean write it down.

If both are yes, build in this order:

  • Write the instructions file first. Only what an agent cannot infer from the code. Start short — the July 2026 evidence favours less (context engineering guide).
  • Add the filesystem second. A directory for prior work with a naming convention you will actually follow.
  • Add the ceiling third. A hard cap on iterations before the agent stops and asks.
  • Add validation last, and never skip it. Whatever gate decides what merges, automate the part that can be automated.

That order matters because each step makes the next one cheaper. Instructions without validation produce fast, confident, unreviewed output. Validation without instructions rejects work for reasons the agent was never told.

The uncomfortable part of Guillermo Rauch's claim is that none of this is prompt craft. It is the same work that made continuous integration valuable twenty years ago, pointed at a new kind of worker. The teams that get compounding returns from agents in 2027 are the ones writing the boring files in 2026.

If you want that layer designed rather than assembled from blog posts, our team builds this for operators — instructions, prior-work structure and the gates that decide what ships.

Frequently Asked Questions

What is an agent factory? An agent factory is the durable system around an AI agent — a persistent instructions file, a searchable filesystem of prior work, iteration limits and a validation gate — that determines output quality more than prompt wording does (Guillermo Rauch on X).

Is AGENTS.md required, or can I use a different file? AGENTS.md is an open format, not a requirement: plain markdown, no required fields, no YAML frontmatter (AGENTS.md spec). The file name matters less than having one durable place agents read on every run.

How long should my instructions file be? Shorter than instinct suggests. Anthropic removed roughly 80% of the Claude Code system prompt for Claude 5 models, and its skill guidance caps bodies at 500 lines with detail pushed to referenced files (Anthropic docs).

Do I need a vector database or knowledge graph for prior work? No. Rauch's described setup is a research folder, an instructions file and a command-line agent — no apps, no knowledge graphs (Guillermo Rauch on X). Files and a naming convention cover most cases.

When is building an agent factory not worth it? When the task runs once, when you are still exploring the problem shape, or when the codebase has too little recurrence to amortise the setup. Prompting is the right tool for throwaway work (harness comparison).

Sources

  1. Guillermo Rauch on X — "The (software) factory is the product" — July 25, 2026
  2. Anthropic engineer on X — the new rules of context engineering for Claude 5 models — July 24, 2026
  3. The New Rules of Context Engineering for Claude 5 Models — July 24, 2026
  4. Guillermo Rauch: AI agents trigger more than half of all Vercel deployments — July 26, 2026
  5. AGENTS.md — an open format for guiding coding agents — living spec, verified July 27, 2026
  6. agents.md reference repository — living repository, verified July 27, 2026
  7. Anthropic — skill authoring best practices — living documentation, verified July 27, 2026
  8. Vercel Open Agents reference app — verified July 27, 2026
  9. Best AI Coding Agents in 2026: Harness, Cost and Accuracy Compared — June 10, 2026
  10. How to Build Your AGENTS.md — updated June 18, 2026
  11. AI Agent Evaluation in 2026: Build an Eval Harness — June 8, 2026
  12. What Are Claude Skills? Agent Skills Explained — July 1, 2026

Share article

Share: