OneManCompany (OMC): AI Organizational Framework

• OneManCompany (OMC) is an organizational framework that treats multi-agent systems as self-governing entities with structured recruitment, coordination, and evolution.
• It introduces Talents as portable agent identities and Containers as execution substrates to decouple individual capabilities from organizational mechanisms.
• Empirical evaluations show that OMC achieves higher success rates and lower costs than baselines, demonstrating its practical value and formal guarantees.

Searching arXiv for the cited OMC paper and closely related multi-agent organization work to ground the article. I’ll look up arXiv entries relevant to OneManCompany and multi-agent organizational frameworks. Searching (Yu et al., 24 Apr 2026), "OneManCompany", and related multi-agent systems organization papers. OneManCompany (OMC) is a framework for elevating multi-agent systems from fixed team configurations to an organisational layer concerned with how heterogeneous agents are assembled, governed, and improved over time. The framework is introduced in "From Skills to Talent: Organising Heterogeneous Agents as a Real-World Company" (Yu et al., 24 Apr 2026), which defines an AI organisation as “a self-governing system of heterogeneous agents with structured coordination, managed lifecycles, and experience-driven evolution.” In this formulation, OMC separates what individual agents know from the organisational mechanisms that recruit them, assign them, coordinate their execution, and update them across projects. Its core constructs are portable agent identities called Talents, typed organisational interfaces implemented by Containers, a community-driven Talent Market, and an Explore-Execute-Review ($\text{E}^2\text{R}$) tree search that unifies planning, execution, and evaluation.

1. Conceptual scope and formal definition

OMC is presented as a response to three limitations attributed to prevailing multi-agent systems: fixed team structures, tightly coupled coordination logic, and session-bound learning (Yu et al., 24 Apr 2026). The central claim is that these limitations reflect the absence of a principled organisational layer. OMC therefore treats the multi-agent system not primarily as a collection of cooperating prompts or tools, but as an organisation with workforce composition, decision procedures, lifecycle management, and persistent evolution.

The formal definition given for an AI organisation is precise: it is “a self-governing system of heterogeneous agents with structured coordination, managed lifecycles, and experience-driven evolution” (Yu et al., 24 Apr 2026). This definition places governance and evolution on equal footing with task execution. A common misconception is to regard OMC as merely a larger multi-agent pipeline; the paper instead characterises it as an organisational abstraction that governs recruitment, decomposition, review, and adaptation over time.

The significance of this definition lies in the decoupling it introduces. The framework distinguishes between individual capability substrates and the organisational machinery that arranges them into a workforce. This suggests a shift from agent-centric design to organisation-centric design, in which the unit of engineering is not only the agent, but also the interfaces, policies, and lifecycle processes that allow agents to be composed and recomposed.

2. Talents, Containers, and the Talent Market

The basic unit of portable agent identity in OMC is the Talent $\tau$, defined as the tuple

$$\tau = (\text{role}, \text{principles}, \text{tools}, \text{skills}, \text{prompts}, \text{resources}).$$

Here, role is a textual or semantic contract such as “Frontend Engineer”; principles are working guidelines; tools are the authorised tool set; skills are small reusable modules; prompts are system or user templates; and resources are domain files or benchmarks (Yu et al., 24 Apr 2026). The paper’s formulation makes Talent a package of identity, capability, and operating constraints rather than a mere prompt template.

Execution is provided by a Container $V$, which supplies six typed organisational interfaces. An Employee is then defined formally as

$e = (\tau_e, V_e).$

This means that the same Talent can be hosted on any Container implementing the required interfaces, which is the paper’s main mechanism for backend heterogeneity (Yu et al., 24 Apr 2026).

Interface	Signature
Execution	execute(task, ctx) → (result, cost)
Task	enqueue(task); dequeue() → task
Event	publish(event); subscribe(filter)
Storage	read(key) → data; write(key,data)
Context	assemble(role, guidance, memory) → ctx
Lifecycle	pre_hook(task,ctx); post_hook(task,result)

The Talent Market $\mathcal{M}$ is the on-demand supply mechanism for Talents. It is described as a growing repository of packaged Talents sourced through three channels: Type 1 curated open-source agent repos, Type 2 prompt-sourced personas plus assembled skills, and Type 3 dynamic assembly from modular SkillsMP modules (Yu et al., 24 Apr 2026). Recruitment is formalised as an action

$$\alpha_{\text{recruit}} : \mathcal{M} \times \text{requirement} \rightarrow \{\tau_1,\ldots,\tau_k\}.$$

The HR agent ranks candidates, the CEO picks one, and the pipeline provisions $(\tau, V)$ (Yu et al., 24 Apr 2026). This design distinguishes labour supply from labour orchestration. A plausible implication is that OMC treats organisational staffing as a first-class computational operation rather than a compile-time configuration choice.

3. Explore-Execute-Review as organisational search

Project execution in OMC is modelled as a tree search over organisational strategies. The paper defines a tree

$\mathcal{T} = (V, E_{\text{tree}}, E_{\text{dep}})$

where $V$ is the set of task nodes, $\tau$0 are decomposition edges forming a strict tree, and $\tau$1 are execution-dependency edges constrained to be acyclic (Yu et al., 24 Apr 2026). Each node $\tau$2 carries

$\tau$3

with task description $\tau$4, assigned employee $\tau$5, FSM state $\tau$6, result $\tau$7, cost $\tau$8, workforce state $\tau$9, and resource state $$\tau = (\text{role}, \text{principles}, \text{tools}, \text{skills}, \text{prompts}, \text{resources}).$$0.

The action space is

$$\tau = (\text{role}, \text{principles}, \text{tools}, \text{skills}, \text{prompts}, \text{resources}).$$1

and a strategy is a sequence $$\tau = (\text{role}, \text{principles}, \text{tools}, \text{skills}, \text{prompts}, \text{resources}).$$2 with structural transition $$\tau = (\text{role}, \text{principles}, \text{tools}, \text{skills}, \text{prompts}, \text{resources}).$$3 (Yu et al., 24 Apr 2026). The policy $$\tau = (\text{role}, \text{principles}, \text{tools}, \text{skills}, \text{prompts}, \text{resources}).$$4 maps the current tree to a decompose-plus-assign plan,

$$\tau = (\text{role}, \text{principles}, \text{tools}, \text{skills}, \text{prompts}, \text{resources}).$$5

The shorthand

$$\tau = (\text{role}, \text{principles}, \text{tools}, \text{skills}, \text{prompts}, \text{resources}).$$6

denotes creation of a child node with description $$\tau = (\text{role}, \text{principles}, \text{tools}, \text{skills}, \text{prompts}, \text{resources}).$$7, assignment to employee $$\tau = (\text{role}, \text{principles}, \text{tools}, \text{skills}, \text{prompts}, \text{resources}).$$8, and dependency set $$\tau = (\text{role}, \text{principles}, \text{tools}, \text{skills}, \text{prompts}, \text{resources}).$$9.

The $V$0 loop repeats three stages until the root is resolved: Explore expands the tree via decomposition and assignment; Execute dispatches ready leaf nodes through the employee’s Execution interface; Review evaluates completed outputs and propagates acceptance or failure bottom-up (Yu et al., 24 Apr 2026). This is not a planner followed by a separate executor. Rather, planning, execution, and evaluation are embedded in one hierarchical control loop.

The review and aggregation semantics are also explicit. A node is resolved if it is a leaf with $V$1, or an interior node for which all non-system-generated children are resolved (Yu et al., 24 Apr 2026). Accepted-to-finished transitions auto-fire and can cascade upward. This bottom-up aggregation is described as AND-semantics: parent resolution depends on child resolution, and review is propagated through the tree rather than handled as an external scoring pass.

4. Scheduler properties, guarantees, and failure handling

OMC attaches formal guarantees to the $V$2 scheduler. The paper lists the following invariants and safeguards: DAG Invariant, Mutual Exclusion, Review Termination, Task Timeout, Cost Budget, Cascade Completeness, and Recovery Correctness (Yu et al., 24 Apr 2026). Concretely, decomposition and dependency insertion preserve acyclicity; for every employee $V$3, $V$4; each node is retried at most $V$5 times, with default $V$6; tasks exceeding $V$7 are marked failed; search pauses when $V$8; cancellations propagate to all dependents; and after a crash, processing nodes revert to pending and the scheduler resumes deterministically.

Two formal statements summarise the execution guarantees. The first is a termination lemma: under finite $V$9, $e = (\tau_e, V_e).$0, and budget $e = (\tau_e, V_e).$1, the loop can create at most

$e = (\tau_e, V_e).$2

nodes, each with at most $e = (\tau_e, V_e).$3 retries, and therefore must terminate in bounded time or trigger a circuit breaker (Yu et al., 24 Apr 2026). The second is a deadlock-freedom proposition: if no ready nodes remain and the root is not resolved, then either all non-root nodes are terminal or blocked; in the latter case a deadlock detector marks the project failed, so there is “no silent stall” (Yu et al., 24 Apr 2026).

These guarantees are notable because they move OMC away from purely heuristic coordination. A common misconception in discussions of multi-agent orchestration is that dynamic decomposition necessarily sacrifices operational predictability. OMC’s design attempts to preserve reconfigurability while still providing bounded retries, explicit budget checks, and failure escalation. This suggests an effort to make open-ended coordination compatible with systems-level runtime properties.

5. Three-layer architecture and organisational evolution

The paper organises OMC into three layers: a Digital Talent Layer, an Organisation Layer, and an Evolution Layer (Yu et al., 24 Apr 2026). The Digital Talent Layer consists of the Talent–Container harness, the six typed interfaces, and the Talent Market as an HR supply chain for on-demand recruitment. The Organisation Layer comprises the $e = (\tau_e, V_e).$4 tree search, the DAG scheduler, FSM lifecycle controls, and inter-agent coordination tools including delegate, accept, meeting, and escalate, all routed through the Event bus. The Evolution Layer includes both individual and organisational adaptation processes.

Individual evolution consists of post-task self-reflection through logging and principles updates via post_hook, together with CEO one-on-ones that update Talent artifacts (Yu et al., 24 Apr 2026). Organisational evolution consists of project retrospectives that distill SOPs, as well as periodic HR reviews, PIP, automated offboarding, and re-recruitment (Yu et al., 24 Apr 2026). The architecture therefore treats learning not as a single parameter update mechanism, but as a structured lifecycle process distributed across employees, management, and the organisation.

The paper further supplies an operating-system analogy for the six interfaces: Execution plus Task correspond to process management; Context to memory management; Storage to file system; the Container contract to device or driver abstraction; Event to IPC; and Lifecycle to security or audit (Yu et al., 24 Apr 2026). This analogy does not alter the formalism, but it clarifies the intended modularity: Talents are portable identities, Containers are execution substrates, and the organisational interfaces play the role of a stable systems boundary.

6. Empirical results and reported use cases

On PRDBench, under zero-shot, one-attempt settings, OMC is reported to achieve an $e = (\tau_e, V_e).$5 success rate, surpassing the state of the art by $e = (\tau_e, V_e).$6 percentage points (Yu et al., 24 Apr 2026). The reported total cost is \$e = (\tau_e, V_e).$76.91 per task. The comparison table in the paper includes individual baselines such as GPT-5.2 at $e = (\tau_e, V_e).$8, Claude-4.5 at $e = (\tau_e, V_e).$9, CodeX at $\mathcal{M}$0, and Claude Code at $\mathcal{M}$1, while the OMC configuration is listed as “Claude Sonnet 4.6 + Gemini Flash 3.1” with $\mathcal{M}$2 (Yu et al., 24 Apr 2026).

Beyond PRDBench, the paper presents four cross-domain case studies.

Case study	Reported composition and outcome
Weekly GitHub AI Agent Trend Report	HR recruits “Research Analyst (GPT-4o)” and “Technical Writer (Claude 4)”; 2-phase tree; repositories verified real; cost $\mathcal{M}$34.49$\mathcal{M}$4<10$ min
Street-Fight Web Game	Recruited “Game Developer (Claude Sonnet 4)” and “Art Designer (Gemini 2.5+NanoBanana)”; human evaluator rejects sprite slicing; E²R adds “Sprite Slicing” subtask; final integration approved
Animal-Character Audiobook Video	CEO recruits “Novel Writer” and “AV Producer”; script Ep1/Ep2, 8 scenes each, TTS, MP4 compilation; cost \$\mathcal{M}$5\approx15$ min
Automated Research Survey	Topic “World Models for Embodied AI (2021–2026)”; recruits 2×Research Scientist and 1×AI Engineer; outputs include a mind map with $\mathcal{M}$6 nodes and 3 novel research ideas; cost \$\mathcal{M}$7<1$ hr

These case studies are used to support the claim of cross-domain generality (Yu et al., 24 Apr 2026). The game example is especially important because it shows human-in-the-loop iteration: a rejected output triggers re-decomposition and dynamic skill injection rather than terminating the workflow. The survey example highlights heterogeneous backends and parallel decomposition. Taken together, the evidence in the paper is intended to show that OMC is not restricted to a single application class such as coding or retrieval-heavy workflows.

7. Interpretation, significance, and boundaries

The paper’s stated significance is that the organisational abstraction—Talents, typed interfaces, and the Talent Market—decouples who does the work from how it runs (Yu et al., 24 Apr 2026). In parallel, the $\mathcal{M}$8 search is said to unify planning, execution, and evaluation under formal guarantees of termination and deadlock freedom. The evolution mechanisms are then presented as the element that turns the system from a static, pre-configured pipeline into a self-organising and self-improving AI organisation.

Several clarifications follow from the formalism. First, OMC does not define a monolithic agent; it defines an organisational framework in which Employees are pairings of portable Talents with interchangeable Containers. Second, it does not assume a fixed workforce; recruitment from the Talent Market is an explicit runtime action. Third, it does not limit review to ex post evaluation; review is structurally integrated into the execution loop and determines acceptance, failure, retries, and escalation (Yu et al., 24 Apr 2026).

At the same time, the article’s claims should be interpreted within the scope reported by the paper. The guarantees pertain to scheduler properties such as acyclicity, bounded retries, timeout handling, and deadlock detection, not to universal task correctness. Likewise, the empirical support consists of PRDBench and four case studies rather than an exhaustive survey of all deployment conditions. Within those bounds, OMC is defined as an attempt to formalise multi-agent systems at the organisational level: a system in which staffing, decomposition, execution, evaluation, and evolution are treated as coupled but modular components of an AI company (Yu et al., 24 Apr 2026).