Organizing agents like a company lifts PRDBench success to 84.67%

In LLM land we are used to measuring progress one hero at a time: who writes better code, who handles websites more carefully, who calls tools more reliably. But as soon as a task gets long, layered and genuinely work-shaped — with dependencies, checks, rework and different roles — the magic of a single agent runs out fast. What is needed is not a pile of bots but something more: structure, management, a memory of past mistakes, a mechanism for hiring and firing. That gap is exactly where OneManCompany, or OMC, lands.

When being smart is no longer enough

The authors want multi-agent systems seen not as a few roles in a chat but as a full AI organization. With a CEO, an HR function, a COO, a marketplace of specialists, a task queue, and even formal procedures like result review and a performance improvement plan. And more to the point, this is not just a pretty metaphor. On the PRDBench benchmark the system solves 84.67% of tasks — 15.48 percentage points above the previous best result.

What the authors actually propose

The core claim of the paper is simple: today's multi-agent systems are missing an organizational layer. Most of them run in one of two modes. The first is a fixed pipeline: roles are spelled out, message routing is known, the steps barely change. The second is looser, with agents working things out on the spot, but with no guarantee they ever reach a result instead of stalling in endless discussion.

OMC tries to take what works in real companies and port it into AI systems. It rests on three pillars:

1. Employee management: an agent is not a prompt, it is a formalized "employee" with a role, tools, a history and an execution environment.

2. Task decomposition and control: work is broken into a tree of subtasks with dependencies and a mandatory review of the result.

3. Organizational evolution: the agents and the "company" itself learn from experience instead of starting from zero in every new session.

This matters for one reason: if we want AI to do more than make a single move — to run a project — we need a governed structure, not just a strong executor. And that is exactly the paper's claim: the next big improvement in agents will come not only from stronger models but from better organizational architecture.

The agent as an employee: talent plus container

One of the better moves in the paper is splitting an agent in two: talent and container.

Talent is who the agent is: role, working principles, skills, tools, domain knowledge. The container is where and how it runs: a LangGraph environment, Claude Code, or a plain scripted runner. Together they make an employee.

Why is that smart? Because in a real company it hardly matters which laptop the designer sits at — what matters is what they can do and how they fit into the process. Same here: one role can in principle live in different runtimes, and very different agents can coexist inside one organization.

The authors standardize interaction through six interfaces: execution, task management, events, storage, context collection and lifecycle. It is essentially an attempt to give an agent organization something like an operating system: any new runtime just has to honor the contract instead of breaking the whole platform.

In practice that fixes several chronic pains of multi-agent systems at once:

On top of this comes a talent market — a catalog of vetted agents that can be hired on demand. That is an important detail: instead of conjuring up a new specialist with a single prompt, OMC tries to pull in agent packages that are already assembled and tested. Not "imagine you are an architect," but "here is a real architect agent, with tools, settings and a quality track record."

How OMC gets work done: explore, execute, review

The heart of the paper is a mechanism with a slightly unwieldy name — Explore-Execute-Review — which the authors shorten to E²R.

The idea is to treat a project as a decision tree. First the system explores how to break the task into subtasks and who to assign them to. Then the employees execute their part. Then the result is reviewed, and if something does not pass, the system does not simply report an error — it returns to a fresh decomposition or another execution pass.

This reads like an attempt to formalize what happens naturally in a functioning company: split the task, assign owners, get an artifact, review it, rework it, and only then pass it further down the chain.

The valuable part here is not the loop itself but the formalization of dependencies. Tasks form not just a tree but a directed acyclic graph: subtasks have dependencies, and the next piece of work does not start until the previous one has been accepted. That can sound like a dull infrastructure detail, but it is often what separates a working system from a demo.

The authors even define a finite state machine for a task: pending, running, done, accepted, failed, blocked and so on. The key rule: moving from "done" to "accepted" requires an explicit review. A result cannot quietly declare itself valid and unblock the downstream branches.

This is one of the strongest engineering points in the paper. A lot of agent pipelines break not because the model cannot do the work, but because an error is declared a success too early — and the whole system then builds its next step on a false foundation. OMC is trying to cut exactly that channel for spreading hallucinations.

Why the PRDBench numbers look serious

The main quantitative check is PRDBench, where the system has to solve software project tasks built on product requirements. These are not small "fill in this function" exercises but something closer to real work: read the spec, break down the work, write the solution and pass an automated evaluation.

In single-attempt mode, with no iterative help from a human, OMC reaches 84.67% success. That is higher than the strong single-agent systems and commercial agents listed in the paper. The gain over the best baseline is 15.48 percentage points.

What is behind that, in the authors' view?

First, dynamic decomposition. The system does not freeze the plan at the start; it can restructure the tasks as work proceeds.

Second, a mandatory review loop. An unreviewed result does not move forward.

Third, a heterogeneous team. One project can combine different kinds of agents and match each subtask to a better-suited executor.

The price for this is cost: roughly $345.59 for 50 tasks, about $6.91 per task. For simple requests that is expensive. But the authors never claim OMC is needed for every chat with a model. Their argument is different: when the task is a project and the cost of an error is high, the organizational layer can pay for itself.

The case studies matter more than the scores

Honestly, it is the case studies that make the paper come alive. The authors show that OMC can do more than write code. From a single sentence, for example, the system assembles a team to produce a weekly digest of trending repositories, hires a researcher and a writer, gathers the data, writes the text and sends the email. Cost: about $4.49.

There is also a game development case: a developer agent and an artist agent build a browser fighting game, an external evaluator finds a problem with the sprites, and the system does not just redo the artifact — it effectively creates a new skill for the artist, slicing sprite sheets into correct frames. That looks less like a script and more like an organization retraining an employee around a problem.

Another case is an automated research survey on world models for embodied AI and robotics. The system hires three specialists, splits up the research, gathers 18 documents, builds a literature map and proposes three research ideas. It is no replacement for a research group, of course, but as a demonstration of range it is convincing.

What do all the cases have in common? Not the specific models but the same management logic: hire, break down the work, assign, review, keep the experience. That is the paper's central argument for the "organizational" view of agents.

Where it is weak

The work is strong, but it is not without questions.

The first limit is that the main quantitative evaluation still covers only software development tasks. Yes, the case studies go wider, but there is no systematic benchmark outside programming yet.

The second is that the paper almost certainly benefits not only from the high-level idea but from a large number of engineering safeguards. That is not a flaw, rather the opposite. But the question remains: how much of the success comes from the organizational principles and how much from plain solid execution discipline, queues, checks and a good choice of agents.

The third is cost and complexity. OMC looks like a system for expensive, long, risky tasks. For simple scenarios it will be overkill. The authors admit as much, suggesting a fallback to a single agent when the task is small.

Finally, there is a conceptual risk: the company metaphor is very appealing, but any metaphor can overpromise. There is no guarantee that HR processes, onboarding and corporate rules turn out to be a universal recipe for every form of AI coordination. As a research frame, though, this is unquestionably a powerful step forward.

Why this paper genuinely matters

Because it moves the conversation. For the past year the industry has mostly argued about which agent is better. This work proposes a more mature question: how the organization of agents itself should be built.

It is like going from "which programmer is stronger" to "how do you set up a team that ships reliably." For real work, the second question is often the more important one.

OMC does not prove that the future belongs to AI companies in the literal sense. But the paper makes a convincing case: separate an agent's abilities from its place in the org structure, add governed hiring, formal review and experience carried between projects, and you get a noticeable quality gain on hard tasks.

The takeaway

OneManCompany is one of those works that is interesting not only for its result but for the change of perspective. The authors suggest we stop thinking of multi-agent systems as a set of roles in one chat and start building them as organizations: with employees, a market of competencies, tasks, processes, review and institutional memory.

On PRDBench that buys a strong gain in quality. In the case studies it buys impressive range: from content work to games to research surveys. Yes, the approach is expensive, heavy and not yet tested everywhere. But it has something many agent papers lack: not one more orchestrator, but an attempt to answer the question of how AI systems should work as a collective.

And this may really be the next big layer in agent engineering: not another super-agent, but a well-run company of agents.