A GTM setup made of agents: orchestrator, client teams, approval
What a GTM org chart with no people in it looks like: one orchestrator, one agent team per client for outbound, a content agent with a Slack approval step, and the rule that holds it together.
Our GTM org chart has no people in it. An orchestrator sits at the top, one team per client hangs below it, and a content agent runs alongside. This playbook describes the build so you can copy it, including the place where it deliberately stops.
One note first, so the expectation is right: the five meetings a day in the chart are the target the setup is built for. They are not a measured average. Anyone selling you an agent setup with guaranteed meeting counts is selling you a number they do not have.
1. The orchestrator
A single agent sits at the top, starts the others and reports back. We run OpenClaw for this, a self-hosted gateway that connects chat apps to AI agents. It is called Mr Krabs, because a cartoon name catches the eye in a Slack channel faster than “orchestrator instance 1”.
Three decisions matter more than the choice of tool:
The orchestrator runs isolated. It sees exactly the directories it needs for its work and nothing else. No access to your other projects, no Docker socket, no route to services listening on the host. If it should later work on one specific repository, it gets that one directory, never the whole tree.
It is not reachable from the internet. The control surface lives on a private network. An agent with access to mailboxes, CRM and sending is a target; it does not belong on a public address.
It runs on subscriptions, not on a pay-per-token key. That sounds like bookkeeping but it is an architecture decision: an agent working hourly produces a cost curve under per-token billing that nobody estimates correctly in advance.
2. One team per client
Below the orchestrator sits one team per client. The separation is not cosmetic. Every client has their own data, their own knowledge about their ICP, their own senders and their own limits. A shared team across clients eventually means a learning from client A ends up in a message to client B.
Each team has four roles:
- Research finds companies and contacts, enriches them, collects signals.
- Qualification scores against the client’s ICP and states the reason. The reason is the part that counts: a score without a reason is a gut feeling with a decimal place.
- Outbound over email and LinkedIn writes and runs the sequence.
- Replies and booking classifies incoming replies and turns the positive ones into meetings.
That order is also the order you build them in. Start at role 3 and you have built a machine that contacts the wrong people quickly.
3. The content agent
Next to the client teams runs an agent that sells nothing. It finds topics, writes a draft and submits it for approval. Three steps, and the third is the important one.
- Ideas come from what actually happened in the work. A content agent that invents topics produces filler.
- Draft means text plus finished graphic. Not text with the promise of a graphic: you can only approve what you can see.
- Approval in Slack is a card in the channel with two reactions under it. A tick means go, a cross means dropped.
The draft then lands as a draft in the posting system, not as a scheduled post. The slot is a human decision.
4. The daily brief
Once a day, for us at eight, a run happens that only reads: numbers per client, new replies, open decisions, backup health. The result is one Slack message that fits on a phone.
Two properties make the difference:
The run is read-only. It sends nothing, changes nothing, writes nothing. A brief that is allowed to act on the side is not a brief.
It names a decision list. The last section is called “waiting on you” and holds items answerable in one word. Everything else in the brief is context; that section is the actual work.
5. The rule that holds it together
The setup may research, score, draft, propose and report. It may not send or delete on its own. Those two verbs are the difference between an assistant and a liability: everything else can be undone, a sent message and a deleted record cannot.
In practice that means three things:
- An automation is armed by a human, not by an agent.
- New content goes out as a draft, never straight live.
- Anything that touches a person outside your own system needs an approval.
And the uncomfortable honesty: once a sequence is armed, it sends its follow-up steps by itself. The approval sits at the switch, not on every individual message. Anyone claiming otherwise either has a different system or has not looked closely.
6. The order to build it in
- Set up the orchestrator isolated, reachable only on a private network.
- Connect the chat channel and name one person as the decision maker. Without that, any channel member’s reaction counts as an approval.
- Build the read-only daily brief. It is the cheapest part and the one that earns trust fastest.
- Build a single client team, roles 1 to 4, and run it until the replies are right.
- Only then the second team. Two teams with the same unsolved problem are two problems.
- Content agent last. It is the most visible part and the one most likely to be overrated.
If you notice at step 3 that nobody reads the brief, it is almost never the agent’s fault. It is that the numbers in it do not trigger a decision. Then the thing to build is the decision list, not the next agent.
Next step
GTM Goat runs exactly what you just read.