Teach Grok Bot one exception before adding another persona

TL;DR: The useful moment in this Grok Bot workshop is a small scheduling preference. Presenter Amrita Venkatraman turns a detail about when she wants to do laundry into a reusable skill. I would test whether a changed preference survives the next run before celebrating the number of personas in the team.

Grok Bot combines named agents, computer access and persistent working context. Its documentation distinguishes a skill, which describes how to do something, from a routine, which tells a Bot when to run a workflow. That makes this useful viewing for people trying to turn an occasional successful task into a repeatable process.

The reusable part is the instruction

In the scheduling example, several ordinary tasks pass through a chief-of-staff agent, a calendar scheduler and a to-do organiser. The presenter adds a preference for doing laundry late at night, inspects the inter-agent messages and checks the resulting calendar. Later, she demonstrates a flight-search workflow on the computer so the system can create a skill from it.

The interesting question for adoption is what remains after the demonstration. A name, a role description and a convincing conversation can make the workflow easy to understand. They do not establish that the next run will apply the right exception without another explanation.

Timestamps

• 7:30–10:40: task scheduling, a saved preference and checking the calendar result.
• 11:20–12:20: the contents of a skill and examples of sharing reusable instructions.
• 12:20–13:40: teaching flight-search preferences through a computer demonstration.

My proposed second run would deliberately change one constraint. Move the preferred time, remove an input or supply a case that conflicts with the earlier example. Then inspect what the Bot does, which instruction it applies and whether the result needs repair. That is a more demanding test than repeating the same happy path.

Give another persona a job to earn

As an illustration, a weekly report workflow might learn that only a material change deserves a paragraph. On the next run, provide a week with no material change. If it still produces a full report because that was the demonstrated shape, adding a research persona has not solved the instruction problem.

I would add another specialist when a specific handoff improves the result and I can identify what each side contributes. Until then, the extra conversation is another place for an old assumption to survive. A single well-understood routine is easier to revise than an impressive cast whose work nobody can separate.

The official teaching guide also calls the generated skill a draft: decision rules and failure handling may be missing from a single example. Saved instructions are not evidence that the underlying model has been retrained. And the workshop's casual computer language should not override current documentation about the member's shared computer.

I reviewed the relevant native-caption passages and six representative frames. I have not independently tested the product's reliability, reviewed every frame or measured savings from this setup. The demonstration makes the mechanism inspectable; the changed-constraint test is the experiment I would add.

Earn the next agent by making the current routine survive a different day.