The Agent Org Chart & Dispatcher

Each role is a written agent definition with its own scope, tools and personality. The reporting line lives in one roster file, and that file is the authority: the hub page, the permission checks and the dispatcher all read it rather than keeping their own copy.

The first chart had fifteen seats, and the task board showed where it was thin. One engineer held every code task across unrelated repos, regulated and not, and the dispatcher runs one session per role, so everything queued behind one seat. Nobody took command of an incident that crossed departments: the NOC, the security agents and the helpdesk each worked their own piece with no one running the timeline.

So I had three AI reviewers benchmark it against how real companies run operations: one from ITIL and managed-service practice, one from SRE and incident command, one from a security organisation and the business side. Their view was that most of the gaps were duties nobody owned rather than missing people. Problem management, change approval, capacity, disaster-recovery drills, vendor review and customer offboarding went into existing roles. The seats that earned their place were the ones with recurring work or a separation-of-duties reason: an incident commander, an engineer who is the only one allowed to touch the regulated apps, a reviewer who checks that engineer's work, a detection engineer, a compliance officer, and an agent-operations lead whose job is auditing the other agents.

The incident commander got its own lane in code, built by the agent org itself the same day the seat was added. Declaring an incident opens an incident id, files a task for the commander and for each responder it pages, parks those responders' other work, pauses the manager rounds above them, freezes routine changes on the affected hosts, and pages me on a Sev1. Responders check in on a timer, and a scribe timeline builds itself from their notes.

A service makes one pass a minute. It keeps every running session supervised, and if there is room, it starts a fresh session for the next eligible task in its own terminal, under its own memory cap, with the Terminal Brain committee reading the screen.

Supervision covers the ways a session ends badly: it never started, it crashed, it went idle, or it ran past a hard time limit. Each one is a failed attempt. Three failed attempts and the task is blocked with the reason, instead of being retried forever.

Managers are not sessions left open all day, filling their context with stale state while they wait. A manager is a short session started when there is something to manage: on a schedule while its branch has open work, and early when one of its reports finishes or blocks. It reads the board, re-queues, delegates, escalates, closes the round with a one-line report, and exits.

Task text becomes an unattended prompt, and that is the security problem with the whole idea. If any agent could assign work to any other, one confused or manipulated agent could write a prompt that runs on its own in a peer's session, with the peer's tools.

So the dispatcher only starts tasks that the owner created, or that a manager above the assignee created. Everything else waits on the board for a person. Three lanes cross the chart on purpose: any agent can file a security request to the security team, with the CEO copied; a program lead can task the named specialists on its team, with their managers copied; and during a declared incident the incident commander can task any responder. Nothing else crosses. An agent also can't borrow someone else's name to get across: who it is comes from the sandbox the dispatcher started it in, so a session filing work as its manager is refused and the attempt is logged off the box. Identity the kernel enforces is the next step, with per-role keys from the secrets vault after it.

The same reasoning sets the limits: a small number of sessions live at once, one per role, a daily budget, a free-memory floor, and a pause switch that stops new work on the next pass, with separate switches for rounds and for incidents.

Customer-facing actions and anything that spends money always need me. The cheap way to build that is an agent that stops and writes a paragraph. The useful way is a question with labelled options, each saying what will happen, one marked as the recommendation, and a comment box. My answer re-queues the task with the choice written into its notes, so the next session starts from the decision instead of from the question.

An idle dispatcher and a dead one look identical: an empty board. On one day the screen-reading committee had made no reading for fourteen hours and nothing said so, because a restart elsewhere had quietly detached it.

Both are now covered by a fleet invariant that runs on a schedule and fails loudly if the dispatcher has not reported in within five minutes or the committee cannot reach the sessions it is supposed to watch. A pause shows as a skip with its reason, so a deliberate stop never reads as a healthy one.