Standup is at 9:07 a.m. The ticket is “add one sentence to the README about the Friday cutoff.” Someone pastes a .grok/config.toml from another repo because “Claude has these.” Nine MCP servers come along. A browser-review plugin waits for a headed Chrome that this laptop does not run. The TUI sits on a spinner for 11 minutes. Nobody has written AGENTS.md. The README is still missing the sentence.
This is Part 18 of the Grok series. Part 17 was the loop: explore, change, check. This part is the extra machinery around that loop. Grok Build reads house rules, skills, plugins, hooks, MCP servers, and it can spawn subagents. None of that is required to add a README sentence. If you still need the four-door map (chat vs Build vs Imagine vs API), use Grok chat, Build, Imagine, and the API.
Names inside the TUI move. Marketplace catalogs move. Re-check x.ai/build and the Build overview before you copy a teammate’s config into a customer repo.
The split between the model and the tooling
- The split between the model and the tooling layer that loads rules, tools, and servers
- What to put in a short
AGENTS.md(and what to leave out) - Skills and plugins in plain English, including where Grok looks for them
- MCP as “tools in another process,” plus why nine servers on day one is a hang waiting to happen
- When subagents and worktrees help, and when grok.com is enough
Harness vs model
The model is the text engine (Grok 4.6 as of writing for Build). The tooling layer around it is the TUI, permissions, file tools, and extra programs. People call that whole wrapper the harness. A smart model in a noisy wrapper still opens nine MCP ports before it reads your README. A plain model in a quiet wrapper can add one sentence and stop.
Official docs are blunt about discovery. Start Grok in a repo and it picks up conventions it finds: AGENTS.md (and the Agents.md / AGENT.md family), skills, plugins, hooks, MCP. It also reads some Claude and Cursor files for compatibility. That is convenient on a repo you designed. It is a surprise on a repo you cloned at 9:04 so you could fix a cutoff line.
Run this before you add anything:
cd ~/sandbox/warehouse-export-toy
grok inspectInspect is the x-ray. It lists config sources, instruction files, skills, plugins, hooks, and MCP servers, with origins. If inspect already shows a browser plugin you did not install in this folder, you inherited it. Do not start the TUI until you know why that plugin is there.

User config lives in ~/.grok/config.toml (Windows: %USERPROFILE%\.grok\config.toml). Project extras often live in .grok/config.toml inside the repo. Official settings notes say a project file is the right place for MCP and plugins you want to share, while personal model defaults stay in the user file. Confirm on the live settings page. The 9:07 a.m. failure was a project file copied like a souvenir.
AGENTS.md as house rules
An AGENTS.md at the repo root is a Markdown note the agent loads every session. Put coding conventions, how to run tests, and the things it must not do. Deeper folders can have their own file. Official docs say the deeper file wins on conflicts, and short specific rules beat long essays. There is no size cap, which is not an invitation to paste the employee handbook.
Write house rules you would say to a contractor on day one. Skip slogans. Skip a history of the company. If a line is not something you would enforce in a PR, delete it.
# AGENTS.md
## House rules
- Default to small diffs. One function or one file unless I say otherwise.
- Do not commit, push, or deploy.
- Do not read, print, or rewrite `.env` files.
- Do not add MCP servers, plugins, or marketplace items unless I ask.
- Ask before touching CI or Docker.
## How to check
- Python tests: `python -m pytest`
- If you change a date helper, run the three-row print in `exports/csv_writer.py`.
## Do not
- Rewrite logging to fix a format string.
- Install a browser plugin for a README sentence.
- Spawn subagents for a one-line edit.After you save that file, run grok inspect again. You should see the rules file in the list. If inspect does not see it, you are in a different directory than you think. That happens more than people admit, especially when two terminal tabs share a window.
For a single run without editing the file, official docs also allow grok --rules "Always use TypeScript." That is a one-off. Prefer the file for anything the next teammate needs. Session flags disappear. The README ticket will come back on Friday.
Skills and plugins
A skill is a reusable folder: a SKILL.md plus optional scripts and notes. Grok walks ./.grok/skills/ up to the repo root, plus ~/.grok/skills/, plus skills inside enabled plugins. User-invocable skills also show up as slash commands (/skill-name). Frontmatter fields like name and description tell the agent when to use it. Extra keys are ignored. You do not need a skill to add a cutoff sentence.
A plugin is a larger bundle. It can ship skills, agents, hooks, MCP servers, and language-server bits. Grok loads ./.grok/plugins/, ~/.grok/plugins/, marketplace installs, and extra paths from config. The TUI has one extensions modal. /plugins, /skills, /hooks, and /mcps open the same place on different tabs.
Hooks are scripts that fire on lifecycle events (before or after tool calls). Project hooks need trust (/hooks-trust or --trust) the first time. That trust decision is stored for the folder. Do not blindly trust a repo you unzipped from Slack so you could “try their Grok setup.”
The 11-minute hang in the hook was a browser plugin that expected a real Chrome window. A plugin that talks to a browser is useful when the job is “click through the staging site.” It is dead weight when the job is one Markdown line. Marketplace installs are sticky. They sit in your user plugin directory and can surprise the next repo you open. Inspect first. Uninstall or disable what this ticket does not need.
MCP in plain English
MCP (Model Context Protocol) is a way to hand an agent extra tools that live in another process: a browser, a database, a ticket system, a design file. Grok can read MCP from ~/.grok/config.toml, from project .grok/config.toml, and (for compatibility) from some Claude and Cursor JSON files. A project server with the same name as a user server replaces it. That is a feature. It is also how a copied file silently swaps your personal server for a teammate’s.
Nine servers means nine processes that must start, authenticate, and stay healthy before the agent writes a sentence. One of them will wait on a browser. One of them will want a token you do not have on this laptop. One of them will time out and the TUI will look frozen. You will blame Grok. The model has not even seen the README yet.
Add MCP when the job is blocked without that tool. Need live tickets? One ticket-server is a conversation. Need nothing but files on disk? Zero servers. Do not clone a list because another product’s screenshot had a long sidebar.
| Add this | When the job needs it | Skip it when |
|---|---|---|
AGENTS.md | Any shared repo the agent will visit twice | A one-off personal scratch folder you will delete |
| One skill | You repeat the same checklist every week | The checklist is three bullets you can paste |
| One MCP server | The data lives outside the repo and you have auth | The file is already on disk |
| Browser plugin | You must see a real page | The change is Markdown or a unit test |
| Subagents | Two independent reads of a large tree | One function, one file, one sentence |
Subagents and worktrees
For larger tasks, Grok Build can delegate to specialized subagents that run in parallel. The launch post showed an explore-style fan-out: several “look at this area” children, then a merge of what they found. Worktree isolation exists, so a child can work in its own git worktree instead of stepping on your dirty files. That is real, and it is easy to overuse.
Use a subagent when two questions do not share a file. “Where is the cutoff documented?” and “Where does the exporter read the cutoff?” can run in parallel on a big monorepo. Do not spawn five explores for a README. You will wait on five summaries of the same paragraph.
Worktrees help when you want the agent to try a change without wrecking the files you are editing by hand. They do not replace review. A worktree full of extra logging is still extra logging. Merge only the hunk you asked for.
If the TUI offers workflows (saved multi-agent scripts), treat them like plugins: inspect, then run on a sandbox. Do not drop a workflow file into the Friday-cutoff branch because it looked official.
When plain chat is enough
Open grok.com (or the Grok app) when the artifact is words and you do not want a process tree. Draft the cutoff sentence there. Paste it into the README yourself. That is not a failure to “use agents.” That is matching blast radius to the ticket.

Stay in Build, with a thin setup, when the agent must see several files and you want a diff. Add one skill when you repeat the same review every week. Add one MCP server when the answer lives in another system and you are allowed to connect it. Add subagents when the repo is large and the questions do not collide. Stop adding when inspect is longer than the ticket.
A chat window is also the right door when you do not have permission to run a folder agent on this machine. SuperGrok and X Premium Plus were the May 2026 launch audience for Build. Your company may still say no. Chat on an approved work account is the fallback. Do not smuggle nine MCP servers onto a laptop to dodge that conversation.
The tooling layer loads rules and tools
| Mistake | What happens | Do this instead |
|---|---|---|
| Copy another repo’s MCP list | 11-minute hang on a browser plugin | Empty inspect, then add one server you can name |
No AGENTS.md, lots of tools | Agent improvises house rules | Write the short file first |
| Skill for a one-line job | Extra prompt noise, same sentence | Type the sentence or use grok.com |
| Trust a project hook on first open | Scripts run in a folder you have not read | Read the hook, then /hooks-trust if you still want it |
| Subagents on a README | Five summaries, no edit | One session, one file |
The tooling layer loads rules and tools (workflows)
In the sandbox from Part 16, add the AGENTS.md skeleton above. Run grok inspect and confirm the file appears. Do not add MCP. Ask Build to add the Friday cutoff sentence under the house rules. If it also opens a plugin modal, you copied config again. Reset and stay thin.
Next in this series is Grok Build for sheets and research (carefully). Spreadsheets and web claims are where a loaded tool list plus a confident model invents a margin formula. Keep the thin setup. Index: Grok series.
The tooling layer loads rules and tools 3
- The tooling layer loads rules and tools. Inspect it before you type a prompt
- Start with a short
AGENTS.md. Add skills and MCP only when the job is blocked without them - Nine servers is not a setup. It is a hang
- Subagents and worktrees are for large, independent reads. Not for one sentence
- grok.com is enough when the artifact is words and you will paste them yourself
Sources
Research and further reading used for this article:
- xAI docs: Grok Build overview (
grok inspect, config path, custom models) - xAI: Introducing Grok Build (AGENTS.md, plugins, skills, MCP, parallel subagents, worktrees)
- xAI: Grok Build (product home)
- grok.com (chat surface when a folder agent is the wrong door)
- xAI: Grok FAQ (plan and product questions to re-check)
- Analytics Made Simple: Learn (related paths on this site)
Keep going
Same lessons in your feed
Short diagrams and hooks on Instagram, X, and Facebook.
