Usage notes: building my team of AI assistants with Grok Bot

Wed, 21 Oct 2026 09:00:00 -0300

Grok Bot is an app where you create AI assistants with a name, a role, and their own memory. They work in the tools you connect and can collaborate with one another. In my team, I configured the assistants to ask for my approval before sending messages, publishing content, or making payments.

On October 16, I put together a team of assistants in Grok Bot. I started with 19 specialists, each responsible for a different area of my routine. I set everything up that day.

The idea was to have someone to turn to depending on the subject: architecture, engineering, product, branding, career, finances, languages, or well-being. Rather than explaining everything again to a general-purpose assistant, I wanted to give each one its own context and responsibility.

On October 19, I added a specialist in biblical teaching. The team now has 21 assistants: 20 specialists and one coordinator.

How I organized the team

The coordinator acts as a chief of staff: it helps organize priorities and routes requests to the appropriate specialist. I also work with it on adjustments to how the team operates.

The specialists share a library of procedures. It covers how to record the context of a task, hand work from one assistant to another, prepare drafts, and manage costs.

I made a point of setting two rules from the start. The first is human approval: no sending messages, publishing content, or making payments without my approval. The assistants prepare the work; I review and decide.

The second is keeping work, company, and personal contexts separate. This is a usage rule I set to avoid mixing information between subjects. I do not treat it as an automatic guarantee from the tool.

Where it is already helping

One use is keeping up with email. I receive a consolidated summary every 30 minutes instead of having to check each inbox separately.

I have also started using the team to turn what I study into content. I paste a summary, receive draft posts for X, and review them before approving. They are then scheduled in Buffer at 15-minute intervals. When each post goes live, I receive a notification with the link.

Other uses are simpler but part of everyday life: practicing conversation with the language specialist and reviewing a short message before sending it.

On the technical side, I adjusted the automated monitoring of figueirego.com with the engineering specialist. I also asked for a plan for a development team, with responsibilities for design, backend, frontend, review, and scrum. That development team is still at the planning stage.

The cost showed up on day one

Setting everything up at once used a lot of tokens. That was the first thing that bothered me, and it remains something I want to improve.

I asked the coordinator to help manage the spending, and we created a set of usage rules.

Two of them: simple requests get a direct answer, without consulting other assistants or opening procedures. And no recurring routine is created without my explicit request, with a preference for one-time reminders that delete themselves afterward.

Not every choice was about spending less. I kept the email summary every 30 minutes because that frequency suits my routine, even though it uses more tokens.

The day after setup, consumption fell by about 81%.

That number needs context: I am comparing a day of use with the day I configured the entire team. Setup consumed an unusual amount, so that decrease alone does not demonstrate savings that will repeat every day. I still need to track usage over a longer period.

What surprised me

What helped me most was the feeling of having my own virtual assistants, each with a role. Knowing which one to turn to made this organization more useful to me.

I was surprised by how each assistant approaches the same subject from a different angle, depending on the role I defined.

So far, I have particularly liked being able to distribute subjects without putting my entire routine into the same conversation.

What I want to explore next

Along with controlling tokens better, I want to understand how to bring this structure into a development environment, similar to the way I use Codex.

I am interested in the harness: the structure around the model that defines which tools it can use, what context it receives, what limits it must respect, and how its output is checked.

I want to make it clear who implements, who reviews, which tests must pass, and when I need to make a decision. I have already asked for an initial plan for this team, but I still need to put that process to the test.