How to run a company with AI agents you can review

Most guides to running a company on AI agents count what you can start. The number that decides the outcome is smaller: how much work one person can read. Kortix is the open-source CompanyOS: your agents, their skills, your company memory, and every connector in one git repo you own. The way to size a company on it is by the review you can staff.

The review sets the size of the company

The experiment is worth reading for its org chart and its audit, which disagree. One public experiment ran seven agents on a single 4GB Hetzner VPS. Inside a week they founded a company, pivoted the business model and shipped a product with 158 tests. Its own audit found two of the seven doing the work.

The org chart: a CEO called Atlas, a CTO called Vega, and five specialists under them. Each of the two main agents ran as its own Linux user with its own OpenClaw gateway on a different port. The five sub-agents were spawned by those two gateways when needed. The owner checked in about once a day to approve the big calls, and that part held.

The audit is where the count collapses. Atlas and Vega were functional. DevAgent and TesterAgent were not, and the agent that built the 158-test product had no name. SalesAgent, MarketingAgent and SupportAgent were declared in the config and never activated, and the author calls them "job descriptions for positions that were never filled." His fifth lesson is the one to keep: "Start with two agents, not seven." The audit that found this ran after the product shipped.

One job per reviewer

Size the company by the desks. Every agent's output should land on one named person who has agreed to read it. Two agents can share a reviewer when their jobs are small. At five, the reading is a full day's work for one person. The experiment's CEO was supposed to check on his sub-agents, and the audit notes that he forgot.

In Kortix a role is one agents.<name> block in kortix.yaml, with its prompt, its model and its permission. Put the reviewer in the same block, in the description. The reviewer's name then sits beside the agent's, in the file a person opens before the first run.

A finish line a reviewer can check in a minute

A finish line names conditions a reviewer can check: the ticket has a reply, the reply cites an order number, and no refund went out without approval. Each condition is visible in the diff, so the review is a check against a list.

Write the finish line in two places: the prompt file the agent reads, and the body of the change request it opens. The experiment's owner had to audit seven agents after the fact to learn what they had done. A finish line in the change request body puts the same three conditions in front of the reviewer at merge time, while the diff is still open.

Memory that arrives as a diff

The experiment's memory was markdown files per agent: identity, personality, the owner, the tools, a heartbeat, a dated journal. The files were well designed. Within a week half of them were out of date. All seven agents still carried the same default SOUL.md, the personality file. Two of them, DevAgent and TesterAgent, still had the blank IDENTITY.md template.

After the MVP shipped, the owner ran a full audit of every agent's files, and that audit is where the stale files surfaced. A memory file that changes in place, with no record of who changed it, is a claim the next session has to trust. Kortix keeps memory in the project repository. An agent that changes the project itself, such as a skill or its memory, opens a change request. The write arrives as a diff: three lines added to a customer note, one line removed from a role file. A person reads it in the same pass as the code, and a wrong line shows up in the diff on the day it was written.

A grant list narrow enough that the diff is boring

Permissions decide how big a diff gets. An agent that can reach ten systems produces changes in ten systems, and the reviewer has to know all ten. An agent that can read one help desk and write one folder produces a diff with a shape you can hold in your head.

Kortix starts permissive: policy.default_mode falls back to allow_all, so the first session runs and asks nothing. Set it to risk before the first run. Add a block rule for the calls that must never happen, and give a held call a time limit. Then grant by name. An omitted grant grants nothing, which is why kortix validate prints none (default-deny) for an agent that lists no skills, commands or secrets.

The support-desk example in the kortix.yaml reference is the shape to copy:

# yaml-language-server: $schema=https://kortix.com/schema/kortix.schema.json
default_agent: support
project:
  name: support-desk

env:
  required: [HELPDESK_TOKEN]
  optional: [STRIPE_API_KEY]
# Registries: what the project has. A registry entry gives nothing to any agent.
skills:
  refund-policy: skills/refund-policy
tools:
  lookup_order: tools/lookup_order.ts
commands:
  triage:
    description: Sort a ticket by urgency.
    prompt: "Read ticket $1 and reply with its urgency: low, normal or high."
  weekly-report:
    description: Write the weekly support report.
    prompt_file: commands/weekly-report.md
extensions:
  web-access:
    pi: npm:pi-web-access@0.30.0
connectors:
  - slug: helpdesk
    provider: http
    base_url: https://helpdesk.example.com/api
    auth:
      type: bearer
    policy_sets:
      read-only:
        description: Reads only.
        policies:
          - match: "get_*"
            action: always_run
          - match: "*"
            action: block
policy:
  default_mode: risk
policies:
  - match: "helpdesk.delete_*"
    action: block
approvals:
  ttl: 4h
# Agents: each one enables registered things by name.
agents:
  support:
    description: Answers help desk tickets.
    mode: primary
    prompt_file: agents/support.md
    permission:
      bash:
        "*": allow
        "git push *": ask
    tools: all
    skills: [refund-policy, kortix-cli]
    subagents: [researcher]
    commands: all
    extensions: [web-access]
    connectors: [helpdesk]
    secrets: [HELPDESK_TOKEN]
    kortix_permissions: [project.session.read, project.gitops.push]
    workspace: { project_repository: true }
  researcher:
    description: Looks up an order's history. Never edits files.
    mode: subagent
    prompt: You research orders and report what you find. Never edit files.
    permission:
      edit: deny
    tools: [read, glob, grep, lookup_order, web_search]
    connectors: [helpdesk]
    policy_sets:
      helpdesk: read-only
triggers:
  - slug: weekly-report
    name: Weekly report
    on:
      cron: "0 0 9 * * 1"
      timezone: Europe/Berlin
    run:
      agent: support
      prompt: Write the weekly support report for the last 7 days.

Read the two agents against each other. The support agent may run any shell command, but a git push asks first, and every connector it can reach is named. The researcher gets four read tools and one lookup, and cannot edit a file. It reaches the help desk through a rule set that allows reads only. Neither agent can do something its block does not name, and the researcher cannot write a file at all, so its output is a report.

A schedule that produces reviewable work

The experiment kept time with cron. A health check every five minutes restarted a dead gateway, and a summary script at midnight wrote a markdown report with uptime stats and the day's events. Both ran as scripts on the same VPS as the agents.

A trigger should produce one artifact per run that a reviewer can read: a report, a triage pass, a draft. Kortix triggers start a session on a cron schedule with nobody at the keyboard. The one in the example runs the support report every Monday at 09:00 Berlin time, so each run ends with one report for one reader.

Then set the ceiling. Decide how many sessions a day the schedule may start, and what a day may cost. Write both down before the first tick, and read the run log at the end of week one against both numbers.

Size the company to the review, then widen

Start with one job that a person already does every week and can judge in a minute. Give it one agent, one reviewer, one finish line and a grant list you can read in one screen. The experiment's own advice points the same way. Its own tally: two agents functional, two half-configured, three barely initialized.

Widen when the diff is boring. A boring diff means the finish line held, the memory change was small, and the grants were tight enough that nothing surprising appeared. Add the second job after that, then the second reviewer, then the schedule.

If you want the longer argument behind the file layout, read what an agentic company is and why an AI-first company needs an operating system.

Try Kortix. Free to start, free to self-host.