Input Factories

Everyone is building agent factories.

Cursor, Codex, Claude Code, Devin. Coding agents that plan, write, test, ship. Internal pipelines with five, eight, twelve sub-agents in series. Orchestrators that retry. Eval loops. Tool calls. The pipeline keeps getting better, almost weekly.

This is not the hard part.

A factory amplifies whatever you feed it. If you feed it a thin brief, it builds something thin, faster. If you feed it a contradictory spec, it resolves the contradiction silently — usually wrong. If you feed it nothing, it invents.

Most teams are scaling their ambiguity.

The agent factory is solved. The input factory isn't.

By "input factory" I mean the layer above the build. The thing that decides what the agents read before they generate. It contains:

• the intent (why this exists, who it's for, what it must do)


• the product spec (scope, edges, what good looks like)


• the design rules (tokens, voice, components, don'ts)


• the brand (how it sounds, what it never says)


• the playbooks (how this team approaches this kind of work)


• the reference code (this is how we do it here)

These already exist. They live in Notion, Figma, Slack threads, the repo, somebody's head. They drift. They contradict each other. Nobody owns them. When the build is wrong, no one knows which one to fix.

This is the bottleneck.

Here is the loop most teams are running today:

1. Agent builds something


2. Designer or PM reviews the PR


3. PR is wrong


4. Fix the PR

Here is the loop they should be running:

1. Agent builds something


2. Designer or PM reviews the PR


3. PR is wrong


4. Which input was thin, stale, or contradictory?


5. Fix the input


6. Run the next thing through the better input

The first loop scales the work. The second loop scales the system.

The first loop is what most teams will look back on as the embarrassing era — when senior people spent their time fixing outputs an agent produced from inputs the senior person never actually wrote.

There is a role shift coming, and it is bigger than it sounds.

The designer stops being the one who fixes the output. They become the one who curates the system that produces the output. When the build comes back wrong, the question is no longer "how do I edit this?" but "what was missing from what the agent read?"

The PM stops chasing tickets. They author the intent — the why — and the evidence behind it. The thing nothing downstream can guess at.

The engineer stops translating. They integrate. They write the reference code, the conventions, the constraints. They make the input layer real in the repo.

In this world the seniority of the work moves upstream. The most leveraged person on the team is whoever owns the inputs.

I think the reason nobody has built this yet is that the inputs feel like just files. Markdown, Figma frames, brand decks, a couple of shared docs. It feels low-status. The factory feels high-status.

But the factory is a commodity. There will be five good ones in eighteen months and they will mostly do the same thing.

The inputs are not a commodity. They are your product's actual intent, captured and made legible to a machine. They are the only thing that makes your factory's output yours instead of generic.

A real input factory does a few things the file-soup version doesn't:

It authors — the inputs are written deliberately, not assembled from drift.

It evidences — every claim points back to the user signal that justifies it.

It governs — somebody owns each input, somebody updates it, the staleness is visible.

It compiles — at build time, the right slice of input is packaged into the agent's context. Not the whole pile. The right slice.

It diffs — when the output is wrong, you can trace which input was insufficient, and improve it.

Karpathy has been writing about a version of this from the other direction: raw notes compiled into a wiki an LLM can read. He is right about the pipeline. The thing he leaves implicit is that for product work, the raw notes aren't notes. They are intent, spec, brand, design rules, playbooks. The wiki isn't a wiki. It is the input factory.

The companies that figure this out first will look, from the outside, like they have better agents.

They won't. They will have better inputs.

If you are building an agent factory right now, the question worth asking is: what does my factory read, who wrote it, and how do I know it's still true?

If you do not have a good answer, the factory is the wrong place to spend the next quarter.

Build the input factory.

I'm building Pathmode, the input layer for product teams building with AI.