How to build an AI operations team: roles, handoffs and controls.

A working AI operations team has five parts: a charter for each role that says what it owns and what it must never do; a routing table that sends each kind of work to exactly one owner; a handoff contract that every message between roles follows; approval gates on every action that commits the business; and an exception path that delivers anything unusual to a person instead of letting it disappear.

This article describes those parts in a tool-neutral way and then notes how they map onto Grok Bot, whose documentation provides named Bots, shared skills, routines, Bot-to-Bot messages, ownership handoffs and group chats. The coordinator role described here is Aevrion's design pattern built on those documented features; it is not a built-in product feature. Where work must be kept apart, the separation is a separate user account, because every Bot on one account shares a computer.

A charter is to an AI role what a job description is to a hire, with one difference: it must be explicit about the things a person would infer. Grok Bot's documentation separates durable rules, which a user gives a Bot in chat and asks it to remember, from task instructions, which are ordinary messages — the charter is that set of durable rules, written deliberately. Personal Bots no longer have a description field; a Team Bot has a description of up to 140 characters, which is what teammates read when they find it, not a place for the charter. The documentation also says safety boundaries should rest on approvals and Auto-review rules, not on memory alone, so a charter's prohibitions are backed by approval rules as well.

1. 01

   Outcome owned

   Decides

   What result is this role accountable for?

   Output

   One sentence, e.g. 'every written inquiry has a drafted reply and a job summary within the working day'

2. 02

   Inputs

   Decides

   Where does its work come from, and in what form?

   Output

   Named sources and the packet format it accepts

3. 03

   Sources of truth

   Decides

   Which systems does it read current facts from?

   Output

   A list of systems and the fact each one is authoritative for

4. 04

   Permitted actions

   Decides

   What may it do without asking?

   Output

   A short list — usually read, draft, file, report

5. 05

   Approval-gated actions

   Decides

   What may it propose but not do?

   Output

   Each consequential action and the person who approves it

6. 06

   Prohibited actions

   Decides

   What must it never do, even if asked by another role?

   Output

   Explicit prohibitions — prices, commitments, payments, deletions

7. 07

   Escalation

   Decides

   When does it stop and hand to a person?

   Output

   Conditions and the destination

When two assistants both believe they own a task, it is done twice; when neither does, it is not done at all. A routing table removes the ambiguity: for each kind of incoming work, one owning role, one fallback, and the condition that sends it to a person. It is a short document that the coordinator follows and the owner can read in a minute.

Grok Bot's documentation suggests a group chat when several Bots need one shared outcome with visible handoffs, with a coordinator assigning work, and direct Bot-to-Bot messages when one role needs another to do something specific. The routing table decides which applies: routine work goes directly to its owner; work that genuinely needs several roles at once goes to a small group. A group holds two to six Bots, and approval requests and email or Slack drafts never appear in it, so each approval is raised in the owning Bot's own conversation.

Handoffs fail in predictable ways: the receiving role lacks context, both roles think they own the next step, or the work is passed on a stale copy of the facts. A handoff contract prevents all three. Every handoff names the new owner explicitly, carries a link to the authoritative record rather than a copy of it, states the requested output and the approval it needs, and is acknowledged by the receiver before the sender lets go.

Grok Bot's documentation describes asynchronous Bot-to-Bot requests that the receiving Bot handles and answers later, with the handoff visible in the conversation, and the passing of task ownership so the user is not the router. Skills shared across Bots are the natural place to define the contract once, so every role writes and reads handoffs identically.

Rules that make handoffs dependable:

• LINK, DON'T COPY

  Pass the identifier and location of the record, never a pasted copy that will go stale. The documentation itself says memory is not an authoritative source.

• ONE OWNER AT A TIME

  Ownership moves; it is never shared. The sender confirms the receiver accepted before closing its part.

• IDEMPOTENT STEPS

  Design each step so that repeating it does no harm — re-drafting a reply is safe; re-sending it is not. The documentation's own routine guidance asks for idempotent retries where possible.

• IMAGES DIRECT

  Group handoff messages are text-only in Grok Bot, so a role that must inspect a photo receives it directly.

If every step needs approval, the owner becomes a rubber stamp and approvals stop meaning anything. If nothing does, the team will eventually commit the business to something it should not. The working rule is to gate actions that commit the business — sending to a customer, publishing, purchasing, changing data or permissions, agreeing terms — and to let preparation run freely.

Grok Bot supports configurable approval for consequential actions, with Allow once, Always allow and Deny, and model-based Auto Review that the documentation describes as a complement to explicit boundaries rather than a replacement. Two properties belong in the design: an approval does not reverse work already done, and an approval raised by unattended work expires without running if nobody answers: after about ten minutes by docs.x.ai's account, or thirty by Cursor's help pages. The architecture that follows is a review queue: roles prepare, the queue collects, and a person works through it at set times.

The most dangerous failure in an AI team is silent: a role meets something outside its charter and quietly does nothing. The defense is an exception queue — a single, visible list where any role puts work it cannot complete, with the reason — and a person who empties it every working day.

Grok Bot's documentation keeps run history for routines and lets Bots notify the user when they finish or need input, but it describes no automatic retry and no automatic failure alert. Its routine guidance asks for a policy for missing and stale data and a stated place to report partial completion. The exception queue is that place.

With more than two or three roles, a coordinator saves the owner from routing every item by hand. In Aevrion's pattern the coordinator receives new work, applies the routing table, hands each item to its owner, watches for items that have waited too long, and assembles a short daily brief of what needs a human decision. It never approves, never sends to a customer and never changes a commitment.

Grok Bot's documentation contains a role called Chief of Staff, but it is narrower than this: a Bot that prepares a source-linked digest of what changed for a person to read, instructed not to send messages or change meetings. The coordinator described here combines that digest idea with the documented group-chat coordinator and Bot-to-Bot handoffs. Because all of a user's Bots share one computer and its sign-ins, the coordinator is a routing role, not a security boundary.

A roster of Bots is not a set of locked rooms. All of a user's Bots work on one shared cloud computer and share its files, browser sign-ins and command-line credentials, and Grok Bot's documentation says separate Bots are not a security boundary. When a workload needs its own computer and its own set of credentials, such as a second business the owner runs or a system only one person should reach, the documentation's answer is a separate Cursor user. Each user is a separate account with its own plan, so separation is a deliberate decision with a cost, not a setting on a Bot.

Taking access away needs the same discipline, whether a role is retired or the person who set it up leaves. The documentation lists the steps for removing access, and the order matters: deleting a Bot does not remove files or browser sessions from the shared computer, so the Bots go last.

The offboarding checklist, following the documentation's steps for removing access:

• PAUSE OR DELETE ROUTINES

  Stop scheduled work first, so nothing runs while access is being removed.

• SIGN OUT OF WEBSITES

  Sign out of every site on the shared computer; a session left signed in remains open to every Bot still on the account.

• UNINSTALL CONNECTORS AND REVOKE AT THE SOURCE

  Remove each connector in the app and also revoke its access in the connected service itself.

• CLEAR THE WORKSPACE

  Remove sensitive files from the shared /workspace folder.

• HIDE OR DELETE THE BOTS

  Only now hide or delete the Bots themselves.

• DELETE THE ACCOUNT IF NEEDED

  When the whole setup is retired, delete the Cursor account.

It is tempting to measure an AI team by how much it does. The measures that matter are the ones that show where it fails: how many items reached the exception queue and why, how long approvals waited, how often QA returned a draft, and which reasons recur. A falling exception count with a stable mix of reasons means the procedures are improving; a recurring reason means a procedure needs rewriting, not a stronger assistant.

Grok Bot's documentation recommends starting with the smallest useful roster and adding specialists only for stable, distinct roles. That is sound advice for any team. A role that is struggling usually has an unclear charter or a broken procedure; splitting it into two roles doubles the confusion. Fix the procedure, let the role run cleanly for several weeks, and only then split off the part that has become a distinct job with its own sources, schedule or approval boundary.

Aevrion Ops can design these teams with a business: role charters, routing, handoff rules, approval design and the integrations a company's own software requires, where each vendor's API or terms allow it, after testing. The operating judgment — what the business commits to and when — stays with the business.

Based on the Grok Bot documentation at docs.x.ai as checked on 13 October 2026. Its statements on Bot rules, Bot-to-Bot messaging, routine triggers, connected apps, approval expiry and payments were rechecked against docs.x.ai and Cursor's help pages on 26 October 2026. Aevrion Ops is an independent consultancy. It is not affiliated with, endorsed by or a partner of xAI, SpaceXSI or Cursor. Grok Bot is named here only to describe it.

1. Write a charter for each AI role — outcome, inputs, sources of truth, permitted, gated and prohibited actions, escalation — before creating it.
2. A routing table gives each kind of work exactly one owner, a fallback and the condition that sends it to a person.
3. Handoffs pass a link to the authoritative record, move ownership explicitly and use idempotent steps.
4. Gate commitments, not preparation; build a review queue because unattended approvals expire.
5. Every role needs an exception queue that a person empties daily; recurring exceptions mean a procedure needs rewriting.
6. A coordinator routes and reports but never decides; it is an Aevrion pattern built from documented Grok Bot features.
7. Separate work by user account, not by Bot, and offboard in the documented order: routines, sign-ins, connectors, files, then the Bots.