Org-Charted Territory: Why AI Agents Need Middle Management

Opening — Why this matters now

The AI industry has spent the last two years trying to turn large language models into workers. The result is a small circus of agents: coding agents, browser agents, research agents, support agents, spreadsheet agents, and agents that appear to exist mainly to summon other agents. Naturally, the next problem is not intelligence. It is management.

That is the useful provocation in From Skills to Talent: Organising Heterogeneous Agents as a Real-World Company, a recent paper introducing OneManCompany — or OMC — as a framework for treating multi-agent systems less like prompt chains and more like an operating organisation.¹

The paper’s central argument is simple, almost offensively managerial: skills are not enough. A skilled agent can perform a task. A team of skilled agents can communicate. But a business process needs more than communication. It needs hiring, assignment, review, escalation, memory, permissioning, retirement, and the unglamorous machinery that prevents work from turning into a polite hallucination festival.

For business users, this matters because most agentic automation projects fail in the space between “the demo worked” and “the process survived Monday morning.” The demo has a prompt. The process has exceptions, missing data, role boundaries, audit trails, budget limits, and someone asking why the invoice workflow emailed a client with a half-finished answer. Very inconvenient. Also very real.

OMC is not just another multi-agent framework. At least in ambition, it is an argument for an organisational layer: a layer that manages agents as a workforce rather than invoking them as disposable tools.

That distinction is where the business value lives.

Background — Context and prior art

Most agent systems today sit somewhere along a familiar ladder:

The paper argues that current multi-agent systems remain constrained by three structural weaknesses.

First, team structures are often fixed before execution. The workflow designer decides in advance that there will be a planner, coder, reviewer, and tester. That works until the task quietly demands a data engineer, compliance reviewer, or API specialist. Reality does enjoy arriving uninvited.

Second, agents are coupled to their runtime environments. A LangGraph agent, a Claude Code session, and a script-based executor may each be useful, but they do not automatically behave like interchangeable employees inside one company. Without a common organisational interface, integration becomes a pile of backend-specific glue code.

Third, learning is usually shallow or session-bound. Many systems can revise a plan during a run. Fewer can remember what went wrong across projects, update standard operating procedures, evaluate underperforming agents, and replace them when needed. In human organisations this is called management. In AI systems it is still treated as a research feature, which tells us something about both AI and management.

OMC addresses this gap with three linked concepts:

1. Talent–Container architecture: separate the agent’s identity and capabilities from the runtime where it executes.
2. Explore–Execute–Review tree search: treat project execution as an iterative search over organisational strategies.
3. Self-evolution and HR lifecycle: allow both agents and the organisation to improve through feedback, retrospectives, SOP updates, and performance management.

This is why the paper’s title moves “from skills to talent.” A skill is a reusable capability. A talent is a deployable worker with role, tools, behaviour, memory, and lifecycle. That is not a cosmetic renaming. It changes the unit of automation.

Analysis — What the paper does

1. Talent is not a tool. It is a portable employee profile.

OMC decomposes each AI employee into two parts:

This separation is powerful because it decouples who the agent is from where the agent runs. A research analyst talent could, in principle, run in different containers. A container could host different talents. This is the kind of abstraction boring engineers like and fragile automation systems desperately need.

The paper defines six organisational interfaces through which containers interact with the platform:

The operating system analogy in the appendix is not decorative. OMC treats heterogeneous agents like an operating system treats heterogeneous processes and devices: abstract the messy substrate behind stable interfaces. This is the right instinct. Enterprise AI does not need every agent to be identical. It needs them to be governable.

2. The Talent Market turns capability gaps into hiring decisions.

OMC includes a Digital Talent Market. Instead of generating a fictional agent from a role prompt and hoping it has the implied capabilities — a classic industry pastime, right next to “just add RAG” — the system can recruit deployable agent packages.

The paper describes three supply channels:

The HR agent ranks candidates and presents them to the human CEO for approval. This matters because capability selection remains a governance decision, not just a retrieval problem. The paper’s version is still research-heavy, but the business pattern is already visible: future automation stacks may need something like vendor management for agents.

That includes provenance, permissions, performance history, and decommissioning. In other words, procurement will discover agents. We have been warned.

3. Explore–Execute–Review is a project loop, not a chat loop.

OMC’s coordination mechanism is described as an Explore–Execute–Review tree search. The system does not merely follow a fixed workflow graph. It expands a task tree dynamically, assigns subtasks to employees, executes them, reviews outputs, and revises strategy when needed.

The loop can be read as follows:

The important detail is the review gate. A completed subtask does not automatically propagate downstream. It must be accepted by a supervisor. This is a direct response to one of the ugliest failure modes in agent systems: early errors quietly becoming input for later agents, which then make the error look more sophisticated. The technical term is error propagation. The office term is “who approved this?”

OMC also combines its task tree with dependency edges, forming a DAG-based execution layer. This allows sibling tasks to depend on one another: for example, frontend work can wait for an API contract even if both tasks share the same parent. A finite state machine governs task lifecycle. Retries are bounded. Timeouts and cost budgets act as circuit breakers. Deadlock detection prevents silent stalls.

This is not glamorous, but it is the machinery that separates a toy multi-agent demo from a process that can run without someone nervously refreshing a console.

4. Self-evolution is organisational memory, not mystical self-improvement.

The paper uses the language of self-evolution, but the mechanism is more practical than mystical. Agents update working principles after one-on-one feedback and task completion. Project retrospectives produce SOP updates. HR reviews agent performance every three projects. Agents that fail repeated reviews can enter a Performance Improvement Plan and eventually be offboarded.

This is almost funny because the paper imports human HR bureaucracy into AI systems. It is also sensible. A workforce that cannot evaluate, coach, or replace its own members is not a workforce. It is a loose collection of chat windows with confidence issues.

The key business point is this: OMC stores learning in agent profiles and organisational SOPs, not in model weights. That makes improvement cheaper and more auditable than retraining. It also makes it more fragile: if the written reflection is poor, the organisation learns the wrong lesson with excellent formatting.

Findings — Results with visualization

The paper evaluates OMC on PRDBench, a benchmark of 50 project-level software development tasks based on product requirement documents. Unlike narrow coding benchmarks, PRDBench evaluates whether an agentic system can interpret requirements, decompose work, implement solutions, and satisfy executable test criteria.²

The reported result is strong:

A fair interpretation is not “OMC is universally better.” The fair interpretation is narrower and more useful: for complex project-level software tasks, organisational coordination can outperform stronger single-agent baselines, but at a visible coordination cost.

The paper also reports four cross-domain case studies:

These cases are more demonstration than proof. They show generality, not statistical confidence. The authors are explicit that systematic evaluation beyond software development remains future work, and that self-evolution mechanisms have not yet been quantitatively ablated. Good. A paper that admits its limitations is already ahead of several product launches.

What seems genuinely new?

The novelty is not that OMC uses multiple agents. That field is crowded enough to need zoning laws. The contribution is the combination of four design choices:

This is a shift from agent orchestration to agent operations. Orchestration asks, “Which agent talks next?” Operations asks, “Who is qualified, what are they allowed to access, what counts as acceptance, what happens if they fail, and how does the organisation learn?”

The second question is less exciting. It is also the one that companies actually pay for.

Implications — Next steps and significance

For business automation: stop designing only the agent; design the organisation around it.

The practical lesson is blunt. An AI agent is not a business process. It is a worker inside a process. The process still needs operating design.

For a company building agentic automation, OMC suggests a better implementation checklist:

This is where ROI becomes practical. Multi-agent coordination is not free. The paper reports about $6.91 per PRDBench task for OMC, and the authors openly note the cost-performance trade-off. That cost is irrational for a simple email rewrite. It may be trivial for a software defect, compliance review, financial reconciliation, or customer-facing workflow where one unreviewed error can be expensive.

The sensible enterprise architecture is not “agent everything.” It is adaptive dispatch: single-agent execution for simple tasks, multi-agent organisation for complex, risky, or multi-step work.

For governance: the organisational layer is a control layer.

Many AI governance discussions focus on model policy: what the model may say, what data it may access, what risks it may create. OMC reframes governance around operations:

• Which agent is authorised to use which tool?
• Which outputs require supervisor acceptance?
• Which dependencies block execution?
• Which failures trigger escalation?
• Which lessons become SOPs?
• Which agents should be retired?

This is closer to how real businesses manage risk. Governance is not a PDF policy admired once per quarter. It is embedded in queues, permissions, review gates, logs, and escalation paths.

The paper’s role-based tool access model is especially relevant. Each agent’s context includes only authorised tools. That means access control is handled before reasoning begins, rather than after the agent has already considered doing something creative. In security, creativity is not always a virtue.

For AI vendors: marketplaces may move from tools to workers.

If the Talent Market idea matures, the agent ecosystem may evolve from tool stores to worker marketplaces. Today, many agent platforms advertise integrations: Slack, Gmail, GitHub, Notion, databases, browsers, APIs. Useful, yes. But enterprises eventually need complete work units: a claims reviewer, month-end close assistant, compliance documentation agent, procurement analyst, or QA auditor.

That requires more than a tool wrapper. It requires:

This is where agent markets become less like app stores and more like staffing platforms mixed with software supply-chain management. Delightful. More spreadsheets. But necessary spreadsheets.

For Cognaptus-style automation: the case study template becomes agentic by design.

OMC maps neatly onto real-world business automation cases. Consider a utility maintenance agent, a recruitment screening agent, a call-center QA agent, or a fleet maintenance agent. In each case, the value does not come from one heroic LLM. It comes from a managed division of labour:

The implementation question becomes: what are the employees, what are their tools, what are their review gates, and what organisational memory should persist?

This is a healthier design pattern than asking one omnipotent chatbot to “handle operations.” Omnipotence is usually just poor scoping with better branding.

Practical adoption model

A business considering this architecture should not start by recreating OMC. It should start by borrowing the organisational principles.

Most companies should live at Levels 2–4 for a while. Level 5 is attractive, but dynamic hiring of agents only makes sense after the organisation has clear roles, access controls, acceptance standards, and logs. Otherwise, the company is not hiring talent. It is inviting strangers into the workflow with API keys. A bold strategy, mostly for people who dislike sleep.

Limitations — Where the paper is still early

The paper’s framework is ambitious, but several constraints deserve attention.

First, the quantitative benchmark is software-heavy. PRDBench is useful because project-level software work genuinely tests planning, decomposition, implementation, and evaluation. Still, enterprise workflows in finance, healthcare, logistics, legal operations, and public services carry different failure modes. A coding benchmark does not prove operational readiness in regulated processes.

Second, the self-evolution component is plausible but under-tested. The authors state that one-on-ones, retrospectives, and performance reviews are implemented, but they have not yet isolated the contribution of each component. This matters because organisational memory can help or harm. Bad retrospectives produce bad SOPs. Bad SOPs scale mistakes with confidence, the most efficient form of nonsense.

Third, cost efficiency remains unresolved. OMC’s result is strong, but the baselines do not report comparable cost data. Without cost-normalised evaluation, it is hard to know whether OMC is better because it is better organised, because it spends more compute, or because both are true.

Fourth, human judgment remains central. The CEO approves talent selection, injects requirements, prunes branches, and decides when iteration should stop. This is not a weakness; it is reality. But it means the quality of the system depends partly on the quality of the human controller. Agentic automation does not remove management. It concentrates management into sharper decision points.

Conclusion — The return of the org chart

The strongest idea in this paper is that agentic AI needs an organisational abstraction. Not another prompt template. Not another agent chatroom. Not another dashboard where simulated employees compliment each other before failing a dependency.

It needs a layer that manages workforce composition, runtime heterogeneity, task decomposition, dependency control, review gates, memory, access rights, cost limits, and lifecycle accountability.

OMC is early, and parts of it remain closer to research prototype than enterprise infrastructure. But its direction is important. The future of AI automation will not be won by the single smartest agent. It will be won by systems that know when to hire, when to delegate, when to review, when to escalate, when to remember, and when to fire.

Apparently, the future of autonomous AI is middle management.

How reassuringly human.

Cognaptus: Automate the Present, Incubate the Future.