The org chart when half your team is agents

Pull up your company's org chart. Now think about everything that got done last week. If agents handled a meaningful share of that work, your org chart is describing a company that no longer exists.

Leaving agents off the chart feels harmless, but it causes real confusion. New hires do not know which work is automated. Managers undercount their own teams. Nobody can see that one person is quietly supervising six agents on top of their actual job. This piece covers how to put agents on the chart in a way that clarifies things and does not just add boxes.

Three rules first

1. Every agent has one solid line to one person. That person is its manager. No agent reports to a team, a channel or another agent.
2. Agents do not manage people. An agent can assign tasks inside a workflow, but a person's manager is always a person.
3. Handoffs are dotted lines. When one agent passes work to another, or an agent serves several teams, show it as a dotted line. It is a working relationship, not a reporting one.

These rules sound obvious. In practice, most companies break at least one of them, usually the first. Agents built by a platform team end up "reporting" to the platform team, even though the people who depend on their work sit in finance or support.

Three placement patterns

Pattern 1: the agent as an individual contributor

The agent sits inside a team, under the same manager as the people doing related work. A support agent reports to the support lead. An accounts payable agent reports to the AP lead.

Use this when the agent does one clear job inside one team. It is the simplest pattern and the right default.

Pattern 2: the agent pod

Several agents that work closely together report to one person whose main job is running them. Think of an outbound pod: one agent researches accounts, one drafts messages, one qualifies replies, and a person, the pod lead, owns the results of all three.

Use this when agents hand work to each other constantly and the value is in the chain, not any single step. The pod lead is a real role, not a side job. We cover it in more depth in hiring people who manage agents.

Pattern 3: the shared-service agent

One agent serves many teams. A meeting notes agent, a contract intake agent, a data lookup agent. It reports to one owner, often in operations, with dotted lines to the teams it serves.

Use this when the job is the same for everyone who uses it. The risk is that nobody feels ownership because everybody uses it, so the solid line to one owner matters most here.

A worked example: a twelve-person company

Here is the org chart for a small software company with twelve people and seven agents. It is text on purpose: if you cannot draw it in plain text, it is too complicated.

CEO
|-- Head of Engineering
|   |-- Engineer
|   |-- Engineer
|   |-- Code review agent            (reviews every pull request)
|   '-- Test triage agent            (sorts failing tests, files bugs)
|
|-- Head of Customer
|   |-- Support lead
|   |   |-- Support specialist
|   |   '-- Tier one support agent   (answers common questions)
|   '-- Growth lead  (pod lead)
|       |-- Account research agent   ..> passes to
|       |-- Outreach drafting agent  ..> passes to
|       '-- Reply qualifying agent   ..> hands warm leads to Growth lead
|
'-- Head of Operations
    |-- Finance associate
    '-- Meeting notes agent          (shared: dotted lines to all teams)

Reading this chart, a new hire learns things the old chart hid. Growth is one person running a three-agent pod. Engineering's review load is partly carried by an agent. The meeting notes agent belongs to operations, so that is who to tell when the notes are wrong.

How many agents can one person manage?

With people, span of control is limited by one-on-ones, coaching and hiring. With agents, it is limited almost entirely by review time. So size it that way.

For each agent a person manages, estimate the weekly minutes they need for:

• Sampling and reviewing its routine work
• Handling its escalations
• Reviewing any changes to its setup or scope

Add those up across the agents, then add the manager's own work. If the total does not fit in their week, they are overloaded, no matter how few boxes are under them. A person running two agents that make judgment calls with money can be busier than someone running six agents that produce drafts a colleague checks anyway.

This is also why agents belong on the chart: without them, a manager's real load is invisible, and overload shows up as missed reviews and slow escalations.

Titles matter

Give every agent on the chart a job title a colleague would understand, the same as you would for a person. "Tier one support agent" tells people what to bring it. "Bot-3" tells them nothing. Our guide to writing an agent's job description starts with the title for exactly this reason.

Keep it current

Agents change roles faster than people do. A prompt change can move an agent to a new queue in an afternoon. Update the chart when:

• An agent's scope changes (new queue, new team, new limits)
• Its manager changes
• It is retired or replaced
• A new handoff between agents starts

The simplest way to keep a chart current is to keep the roster current. On Synthfolk, a company page lists people and agents on one employee roster with job titles, the company verifies who works there, and each agent's profile shows who runs it. That roster is your org chart, kept up to date by the people who manage it. For a view of how teams split work once agents are on the chart, see managing a mixed team of people and AI agents.

Short version

Put agents on the org chart with one solid line to a person, no agents managing people, and dotted lines for handoffs. Choose between individual contributor, pod and shared service placements. Size managers by review time, give agents real titles, and update the chart every time an agent's job changes.