Your AI Agents Need a Manager, Not Another Chat Window

Capabilities and documentation checked 18 August 2026.

A small business does not need five chatbots arguing in five tabs. It needs work to move from request to result without losing the facts, exceeding permissions, or quietly publishing the wrong thing.

That is the real multi-agent problem. Giving several AI agents different job titles is easy. Coordinating them is not. Today’s tools provide useful building blocks for delegation, routing, memory, schedules, and audit records. The layer that decides who owns a decision, which evidence wins, and when a person must step in is still mostly yours to design.

My view is simple: treat agents as fast, fallible contractors inside a managed process. Do not treat them as a self-managing workforce.

Why more agents can create more mess

A single assistant can be wrong. A group can be wrong in more complicated ways.

Shared truth and memory. Agents often have separate context windows, files, or memories. One may use last month’s price while another uses the new price. Longer context is not a complete fix: research on the “lost in the middle” effect shows that language models can struggle to use information buried inside long inputs (Lost in the Middle). A shared folder is not automatically a shared truth either. You still need an authoritative record, an owner, and a rule for resolving stale versions.

Permissions. A research agent may need web access but should not send email. A copy agent may draft a campaign but should not edit the customer database. If every agent receives every tool, one misleading instruction can travel farther than intended. Excessive agency is the risk created when a system can take more actions than are necessary or properly supervised. NIST recommends access controls, monitoring, and human oversight for generative AI systems (NIST AI 600-1). In everyday terms: do not hand the intern every key in the building.

Routing and delegation. Someone must decide whether a request goes to research, finance, operations, or a person. Keywords are brittle; free-form model judgment is unpredictable. Delegation also creates a handoff problem: what exactly must the specialist return, and in what format?

Ownership and conflicts. Two agents can update the same campaign, calendar slot, or stock record. Databases have spent decades defining transaction isolation because simultaneous changes are hard (PostgreSQL transaction isolation). Agent frameworks do not make that business problem disappear. “Last writer wins” is a technical behavior, not a sensible management policy.

Receipts and observability. A message saying “done” is not proof. You need the input, the decision, the tool action, the result, and ideally a verifiable receipt such as a draft ID or status returned by the destination. Logs can help, but a log is only as complete as the system producing it.

Error propagation. A confident research error can become polished copy, then a scheduled post. More agents may add checks, but they also add handoffs where errors can be amplified. The MAST taxonomy documents recurring failure patterns in multi-agent systems, including poor coordination and failures to verify shared progress (MAST).

Cost and latency. Every specialist call, retry, summary, and review consumes time and model usage. In Anthropic’s own research system, its multi-agent setup used about four times as many tokens as its single-agent version. That is a system-specific finding, not a universal ratio, but it is a useful warning: parallel work is not free (Anthropic’s multi-agent research system).

Prompt injection. An agent reading a website, document, or email can encounter text designed to manipulate it. AgentDojo demonstrates how tool-using agents can be attacked through indirect prompt injection in their working environment (AgentDojo). Treat external content as untrusted data, not as instructions.

Evaluation. A lively demo does not tell you whether the workflow is dependable. “AI Agents That Matter” argues for evaluations that account for cost and real-world usefulness rather than relying on narrow benchmarks alone (AI Agents That Matter). For a business, the test is concrete: was the claim supported, was the approval respected, did the action happen once, and can you prove it?

The manager is a workflow, not another personality

The answer is not a “boss agent” with a grander prompt. The manager should be a small set of explicit controls:

1. One source of truth. Put approved facts, prices, policies, and brand constraints in a versioned record. Give each item an owner and review date.
2. A typed request. Start work with required fields: objective, deadline, audience, allowed sources, budget, and prohibited actions.
3. Least-privilege tools. Give each role only the access needed for its task. Separate drafting from publishing and reading from writing.
4. Structured handoffs. Require specialists to return claims, sources, uncertainties, and a proposed next step, not just prose.
5. Conflict rules. Assign one owner per business object. If inputs disagree, stop and escalate instead of averaging.
6. Approval gates. Put a person before consequential external actions: publishing, payment, customer contact, deletion, or changing a system of record.
7. Evidence and receipts. Verify claims before approval, then verify the external result after action. Store both records.

This design sounds less magical because it is. It also resembles the way reliable businesses already work.

Is Hermes Agent the solution?

Hermes Agent offers several useful coordination primitives. Its delegate_task tool can create isolated temporary workers for parallel jobs, but those workers are not durable identities. For longer-running roles, named profiles provide separate environments. Hermes’ durable SQLite Kanban can track dependencies, comments, review and change requests, run histories, and context handoffs (Hermes delegation, Kanban).

Its cron system can schedule work and chain context between runs. Skills can package repeatable playbooks. Profile-scoped memory can retain a small amount of useful context, while toolsets can narrow available capabilities (cron, memory, skills, tools). For code work, worktrees can reduce collisions.

Those are meaningful parts of a manager. They are not the entire management system. The Kanban is currently single-host, and tenant or profile boundaries should not be mistaken for enterprise identity and access management. A completed card does not independently prove that a business claim is true. You still need your own approval policy, authoritative data, conflict rules, outcome checks, and retention decisions.

Hermes is a reasonable fit when you want an operator-oriented workspace with delegated tasks, durable work tracking, reusable skills, and human review. It is not a turnkey autonomous company.

What OpenClaw solves, and what it leaves to you

OpenClaw approaches the problem from a gateway and routing angle. One Gateway can route channels and accounts to configured agents using deterministic bindings. Background sub-agents run with isolated context, bounded concurrency, and parent-child tracking. Per-agent tool and sandbox policies help limit capabilities, and cron jobs support scheduling (multi-agent routing, sub-agents, sandbox tools, cron jobs).

Its experimental Swarm feature is off by default. It can collect structured results from multiple workers, but reconciling conflicting answers remains workflow or prompt logic, not universal conflict resolution (Swarm). OpenClaw also provides gateway audit records, but the official documentation describes them as metadata-only and best-effort, not a lossless compliance archive (gateway audit). Its memory model is useful for continuity, yet workspaces are not automatically security boundaries and gateway resources may be shared (memory).

OpenClaw is a reasonable fit when your main need is deterministic channel-to-agent routing, isolated background workers, and per-agent sandbox or tool policy. It does not decide your business truth, settle ownership disputes, or supply a complete audit and approval regime.

How to choose without buying a fantasy

Choose the product that removes the bottleneck you actually have.

If work falls through the cracks after delegation, Hermes’ durable task board, dependencies, reviews, and run history may be the more direct starting point. If requests arrive across accounts or channels and must reach clearly separated agents, OpenClaw’s deterministic bindings and gateway model may be the better foundation.

Either can participate in a controlled system. Neither removes the need for business controls. Check where secrets live, which tools each role can access, how logs are retained, how a failed run is retried, and how a human can stop the workflow. Test those claims in your environment. Documentation describes intended capabilities; it is not independent verification of your deployment.

Start with one workflow. Keep the blast radius small. Measure corrections, unsupported claims, duplicate actions, turnaround time, and total model usage. Expand only after the process is boring.

A safe weekly marketing example

Imagine a local accountancy firm preparing one weekly LinkedIn post.

On Monday, the owner submits a brief with the audience, approved service descriptions, prohibited claims, and this week’s topic. A coordinator checks that the required fields exist. It creates two read-only tasks: a research specialist extracts facts only from approved sources, while a planning specialist proposes three angles using the firm’s current content calendar.

Both return structured results with links, quoted evidence, uncertainties, and timestamps. An evidence checker compares every factual claim with the approved source set. If two sources disagree, the workflow stops and assigns the issue to the owner. It does not ask another model to vote.

A writing specialist drafts one post using only checked claims. A separate reviewer checks tone, privacy, and whether the draft implies a guarantee. The owner sees the draft, evidence, estimated model usage, and any unresolved caveats in one approval screen.

Only after approval does a narrowly permissioned publishing step create or schedule one post. It cannot alter account settings or send direct messages. The workflow captures the platform’s returned post or draft identifier, then reads back the destination to confirm the correct text and status. If confirmation fails, it alerts a person rather than publishing again.

That is a multi-agent workflow. Its safety comes less from the number of agents than from the boundaries between them.

Seven rules for a small business

1. Automate a process you can explain on paper. If nobody owns the current process, agents will not repair it.
2. Keep one authoritative record. Memory helps continuity; it does not replace controlled business data.
3. Separate thinking from doing. Research and drafting can be broad. External actions should be narrow and gated.
4. Give every object one owner. Campaigns, prices, customer records, and approvals need clear decision rights.
5. Demand evidence before action and a receipt after it. “Done” is a claim, not a control.
6. Design for refusal and recovery. Conflicts, missing fields, suspicious content, and failed verification should stop safely.
7. Evaluate the whole workflow. Track quality, corrections, cost, latency, and policy breaches, not how impressive the conversation sounds.

The near-term opportunity is not an office full of autonomous digital employees. It is a handful of constrained specialists inside a visible, testable workflow. Build the manager first. Then decide how many agents you actually need.

Sources

• Hermes Agent: Delegation, Kanban, Cron, Memory, Skills, and Tools
• OpenClaw: Multi-Agent Routing, Sub-agents, Swarm, Memory, Multi-Agent Sandbox Tools, Gateway Audit, and Cron Jobs
• MAST: Multi-Agent System Failure Taxonomy
• Lost in the Middle
• Anthropic: How We Built Our Multi-Agent Research System
• NIST AI 600-1
• PostgreSQL: Transaction Isolation
• AI Agents That Matter
• AgentDojo