One operator per job
You don’t have to funnel every task through a single generalist operator. Set up several, each scoped to a role: for example, one for inbox triage and follow-ups, one for research, and one for scheduling and admin. Each works independently, in its own workspace, with its own memory and its own access.
A small team gets built the same way: a few people, each with a clear remit and exactly the access their job requires.
What splitting by role looks like
A small operations setup might run three operators: an inbox operator that triages messages and drafts replies, a research operator that handles recurring competitor and market briefs, and a scheduling operator that manages meetings and follow-ups. Each gets only the access it needs. The inbox operator doesn’t need your research sources, and the research operator doesn’t need to send emails.
That scoping is a control. An operator with narrower access is simpler to reason about and needs less oversight, because there’s less it could get wrong.
Working in parallel
Each operator runs in its own cloud workspace, so they never wait for the same turn. A research operator can be two hours into a background task while your inbox operator finishes a five-minute digest and your scheduling operator holds a meeting request for your approval. You check in on each separately, and none of them waits on the others.
That’s separate work happening at the same time, not one operator switching contexts.
Separate memory, separate permissions
Each operator keeps its own memory by default. Your research operator doesn’t know what your inbox operator has learned about a client’s tone preferences, and your scheduling operator doesn’t carry research context it doesn’t need. If you want two operators to share some context, you set that up deliberately.
The same goes for approvals: rules are set per operator and per task, so an operator that can send client-facing emails can carry stricter approval requirements than one that only reads and summarizes.
Naming and organizing operators
Each operator gets its own name, such as “Research” or “Inbox”, so it’s clear at a glance which one you’re talking to or reviewing. You can rename an operator, adjust its role and access, or retire it without affecting the others.
Keeping track of several operators at once
Every operator has its own task history and its own receipts, so you can review one without wading through another’s activity. Your morning check-in can cover all of them at once: what the inbox operator handled overnight, what the research operator’s weekly brief found, and what the scheduling operator has waiting for approval.
A concrete example
A small consulting firm might run an executive-assistant operator for scheduling and travel, and a separate research operator for client briefs. The executive-assistant operator has access to calendars and booking sites and asks for approval before it confirms anything. The research operator has access to reference material and the web and never touches billing or accounts, so it runs comparisons and drafts on its own with fewer approvals. Each shows up separately in your day, with its own history, and neither one’s access widens to cover the other’s job.
When one operator is enough
Plenty of people run a single, well-rounded operator for everything, and that’s a reasonable way to work. Splitting by role tends to pay off once the access, the volume of tasks, or the need to keep work separate, like client-facing versus internal, makes one generalist operator harder to trust or to review at a glance.