How to build an AI org chart: managers, departments and a chief of staff

One bot is a chat. Six bots is a mess. Six bots with a manager is a team. A practical guide to structuring AI bots like a real company.

By The Fluf team · Published October 21, 2026 · 6 min read

One bot is a chat. Six bots is a mess. Six bots with a manager is a team.

Most people who get serious about AI bots hit the same wall. The first bot is great. The second is handy. By the fifth you have a sidebar full of bots that don't know each other exist, three of them have half-done the same research, and you've become the switchboard that copies output from one window into the next. You hired help and got a second job.

The fix isn't a smarter model. It's structure. Companies worked out a long time ago how to get many people pulling in one direction: roles, managers, reporting lines, and clear rules about who decides what. Bots need the same thing, and it turns out they follow it better than most humans do.

This guide is tool-agnostic. The principles work in a framework, a no-code builder or a desktop app. We use Fluf as the worked example because hierarchy is built into it, but you can apply every step anywhere.

Why flat bot lists break

A flat list of bots has three failure modes.

Nobody owns the outcome. You ask the research bot for competitor pricing and the writing bot for a landing page. Neither knows the other's work exists, so the landing page quotes no prices and the research sits unread.

Context lives in your head. Every handoff runs through you. You become the memory, the router and the quality check. That's the work you were trying to hand off.

Risk has no gatekeeper. When five bots can each send email, spend money or delete files, you need five sets of guardrails, and you'll forget one.

A hierarchy fixes all three. Someone owns each outcome, context flows along reporting lines instead of through you, and risky actions get escalated to one place.

The shape: workspace › business › department › team › bot

Start with a structure that matches how your work is actually split. In Fluf it's five levels:

Workspace: everything you run. One per person.
Business: one product, company or client. Each keeps its own memory, connections and files, so your agency client's data never leaks into your side project.
Department: a function inside a business, such as Growth, Product or Operations.
Team: an optional sub-group when a department gets big, such as Content inside Growth.
Bot: a single worker with one clear job.

You don't need every level on day one. A solo founder can run a business with two departments and six bots. The structure is there for when you grow into it.

The three roles

Every bot in a working hierarchy plays one of three roles.

1. The chief of staff. One bot at the very top that sees everything. It knows every business, every department and what each bot is working on right now. You talk to it when you don't know who to talk to. It turns "get the launch ready" into assignments, chases progress and gives you the short version. In Fluf this is Pom, the main bot, and it sits above every business in your workspace.

2. Managers. One per business (the main bot for that business) and one per department or team. A manager doesn't do the deep work. It breaks goals into tasks, assigns them to the right specialist, reviews what comes back, and reports up. Good managers say no to vague work and send it back with a question.

3. Specialists. Everyone else. Each has one narrow job and the tools for it: a researcher with web access, a writer with your brand voice, an ops bot with access to your files. Narrow beats clever. A bot that only verifies facts will verify facts far more reliably than a generalist asked to "also double-check".

Write a role card for every bot

The single most useful habit is a short role card. It tells the bot what it is, where it sits and what it may do. Keep it under a page. Here's one for a research specialist:

name: Scout
role: Market researcher
business: Lumen (solo SaaS)
department: Growth
reports_to: Atlas (Growth manager)
job: >
  Find and verify facts about competitors, pricing and customer pain.
  Always return sources with dates. Flag anything older than 90 days.
tools: [web_search, browser, notes]
can_do_alone:
  - read any public website
  - write notes in the Growth library
must_ask_first:
  - creating accounts or signing up for trials
  - anything that costs money
escalate_to_manager_when:
  - two sources disagree on a number that matters
  - the task is bigger than 2 hours of work
done_means: >
  A short summary on top, a source list below, and a one-line
  recommendation for Atlas.

Notice what's in there: who it reports to, what "done" looks like, and the exact line between acting and asking. That last part is where most setups go wrong. Write it down once and the bot holds it every time.

Set the rules for delegation, reporting and escalation

Structure only works if work moves along it predictably. Three rules cover most of it.

Delegation goes down. Managers assign work to their own reports. The chief of staff assigns to managers, not straight to specialists, unless you tell it to. This keeps managers accountable for their department.

Reports go up, short. When a specialist finishes, it reports to its manager with the result on top. The manager combines reports and sends one summary up. You read one message instead of six.

Escalation goes up until someone can decide. A specialist that's stuck asks its manager. A manager that can't resolve it asks the chief of staff. Only decisions that genuinely need you reach you.

Peer-to-peer is fine too. Your writer can ask your researcher for a source directly. Just make sure the result still lands with the manager who owns the outcome.

Approvals: one "Needs you" queue

The best part of a hierarchy is that risk has a single exit. Instead of approving things in five windows, every risky action (sending something, spending money, deleting something, posting publicly) lands in one place.

In Fluf that place is the Inbox, under Needs you. A bot pauses, explains what it wants to do and why, and waits for your yes, no or change of course. Everything else carries on in the meantime. Set the bar per bot in its role card: a social bot might draft freely but never post; an ops bot might rename files freely but never delete.

Read the bot-to-bot conversations

When bots talk to each other, you should be able to read it. Not because you need to supervise every line, but because it's the fastest way to see why something happened. If the launch post quoted the wrong price, open the thread between the writer and the researcher and you'll see exactly where it went sideways.

Fluf shows these conversations on the Team screen, next to the org chart. Treat them like a manager reading a team channel: skim, spot patterns, fix the role card, move on.

Two starter org charts

Copy one of these, rename the bots, and adjust from there.

Solo SaaS founder (fits the Free plan: 2 businesses, 6 bots)

Pom (chief of staff)
└── Lumen (business) · main bot: Kit
    ├── Growth · manager: Atlas
    │   ├── Scout: market research
    │   └── Echo: content and social drafts
    └── Product · manager: Kit (doubles as main bot)
        ├── Ash: bug triage and support replies
        └── Sprig: docs, changelog and file tidying

Six bots, two departments, one person approving. Kit pulls double duty as the business's main bot and the Product manager, which is fine at this size.

Agency running three clients (Pro)

Pom (chief of staff, sees every client)
├── Client A (business) · main bot: Atlas
│   ├── Research: Scout
│   ├── Content: Echo, Juno (design review)
│   └── Reporting: Zip
├── Client B (business) · main bot: Kit
│   ├── Content: Hazel
│   └── Ops: Sprig
├── Client C (business) · main bot: Opal
│   └── Growth: Scout-2, Nori (fact check)
└── Agency HQ (business) · main bot: Mack
    └── Finance and approvals: Fern

Each client is its own business, so memory and connections stay separate. Pom sees across all of them for your Monday overview, and Mack guards the agency's own money.

How other tools handle hierarchy

You don't need Fluf to do this, and it's worth knowing the alternatives.

CrewAI has a hierarchical process where a manager bot, either auto-created or one you define, delegates tasks to role-based workers and validates their results (CrewAI docs). It's an open-source Python framework, so it suits developers who want to code the structure themselves.

Paperclip is an open-source control plane built around an org chart, with reporting lines, per-bot budgets that pause at a limit, scheduled wake-ups and approval steps, including approval for new "hires" (GitHub). You bring your own bot runners. One review estimated ongoing upkeep at a few hours a week (fast.io).

Fluf takes the same ideas into a desktop app: the org chart is a screen you drag bots around on, every bot has a face and a name, and the hierarchy runs locally on your Mac or Windows machine using your own API keys or your installed Claude Code and Codex.

Start small, then promote

Don't design a 40-bot company on day one. Start with a chief of staff and two specialists. When you notice yourself routing the same kind of work again and again, add a manager for it. When a manager's queue fills up, split it into teams. Org charts that grow from real work beat org charts drawn on a whiteboard.

Build your first AI team in Fluf. Free for 2 businesses and 6 bots. Pro is $19 a month, with a 14-day trial and no card needed. Download Fluf for Mac or Windows.