I want my AI colleagues to become easier to work with the longer we work together. If I explain a preference, correct a mistake, or discover a better way of doing something, that experience should help with the next task.

I also want to see what they learned. An assistant quietly developing assumptions about me is a rather different proposition from one that can show me a lesson, its source, and where it applies.

We have now added that structure to my team of Grok bots. The system runs on their shared Linux computer, and I have made the reusable implementation available on GitHub.

What learning means here

Grok bots already have memory. They can retain preferences, facts, and summaries, as the Grok documentation explains. Our addition gives selected lessons an explicit path from an interaction to later use, with evidence, review, and a record of changes.

The model itself stays the same. We are storing useful experience outside the model and retrieving it when a bot starts relevant work. That makes the experience inspectable and lets us correct it independently of the underlying AI.

Here is a hypothetical example. I tell a bot: “For future project briefs, put the next action first.” The bot records that correction with a reference to the conversation. It can then create a lesson: “Lead project briefs with the next action.” When it prepares a later brief, it retrieves the lesson alongside the task.

The word “future” matters. A request for a short answer today does not necessarily mean I want short answers forever.

A lesson needs evidence and an address

The system keeps the observation separate from the interpretation. A correction or a checked result becomes an evidence record. A proposed lesson points back to that evidence and states why it should affect future work.

We also decide where the lesson belongs. A preference can stay with one bot, apply to bots working in the same area, or become a general work preference for bots that explicitly accept shared guidance. Personal contexts can remain local, and a creative bot can keep its own voice.

This prevents a useful instruction for one job from casually becoming a rule for every job. My preference for a concise business update should not flatten every piece of creative writing.

An explicit, durable preference for one bot can become active immediately. Shared lessons and workflow changes go into a review queue. Guesses stay proposals until there is evidence to support them. Existing roles and approval rules continue to govern what each bot may do; a remembered lesson grants no additional permission.

One bot reviews. I get the report.

One bot acts as curator. In my setup, it reviews the queue at 08:15 and 18:15 Vienna time, checks the attached evidence, and decides which candidates are ready to use. Ambiguous lessons can remain pending.

After every review run, it gives me a short summary: what became active, which bots or areas it affects, what remains pending, and anything that failed. When nothing changed, it explicitly says, “No new learning this run.”

That was a requirement I added during setup. I want to monitor the system without reading its database. The report describes what happened in that review; it does not claim to list every local preference a bot may have adopted between reviews.

Other bots pick up applicable lessons during their next normal task. We do not need to wake the whole team every time one bot learns something.

The infrastructure is deliberately small

Grok provides a persistent computer shared by the bots. We use that existing machine for a small Python program and a SQLite database. The learning store needs no separate model subscription, vector database, or continuously running server. Normal Grok usage still applies.

Each bot gets a short addition to its existing description: consult the learning system when starting substantive work, follow the shared protocol, and continue the original task if memory is unavailable. Its original role stays intact.

The database stores evidence, lesson versions, review decisions, and retrieval records. We can inspect which lessons were returned for a task and follow their sources. That tells us what context the bot received; assessing how well it used that context still requires looking at the result.

In an earlier article, I wrote about making an AI second brain auditable. This applies the same idea to the lessons agents carry into their work: keep the history and make changes reversible.

Build your own

The Grok Bot Learning repository contains the code, a synthetic demo, configuration examples, and a setup prompt for native integration. It uses an MIT license and contains none of my bots’ private profiles or conversations.

You choose the bots, their scopes, and the curator. Run the demo, configure your own system, then follow the deployment guide to preserve the original profiles, test restoration, and enable learning. Native tooling can differ between accounts and versions, so that verification is part of installation.

I want a system whose experience becomes useful and whose assumptions stay visible. Being able to ask what changed, inspect the evidence, and undo a bad lesson is what makes me comfortable letting it learn.