Command Center vs Team-Hub

Every instance in a team is one of two kinds, and they play opposite, complementary roles. A Command Center is the cockpit and the quality desk — where you direct work and where your reviewers, critics, and judges sit. A Team-Hub is the production line — where the workhorse workers churn out research, code, drafts, and designs around the clock. Knowing which is which makes every other team decision obvious.

Command Center — the cockpit + the control plane

A Command Center is a full desktop install of askTheodor, run by one operator. It is the only kind of instance that gives you the whole app — Chat, Companies, Plans, Library, Settings, Fleet — and the only place where money is spent and outreach is actually sent.

Two jobs sit naturally on a Command Center:

• The cockpit. You delegate tasks out to hubs, watch them in the Fleet screen, review what comes back, and approve the things that need a human. Day-to-day steering happens here.
• The control plane. The Command Center is the ideal home for your quality-gating workers — the Reviewers, Critics, Judges, Testers, and QA personas whose whole job is to inspect the artifacts the hubs produce (documents, images, posts, plans) and pass or fail them. Theodor, your orchestrator, lives here too. Keeping the “graders” close to you means the human and the AI quality checks share one place.

Match workers to the plane

On the worker-activation screen you can filter by plane — Command-center roles (Reviewer, Judge, Critic, Tester, QA, Orchestrator) versus Production roles (Researcher, Developer, Creative, Writer, Analyst, Digestor, Planner). Worker dropdowns also show each persona’s job role next to its name, so you pick the right one fast. (This taxonomy UX is shipped.)

Team-Hub — the production line

A Team-Hub is a headless runner — askTheodor started with --runner, with no window, typically on a VPS. Nobody sits at it. Its purpose is to run the workhorse workers 24/7:

• Research — scouting sources, gathering and summarizing.
• Development — writing and editing code.
• Creative / design — producing images and creative drafts.
• Docs & writing — long-form documents, reports, posts (as drafts).
• Plans, digestions, routines — the scheduled and multi-step background work.

It holds the shared Companies, Library, Plans, and Workers, synced with every Command Center that’s paired to it, and it runs Plans, the Reviewer sweep, and the stuck-task watchdog on its own.

A hub never touches money and never sends

This is the hard rule. A Team-Hub has no payment tools in any worker’s allowlist, and its channels are draft-only — a worker whose task is “send this email” or “post this reply” prepares the draft and nothing more. The actual send happens later, from a Command Center, after the outreach approval chain. The hub literally can’t send; running headless, its approval gate auto-denies anything that would leave the machine.

Side by side

	Command Center	Team-Hub
Form	Full desktop app, has a window	Headless --runner, no window
Who uses it	One operator (you / a teammate)	Nobody — it runs unattended
Typical home	Your laptop / workstation	A VPS, on 24/7
Best-suited workers	Reviewers, Judges, Critics, QA, Theodor	Researchers, Developers, Creatives, Writers
Runs Plans/Routines	Yes	Yes (24/7)
Spends money	Yes	Never
Sends email / posts	Yes — the only place sends happen	Never — drafts only
Licensing	Your base app license	The paid “remote” add-on

Why split it this way

Separating the control plane (Command Centers) from the production line (Team-Hubs) gives you two things at once: hubs can run flat-out and unattended on cheap server hardware, while every consequential action — spending, sending, deleting — is funnelled back through a human at a Command Center. The split is the safety model, not just an architecture choice.

How the two stay in sync and how delegation actually travels between them is covered in Fleet & sync.

In practice

Put the graders where you are, the grinders where the uptime is. That’s the whole placement rule. Reviewers, Critics, Judges, QA and Theodor belong on your Command Center because their output is judgement you’ll act on; Researchers, Developers, Writers and Creatives belong on the hub because their work is volume that benefits from running all night. Split a Company along that line and both halves get what they need.

Two arrangements that follow naturally:

• An overnight research pipeline. Hub workers scout and summarise sources through the night; your Command Center’s Reviewer critiques what came back; you read a checked digest in the morning rather than raw output.
• A drafting line for outbound content. Hub writers produce drafts continuously and cannot send any of them. You review and release from the Command Center — the volume is unattended, the consequential step never is.

The plane filter on the worker-activation screen is there to make this easy — filter by Command-center versus Production roles rather than deciding worker by worker. Worker dropdowns show each persona’s job role next to its name for the same reason.

“A hub can’t send” is structural, not a setting you could forget to enable. Its channels are draft-only, the approval gate auto-denies with no operator present, and payment tools are never in a hub worker’s allowlist. That’s what makes it reasonable to leave a machine running unattended on the public internet — see Outreach approval.

Don’t put a Reviewer on the hub and expect a quality gate. It will run, but its verdicts land on a machine nobody is watching. The point of the control plane is that a human is near it.

🎓 Learn it hands-on: Fleet: a Team-Hub on a VPS

Terms in this page

• Command Center — a full desktop install of askTheodor run by one operator; the cockpit you steer from, the home of the control plane, and the only place sends and final approvals happen.
• Team-Hub — a headless --runner instance (usually on a server) that runs the workhorse workers 24/7; the paid “remote” add-on.
• Control plane — the quality-gating layer: the Reviewer, Critic, Judge, Tester, and QA workers (plus Theodor) that inspect and pass/fail what the hubs produce. Best hosted on a Command Center.
• Production line — the workhorse workers (research, development, creative, docs, plans) that generate the actual output, run on a Team-Hub.
• Plane — a hint tagging each worker as a Command-center role or a Production role, used to filter and suggest the right worker for the job.
• Headless / runner — running with --runner and no graphical window, so the app can live on a server.
• Draft-only channel — an inbound channel where a worker may prepare a reply but the app sends nothing; the default for hubs.
• Approval gate — the checkpoint that pauses sensitive actions for human approval; when running headless it auto-denies, which is what makes a hub unable to send.
• Allowlist — the set of tools a worker is permitted to use; hub workers have no payment tools in theirs.
• “Remote” add-on — the paid entitlement that licenses running askTheodor headless as a Team-Hub.
• Orchestrator (Theodor) — the built-in chief-of-staff worker that coordinates the others and drafts Plans.