Distinguish personal bots, groups and Team Bots
The documentation describes groups containing two to six bots. A Team Bot instead gives several employees access to one shared configuration. These are different ways to organise work. Sources: collaboration and Team Bots, checked October 25, 2026.
Our assessment: first decide whether one person needs to coordinate several steps or an entire team needs the same process. An individual workflow may be enough for a monthly analysis. A shared internal information service needs different ownership. Record this decision before creating additional bots; a larger number does not resolve an unclear task.
Define roles around outputs you can review
For a pilot, we suggest three briefs: collect material, prepare a draft and identify unresolved issues. This is our proposed division of work, not a provider promise of independent quality assurance. Research returns source locations and dates; drafting uses only approved material; review identifies missing evidence. Give the roles clear names and define who resolves disagreements.
Two bots using the same unsupported starting text do not create additional evidence. Ask the reviewing role to compare the output with specific source material. For example, it should trace each figure to a spreadsheet cell. A value that cannot be traced remains unresolved. The human owner then decides whether the draft is suitable for use. Also record what each role should leave alone. A research brief, for example, does not need permission to reorganise the filing system. This boundary helps later review: the team can assess whether work stayed within its agreed scope as well as checking the content itself.
Write a handoff as a clear work brief
Our recommended handoff records the goal, source, current status, output location and next decision. Add unresolved questions and actions that have not been authorised. The next participant should not have to reconstruct the brief from a long conversation. A link to the reviewed working version is more useful than a message saying the task is finished.
Example: research hands over five sources for an internal market briefing. Drafting is asked to turn them into one page with source links. Review reports factual gaps and labels assumptions. Nobody publishes or sends the briefing. This illustrative workflow is a suggested test; it is not a client project and makes no claim about measured time savings.
Review shared access separately
Bot roles do not separate access: one user’s bots share that user’s computer and sessions. Team Bots distinguish personal OAuth sign-ins from shared keys. Sources: security FAQ and Team Bots, checked October 25, 2026.
Our implementation recommendation is a small access matrix: permitted sources, possible changes and a responsible person for each role. Check the matrix against the accounts actually connected. Confidential areas need verified technical separation; a role name in a chat is insufficient. If access remains unclear, keep that source outside the pilot until the responsible IT team has assessed it.
Test collaboration with failure cases
For acceptance, process the same starting cases with one bot and then with the proposed division of roles. Compare subject accuracy, clarification requests and total handling time, including review. Parallel work is useful when it delivers a verifiable benefit for this task. A deliberately easy demonstration should not be treated as evidence for an entire business process.
Include a missing attachment, a conflicting source and a withdrawn brief. Check that unfinished work remains identifiable and completed outputs can be found. Define when the bots should stop and who takes over. Acceptance should produce a recorded decision: continue, reduce the scope or abandon the approach. A failed test is useful when it exposes a boundary before regular use.
Assign ownership and maintenance
One person owns the brief, approvals and workflow changes. A second should understand the documentation and be able to cover absences. We recommend a short change record for new sources, revised instructions and additional permissions. Repeat the important acceptance cases after those changes. This turns a promising first attempt into a process whose boundaries the team understands.
If you want support defining these roles and handoffs, our Grok Bot setup service explains the possible scope, with pricing on request for the confirmed scope. The existing AI System Check structures the starting point. You can also send specific questions to hello@lol.marketing without including confidential material or credentials. Implementation and support are provided independently by lol.marketing LLC. We are not affiliated with, authorised by or endorsed by xAI or SpaceXSI.
Frequently asked questions
How many roles should a first pilot have?
We recommend a small number of distinct tasks. Start with research and drafting, for example, and add another role only when its output and value can be assessed. Human acceptance remains a separate responsibility.
Does a reviewing bot replace professional approval?
Not in our proposed workflow. Review produces findings, source comparisons and open questions. The responsible person then evaluates the output and decides whether it can be used.
What should be defined before adding more bots?
First define the goal, sources, output format and ownership. Then check whether an additional role resolves a bottleneck or simply introduces more handoffs and review work.
Keep it verifiable
Primary sources
- Grok Bot: Team BotsSource checked:
- Grok Bot: messaging and collaborationSource checked:
- Cursor: Grok Bot security FAQSource checked:
