AI agent org chart

An org chart for bots,
written as code.

An AI agent org chart declares which bots exist, which unit each one belongs to, who approves their work, and what they may spend. Klingbar keeps that declaration in a versioned file your team reviews and signs, not in a diagram nobody can enforce.

Definition

What an AI agent org chart is

An AI agent org chart is the authority file for a group of bots. It answers four questions that a prompt cannot: which bots exist, which unit each one belongs to, whose approval their work routes through, and what each role is allowed to spend. Everything a bot is permitted to do traces back to a line in it.

The distinction that matters is between describing an organization and constituting one. A slide describes. A file that the system reads before it acts constitutes. When the chart is the thing the runtime consults, an organization stops being a story you tell about your bots and becomes a fact about them.

org.toml
[[unit]]
name = "research"

[[member]]
handle  = "scout"
unit    = "research"
role    = "market analyst"
budget  = "5.00 USD/day"

Four declarations: a unit exists, a bot belongs to it, the role it holds, the money it may spend.

Shapes

Five topologies, and when each earns its keep

Single bot. One worker, one job, one schedule. No chart is needed; a role contract is enough. Most first deployments live here and should.

Supervisor. One coordinating bot fans work out to several workers and assembles the results. The chart's job here is to say who the supervisor is, so the answer does not depend on which prompt ran first.

Hierarchical. Units nest, and each has its own budget and its own approver. This is the shape that makes spend controllable: a ceiling on a unit binds every role inside it.

Handoff. Work moves between peers by role rather than by name, so replacing a bot does not rewrite the routing. The chart names the roles; the bots holding them are swappable.

Human in the loop. A named person sits on the path of specific actions. That person is not a comment in a prompt — they are an approver identity in the chart, which is what makes the gate enforceable. See human approval workflows.

Pick one on purpose
single · one job supervisor · fan-out hierarchical · nested budgets handoff · route by role human in the loop · named approver

A topology chosen by accident is still a topology. Writing it down is how it becomes a decision.

Why a file

Review, diff, revert

Review. A change to the organization arrives as a diff before it takes effect. Someone reads the four lines that moved a bot into a unit with a larger budget, rather than discovering it in a bill.

Diff. The question "what changed about how this org is allowed to operate, and when" has an exact answer, because the answer is a text diff rather than a memory.

Revert. A restructure that turns out badly is undone by restoring bytes. Nothing has to be reconstructed from a screenshot of last week's diagram.

This is the whole argument for infrastructure as code, applied to the layer above the runtime. The chart is not documentation of the organization. It is the organization.

A chart change, reviewed
diff · four lines approver · named signature · bound to these bytes

A human approves the exact bytes. An approval cannot be spent against a version that moved after it was given.

What it declares

Units, members, an approver, and budgets

A Klingbar chart declares units (the groups work is organized into), members (the bots in them and the role each one holds), an approver identity at the root (the human the organization answers to), and the budgets those roles work under.

Activation reads exactly three facts, and they are facts about capability rather than paperwork: the chart parses, its root resolves to a declared member carrying an approver identity, and it declares at least one unit. An organization that satisfies those three can decide things. One that does not, cannot — and Klingbar says so in those words rather than colouring the card green.

The same function answers the setup checklist and the activation gate, so the checklist can never describe a bar that the gate does not actually apply.

Can this chart decide?
it parses root resolves to an approver at least one unit

Three questions about what the chart can do — not about who signed off on it.

Editing

A visual editor that only ever splices bytes

A chart is a file a human signs the exact bytes of, so an editor that rewrote it wholesale would break the one property that makes signing meaningful. Klingbar's org design editor works as a byte splice: moving a bot between units changes only the spans that describe that bot, and the rest of your file — comments, ordering, formatting — comes back exactly as you wrote it.

It also refuses to guess. Anything it cannot map to an unambiguous span falls back to the raw-text editor, which is the floor and is never taken away. The editor never decides what a chart means, either: the runner's own parser is the arbiter, and an invalid chart is refused with the line and column that broke it.

The canvas is progressive enhancement over markup that already works. Every operation has a plain form behind it, and the whole edit-to-approval path is reachable from the keyboard alone.

Editor guarantees
splice · not rewrite ambiguous · falls back to raw text validation · the runner decides keyboard · complete path

Your comments and your ordering survive an edit made in a browser.

The honest limit

When you don't need one

If you have one bot doing one job on a schedule, an org chart is overhead. Write it a role contract — duties, boundaries, a budget, an escalation path — and stop there. A chart with a single member declares nothing that the role contract did not already say.

A chart starts paying for itself at the point where bots consume each other's output, where work has to reach a reviewer before it ships, or where spend needs a ceiling per unit rather than per bot. Below that line it is structure for its own sake, which is a cost with no matching benefit.

Related reading: human approval workflows for deciding which actions need a person, and self-hosted agents for where the bots described by the chart actually run.

Frequently asked

What is an AI agent org chart?

An AI agent org chart declares which bots exist, which unit each one belongs to, who approves their work, and what they may spend. Klingbar keeps that declaration in a versioned TOML file rather than a diagram, so it can be reviewed, diffed, and reverted.

Why write the org chart as a file instead of drawing it?

A diagram describes an organization; a file constitutes one. Because the chart is text, a change to it is a diff a human reads before it takes effect, a bad edit is one revert away, and the shape of the organization on any past day is recoverable from history.

What does a Klingbar org chart declare?

Units, the members in them, an approver identity at the root, and the budgets each role works under. Klingbar's activation check reads exactly three facts: the chart parses, its root resolves to a declared member carrying an approver identity, and it declares at least one unit.

Do I need an org chart for a single bot?

No. One bot doing one job on a schedule needs a job description, not a chart. The chart earns its place when bots depend on each other's output, when work has to route to a reviewer, or when spend must be bounded per unit rather than per bot.

Can I edit the chart without writing TOML?

Yes. The org design editor maps each edit onto a byte splice over the original file, so a move or a rename changes only the span it touches. Anything the editor cannot map unambiguously falls back to the raw-text editor, which is always available.

Give your bots a chart worth signing

Klingbar is in early access. Join the waitlist and we'll reach out as capacity opens.

Join waitlist