Virtual organizations of autonomous agents

This research field asks how a company works when most of its staff are software agents. “Virtual organization” is my name for it. I apply it in client work, on an information platform that is built with a changing set of agents from different harnesses, among them Claude Code and Codex. Two arrangements exist: agents with roles on an orchestration server, and parallel coding sessions in one repository under rules that hooks enforce. The dated account of the first arrangement is in the blog post Running a company of AI agents.

An org chart of agents

A self-hosted open-source control plane holds issues, goals, confirmations and approvals. The org chart has a CEO agent, a chief each for data, technology and marketing, and an engineer under the technology chief.

The delegation rule: a chief never executes. One task goes to one agent. The chief assigns an idle agent of its team or creates a new one and never assigns to a busy one, so the number of agents follows the number of tasks. Each code agent works in its own git worktree, commits under its own name and opens a merge request. The production branches are protected, so an agent’s key cannot push to production.

The human gate before production

The development environment is autonomous. Every production change needs a human confirmation, and an approval never carries over to the next change. The same holds for every push to the release branch. Questions of classification and every new type in the data model are also decided by a human.

Reports, clocks and jobs

An agent can do correct work and still report it wrong, because it counted against a wider scope than the task had. A report is therefore measured by a verifier that does not depend on the agent that did the work. The verifier is read-only and exits with an error outside the scope of the task. If the verifier and the agent disagree, the verifier’s number stands and the agent runs again.

A run and a task have separate clocks. The control plane ends a run after a fixed time, and the task behind it may need longer. An agent that waits inside a run is reported as timed out while its job goes on, so long jobs run detached and are polled, or they become child issues.

One job is in flight per agent, because a second job started by the same agent can destroy the first. Termination of an agent is irreversible in the control plane, so an agent is never terminated.

Rules as machine checks

Rules in prose do not bind an agent. A rule with a large blast radius therefore becomes a machine check: a hook that blocks the action before it happens. The blocked actions are writes to the live database, search reindexes, deletes of media on the servers and pushes to the production branch. Where an override exists, it is a file that a human creates and an agent never creates. The work page AI agents under rules lists the hooks.

One rule file serves every harness, so a rule is written once and holds in every session. Agent memory is a versioned file set that is mirrored into the repository. Both follow from one principle: the agent is replaceable. Identity, rules and provenance stay in the store, and a new agent or a new model picks them up from there.

Open questions

A hook binds only the harness that loads it. Agents on an orchestration server need their limits elsewhere: dispatch to development systems only, self-guards in the scripts and the human confirmation. Whether that is enough for more autonomy is open.

The main question is which decisions can leave the human queue without a loss of quality, and how that is measured.

A spoken overseer above several agent sessions is the second open question. Open are when it speaks and how a person addresses one session among several.