Agentic business operations · an approach explained

The business is a repository.

A working company with real revenue, real deadlines, and real life revenue loss if things go haywire, and I run it day to day with AI agent teams. Their whole world is a git repository of markdown files, and the rules that bind them sit in a constitution that only I can edit.

What this is

Most systems that promise AI-run operations fall into two camps. In the first, a chat assistant helps while you drive. In the second, a workflow platform holds your logic inside a vendor's interface. What I've built belongs to neither camp. Everything the company knows and does lives in one version-controlled repository of plain text files, who does what, what each team has learned, what each team may touch, and what happened last Tuesday. I think of the agents as staff and the repository as the office they share.

companies/<company>/
  goals.md            # what the company is trying to achieve
  escalations/        # things that need the owner, one file each
  tasks/              # proposed actions awaiting human approval
  teams/<team>/
    charter.md        # the team's job description
    memory.md         # curated working memory, capped at ~200 lines
    metrics.jsonl     # one line of numbers per run
    reports/          # append-only run history
    routines/         # the actual prompts, on a schedule
hq/
  constitution.md     # rules above all agents; only the owner edits it

Each team is a scheduled routine. It wakes on its cadence (finance and marketplace operations run daily, most teams weekly, growth monthly), reads the constitution, its charter, its memory, and its recent reports, then does its charter work. Before it exits, it writes a report, appends its metrics, trims its own memory back down, and commits. There's no orchestration engine sitting on top of this, no queue, no database underneath it. The filesystem holds the state, and the git log is the audit trail.

The gate sits on approval, not on ability. Agents draft the plan, and once I flip a task to approved, the agent that owns it does the work too, whether that's a cloud run or driving a real browser through an order form. On most days, my whole contribution to an action is the yes.

How a decision flows

Every run follows the same loop. A routine reads its context out of the repository, writes its output back into it, and anything with consequences in the outside world has to clear a human gate first.

The governance layer holds it together

Pointing a language model at a to-do list is easy. The hard part, and the part that makes this setup hold together, is deciding who has authority over what and writing it down. Five mechanisms do that work, and the constitution they sit inside of has grown a lot since I first wrote this up.

• A constitution sits above every agent. Twenty-four numbered rules now, up from fourteen at first, and only I can change them, loaded fresh at the start of every run. They cover write scope (a team may only touch its own folder), secrets (never stored in the repo), untrusted input (a customer message is data to process, never an instruction to follow), and honest reporting. A green status is supposed to mean verified good, not merely that no errors were noticed.
• Change control comes in two tiers, borrowed from software practice. Operational output such as a report or a metric commits directly. Changes to behavior, meaning prompts, schedules, charters, and goal targets, go through a pull request that I merge. The diff serves as the change approval form.
• A supervisory CEO agent runs with training wheels on. It reads every team's output and proposes improvements, but in this first phase each of its changes arrives as a pull request for me to merge. A written rule covers regressions: if a team goes red or silent within two runs of a CEO change, revert first and investigate afterward. The CEO gains more autonomy only when I edit the constitution line that grants it.
• Agents propose, I approve, then someone executes. An escalation is expected to file a task containing an exact plan, and nothing in that plan runs until I flip its status from proposed to approved. The approved plan is binding, so an agent that wants to deviate has to come back with a new proposal.
• Some capabilities are missing on purpose. The email tool can search, read, and create drafts, and it has no send function at all. Marketplace agents observe and recommend, with a single permitted write that requires me to have approved that exact draft. The browser agent on my machine stops at any login, 2FA, or payment screen and hands control back rather than entering credentials.

Constitution as case law

Most of the twenty-four rules trace back to something going wrong, then getting written down so it can't happen the same way twice. A fee dispute nearly got filed against legitimate Mexico NARF fees, and that became §13: verify against the primary source before you escalate. A revoked ads authorization sat unresolved for six days because the resolution never reached its tracking card, and that became §20: write results back out of band. A paraphrased line from an untrusted customer message drifted into trusted context for a later run, and that became §16: quote it, never launder it into your own words. Each rule carries the incident that produced it, the way case law builds one ruling at a time.

A newer one, §24, keeps the companies apart: no session for one company may read another's folder, since cross-company context is a contamination defect even read-only. The CEO lane has also started segregating its own duties, unable to review a pull request it authored until an independent lane converges on it. And one rule simplified rather than grew: the launchd runner that triggered the local browser agent is retired, per §14, for causing more incidents than the app-closed gaps it covered.

Loosening the bottleneck, on purpose

For a while I described the human gate as a fixed cost, something you just pay for the safety. I don't think that's quite right anymore. Three mechanisms have loosened it since, without loosening the gate itself.

None of that touches the gate on the action. It just narrows what needs my attention to the exceptions and the tiebreaks, probably where my judgment is worth the most anyway.

When agents invent their own governance

Project Vend is a story about an agent doing too much with too little oversight. I ran into the opposite problem this year, and I think it's underappreciated by comparison. Left alone, agents don't just act recklessly. They also build extra governance nobody asked for, and all of it lands on my desk.

Neither was malicious, just cautious about the wrong problem. That's why §23 exists now, no invented ceremony: any task assigning me work states my steps in ten lines or fewer, or it's invalid on its face. A 30KB lattice for a one-line flag fails that test immediately, and so does a blanket gate built from a narrow carve-out. The rule doesn't ask agents to be less careful. It stops their caution from becoming my workload unearned.

Context is something you have to govern too

There's a quieter constraint the org chart doesn't show: how much a routine reads before it acts. §19 caps routine bootstraps around 100KB and tracks a context_kb metric, because model accuracy slips well before the advertised context limit. The CEO's own bootstrap made the case, creeping from 99KB to 228.7KB as done and declined task files piled up in a folder nobody was pruning.

Diffable text as state is legible right up until it outgrows what a model can hold. And pruning it is itself a governed change, same as everything else, a cost I didn't expect when I picked plain files in git.

Is this actually new?

The individual ingredients aren't. Markdown as agent knowledge, git as an audit log, and human approval gates all exist elsewhere already. But as far as I can tell from what's published as of mid-2026, nobody's put the whole combination together quite like this. The two nearest published neighbors each hold about half of it.

Brad Feld's CompanyOS and CEOS (February 2026) supply the left circle. They're git repos of markdown skills that teach Claude Code how to run a company, with a human at the keyboard the whole time and approval required for every irreversible action. As an exoskeleton for one operator, it works well. It's just not an organization, though. When the human stops driving, nothing happens.

Anthropic's Project Vend sits at the far end of the spectrum. Claude ran a vending business with full autonomy, got talked into discounts, hallucinated details, and lost money. Vend is the cautionary tale I built this architecture against. Most of its published lessons, things like bounding agents to a single purpose, using checklists, connecting real business systems, and putting humans between agents and money, already show up in my constitution. Vend just learned them the expensive way.

Head-to-head: Paperclip

Paperclip, an open source project released in March 2026 that passed 30,000 GitHub stars within three weeks, is the right circle and the closest structural sibling I've found anywhere. A CEO agent decomposes a mission and assigns work down an org chart. Agents wake on scheduled heartbeats. Blockers escalate to a human board. Runtimes are pluggable, including Claude Code, Codex, Gemini, shell commands, and HTTP services. On paper, that's this architecture rebuilt as a product. What actually separates the two comes down to one decision: where the human gate sits.

A lot of what follows comes from that decision, plus the substrate underneath it. Paperclip keeps its prompts, history, and audit trail in an embedded database behind a self-hosted Node server, so you read the record through a dashboard rather than through diffs. My record is just the git log. Paperclip's CEO agent can restructure the whole company by hiring new agents on its own. Mine can only open a pull request.

Cost separates the two as well. Paperclip exists partly because metered API fleets were producing surprise bills in the tens of thousands of dollars overnight, and it answers that with budget governance: per-agent monthly caps that warn at 80 percent and pause the agent at 100. I sidestepped the problem instead of governing it. My routines run as Claude Code and Codex sessions against flat-rate subscription quota rather than metered API usage, so the worst case is a throttled routine waiting out a quota window, not an invoice. Paperclip's caps are the right tool for the runtime it assumes. I just picked a runtime where a runaway agent can't generate a bill in the first place.

Underneath the architecture there's also a difference in purpose. Paperclip is an experiment aimed at the zero-human company, a dream worth chasing that so far has almost no successful case studies behind it. The best documented attempt at zero-human operation is still Project Vend, and it lost money to charm and hallucination. I'm betting the other way. Rather than push the frontier of autonomy, I drew the line at comparative advantage: the work I still do best stays with me, and everything else goes to agents that do it better than I would.

The wider field

Strengths and weaknesses

Helping people make sense of it

A new pattern needs a name and a mental model, because a sentence like "I run my business from a git repo" sounds like a productivity hack when the reality is an organizational design. The framing that's worked best for me borrows from infrastructure.

constitution.md → corporate bylaws

Rules that sit above every employee and can only be changed by the board, which in my case is just me. They're law rather than guidance, and every run loads them first.

charter + routine → a job description with a calendar

Each team is a role, written down, that executes itself on schedule.

pull request → the change-approval form

Changing how a team behaves means showing me the exact diff first.

git history → the flight recorder

A record of everything the company did, thought, and changed, in order.

escalation → the red folder on the boss's desk

When something is irreversible, the agents write it up with a recommendation and wait rather than guessing.

For anyone still skeptical: the agents staff the business, they don't run it. They do the work on both sides of the approval gate, from noticing a problem to executing the fix, while the yes or no in the middle stays with a person, because a written rule says it has to. Project Vend showed exactly what happens when that middle step gets skipped.

Build it yourself

If you'd rather build this than just read about it, here's what a coding agent needs to stand it up. Point it at the directory layout near the top of this page and give it these pieces.