Managing Multi-Agent Systems Like a One-Person Company

A multi-agent system is easy to start and surprisingly hard to operate. Add a planner, a coding agent, a researcher, and a reviewer; give them a shared chat; then watch apparently simple work dissolve into repeated searches, ambiguous ownership, stale context, and agents approving their own output.

I have found that many of the ideas used to manage a company also work well for managing a team of agents. I act as the CEO: I decide what matters, set priorities, and remain responsible for the result. Each project can have a director who plans the work, delegates it, and checks what comes back. Larger projects may also need team leads, while specialist agents or temporary squads handle the actual tasks. As the team grows, an HR-like process can help define new roles, test them, manage their access, and retire them when they are no longer useful.

These are not claims that an agent is an employee, or that a system becomes a legal or moral actor. Agents do not carry responsibility; people do. The metaphor is useful because it forces questions that a collection of chat windows avoids: Who owns this work item? Which state is authoritative? Which tools may act? What is the budget? Who can approve the result? What evidence survives after the conversation ends?

1. From agent chats to an operating model

A chat is an interface. It is not an operating model. Once work survives beyond one conversation, the system needs a control plane that separates coordination from execution. That plane contains at least a work queue, a state machine, role contracts, permission policy, budgets, artifacts, traces, evaluation, and human approval.

This distinction also clarifies the director's job. A director should not become the most capable worker that happens to call other agents occasionally. Its scarce resource is global context: goals, dependencies, risk, current state, and the evidence returned by workers. If it spends that context doing every local task, coordination quality falls and the director becomes a serial bottleneck.

The pattern resembles a manager calling specialists as tools. OpenAI's Agents SDK documentation distinguishes this arrangement from handoffs, where a specialist takes over the conversation. Neither is universally better. A manager preserves central control; a handoff gives the specialist direct ownership of the next interaction. The operating model should state which one changes ownership and which one merely performs delegated work.

2. Work enters through issues and events

Work should enter the company as a durable work item, not as an instruction that exists only inside a model context. The source may be a manually created issue, a scheduled job, a webhook, a source-control tag, or an autopilot process. All should normalize into the same envelope before an agent acts.

A small state machine is usually enough: intake → triaged → assigned → running → review → approved → done, with explicit blocked, failed, and escalated states. A review that requests changes returns the item to execution without erasing the previous artifact or decision. Each transition records actor, time, inputs, outputs, and reason.

The artifact, not the final chat message, is the deliverable. It may be a patch, report, ticket update, evaluation result, or structured decision record. The trace explains how it was produced. Neither alone proves correctness: an artifact needs acceptance tests, while a trace needs comparison with the environment's postconditions.

3. From a few real workflows to one control plane

I already run agent workflows across several kinds of work. Their triggers, execution cycles, and deliverables differ, but many reduce to the same control flow. The following three examples are a sample, not an inventory: they show how schedules, work-management systems, and source-control events can enter one model of work, state, delegation, and review.

3.1 A weekly operating review

Every Friday afternoon, a scheduled agent analyzes my work for the week. It examines categories of projects, token consumption, human time, agent time, and skill usage. The useful output is not a celebratory count of completed tasks. It is an operating report that can reveal where supervision, waiting, coordination, or repeated tool use consumed the week.

In company terms, this is a finance-and-operations function. In system terms, it is a scheduled, read-oriented workflow with defined data sources, a reporting artifact, and a human reader. It should preserve the definitions behind each metric so that a change in instrumentation is not mistaken for a change in performance.

3.2 Jira synchronization and routing

I also use scheduled agents to synchronize Jira tickets and delegate them according to ticket type. Here the ticket is already a durable work item. The synchronization layer maps external fields into the local control plane, preserves the external identifier, and makes assignment policy explicit.

The difficult part is not asking a model to classify a ticket. It is handling duplicate synchronization, changed priorities, missing dependencies, cancellation, and authority. A safe route may create an assignment proposal, while a higher-trust route may dispatch a read-only task automatically. Mutation of a production system can require a separate approval state.

3.3 Tag-triggered evaluation squads

In some of my projects, I have also set up automated evaluation pipelines. A new tag triggers an evaluation squad that runs different evaluations. The tag supplies a reproducible version boundary; the squad supplies temporary parallelism and context isolation. Results return as artifacts associated with that tag rather than as disconnected summaries.

This is where a squad is better than a permanent department. Evaluations can run independently and then converge on one release decision. The squad can disappear after the work item closes; the workflow, evaluation definitions, and evidence remain.

4. Flat, hierarchical, or hybrid

Human companies have departments, subdepartments, and teams. Agent systems can use the same shapes, but copying an org chart is not a design argument. Every extra layer adds another context handoff, another place for goals to drift, and another execution step that consumes time and tokens.

A flat structure is appropriate when a director can understand the work, specialists are few, and dependencies remain visible in one queue. It minimizes relays and makes failure attribution easier. It becomes fragile when one director must maintain too many unrelated tool contracts, risk classes, or parallel branches.

A hierarchy is justified when a subdomain owns something real: a separate queue, durable state, permission boundary, budget, service-level objective, or review responsibility. A lead can then compress local detail into a stable interface. If it only restates messages between director and worker, it is coordination tax.

Most practical systems will be hybrid: shallow by default, hierarchical around genuine control boundaries, and temporarily wider when parallel work is valuable. Team shape can change per project or even per work item; it need not be a permanent property of the platform.

There is no trustworthy universal maximum team size. Amazon's original two-pizza-team discussion concerns human teams and emphasizes small size, single-threaded ownership, charter, metrics, and end-to-end responsibility. It is not a law for agents. AWS documentation has also exposed changing product constraints: one Bedrock page states a maximum of ten collaborators per supervisor “at this time,” while the current service quota table lists a different adjustable quota. A product limit should not be promoted into an architectural constant.

The right size is a function of task independence, handoff loss, review capacity, permissions, latency, and budget. Anthropic's multi-agent research system reports benefits for breadth-first research with independent directions, but also high token use, duplicate work, and coordination difficulty. Those findings support conditional use, not “more agents” as a goal.

5. Workflow, skill, ephemeral squad, or durable agent?

Many agent organizations grow because every recurring request becomes a new persona. That confuses reusable capability with durable ownership. I use four levels, in increasing operational cost.

A useful test is subtraction. If the proposed agent loses its name but nothing about its queue, state, access, budget, review, or escalation changes, it is probably a skill or a temporary execution context. A role should exist because the system must govern it differently, not because personification makes the diagram easier to remember.

6. Role contracts and compute policy

A durable role needs a job description that software can enforce. A name and system prompt are insufficient. I would record the following as a versioned role contract:

• charter, goals, in-scope work, and explicit exclusions;
• accepted inputs, required outputs, and artifact schema;
• tools, data access, credentials, and permission limits;
• token, time, tool-call, and financial budgets;
• default model and effort, allowed overrides, and fallback policy;
• SLA, timeout, retry, cancellation, and escalation behavior;
• acceptance tests, reviewer, approval class, and human owner;
• contract version, evaluation suite, deployment stage, and retirement criteria.

Model selection belongs inside this contract but should not be fixed forever. Different work deserves different models and effort levels. A classification step, a code change, a visual inspection, and a high-risk review may have different needs. Even agents inside one squad may use different models.

I prefer a resolution chain: organization defaults establish the supported baseline; role defaults reflect normal work; the work item may request an approved override; the runtime may escalate within policy after a defined failure. The trace records the resolved model, version, effort, budget, and reason. OpenAI's Agents SDK documentation explicitly supports per-agent model configuration, run-level overrides, and mixed models, illustrating the mechanism even though the policy remains application-specific.

A more capable model should not automatically receive more authority. Capability routing and permission routing are separate. Escalating reasoning effort may change cost and latency; escalating tools or credentials changes risk and should cross a different gate.

7. Separate planning, execution, review, and approval

A single agent can plan, execute, and check low-risk work, but it should not silently redefine the acceptance test and then approve itself. The system needs separation of concerns even when it does not need four permanent agents.

Planning fixes the goal, scope, dependencies, and acceptance criteria. Execution produces the artifact. Review compares that artifact with criteria and environmental postconditions. Approval authorizes a consequential transition. These functions can be implemented by deterministic code, models, or people according to risk.

Deterministic checks come first: schema validation, compilation, tests, expected file changes, external state, budgets, and permission use. A separate reviewer is valuable for semantic quality or ambiguous outcomes, but model review has limits. Anthropic's work on long-running app harnesses reports that self-evaluation tends to overrate generated work and that a separate evaluator adds cost and latency. Changing the model can reduce correlated failure, but it does not make the reviewer independent in the institutional sense.

The worker must not be able to edit its rubric, delete adverse trace events, or grant itself broader permissions. High-impact actions still require deterministic policy or human approval. Review is evidence for the accountable person, not a transfer of accountability to another model.

8. Hiring is a controlled system change

Creating a durable agent changes the attack surface, cost structure, and failure modes of the system. It should look more like deploying a service than writing a persona.

1. The director opens a role request describing the unmet ownership boundary and why a workflow, skill, or temporary squad is insufficient.
2. A recruiter function and the director produce the role contract, tool surface, permission set, and evaluation suite.
3. The candidate runs offline tests and adversarial cases, then enters a shadow or read-only probation period.
4. A probation evaluator checks artifacts, recovery, refusal, escalation, and budget behavior—not only successful tasks.
5. An HRBP or governance function assigns runtime identity, minimal access, display metadata, owner, review schedule, and revocation path.
6. Rollout expands gradually; later audits may upgrade, merge, restrict, or retire the role and its skills.

A display name or avatar helps a human recognize traces and queues. It is not a security identity. The runtime principal, credentials, allowed resources, and audit subject must remain separate and machine-verifiable. NIST's current agent identity and authorization concept paper frames this area as an emerging problem space rather than a finished standard. Established least-privilege and audit principles still apply.

The lifecycle ends with revocation. Retiring an agent means stopping schedules and webhooks, draining or reassigning its queue, revoking credentials, preserving required audit evidence, and deciding whether useful knowledge becomes a skill. Deleting the prompt is not decommissioning.

9. The organization must pay rent

An organization should become simpler or more reliable because a role exists. If it only increases activity, it is overhead. Throughput alone rewards agents for creating tasks, messages, and reviews. I would operate the system with a balanced set of measures:

Coordination cost includes director turns, handoffs, context reconstruction, duplicate exploration, and review. It should not be hidden inside “agent work.” A useful organization review asks whether a role can be merged, whether repeated instructions should become a skill, whether a deterministic step can replace a model call, and whether an unused permission can be removed.

Raw utilization is a poor target. An idle reviewer may be exactly right if few risky changes arrive. A busy director may reveal bad decomposition. The goal is accepted outcomes with controlled risk and reasonable human attention, not maximum agent occupancy.

10. Start with the smallest viable company

I would begin with one human owner, one director, one queue, and one explicit state machine. Use deterministic workflows for stable paths, package repeated bounded capability as skills, and create temporary specialists only when context isolation or parallelism pays for the handoff. Add a durable role after persistent ownership and a distinct control boundary become visible in the data.

Every work item should end in an artifact, a trace, and a review decision. Every role should have a contract, minimal permissions, a default compute policy, an evaluation suite, and an owner. Every recurring trigger should be idempotent. Every high-risk transition should have a human or deterministic policy gate.

The company metaphor is successful when it disappears into these concrete mechanisms. The result is not an autonomous company and not a simulation of employees. It is a system in which a single person can direct more work without losing the ability to understand scope, authority, cost, evidence, and failure. Organization is useful only when it makes those boundaries clearer.