Outreach approval

The single firmest promise in a team setup is this: a Team-Hub never sends or posts anything on its own. A hub worker handed an outreach task — send this email, post this reply, fire off this DM — prepares a draft and stops. You review it, a human approves it when it matters, and the actual send happens from a Command Center, never from the hub. This page explains the chain that makes that guarantee hold.

Why hubs can’t send

A Team-Hub is built so that sending is structurally impossible, not merely discouraged:

• Draft-only channels. A hub’s connectors are inbound-and-draft only. When a message arrives, the assigned worker writes a reply into a draft; the app sends nothing.
• The approval gate auto-denies when headless. Any tool action that would leave the machine hits the approval gate — and because a hub runs with no operator present, that gate auto-denies. There is no one at the hub to click “send”, and the hub won’t do it unattended.
• No money tools at all. Payment and billing tools are never in a hub worker’s allowlist, so money-adjacent outreach can’t be completed there even in principle.

The hub can prepare anything. It just can’t release it.

The two-stage approval chain

When a hub worker produces outreach, it travels through up to two gates before anything goes out:

Hub worker has an outreach task (send email / post reply / DM)
        │
        ▼  prepares the artifact — DRAFT only, nothing leaves
   draft saved + flagged "pending outreach"
        │
        ▼  Stage 1 — Theodor (the hub's orchestrator) reviews
   Theodor approves  ── reject ──▶ back to the worker to rework
        │ approve
        ▼  Stage 2 — a human approves (when required)
   you approve on a Command Center  ── reject ──▶ back to the worker
        │ approve
        ▼  ONLY NOW does a Command Center (never the hub) perform the send

• Stage 1 — Theodor. The hub’s own orchestrator reviews the draft first. If it’s off-brief or sloppy, it goes back to the worker for a rewrite before a human ever sees it. This catches the obvious problems automatically.
• Stage 2 — a human. When a send is external, money-adjacent, or sensitive, a person must approve it from a Command Center. Internal-only drafts may be configured to need just Theodor’s nod.

The send always happens from a Command Center

Even after both approvals, the send is executed by a Command Center, not by the hub. This isn’t a formality — the hub has no send capability to invoke. Approval and execution are deliberately on different machines, so the box running unattended on a server is never the one that can reach out to the world.

What needs a human (and what you can relax)

Whether Stage 2 is required is policy-driven, and it defaults to the safest setting:

• Any external send or public post → a human approves. This is the default and the recommended posture.
• Internal drafts (e.g. something staying inside your workspace) may be set to require only Theodor.
• The requirement is configurable per channel and per worker, so you can be stricter on, say, your public social account than on an internal notes channel — but you tighten down from safe, you don’t loosen by accident.

This is the same gate you already trust

The outreach chain is the team-scale version of askTheodor’s everyday rule: workers draft outward-facing things and pause for your approval. If you’ve used Chat and watched a worker stop before sending an email, you already understand this — teams just add Theodor as a first reviewer and make the final send live on a Command Center.

Status: partly shipped

Shipped today: draft-only channels and the headless approval-gate auto-deny — so a hub genuinely cannot send right now. In progress: the full two-stage chain as a first-class flow — Theodor’s Stage-1 review, the “pending outreach” queue surfaced on a Command Center, and the per-channel/per-worker Stage-2 policy. Until that lands, the protection is “hub drafts, you send manually from a Command Center”; the chain formalizes and streamlines it.

In practice

This is what makes an unattended machine safe to run at all. A server executing agent work around the clock, reachable from the internet, with nobody watching — the reason that’s a reasonable thing to do is that the worst it can produce is a draft. Every path outward ends at a machine with a person at it.

Note the difference between “won’t” and “can’t.” The hub isn’t configured to decline sends; it has no send capability to invoke. Draft-only channels, an approval gate that auto-denies with no operator present, and no payment tools in any hub worker’s allowlist are three independent reasons the same action fails. Configuration mistakes don’t undo that.

Two things this lets you set up without anxiety:

• An inbox that answers itself, almost. Incoming mail reaches the hub, the assigned worker drafts a reply, and the draft waits. You skim and release from your desktop — the labour is automated, the decision isn’t.
• Scheduled social content. Posts get written on the hub on whatever cadence you set, and accumulate as drafts. Nothing appears publicly until you approve it.

Tighten down from safe rather than loosening carelessly. External sends and public posts requiring a human is the default and the recommended posture. The per-channel, per-worker policy exists so you can be stricter on your public account than an internal notes channel — the movement worth making is toward more review, not less.

Today the protection is real but manual. Draft-only channels and the headless auto-deny are shipped, so a hub genuinely cannot send right now. Theodor’s Stage-1 review, the pending-outreach queue on the Command Center, and the per-channel Stage-2 policy are in progress — until they land, the workflow is “the hub drafts, you send from a Command Center,” which is the same guarantee with more of your time in it.

Terms in this page

• Outreach — any action that reaches outside your workspace: sending an email, posting a reply, sending a DM.
• No-send guarantee — the rule that a Team-Hub never performs outreach itself; it only drafts.
• Draft-only channel — a connector where an incoming message produces a worker-written draft and the app sends nothing automatically.
• Approval gate — the checkpoint that pauses sensitive actions for human approval; on a headless hub it auto-denies, which is why a hub can’t send.
• Auto-deny (headless) — the approval gate’s behavior with no operator present: it refuses, rather than acting unattended.
• Two-stage approval chain — the path an outreach draft follows: Stage 1 Theodor reviews, Stage 2 a human approves (when required), then a Command Center sends.
• Stage 1 (Theodor review) — the hub orchestrator’s first-pass approval or rework of a draft.
• Stage 2 (human approval) — a person’s approval on a Command Center, required for external, money-adjacent, or sensitive sends.
• Policy-driven — whether Stage 2 is required is set by configurable policy (per channel / per worker), defaulting to the safest option.
• Pending outreach — the flag on a draft that has been prepared but not yet approved or sent.
• Theodor (orchestrator) — the built-in chief-of-staff worker; here, the first reviewer of outreach drafts.