How to Run a Company with AI Agents

When you use AI tools, you still carry out the work: ask for a draft, move it into place, start the next task. In this model, the agent carries the job through its permitted steps, asks for judgment when it reaches a boundary, and returns something that can be checked.

“Owns an outcome” means responsibility for the work within a charter, a written job description with limits. It does not mean an agent chooses the company’s purpose or gets unlimited authority. The Example team page makes the division of responsibility visible: the agents, their roles, and their status.

1. Give each area of work an owner. Write what the agent owns, what it may decide, when it must ask for a decision, and the evidence required to close the job. A name tells you who is responsible; the charter sets the limits.
2. Make handoffs explicit. Agents coordinate on a shared message bus instead of routing every request through me. A useful handoff identifies the work, the decision needed, and the evidence the next agent should inspect.
3. Schedule attention. A heartbeat runs an agent on a schedule; it first checks whether work is due and exits when nothing is, then checks messages and decides what to advance. Waking up is a reason to inspect, not an obligation to produce something new.
4. Separate the gates. One judgment asks whether the work is built right. Another asks whether it serves a real customer and can earn. Ask whether the idea is worth building before execution, too.
5. Close with evidence. The receipt must show the actual result. A deployment is evidence of deployment; a working user journey is evidence of function; neither alone proves revenue.

“We gave two different agents the power to block a release — on purpose.” records why I separated technical readiness from commercial judgment. Both owners can block a release. A product is only done under that rule when it is in-market and earning.

For the mechanics behind that loop, read AI Agent Operations: Orchestration, Buses, Gates & Receipts: how the bus keeps handoffs stored, heartbeats schedule check-ins, and gates require evidence from the live result.

To put the charter to work, use Delegating Real Work to AI Agents and Verifying It: a first job with clear limits, a reusable charter, evidence for accepting the work, and a stop-list.

Before work starts, I need to be clear about the customer’s problem and what result would count. While the work runs, an agent asking for help should bring me a specific decision. Before I accept the work, I need evidence that answers the original question. An account of how busy the agents were leaves that question open.

The distinction shows up in “98 commits in a week. The commit count tells me almost nothing.”: agents produced 98 commits in a week, while my review focused on what to accept. Whether someone could log in, see the right information, and use the page without a mouse mattered more than the count.

Write down what must be true to accept the work before the review runs. For a save action, check that the saved state survives a reload. A success message only proves the page displayed a message. Give the reviewer the authority to hold the release, and require evidence to clear each finding.

“I don't let my own AI say a high-stakes release is done. A rival AI signs off first” records a release held after the outside verdict came back not ready. It also records false findings from the auditor. Different blind spots help, but neither model gets to win by assertion.

“A green checkmark that isn't the AI's own word: building a quality check with teeth” describes 24 out of 24 controls falsely failing because the checker was broken. The hardened gate kept 344 unchecked items marked NOT-CHECKED and made an all-waived result invalid. A gate needs to resist status gaming, and it needs to be checked itself.

A plausible answer rests on the wrong premise.

Have the reviewer question the scope and interpretation as well as the conclusion. In “I don't let my own AI say a high-stakes release is done. A rival AI signs off first”, a rolling 28-day metric had been read as a daily one.

The green check is easier to produce than the outcome.

Require evidence of the user journey, keep unchecked work separate from passed work, and verify that the gate actually runs. “A green checkmark that isn't the AI's own word: building a quality check with teeth” shows why tests of the checker alone are not enough.

Every heartbeat becomes another unnecessary task.

Allow a logged refusal. In “The smartest thing my night-shift agent did all month was refuse to publish”, a content agent declined a ninth near-identical post and improved 16 live posts instead. Review the reason for doing nothing alongside the reasons for shipping.

I want the record to include held releases, unanswered checks, and justified refusals. Removing those makes the dashboard easier to admire and harder to trust.

Read the homepage operations panel and cumulative track record alongside the Example team page and AI Guides. The panel shows activity; the examples explain the job, the check, and the cost. The 98-commit week is a separate historical window in “98 commits in a week. The commit count tells me almost nothing.”. Its rate is independent of this snapshot.

“I put my AI staff on a payroll page — with real commit counts and blanks where I don't measure yet” explains the measurement boundary: the staff activity counts cover a trailing seven-day window, and unmeasured fields stay blank. None of these counts establishes profitability, customer satisfaction, or a promise about what another company can ship.

Source note: the linked examples are my published operating accounts. Their underlying evidence records do not currently have public artifact links. They support the account given here; they are not an independently audited performance dataset.