21 Equipping the agent
A wrench is not a mechanic. A new colleague’s first day ends with a laptop, a badge and a login to everything the team lives in. Then comes the part that’s on no checklist: some time in the afternoon somebody pulls a chair over to show them how the deploy script is actually run, which flag everybody passes, which one you never pass on a Friday. The tool arrives with a person who knows what it’s for, or it arrives as a surprise.
The chapters before this one gave the agent the floor plan (Chapter 6), the teaching, a place in the team’s review and a name on the door. What it still lacks is the toolbox. Crystalline’s answer is that the domains holding the knowledge also ship the tools that knowledge depends on, into the harness, with a person’s consent, and keep them current afterwards. This chapter is that mechanism, and it’s the last practical one before the book turns to what all of it was for.
21.1 What a domain can ship
The list is short. Skills are the playbooks a harness loads before a kind of task. Slash commands are the short prompts a person invokes by name. A subagent definition is a role with its own instructions that the harness can hand a piece of work to. MCP server configs let a domain about the payments service bring along the server that reaches the payments staging environment. Each kind is a folder in or beside the domain.
An artifact is written once, in whichever dialect its author’s harness speaks, and translated into every harness whose format can carry it. Claude Code and Codex take all four kinds: an agent written as markdown becomes Codex’s TOML dialect, or the other way round, and an MCP server registers through the harness’s own CLI. The Copilot CLI takes every kind but commands, since it has no prompt-file surface for one to land on, so a command is skipped there with a notice rather than silently. Cursor, Kiro, Gemini CLI and Qwen Code take skills only, and the other kinds are skipped there with the same notice. Where the target cannot express a field, a vendor model name or a permission mode, the field is dropped and the notice says which.
The manifest declares what a domain ships in a ## Provisioning section, one bullet per kind:
## Provisioning
- skills: skills
- commands: commands
- agents: agents
- mcps: mcpsEach bullet is type: path. The path is relative to the manifest itself and may climb out of the domain root with ../, for a folder that lives beside the domain rather than inside it. The mcps folder holds one JSON file per server, named by its own name member or, failing that, by the file. The starter manifest that crystalline domain init scaffolds leaves the section out on purpose: it’s added by hand, once a domain has something to ship. A manifest gains it the week somebody writes the first skill.
21.2 Why the tools travel with the knowledge
A harness has a skills folder of its own, and a team could commit into it directly, so it’s fair to ask what a domain adds, and the answer is the wrench. The knowledge that says when a tool applies, and how it’s run here, is an engram: the runbook that says the deploy skill is for the payments service and never for the ledger, the gotcha about the flag, the convention about Fridays. The tool is the skill. Keep them in the same domain and a new member’s harness receives both in one motion. The engram that says “use this” can’t drift from the thing to use, because the two live together and travel together.
The rule that follows: never provision a tool without the engram that says when it applies. A skill teaches a harness how. Only the domain’s knowledge says whether this is the moment, and whether it’s the moment here. A well-equipped domain reads like a workshop where every drawer is labelled, and the label is an engram somebody can correct. The sonic screwdriver famously doesn’t do wood. A tool arrives with its limits written down or it arrives as a surprise.
Crystalline’s own skills are the worked example. The routing, capture, schema, collaboration, provisioning and presentation skills from chapter 15, and the consolidated one for Claude Desktop, are exactly this: playbooks that say how to use the tools well, shipped by the thing whose knowledge they depend on. crystalline install places them into the harness’s skills folder. The install receipt keeps them current across upgrades, with an edited copy kept beside the new one as SKILL.md.bak. A remote harness that never ran the CLI reads the same seven through the skills tool, an index with no arguments and one full SKILL.md by name, or as skill://<name>/SKILL.md resources. Provisioning is that mechanism, opened to your domains.
21.3 Consent
Nothing installs until a person decides. A domain that declares a Provisioning section with something in it and has no decision yet surfaces at the start of the next session, as one line trailing the routing block the hook delivers:
[crystalline] The `engineering` domain ships artifacts to provision
(mcps: 1, skills: 1) but has no decision yet - ask the user, then apply
it with the `provision` tool or `crystalline provision allow engineering`.The agent raises it with whoever is at the keyboard and applies the answer with the provision tool.
The decision is per domain and per machine. It is recorded in the domain’s registration in config.yaml, as provision: true or false, never in the manifest, for the same reason chapter 17 kept review mode out of it: what a domain ships is knowledge the team shares; whether this machine takes it is a choice its owner makes. Denying removes whatever the domain already shipped. status prints every domain’s decision and counts, grouped allowed, undecided and denied and sorted by name, then every onboarded harness’s installed state and the domains still waiting (Figure 21.1). The domains that ship nothing and the virtual ones fold into one line each unless you ask for the full list. The provision tool answers the same report to an agent, and until some domain declares a section it has nothing to allow or deny and says so. Allow, deny and apply need the instance admin role on a shared instance whose agents sign in, because each changes what the daemon’s own machine installs. The report stays a read: any account gets it, listing only the domains that account may see.
From the terminal the two decisions and the report are three commands:
crystalline provision allow engineering # opt in, then reconcile
crystalline provision deny engineering # opt out, removing anything already shipped
crystalline provision status # decisions by group, every harness's installed state (--all lists every domain)21.4 Reconcile
Bare crystalline provision reconciles every opted-in domain into every harness this machine onboarded with crystalline install. Run it as often as you like. It converges. It installs what’s missing, updates what a domain changed and retires what a domain no longer ships. Anything it didn’t write itself it treats as somebody else’s. A provisioned file you edited by hand is still brought current, with your edited version kept beside it as a .bak copy rather than lost. Retiring an edited file renames it to .bak the same way. A file Crystalline never wrote is adopted when it already matches byte for byte and otherwise left alone, never overwritten. An MCP server name already registered by somebody else is left where it is, with a notice.
Most of the time nobody runs it. The session-start hook checks whether anything drifted since the last reconcile, a stat of the domain’s folders against the receipt with no hashing. When something did, it reconciles the file artifacts on the spot and reports one line: how many were refreshed. MCP changes are the exception: registering a server means spawning the harness’s own CLI, which a hook shouldn’t do, so those wait for an explicit run and a second line says so. Change a skill in the domain, and the next session has it.
crystalline doctor is the report-only view. When a domain ships artifacts it lists each declaring domain’s decision and shipped counts, then each onboarded harness’s counts of drifted, edited, orphaned and missing files against what was last reconciled. --fix never reconciles a harness. An undecided domain is a normal state awaiting a person, never a fault, and an edited file is left alone by design.
21.5 The team’s toolbox
A team domain ships to everyone. The folders the manifest declares travel with the domain when it’s pulled. Even a folder that lives beside the domain in the repository is mirrored down with it. Each member’s harness sees the same skill that merged, and a change that lands in the repository reaches every harness at its next session start. Each member decides once, on their own machine. The decision is theirs, the contents are the team’s. Day one now includes the tools and the floor plan.
Adding to what a domain ships, or changing it, is a code change, and you make it the way you make any other. Clone or pull the repository the domain lives in. Edit the ## Provisioning section of the manifest, put the skill, the agent definition or the MCP config into the folder it declares and commit. Open the pull request, have it reviewed as code and merge. From the merge on, every instance that follows that domain brings the change down with its next pull, and each member’s next session start reconciles it into their harness; an MCP change waits for an explicit crystalline provision, as above. You don’t need the folder layout by heart for any of it: the provisioning skill lets the agent walk you through the setup, proposing each step and waiting for your yes before it runs anything. The collaboration tools of chapter 17 exist for knowledge. An agent’s share_changes would carry a skill that sits inside the domain root, since a share takes every file in it. A folder declared beside the domain with ../ is outside what a share can see at all. And a reviewer opening a proposal expects engrams, not a deploy procedure with a server address in it. Keep the tools on the code path and the knowledge on the sharing path, and each review stays the kind of review it should be.
The club domain gains two folders. Under skills/ sits review-writing, the way the club writes a review, which Dallas had been explaining by chat: which questions to answer, what stays spoiler-free, why a star rating without a sentence is worthless. Under mcps/ sits the one file that tells a harness how to reach the library’s catalogue. Beside them, in the domain itself, is a checklist engram saying when the skill applies and linking to last year’s reading list, next to the club’s rule about never picking a book nobody has finished, which the domain already held. Dallas makes the change on a checkout, the way anything in the club’s repository changes, you review the pull request and it merges.
Your next session opens with the routing block and one extra line: club ships artifacts to provision, two of them, and has no decision yet. Your agent asks, you say yes and the agent calls provision with allow. The skill lands in your harness’s skills folder, and the catalogue’s server is registered through your harness’s own command line. A week later you add a note to the installed SKILL.md about the library card that differs on your machine, and doctor counts one edited file and leaves it alone. Later Dallas changes the skill in the repository. The pull brings it down, the next session start reconciles and your agent reports one artifact refreshed. Your version sits beside the new one as SKILL.md.bak. You move the note where it belonged in the first place, into an engram about your own setup, and the skill stays the club’s.
A pair of receipts does the remembering. The install receipt says which harnesses crystalline install onboarded on this machine, and provisioning targets only those. The provisioning receipt is the ownership record: every file and MCP server a reconcile installed, with a hash of what it wrote. A recorded file is Crystalline’s to update or remove; an unrecorded one is somebody else’s. An installed file whose bytes no longer match the recorded hash is a hand edit; a domain whose current bytes differ from that hash is drift. That one receipt is where status and doctor read their edited and drifted counts. Domains are projected in the order config.yaml registers them, and when two ship a file to the same path the first wins, with a notice naming both. A virtual domain never ships anything; it has no folder to ship from.
The stranger on main street had a laptop of their own and no idea what your deploy script was called. A colleague is somebody you handed the tools, on purpose, and showed which drawer they live in. The agent is handed them the same way: one domain at a time, with a yes each time and never a wrench without the label.
A domain ships the tools its knowledge depends on: skills, slash commands, subagent definitions and MCP server configs, declared in a ## Provisioning section of its manifest and translated into every harness whose format can carry them. Nothing installs until a person decides. An undecided domain surfaces at session start, crystalline provision allow and deny record the decision per domain and per machine, and status reports every decision and every harness’s state. A bare crystalline provision reconciles idempotently, keeping hand edits as .bak and never overwriting a file it didn’t write. The session-start hook reconciles file artifacts on its own, and doctor reports drift without touching anything. Pair every tool with the engram that says when it applies. A team domain ships the toolbox to every member’s harness with the knowledge that explains it, and a change to that toolbox is made as a code change, committed and reviewed in the domain’s repository, from where every connected instance pulls it.