Running a company on pull requests

The useful unit of agent work is not a chat, a session, or a completed tool call. It is a pull request.

Chats are hard to audit. Sessions end. Tool calls can change reality before a human understands what happened. A pull request is different: it contains a bounded proposal, the files it changes, the reason for the change, and a place to accept or reject it.

Software teams built this machinery for contributions from humans they did not completely trust. That is not an insult; it is the premise of review. We separate authorship from acceptance, run checks, inspect the diff, and merge only when the change earns it. Agent labor fits the same boundary.

This suggests an operating model for a small company with a large software workforce: task files are briefs, branches are workspaces, diffs are deliverables, and pull requests are airlocks. Work can accumulate on one side without entering company reality. A human opens the door.

The overnight desk

An overnight queue can produce several bounded branches and leave a human with finite morning decisions. The home page carries that scene; the point here is the boundary: agents can prepare changes while a human keeps the authority to merge them.

The impressive part is not that agents worked while a human slept. Cron has done that for decades. The difference is that judgment stayed on the human side of a review boundary.

Files remove the integration tax

This model becomes expensive if every task begins with an API project. An agent assigned to a ticket system needs a credential and its object model. To draft in a CMS, it needs another tool. To reconcile a product catalog, it needs a third. Now the operator is maintaining integrations instead of directing work.

A file has no onboarding flow. The agent can already list it, read it, search it, edit it, and show the result. The manifesto covers the broader setup-cost comparison; here the useful property is that the conventions stay visible in the checkout.

That does not mean structure is optional. A fleet needs stable paths, small record shapes, identifiers, and declared ownership. But those conventions are visible in the same checkout. Agent A can draft, agent B can check the claims, and agent C can repair the links without receiving a forwarded transcript. The repo is both workspace and handoff.

RepoTodo makes this literal: the task is a markdown file in TODO/, its status change travels with the implementation, and its surfaces read the same record. Delete the task UI and the brief, discussion, and outcome remain. That property is load-bearing. Without it, the pull request can show the code change but not the operating context that produced it.

A launch becomes one review

Consider a price change. In the usual stack, the decision lives in a document, implementation is a code PR, the help center is updated in a CMS, the launch email waits in another service, and the checklist is closed somewhere else. Each surface can say “done” while disagreeing about the amount or effective date.

In a repo-native workflow, an agent prepares a branch containing the pricing constant, the migration note, the help article, the email source, and the task outcome. The pull request exposes a useful fact: the email says the new price starts Tuesday, while the help article says Monday. A reviewer catches the disagreement before either version ships.

The merge can trigger renders and deliveries at the edges. The site may run on a CDN and the message still goes through a mail provider. Repo-native is not anti-service. It keeps the source records and the decision boundary in the place where one diff can show how they relate.

This is what “running a company on pull requests” means. It does not mean forcing payroll or payment events into git. It means making an operational change reviewable as one coherent proposal wherever files are an appropriate system of record.

The human job changes

With this boundary in place, the scarce work becomes direction and review. The operator has to state what outcome is wanted, what evidence counts, which paths may change, and which consequences require separate approval. Then they have to read what comes back.

That is still work. It is also a better description of executive leverage than copying facts between dashboards. A single person can direct several independent branches because each branch preserves its own context and waits for a merge. Adding an agent does not require buying it a seat in every tool; it requires giving the job a clean boundary.

Git also makes refusal cheap. A weak proposal can be closed without restoring 40 records through an admin screen. An ambitious proposal can stay open while the current plan continues on main. An agent can be replaced mid-task and the next one inherits the branch, the comments, and the files, not somebody's memory of the conversation.

What the airlock does not stop

A pull request is a safety rail, not a proof of correctness.

Review fatigue is a real failure mode. If five agents each open a 2,000-line change overnight, the human does not have leverage; they have a queue designed to be rubber-stamped. Small tasks, path boundaries, diff-size budgets, and automatic checks are part of the operating model. So is saying no to work that cannot be reviewed economically.

A diff cannot show every consequence. It can show that an email template changed, not whether the message will land in spam. It can show a new price, not whether customers will understand it. It can show a generated data file, not whether the generator encoded a false assumption. Previews, tests, domain experts, and staged releases remain necessary.

Some actions are side effects, not file edits. Sending a message, refunding a payment, rotating a credential, and changing a DNS record touch external reality. Recording intent in a PR makes those actions auditable, but the merge should not silently grant unlimited authority. Sensitive operations need narrow credentials, explicit approval gates, idempotency, and logs from the service that performed them.

Git records bad judgment faithfully. An approved mistake has excellent provenance and is still a mistake. History helps investigate and reverse it; history does not supply taste, strategy, or accountability.

The honest model therefore has more than one guardrail. The task bounds the job. Permissions bound the paths and services. Checks catch mechanical errors. The pull request makes the proposal legible. A human remains responsible for the decision to merge.

The company as a reviewable system

Most agent demos optimize for the moment the machine acts. An operating system should optimize for the morning after: Can someone see what changed? Can they connect it to the direction that authorized it? Can they reject it without repair work? Can another agent continue it without reconstructing a private session?

Files, branches, and pull requests answer yes often enough to build a company around. They turn agent output from an event into a proposal, and they keep the proposal outside reality until someone accepts it.

That is the deeper agent argument for repo-native software. The repo is not only the interface agents already know. Git is the governance layer their work was missing.

Read the repo-native manifesto for the full set of invariants and the workloads this model deliberately leaves outside the repo.