The org is the coordination model

The first pattern is wire-the-flow. Most agent frameworks expose orchestration as a graph or a class diagram and let the engineer compose it. The user is in control, the abstraction is exact, and the cost is that the user is doing the orchestration work.

The second pattern is hide-the-agents. Cloud agent platforms and some consumer apps treat the multi-agent layer as an implementation detail. The user sees one assistant and the platform fans the request out under the hood. The cost is the inverse: the user is not doing the orchestration work, but they also can't tell what is happening, can't address a specific agent, and can't reason about why one part of the response disagrees with another.

Both patterns are extreme answers to the same question. The first asks the user to learn a new abstraction (the graph). The second tries to hide the abstraction entirely. We picked a middle answer: an abstraction the user already has.

An org chart is a shape almost everyone already understands. There is a person at the top who decides what gets done. There are people who do the work. Delegation happens between them — the boss assigns, the worker reports, and sometimes the worker pulls in a peer for review.

We took that as the runtime primitive. A CEO employee sits at the top. Specialists sit below. The CEO routes — given a request, it picks the employee who should own it. Specialists can delegate to peers when the work is genuinely cross-functional. Peer review is a primitive: any specialist can convene a moderated discussion where peers critique each other's output before anything ships.

This isn't a hierarchy in the bureaucratic sense — there are no titles, no salary bands, no performance reviews. It is a hierarchy in the coordination sense: someone has to decide who does what, and routing through one decision-maker is more reliable than routing through a committee.

Cognitive load. Users don't have to learn anything new to understand who is in the room. Everyone has worked with a team, even if it was a school project or a side gig. Asking “who should do this?” and routing through a CEO is the same question and the same answer they use in the rest of their work.

Addressability. Because the agents are visible and named, the user can address them. “Marketing Strategist, draft the launch announcement” works because there is a Marketing Strategist. In a hide-the-agents product, that sentence has no referent. In a wire-the-flow product, that sentence requires the user to have built the agent first.

Debuggability. When an answer is wrong, the user can tell which employee owned it and ask them to revise. The org chart gives the user a way to reason about disagreement: if two employees gave conflicting advice, that disagreement is legible. In a single-assistant product, the assistant is just “wrong” — there is no second opinion to triangulate against.

Memory follows the role. Per-employee memory is only a coherent design if the user thinks in terms of employees. Per-task memory or per-thread memory would be the consistent design for a single-assistant product. Per-role memory is what makes a six-month-old employee feel like a colleague.

Concretely: when you DM the CEO, the CEO model is asked to pick which specialist should own the request. The CEO can answer directly, delegate to one specialist, or fan the work out to several. When a specialist is delegated to, they run with the request inside their own context window — their own memory, their own tool set, their own approval rules — and report back when done.

Peer review is a separate primitive. A specialist can convene a moderated discussion with one or more peers — say, the QA Reviewer pulls in the App Builder for a sanity check on a code change. The discussion runs as a bounded conversation between named agents, with a moderator model keeping it on track. The result is a single agreed-upon answer, not a transcript of disagreement.

The scheduler handles background work. Employees can carry recurring routines — “check this folder daily,” “watch for new files in this directory.” Routines run when the app is open and surface results as DMs the next time you check.

Flat collaborative tasks are awkward in a hierarchy. If three employees genuinely need to co-author one document with no clear lead, the CEO routing pattern is overhead. The peer-review primitive helps, but the natural shape there is closer to a meeting than a delegation.

Long single-agent context tasks are also awkward. If the work is one long reasoning chain by one specialist, the CEO layer adds latency. We let users DM specialists directly for exactly this reason — but the CEO-first default is a small tax for those workflows.

When the routing logic itself is the value — say, you are an engineer building a product that needs custom orchestration — the templated hierarchy is the wrong abstraction. Use a framework. The right shape for that audience is exactly the one CrewAI and AutoGen already offer.