new·Update the plugin: three new commandsThe mozg plugin is at 0.4.0. New: /mozg:update re-reads a brain against its sources (only pages that actually changed cost anything), /mozg:sync writes your shelf into .mozg/brains.md so every session starts knowing your brains offline, and /mozg:add shelves a catalogue brain without opening a browser. Training got a five-phase protocol that skips what the brain has already read.all news →
mozg.betaSign in

How people use it

Somebody knows
something.
Now the agent does.

A brain is a small, measured body of knowledge that agents can search and people can sell, share or keep private. That sentence means nothing until you see it used, so here are the people using it — an artist, a company, a game studio, a maintainer, an agency, a first-time founder, an engineer with three agents open. Every one starts from something they already have.

The people below are composites, and the portraits are drawn — not customers, and not photographs pretending to be. The situations and the mechanics are real.

01 · An artist, a teacher, anyone with a method

He sold the method, not the paintings

Illustrated portrait of Íris, illustrator and art director, twenty years of it

Íris

illustrator and art director, twenty years of it

the problem · “I can teach my method to one apprentice at a time, and I have run out of time. Every generator gives me the average of everyone, which is exactly what my clients pay me not to be.”

after · “The method is a brain now. It scored 84%, which told me which of my own rules I had never actually written down. People buy it, their agents work the way I work, and I keep 95%.”

the workthe methodbrain · 84%sold, kept, updatedtheir agents
One method, taught once, working in many hands at the same time

Picasso could paint a Picasso in an afternoon. What took a lifetime was the method behind it — how a figure gets broken into planes, when a colour is allowed to lie, which rules to violate and in what order. He sold canvases. The method he could only give away in a studio, one apprentice at a time.

The modern version of that person has the same asset and the same problem. They have a way of working — how they light a scene, how they name things in code, how they structure a lesson, what makes their game feel like theirs — and it lives in their head and in a folder of examples. Models trained on the whole internet produce the average of everyone. The average is exactly what they are paid not to make.

So they turn the method into a brain: not the artefacts, the decisions behind them. Each rule becomes a note with its reason attached; each example becomes a note whose body is the working thing, kept whole. Then they price it. Anyone who buys it points their own agent at it and gets work made the way they make it — and the exam score on the page is the proof that the brain actually holds the method rather than a description of it.

Ninety-five per cent of every sale goes to the author. The brain keeps being theirs, keeps being updated by them, and stops being a thing that can only be taught in a room.

"Draw the key art for my level. I do not know how to describe what I want, just make it look like the rest of the game."

Without a brain

A competent illustration that could belong to any game: even lighting, a smooth gradient sky, every figure whole and symmetrical. It looks like the average of every image ever made, because that is what it is.

With the brain

It searches the method first and comes back with the rules by name: one broken plane per figure, warm rim light on the subject only, background cooled two steps, no gradients — the studio bans them. Then it draws to those rules and says which ones it applied, so the artist can argue with a decision instead of with a picture.

How it is actually done

  1. brain_create with a goal written as the question a buyer will ask: not "my style" but "answer how to compose, light and colour a scene the way this studio does".
  2. Feed it what already exists: /mozg:train reads your notes, briefs and finished work from a local folder on your own CLI subscription — the material never leaves your machine, only the distilled notes do.
  3. Sit the exam. The score and the list of failed questions tell you which parts of your method you have never actually written down; that list is your next hour of work.
  4. Price it on the brain's page, publish, and the catalogue does the rest. Buyers connect it over MCP; you keep 95% and keep editing it.

Where it stops: A brain teaches decisions, not hands. It will make another person's agent choose the way you choose — it will not reproduce a signature, and it cannot stop a buyer from learning from what they bought. That is what teaching has always been.

share this one: mozg.sh/stories#the-artist

02 · A company with software nobody outside has ever seen

They taught the AI their own program, and it never left the building

Illustrated portrait of Marek, platform lead at a 200-person insurer

Marek

platform lead at a 200-person insurer

the problem · “Our billing service was never on the internet, so every answer the AI gives about it is invented — confidently. Three people know how it really works and they spend their day being a helpdesk.”

after · “The manual, the runbooks and the ticket decisions are one private brain, taught from our own machines. Forty people ask it instead of asking them. Nothing raw left the building.”

your machines, your keythe manualprivatebrainforty people, answeredoutside
A loop that closes inside the building: notes in, answers out, nothing else

An internal system has one manual, three people who really understand it, and forty who ask them questions. The AI everybody now has on their desk is useless here by definition: the program was never on the internet, so no model has ever seen it. Every answer it gives about the system is invented, confidently.

The manual is not the problem — they have one. The problem is that it is a hundred pages nobody reads, and its answers cannot be found in the two minutes an engineer actually has. Pasting it into a chat costs the whole context window and still loses the one paragraph that mattered.

So it becomes a private brain. The docs, the runbooks, the decisions made in tickets, the conventions that exist only in code review — all of it distilled into notes and searchable by every agent the company connects. Private means private: the brain is not in the catalogue, cannot be found, and is readable only by the addresses invited to it.

Two paths for keeping the material inside. Teach it locally, where an agent on the company's own subscription reads the documents on a company machine and only finished notes cross the wire; or set the company's own API key so the extraction runs against their provider and their contract rather than ours. Either way the brain answers the forty people, and the three stop being a helpdesk.

"Billing failed with error 42 for this customer. What do I do?"

Without a brain

A confident paragraph about HTTP status codes and generic retry advice. Error 42 exists only inside this company, so every word of it is invention — and it reads exactly like knowledge.

With the brain

"42 is the retry queue being full — it is not the customer's card. The runbook says: check the queue depth first, drain it with the maintenance job, and only then re-run the invoice. It also warns that re-running before draining double-charges, which happened in March." A new engineer just answered like the third person who knows the system.

How it is actually done

  1. Create the brain private (the default) and write the goal as the question the team keeps asking: "answer how our billing service behaves — the endpoints, the retry rules, the fields nobody documents".
  2. Teach it without uploading raw material: /mozg:train in the repository, on your own agent subscription. Only the notes are sent, and every note is scanned for secrets and PII on the way in and again at publication.
  3. Or, if you would rather paste URLs and let it read: settings → your own API key, and the extraction runs on your provider under your agreement.
  4. Invite the team by email address; each person connects their own agent with their own token, so removing somebody removes only their access.
  5. Self-hosting is the strict version: the whole thing runs in your own Docker, with your database and no outside dependency at all.

Where it stops: Nothing here makes a compliance decision for you. The extraction step calls a model unless you teach locally, so if your rule is "no third party ever sees this text", teach locally or self-host — and read docs/SELFHOST.md before promising anybody it is airtight.

share this one: mozg.sh/stories#the-closed-company

03 · A studio shipping on somebody else's platform

The platform changed its API. The brain noticed; the model did not

Illustrated portrait of Dima, slot developer, two-person studio

Dima

slot developer, two-person studio

the problem · “The platform's docs move weekly and the model answers from last year. I found out during submission, which is the most expensive place to find out.”

after · “Platform brain from the catalogue, studio brain of our own. The agent asks before it guesses — and it proposed anticipation on the third reel before I knew the word.”

the platform, weeklyplatform brainre-read on changeyour team, as you workstudio brainwritten by handagentasks first
Two brains, different jobs: the platform moves, the studio accumulates

Shipping a slot game on a platform like Stake Engine means living inside somebody else's contract: a wallet API with exact endpoint shapes, a maths package that must validate before it uploads, an approval checklist that fails a build for a missing disclaimer. All of it documented, all of it moving.

An agent asked about that platform answers from training data. Training data has a date, and platform docs changed after it — so the endpoint it confidently writes is last year's, the maths file it generates fails validation for a field that got renamed, and the studio finds out during submission.

Two brains fix it, and they are different in kind. One holds the platform: built from the documentation repository, re-read when pages change, split so a question about the wallet lands in the wallet brain rather than competing with the frontend guide. The other holds the studio: the conventions, the pitfalls hit twice, the reason a mechanic was cut — the knowledge that exists nowhere but in the team.

The agent asks before it guesses, and the brain says what it does not know. That second part is the one that saves a submission: a gap list is an honest "check the docs yourself here", where a model's silence is not.

"When two scatters land, the spin should feel more exciting. I do not know how these games do that — make it good."

Without a brain

A screen shake and a louder sound on the win, added after the reels have already stopped. It has no idea that the excitement in a slot happens *before* the outcome, so the moment it was asked about is the one moment it leaves empty.

With the brain

It searches the platform and studio brains and comes back with the name of the thing: anticipation. "With two scatters visible, the remaining reel slows and its anticipation animation plays until it stops — that is where the tension lives. Your studio brain says anticipation only fires from the third reel on and never on a guaranteed loss, and the platform's event contract wants it emitted as its own event so the frontend can play it during the spin." Then it builds that. The person who asked had never heard the word, and got what a veteran would have specified.

How it is actually done

  1. Take the platform brain from the catalogue — the official docs are already there, free, with a score and a gap list. library_add puts it on your shelf from the CLI.
  2. Create your own studio brain beside it, and let the agent write to it as you work: brain_write saves the convention you just settled, brain_feedback flags a note that turned out to be wrong.
  3. Run /mozg:sync so the project carries a map of both, and every session starts knowing they exist without spending a call to find out.
  4. When the platform ships a change, /mozg:update re-reads its pages; only the pages that actually changed cost anything, and the notes from an old page are superseded rather than deleted so you can see what it used to say.

Where it stops: A brain scoring 70% is right about seven questions in ten and honest about the rest — it is not a substitute for reading the approval checklist before you submit. Use the gap list as the list of things to verify by hand.

share this one: mozg.sh/stories#shipping-a-game

04 · Whoever maintains a library or a set of docs

Every question her docs could not answer arrived as a list

Illustrated portrait of Ada, maintainer of a mid-sized open-source library

Ada

maintainer of a mid-sized open-source library

the problem · “I cannot see which page confused a reader, and most of my readers are agents now. They invent an answer, then open an issue that costs me an hour.”

after · “The brain sits an exam on my docs and classifies every failure. Searches that found nothing become questions. My roadmap arrives as a list instead of as issues.”

the docsas writtenbrain + examscore · gapsreal agents, askinga search that found nothing becomes an exam question
The loop that writes the roadmap: a failed search becomes an exam question

A maintainer's documentation is judged by a reader she never meets, and now most of those readers are agents. She has no idea which page confused them, which answer they invented instead, or which question her docs simply do not contain.

Publishing her docs as a brain changes what she can see. The brain sits its own exam — questions generated from the goal, graded against what retrieval actually returns — so the score is a measurement of her documentation, not of her writing. Failures come back classified: material that is absent, a page too thin to answer, an answer that exists but ranks below something adjacent. Three different fixes, named.

Then the readers add to it. When an agent searches the brain and gets nothing useful, that query becomes an exam question — so the next sitting measures what people actually asked and could not get. A corrections trickle in from agents that found a note contradicting reality, and she reviews them like pull requests.

The public score and gap list do something else, too: they tell a developer deciding whether to trust the brain exactly how far to trust it. Nobody has to take her word for it.

"Configure the cache the way this library wants it. I am following a blog post from last year."

Without a brain

The option name from that blog post, which was renamed two releases ago. The code runs, the cache silently does nothing, and the developer blames the library — then opens an issue that costs the maintainer an hour.

With the brain

The current option, its type and its default, quoted from today's docs, plus the sentence that saves the issue: "the old name still parses and is ignored, which is why your cache looked configured". And when the docs genuinely do not cover something, the brain says so instead of guessing — the maintainer sees that question appear in her gap list.

How it is actually done

  1. Point brain_add_source at the docs repository or the site root, and let the crawler read the source markdown rather than the rendered shell — API tables arrive as data instead of as pictures of tables.
  2. Write the goal as the promise you want measured. The exam is generated from it, so "answer configuration questions with the exact option name, type and default" produces a harder and more useful exam than "be about my library".
  3. Publish it. Free is fine and normal — the catalogue is free — and the score plus the gap list are on the page for anyone to read.
  4. Work the gap list like an issue tracker: absent material wants a source, a thin note wants deepening, a ranking problem wants the question's own words in the note.

Where it stops: The exam measures whether an answer can be retrieved, not whether your library is well designed. A brain at 95% on bad docs means the bad docs are consistently findable.

share this one: mozg.sh/stories#the-maintainer

05 · An agency, a consultancy, anyone with many clients

Twelve projects, twelve brains, no more onboarding by shoulder-tap

Illustrated portrait of Noor, technical lead at a twelve-client agency

Noor

technical lead at a twelve-client agency

the problem · “Our real product is context, and it lives in people's heads. Every new developer learns it by tapping a shoulder, and every agent session starts as a stranger.”

after · “One brain per project, filled as the work happens. A dormant project comes back with its reasoning intact, and a finished one leaves as a file the client keeps.”

twelve clientsa brain eachfilled as work happensCLAUDE.mdhandover
One brain per project, and each one leaves as a file when the work ends

An agency's real product is context. Twelve clients, twelve stacks, twelve sets of rules about naming, deployment, and which library is banned because of an incident three years ago. A new developer learns it by asking someone; an agent never learns it at all, which is why its first pull request always looks like a stranger wrote it.

One brain per project fixes both. It is filled as work happens rather than in a documentation sprint: when a convention gets settled in review, the agent writes the note; when a pitfall costs an afternoon, the agent writes the note. Nobody sets aside a Friday for it.

The value shows up at the seams. A developer joining reads the brain instead of a person's memory. An agent starting a session searches it instead of guessing. A project going dormant for six months comes back with its reasoning intact — and when it ends for good, the whole brain exports as a CLAUDE.md or an AGENTS.md the client keeps, with no account and no subscription.

"Add a delete endpoint to this client's API."

Without a brain

A textbook handler: 204 on success, a bare error string, a library the client banned after an incident, and no audit row. Every line is defensible in general and wrong here — and it takes a reviewer twenty minutes to explain why, again.

With the brain

The client's own shape: soft delete because nothing is ever really deleted in this system, the house error envelope with its code list, an audit row written in the same transaction, and the banned library avoided with the reason attached. The pull request looks like the team wrote it, because the team's reasoning is what it read.

How it is actually done

  1. One brain per project, named after it, with a goal describing the project's own rules rather than its technology.
  2. Let the work fill it: brain_write from the agent whenever a convention is settled, /mozg:teach when the knowledge is in somebody's head and needs interviewing out of it.
  3. Share by email to the people on that project; each connects their own agent with their own token, and access ends when the person does.
  4. On handover, export the brain as CLAUDE.md, AGENTS.md or a Claude Skill. The client keeps a file that works with no account — and if they ever want it live again, the brain is still here.

Where it stops: Twelve brains is twelve things to keep current. A brain nobody has taught in three months has an old score and says so, which is better than a stale context file — but it is still stale, and the honest move is to retire it rather than let an agent trust it.

share this one: mozg.sh/stories#the-agency

06 · Somebody building software without being a developer

She could not tell when the AI was lying to her

Illustrated portrait of Kat, founder, first product, no engineering background

Kat

founder, first product, no engineering background

the problem · “The agent writes code faster than I can read it. When it is wrong I find out days later, and I have no way to tell the difference — it sounds equally sure both times.”

after · “Now it searches a brain for the framework I am on and quotes the current option, with a score on it. When the brain does not know, it says so — and that sentence is worth more to me than the code.”

"just do itproperly"from memoryundated, uncheckedfrom the braindated · 84% · citedshe can checkwithout reading code
The beginner's missing instrument: an answer with a date and a score on it

The most common person building software today cannot read the output. They describe what they want, the agent writes it, and the thing either works or it does not. When it does not, the reason is somewhere in a file they cannot audit.

The failure that hurts is not a crash — a crash is honest. It is the code that runs against an option renamed two versions ago, or a pattern the framework abandoned, written with total confidence because the model learned it before the change. A developer would notice. This person cannot.

A brain gives them the one thing they were missing: a source that is dated and scored. The agent quotes the current option and says where it came from; when the brain has no answer, it says that instead of inventing one. The beginner does not become an expert — they become somebody who can tell a fact from a guess, which is most of what expertise buys you here.

“Add login to my app. I do not know what any of the options mean — just do it properly.”

Without a brain

A tutorial from a year ago: an auth pattern the framework has since replaced, a session cookie without the flags that stop it being stolen, and no way for her to know any of that. It runs, which is the problem.

With the brain

The current pattern, quoted from this month's documentation, with the two settings that matter named and explained in a sentence each — and one honest line: “the brain does not cover social login for this framework, so verify that part.” She knows exactly which part to have somebody check.

How it is actually done

  1. Start from /basics if the words are new — it explains agents, MCP and brains without assuming any of them.
  2. Take the brain for whatever you are building with from the catalogue. Free, and the score tells you how much to trust it before you rely on it.
  3. Connect your agent once, then keep asking in your own words. You do not need the vocabulary; the brain has it.
  4. When something goes wrong, ask the agent to search the brain and quote the source. “Where did you get that” is a question it can now answer.

Where it stops: A brain does not make code correct — it makes the knowledge behind it current and checkable. Somebody still has to read the important parts, and a brain that says “I do not cover this” is telling you where to find that somebody.

share this one: mozg.sh/stories#the-solo-builder

07 · Anyone who uses more than one agent, or changes agent

She taught it once, and switched tools without losing it

Illustrated portrait of Mira, senior engineer, three agents open on any given day

Mira

senior engineer, three agents open on any given day

the problem · “I taught Claude our conventions, then the team moved to a different tool and it knew nothing. Built-in memory belongs to whoever built the agent, not to me.”

after · “The conventions live in a brain now. Every agent I connect reads the same one, and when I switch tools I lose nothing but the keyboard shortcuts.”

Claude CodeCodexCursorone brainsame note, one dateexport, any timeworks with no account
One brain, every agent — and a file to leave with

Every agent has memory now, and every one of those memories belongs to the company that made it. Teach one tool your conventions and the next knows nothing. Change tools — which everybody has done at least once in the past year — and you teach it all again.

There is a quieter version of the same problem: two agents at the same time. One writes code, one reviews it, and they disagree about a convention because only one of them was ever told. The disagreement looks like a technical dispute and is really a filing problem.

A brain sits outside all of them. It is reached over MCP, which every serious agent now speaks, so the same knowledge answers Claude Code, Codex, Cursor and whatever ships next quarter. And if you leave the product entirely, the brain exports as a file that keeps working with no account at all — which is the only honest form a promise like this can take.

“Why did the review agent flag this? The one that wrote it said it was fine.”

Without a brain

Two agents with two private memories, each confident. Somebody spends twenty minutes arbitrating a disagreement that exists only because the convention was written down in one place and not the other.

With the brain

Both read the same note, and it has a date and a reason attached: “we stopped doing it that way in March, because of the incident in the note below.” The dispute ends in the time it takes to read one paragraph, and the answer does not depend on which tool asked.

How it is actually done

  1. Put the conventions in a brain rather than in one agent's memory — the agent can write them there itself with brain_write as they get settled.
  2. Connect every agent you use to the same brain. One command each; they all speak MCP.
  3. /mozg:sync writes the shelf into the project, so a new tool on a new machine starts knowing what exists.
  4. Export whenever you like — CLAUDE.md, AGENTS.md or a Skill. Leaving is meant to be cheap; that is what makes staying a choice.

Where it stops: MCP is the reason this works, so an agent that does not speak it is out of reach — for those, the export is the answer, and an export is a snapshot with all the staleness that implies.

share this one: mozg.sh/stories#every-agent

The part they all share

None of them wrote a context file. Each one took knowledge that already existed — a method, a manual, a platform's docs, a client's conventions — and made it something an agent can search and a person can measure. The measurement is the part that matters: every brain here can tell you its score and list the questions it still fails, which is the one thing a pasted document will never do.

Start hereTake one from the catalogueWhat it costs