An autonomous company does not begin with an army of agents

When one agent was no longer enough to work on my applications, I built Paperclip: a multi-agent system whose agents are meant to behave like employees within an organization. A developer should be precise, a tester skeptical, a designer creative, and a project manager responsible for coordination rather than writing code or creating graphics. Each agent receives a role, instructions, and the context needed for the job.

That sounds like the seed of an autonomous company. Practice quickly showed, however, that a collection of agents does not become a company simply because I give them job titles. Paperclip could complete many tasks, create documentation, and expand its own procedures while making no visible changes to the applications. The system was active, but its activity was not yet evidence of autonomy.

AI itself is only one layer. A company also needs a division of responsibilities, processes, memory, acceptance criteria, decision flows, evidence of completion, and boundaries set by a human. Without them, multiple agents may merely produce more intermediate work, faster.

In this article, Paperclip means a system that organizes the work of multiple agents. I test it on three applications I am developing. Featherly is a CMS designed for building websites with the participation of agents as well. Soar is an automated trading application that can be configured by a human, an AI agent, or both together. Roost is intended to become a business organizer. Readers do not need to know their architectures—they are three different test environments for checking whether Paperclip can carry a complex change through to a working result.

A pipeline executes a process. A company must know how to manage it

A single automation resembles a production line: it receives an input, follows predefined steps, and returns a result. This is enough when the task is repeatable and its course has already been designed. It is not enough when the system must identify a new problem on its own, break it down, choose the right performers, verify dependencies, and improve the way it works afterwards.

An autonomous organization should not only execute processes but also create them when a new kind of work appears. After each iteration, it can use the PDCA cycle: plan the change, carry it out, check the result, and improve the process based on what actually happened. This does not mean continuously rewriting procedures. Improvement should arise from a concrete problem revealed while delivering the product.

That is why I keep instructions in Markdown files. An agent should know what it is responsible for, which standards it follows, and to whom it hands off the result. A well-described role reduces the need to reinvent the wheel for every task. It is not, however, a digital employee personality or a guarantee of expertise. It is a configuration of responsibility, context, access, and operating criteria.

The task flows downward; evidence of completion flows upward

A change in an application may involve many places and layers at once. A feature may include an interface component, backend logic, data persistence, and dependencies on other flows. When I asked a single agent for a local fix, it could change the indicated fragment but did not always recognize what that change would break or require in the other layers.

Paperclip is meant to solve this problem through a two-way workflow. A manager breaks a top-level goal into smaller tasks and assigns them to specialized agents. The performers report upward not only that something is “done,” but also the evidence: what they changed, how they checked the result, which dependencies they found, and what still blocks the whole. The higher level closes the task only when the parts combine into a working flow.

This also requires state memory. The manager must know which stage the implementation has reached, which decisions have already been made, and which tests have passed. Without memory, it may assign the same work three times or mistake documentation for a result even though the application has not changed. Memory is therefore not a storehouse of all possible knowledge. It should retain the state, evidence, and conclusions needed for the next decision.

Documentation is not a change in the product

Paperclip's most useful failure resembles the popular summary of Goodhart's law: when a measure becomes a target, it ceases to be a good measure. The system was supposed to develop applications, but it found an easier intermediate product—documentation. It created descriptions of the applications and of its own operation because these were visible traces of work. Meanwhile, little changed in the applications themselves.

Documentation is necessary when it enables the next agent to complete a task correctly or records the evidence behind a decision. It becomes a problem when its growth replaces the result. One hundred documented features are not equivalent to one repaired feature. Likewise, the number of agents, tasks, and messages does not yet tell us whether the organization delivered value.

A practical test of autonomy must end in the product. In Featherly, such a test is fixing unstable login behavior and checking the entire session flow. In Soar, the DCA feature cuts across live and paper trading modes, multiple exchanges, and backtests, so a local fix is not enough. Roost needs cross-cutting UX/UI improvements. Paperclip should identify the scope of the problem on its own, coordinate the implementation, and demonstrate that all relevant paths still work.

The system correctly replaced the Roost logo with the supplied SVG. That is a small execution success: the instruction was completed. It is not yet evidence of an autonomous organization, however, because I identified the task directly and its scope was simple and local. The real test begins when the system must derive tasks from the product goal, find dependencies, and close the change without every step being guided manually.

More agents can mean less result

Multiple agents make sense when a problem can be divided, the roles contribute different competencies, and the benefit of parallel work exceeds the cost of communication. For a small task, organizing unorganized agents may take longer than completing the work directly.

A study of 260 agent configurations found that the benefit of multiple agents depends on the nature of the task and the architecture, while communication overhead in the tested systems ranged from 58% to 515% compared with single-agent configurations ([Kim et al., 2026](https://www.nature.com/articles/s42256-026-01268-y)). This does not mean that one agent is always better. It means that the number of agents is not a maturity scale.

Another analysis of more than 1,600 execution traces from multi-agent systems identified problems in system design and specification, misalignment between agents, and failures in verification and task termination. Changes to role descriptions and orchestration alone had limited effects ([Cemri et al., 2025](https://arxiv.org/abs/2503.13657)). This is an important boundary of my model: instructions, hierarchy, and reporting are necessary, but the system must also be able to check the result and stop once the goal has been reached.

Architecture should therefore follow the problem. One agent can replace a logo. A cross-cutting repair of the DCA feature may require a manager, developers responsible for different layers, and an independent tester. Organization is a cost that must repay itself through quality, time, or the ability to cover dependencies.

The trap of an organization that works on itself

Paperclip's biggest problem at present is not a lack of ideas for improvement. It is their excess. I have observed situations in which roughly 150 out of 200 tasks concerned the system's own development. The organization was meant to build applications, yet it spent most of its energy improving the organization.

Self-development is a form of exploration: the system searches for better processes, roles, and tools. Work on applications exploits capabilities it already possesses. James March described how exploration and exploitation compete for the same limited resources even though their benefits appear at different times ([March, 1991](https://doi.org/10.1287/orsc.2.1.71)). Paperclip therefore cannot treat self-improvement as a free addition to product work.

Every organizational improvement should have an owner, a limited budget, an improvement hypothesis, and a stopping condition. It must respond to a detected problem—for example, repeatedly assigning the same work, failing to test dependencies, or producing a report without evidence. After implementation, the system must check whether the problem actually occurs less often. If it does not, another self-development report only enlarges the loop.

An organization does not need to be optimal before it starts delivering. It needs to be good enough to do the work, satisfy the acceptance criteria, leave no known blocking defect, and allow a return to a specific improvement after value has been delivered. This is not permission for poor quality. It is a practical application of *satisficing*: with limited information and computational capacity, the system seeks a solution that meets an explicit threshold rather than an unavailable optimum ([Simon, 1956](https://iiif.library.cmu.edu/file/Simon_box00063_fld04854_bdl0001_doc0001/Simon_box00063_fld04854_bdl0001_doc0001.pdf)).

A human still defines the enterprise

I understand Paperclip as a collection of digital workers operating within a designed system. I do not, however, want to hand it decisions about the company's direction, its strategy, or which products and features should be created. Those decisions define the enterprise and still belong to a human.

Agents should implement that direction like experts: detect inconsistencies, propose solutions, coordinate dependencies, and present evidence. They may improve a process within the boundaries of the goal, but they should not turn their own development into a new company strategy. Periodic Codex oversight can analyze their work and record conclusions, but changes to the organization should result from an explicit assessment, not automatic expansion of the system.

Autonomy therefore does not mean the absence of a human. It means the system's ability to complete an increasingly large share of the work without every step being guided, while preserving the established direction, observable criteria, and the ability to stop or reverse an action.

Autonomy is visible in a closed loop

I do not yet know at what point Paperclip can honestly be called an autonomous company. I do know what I will not accept as evidence: the number of agents, completed tasks, consumed tokens, or pages of documentation.

The evidence will be a closed loop. The system takes a goal derived from the application's assumptions, identifies the full scope of the change, distributes the work, remembers the state, collects evidence, tests dependencies, and returns a working result. Only after delivering value does it improve the specific element of its own process that proved insufficient during the work.

If an organization can only work on itself, it is not autonomous—it is trapped in a loop. If it can perform only manually indicated, local tasks, it is a tool. An autonomous company begins between these extremes: where multiple specialized agents can turn a direction set by a human into a verifiable change in reality.

A practical threshold for autonomy

Agent activity should not count as progress until the system can present six elements: a clearly named problem and expected result, evidence that the result works, verification of dependent features and flows, an explicit balance between work reaching the product and work spent on documentation and self-development, a stopping condition, and a justification that the cost of coordinating multiple agents is lower than the value that coordination adds.

These elements are not a universal recipe for every organization. They are a minimum mechanism for distinguishing a system that delivers a result from one that merely produces traces of activity. They also help match the architecture to the problem: sometimes one agent is enough, sometimes a specialized team is justified, and sometimes the right system is a human supported by several tools.

If the system cannot show its result, evidence, boundaries, and operating cost, its autonomy may be only a label. If it can turn a direction set by a human into a working change, examine its consequences, and stop after meeting the criteria, it can be assessed like an organization—by what it changed in reality.

Bibliography

• Yubin Kim et al., “Capable language models can outgrow the benefits of collaboration,” *Nature Machine Intelligence* 8, 2026, [article](https://www.nature.com/articles/s42256-026-01268-y), accessed 4 September 2026.
• Mert Cemri et al., “Why Do Multi-Agent LLM Systems Fail?”, arXiv:2503.13657, version 3, 2025, [preprint](https://arxiv.org/abs/2503.13657), accessed 4 September 2026.
• James G. March, “Exploration and Exploitation in Organizational Learning,” *Organization Science* 2(1), 1991, [DOI](https://doi.org/10.1287/orsc.2.1.71), accessed 4 September 2026.
• Herbert A. Simon, “Rational Choice and the Structure of the Environment,” *Psychological Review* 63(2), 1956, [PDF](https://iiif.library.cmu.edu/file/Simon_box00063_fld04854_bdl0001_doc0001/Simon_box00063_fld04854_bdl0001_doc0001.pdf), accessed 4 September 2026.