An Agent With Eleven Jobs Is Not a Chief of Staff

Every few months the market rediscovers “multi-agent.” The demo is always the same: one chat window that can open mail, book travel, update CRM, write code, and spend money. The creator labels it a Chief of Staff. The buyer hears leverage. The operator should hear blast radius.

An agent with eleven jobs is not a Chief of Staff. It is an uninsured intern with your logins.

That sentence is the whole product lesson. Specialty beats god-mode. Orchestration beats a pile of tools. Human gates beat silent side effects. If you skip those three, you did not build an AI workforce. You built a faster way to make expensive mistakes.

One job per seat

In real companies, roles exist because authority has edges. A bookkeeper is not also the person who posts on social and closes the bank account. AI work needs the same edges.

A strong multi-agent design starts with seats, not personas with cute names:

• Job — one primary outcome the seat owns
• Connectors — only the systems required for that job
• Context diet — what knowledge it may load, and what it must never see
• Schedule — when it may run, and when it must stay dark
• Effect class — read, draft, send, spend, delete, merge, deploy
• Proof — what independently observable evidence means “done”
• Stop/recovery — who freezes it, and how you reverse damage

If you cannot fill those fields, you do not have a seat. You have a vibe.

This is why “one bot that does everything” fails in production even when the model is excellent. The failure is not intelligence. The failure is unscoped authority.

Chief of Staff is a mouthpiece, not a superuser

A useful Chief-of-Staff pattern is narrow: the human talks to one orchestrator. Specialists stay behind it. Messaging surfaces (Slack, Telegram, SMS) route through the orchestrator so the operator has one conversation and one audit trail.

That only works if the orchestrator is not also the spender, deleter, and deployer.

The CoS may:

• intake and classify work
• route tasks to the right seat
• summarize status
• request approvals for high-effect actions
• package receipts after work completes

The CoS should not, by default:

• archive or delete important records without a human gate
• move money or place orders unattended
• merge irreversible changes
• hold personal and company credentials in the same identity

If your “Chief of Staff” can do all of those silently, you did not hire an executive assistant. You handed the keys to a process that cannot be fired cleanly.

Work seats and personal seats do not share closets

Identity boundaries are not a privacy nicety. They are liability design.

Work seats get work connectors. Personal seats get personal connectors. Mixing them is how a helpful automation turns a family calendar into a client email incident, or a shopping agent into a company-card problem.

Most teams skip this because the first demo is easier when everything is already logged in. The second week is when the shared OAuth surface becomes the story.

Redesign the work before shopping for another agent product: separate identities, separate connector scopes, separate approval paths. The tool is secondary.

Routines are governance, not convenience

Always-on agents feel powerful until the token bill, the silent cron failure, or the 2 a.m. side effect arrives.

Scheduled routines with explicit windows are a control plane:

• run the morning intake between 05:30 and 06:30
• allow draft-only customer replies during business hours
• require dual approval for spend after a threshold
• freeze unattended computer control outside a named maintenance window

Schedule is the same family as budgets, rate limits, and stop conditions. If an agent can act any time with any effect class, you do not have operations. You have ambient risk.

Human gates belong on effects, not on theater

Many “approval UIs” ask humans to rubber-stamp low-stakes drafts and then auto-execute the actions that matter. Flip that.

Low-effect work can move with light review:

• research summaries
• internal drafts
• candidate outlines
• status digests

High-effect work needs a hard gate:

• external send
• money movement
• deletion or archive
• production merge/deploy
• broad mailbox or CRM writes

The question is not “did a human click Allow?” The question is “did a human authorize this *effect class* with enough context to own the consequence?”

The missing product is a seat registry

Most teams already have fragments of a multi-agent stack: profiles, skills, crons, queues, chat bots, browser sessions. What they lack is a single registry that answers:

1. Who may talk to the business?
2. Through which channels?
3. With which systems attached?
4. On which schedule?
5. Under which effect classes?
6. Proven by what receipt?
7. Stopped and recovered by whom?

Until that registry exists, adding another specialty agent increases surface area without increasing control.

This is also why skill libraries and seat design complete each other. Shared procedures without seats still bottleneck on one laptop and one overloaded thread. Seats without shared procedures still invent the work differently every day. Company-owned skills make work portable. Seat contracts make work safe enough to delegate.

What to do this week

Do not start with eleven use cases. Start with three seats:

1. Research seat — read-only sources, draft memo, no send
2. Ops seat — internal task updates, no customer send, no spend
3. Chief-of-Staff seat — intake, routing, status, approval requests only

Write the seven fields for each. Put human gates on send/spend/delete/merge. Split work and personal connectors. Give every routine a window and a stop owner.

Then, and only then, add the fourth seat.

Multi-agent is not a feature checklist. It is an authority map. If the map is blank, the impressive demo is just an uninsured intern learning your business at full speed.