How to Run a Company With AI Without Handing It the Keys

You are one person shipping a real product, and the recurring work keeps piling up behind it. The marketing nobody writes. The outreach batch that should go out weekly. The support digest. The competitor sweep. The release notes. Each one is familiar, and each one steals an afternoon you wanted to spend building.

So the pitch for an autonomous company lands hard. Describe the business, hire a cast of agents, approve a strategy, and let it run while you sleep. The promise is that the whole operation runs itself and you watch from above. It is an attractive story precisely because the work you want gone is the work you are worst at keeping up with.

The story breaks the first time it matters. A black box that runs the company runs it your way only by accident. It sends the email you would have rewritten, spends on the retry you would have stopped, and makes the pricing call you would have made yourself — and you find out after, from the result, not before, from a decision. "Set it and forget it" is not a control model. It is the absence of one.

There is a better way to read "run your company with AI." Not as a box that runs itself, but as an operating model you assemble and stay on top of — where agents do the doing, and you decide, in advance and in the moment, where their judgment is allowed to stand in for yours.

The real choice is not autonomy versus supervision

The autonomous-company framing offers two settings: hover over everything, or trust the box. Both are bad. Hovering destroys the reason you delegated. Trusting the box means inheriting decisions you never saw.

The useful framing is different. For any piece of recurring work, you are choosing how much an agent may decide alone, where its output has to pass a gate, and what comes back to you when judgment is required. That is not one global dial. It is a set of choices you make per workflow and per agent, and the right answer is rarely the same twice.

A pricing email and a competitor research summary are both "agent work." One can go out the moment it reads well. The other should never leave without your sign-off. An operating model that cannot tell those apart is not running your company — it is gambling with it.

The operating model, in six parts

Here is a model you can apply whether or not you ever touch a specific product. Six parts, each answering a question the black box leaves unanswered.

Part	Question it answers	What it replaces
Deterministic workflows	What exactly happens, in what order, every time	An agent improvising the steps on each run
One inbox	Where do the decisions that need me show up	Approvals scattered across Slack, email, and terminals
Autonomy level per agent	How far may this agent go before it stops	A single global "trust" setting
Budgets	How much may this cost before someone is asked	A bill you read after the spend
Verifiers	What gate does the output pass before it counts	"The agent said it is done"
Plan and risk score	Does this run need a human before it starts	Finding out it was risky from the outcome

None of these are exotic. Each one is the specific control that stops a specific failure. Assembled, they are the difference between running a company with AI and being run by it.

Turn recurring work into deterministic workflows

The first move is to stop asking an agent to figure out a recurring job from scratch each time. Recurring work has a shape. Pin the shape down.

A deterministic workflow is an explicit graph of steps, not an open-ended instruction. Steps can branch on a condition, pause for an approval, run a verifier, and retry on failure within a limit. Every step leaves a log of what happened. A run you can read is a run you can trust to do the same thing next week — and to tell you precisely where it went wrong when it does.

This is the opposite of "handle the marketing." It is: pull the leads from this source, match each to an angle, draft the batch, check the do-not-contact list, stop for your approval, send, record what went out. The steps do not drift between runs because they are not regenerated between runs.

Not every job deserves this. A one-off task, or a job that changes so much that nothing carries over, is better left as a quick chat. Determinism is a cost you pay once for work that genuinely repeats. Pay it only there.

Route every judgment call to one inbox

Once work runs on its own, the danger is that the decisions it needs scatter. A blocker in a log. An approval in a chat. A question nobody sees until the run already guessed. The fix is a single place where everything that needs your judgment arrives.

An inbox is not a notification feed. A notification says something happened. An inbox item says someone must decide something — approve this draft, answer this question, review this failed check, accept or reject this proposed follow-up. After setup, this is where most of your time goes: not watching runs, but clearing the small set of decisions only you can make.

This is what makes delegation real for one person. You are not in the loop on every step. You are in the loop on exactly the moments where your judgment changes the outcome, and nowhere else.

Set an autonomy level per agent

A global trust dial is too blunt, because the same agent doing different work warrants different freedom. Autonomy is better set per agent, as a level you can name and change.

Level	The agent...	Fits work like
Supervised	Proposes, and you approve before most actions	Anything customer-facing or irreversible
Balanced	Acts alone on routine steps, stops at defined gates	Drafts, research, internal docs
Autonomous	Runs the workflow end to end, surfacing only exceptions	Well-verified recurring jobs with a strong gate
Full autonomy	Runs without routine approval gates	Low-blast-radius, easily reversed, repeatedly proven work

Read the table top to bottom and the rule is plain: autonomy rises only as the cost of a mistake falls and the strength of the gate rises. Full autonomy is not the goal you graduate toward for everything. For a pricing change, a customer reply, or anything you cannot cleanly undo, it is the wrong choice — and saying so out loud is part of the model, not a failure of it. Start an agent supervised, watch a few real runs, and move the level only when the evidence earns it.

Cap spend with budgets

An agent has no instinct for "enough." Told to keep going until done, it will keep going — retrying the expensive step, calling the costly tool — and the spend is invisible while it happens and obvious only on the bill.

A budget makes the ceiling a decision instead of a discovery. Set a money budget and a token budget on the work. As it runs, you get an alert at 80 percent of the limit, and at 100 percent the agent does not push past it — it pauses and must request more, which arrives in your inbox as a question before the money moves, not a receipt after.

The honest tradeoff: a budget set too low stops legitimate work that needed one more pass, and you will sometimes approve more in the moment. That is the point. You can always grant more budget. You cannot un-spend money on work you never agreed to.

Gate output with verifiers

Most company work has no compiler. There is no test suite for an investor update, no CI for a support reply, no pass or fail signal for whether a marketing draft is good enough to send. The black box treats "the agent says it is ready" as the gate. That is not a gate.

A verifier is an explicit check the output must pass before it counts. Some verifiers are automatic — a command runs, a link resolves, a required field is present. Some are a human approval, which is a real verifier when it has a named owner and leaves a record. Some are a structured review checklist. The rule is that the gate is named before the output is trusted, and that a failed gate creates an inbox item rather than passing quietly.

Match the verifier to the work. A code change can lean on tests and a reviewable diff. A pricing email cannot — its gate is a person. The weaker the automatic check, the more the gate has to be you.

Have each task plan and score its risk before it runs

The last part is what most directly answers the "set it and forget it" temptation. Before a task acts, it can plan: write a short work spec describing what it intends to do. And it can score the risk of that plan across four dimensions, so the decision to require a human is made before the run, not after the damage.

Risk dimension	The question	High score means
Blast radius	How much does this touch if it goes wrong	Many systems, people, or records affected
Novelty	Has work like this run and succeeded before	New, unproven, or one-of-a-kind
Sensitivity	Who sees or feels the outcome	Customers, money, public, or legal exposure
Reversibility	How cleanly can this be undone	Hard or impossible to take back

A low-risk plan — small blast radius, proven before, internal, easily reversed — can run within its autonomy level without interrupting you. A high-risk plan gates: it lands in your inbox with its spec and its scores attached, and waits. This is the mechanism that lets you run an agent autonomously on the routine ninety percent while still catching the risky ten before it acts, rather than reading about it afterward.

Where this stops being a diagram

These six parts are the operating model behind Task Machine, and they are how it reads "run your company with AI" — not as a box that runs itself, but as a system you assemble and stay on top of.

You work it through three connected surfaces. You use chat to set direction and fan work out into tasks, agents, and workflows. You use the inbox to approve, answer, and review everything that needs your judgment. You open a task to dig into the detail of one piece of work. Chat to direct, inbox to approve, tasks to dig in.

Underneath, the parts map directly. Recurring work runs as deterministic workflows with branch, approval, verifier, and retry nodes, each leaving step-level logs. Every agent carries an autonomy level — Supervised, Balanced, Autonomous, or Full autonomy. Money and token budgets ride with the work, alert at 80 and 100 percent, and pause the agent to request more rather than overrunning. Planning writes a work spec and scores blast radius, novelty, sensitivity, and reversibility to decide whether a run gates for approval. Agents reach the tools you already use through MCP-backed connectors, and you start not from a blank configuration but from a playbook in the catalog — a job-specific bundle for recurring work like outreach, content, or status reports.

Be clear about where agents run. They execute on your own machine — through Codex, Claude Code, Opencode, Pi, OpenClaw, or Hermes — where your files, CLIs, and project tools already live, so they act in the real environment instead of a sandboxed copy. The tradeoff is that the machine has to be reachable when a job runs.

The honest limit of the whole model

This model asks more of you than the black box does. You decide the autonomy level, set the budget, define the gate, and clear the inbox. It is more setup than describing a company and walking away, and for genuinely one-off or constantly-changing work it is more structure than the job is worth.

That cost buys the one thing the autonomous-company pitch cannot: the company runs your way on purpose. Full autonomy stays the wrong choice for irreversible, customer-facing, high-stakes work, and the model is built to say so rather than paper over it. What you get back is the afternoons — the recurring work runs without you watching every step, and your attention goes only to the decisions that are actually yours to make.

If that is the trade you want — agents doing the recurring work, you keeping the decisions that matter — join the private beta on the waitlist, and bring the one recurring job you are most tired of redoing.