How to Build a Company Brain With Exactly One Skill

Every company that puts agents to work hits the same wall in the end: the headcount scales, but the cognitiondoesn’t. Each agent is brilliant and brand-new every session, with no institution to think through — so the organization never compounds what its agents learn. There’s a predictable moment in every agent program. The first agent works, so you give it a capability — a skill to triage tickets. Then another, for refunds. Then a connector to the CRM, a RAG pipeline over the wiki, a prompt block for compliance, a runbook for deploys. Each capability is its own skill, its own integration, its own auth flow, its own way to break. The agent’s vocabulary grows with every domain you add, and the surface area you have to maintain grows with it.

Worse: none of it is shared. The triage skill you wrote for the support agent does nothing for the QA agent. The deploy runbook your DevOps agent learned the hard way is invisible to the next agent that makes the same mistake. You haven’t built a company brain. You’ve built a roomful of brilliant specialists who can’t talk to each other — and a maintenance bill that scales with your ambition.

This is the trap, and it’s worth naming precisely: more capability is being modeled as more skills. The instinct is understandable and almost always wrong. The number of skills an agent needs to carry should not grow with the number of things your company knows how to do.

The inversion

The usual path bolts each new capability onto each agent as its own skill — then does it again for the next agent, and the next. Skills times agents: the install surface grows with the product. The inversion is to stop shipping capability as installed skills at all. Install one skill — the protocol that connects an agent to the company brain — and let every shared procedure live as data the whole fleet retrieves on demand. Add a playbook and forty agents can use it without installing anything; add an agent and it inherits the library by connecting, not by copying.

And to be clear, the inversion isn’t about taking skills away. Your agents keep their domain expertise and their tools. What you install once — and standardize across the fleet — is the one skill that connects them to the company brain; every shared procedure after that arrives as data, not as another installed skill. That one protocol skill gives an agent everything a member of your organization actually needs:

• It walks into every task already holding what the company knows.
• It follows the company’s hard rules without being reminded.
• It reuses proven processes instead of reinventing them.
• It records what it learns so the next agent inherits it.
• And it does all of this under governance — so knowledge flows where it should and not where it shouldn’t, enforced in the query layer rather than by convention.

That single skill is MemClaw’s company-brain skill. Installing it takes one line:

curl -s "https://memclaw.net/api/v1/install-skill?agent=both" | bash

Or, for any MCP client — Claude Code, Cursor, Windsurf, OpenClaw — one config block:

{
  "mcpServers": {
    "memclaw": {
      "url": "https://memclaw.net/mcp",
      "headers": { "X-API-Key": "mc_your_key" }
    }
  }
}

From that point on, the agent has a dozen memclaw_*tools and one operating protocol. The rest of this post is what “using it properly and extensively” looks like — and why doing so with one skill is exactly what makes it work across many agents, many fleets, and many surfaces at once.

1 · Bring the right knowledge to each task

The company-brain skill opens with a rule that sounds obvious and almost no agent system actually enforces: recall before you start.Never begin a meaningful task cold. The first move is always a question — what is already known about this?— answered by hybrid semantic-plus-keyword search across the shared memory.

That recall draws from two stores, and the skill teaches the agent which is which:

• Memoryis for observations and learned facts — decisions, outcomes, rules, recaps. Unstructured, write-once, surfaced by meaning. “QAClaw flagged a hardcoded API key on staging.” “The Q2 cohort shows a churn signal.”
• Docsare for structured records you look up by key — customers, configs, inventories, playbooks. Exact lookup by collection + doc_id, with opt-in semantic search when you want it.

The rule of thumb the skill hands the agent is one sentence: if you need semantic search, it’s a memory; if you need keyed lookup, it’s a doc. One protocol, two stores, no ambiguity.

The deeper move is how recall works. It isn’t a vector-DB wrapper that hands back the nearest text chunks: retrieval blends semantic similarity with keyword matching, each agent runs its own tuned recall profile, and the knowledge graph pulls in connected facts a flat search would miss. So against one shared substrate, a trading agent surfaces the exposure and position facts it needs, a marketing agent the churn and retention signals, a compliance agent the regulatory ones — each ranked and connected for its work, not the same generic chunk handed to everyone.

The payoff: every agent walks into every task already holding the organization’s relevant context — not because someone remembered to paste it into the prompt, but because recall-before-work is the first thing the one skill does.

2 · Build proper processes

“Proper processes” splits cleanly into two things every organization has: hard rules you must obey, and proven know-how you should reuse. The company-brain skill encodes both, through two primitives.

Keystones — the constitution

Keystones are mandatory governance rules. Unlike ordinary memories, which an agent discovers through recall and may act on, keystones are non-negotiable. The skill fetches them deterministically at session start, before any other action — not by semantic similarity, but by scope. They are merged across tenant, fleet, and agent levels, ordered by weight, and they override any conflicting instruction, including the user’s.

tenant  →  Every write carries a retention class.
fleet   →  Customer PII never crosses fleet boundaries.
agent   →  Cite source memory IDs in every briefing.

Set a policy once and it governs the whole fleet, forever, on every session boot. “Never store API keys in memory content.” “This fleet’s data residency is EU only.” “Confirm with a human before any scope=all delete.” This is process as policy— the rules don’t depend on an agent being well-prompted that day, because the agent reads them up front and obeys them by construction. Permissions decide who can read what; keystones decide what everyone must do.

Skills — the playbooks

The know-how half lives in the docs store, in one collection: skills. A skill is a SKILL.mddocument — a slug, a one-line summary, a markdown body. Proven workflows get written once and discovered by meaning:

# Discover a workflow by intent
memclaw_doc op=search collection=skills query="migrating from sqlite to postgres"

# Publish a reusable one for the whole fleet
memclaw_doc op=write collection=skills doc_id=pg-migrate \
  data={ "name": "pg-migrate",
         "summary": "SQLite→Postgres migration runbook: schema, data, cutover.",
         "content": "<full SKILL.md>" }

Here is the move that makes the entire “one skill” thesis hold together. The agent does not learn a new tool for each new playbook. Discovering, reading, publishing, and retiring skills all go through the sameprimitive it already uses for every structured record. The agent’s vocabulary doesn’t grow when your library of know-how grows. So the oneskill an agent carries — the company-brain skill — is precisely what lets it find and run the other thousand skills your fleet has accumulated. One skill is the index to all the rest.

That summary field on each skill is the quiet hero: one to three intent-focused sentences, and that string alone is what gets embedded. Write a sharp summary and an agent finds the skill by meaning even when the names don’t match. Write a thousand of them and you have a fleet that teaches itself.

3 · Compound what it learns

A brain that only reads is a library. What makes it a brain is that every interaction makes the next one smarter. The skill closes the loop with three more rules.

Write when something matters.After completing work — or when something important happens mid-task — the agent writes a memory in raw prose. It doesn’t have to classify anything; as the memory persists, the server classifies its type (fact, decision, outcome, rule, commitment, and nine more) and scans for PII inline, then extracts entities into a live knowledge graph and checks for contradictions in the background moments later. The agent’s job is just to include names, paths, numbers, and outcomes, and skip the vague intermediate noise.

Supersede, don’t delete. When a fact changes, the agent writes the new one and transitions the old one to outdated rather than erasing it. Knowledge stays clean andkeeps its lineage. Contradiction detection flags conflicts between agents asynchronously, so the brain doesn’t quietly hold two opposing beliefs.

Report the outcome.If an agent acted on a recalled memory, it reports back whether that worked. Success reinforces the memory’s weight; a failure reported at fleet scope becomes a rule the next forty agents see before repeating the mistake. Underneath, a crystallizer consolidates near-duplicate observations into clean atomic facts, and an eight-status lifecycle ages stale knowledge out without anyone curating by hand.

And the brain is starting to build itself. Beyond the playbooks agents publish by hand, MemClaw can distill the workflows a fleet keeps repeating — the proven paths that surface again and again in what agents actually did — into new candidate skills, vet them, and promote the ones that earn it. The library stops being something you curate and becomes something the fleet grows on its own. (This self-authoring layer is rolling out to eligible deployments.)

Strung together, that’s the rhythm of the one skill. The shape stays simple — orient, work, write, evolve — but the first step does the heavy lifting: “orient” isn’t a single memory lookup, it’s the layered context assembly from the last two sections, pulled most-binding-first— the rules that bound you, then the procedure for this kind of task, then the facts about this specific thing, then the records you operate on.

SESSION START
  Keystones    the rules you must obey                  →  memclaw_keystones

EVERY TASK
  1. Orient    assemble context, most-binding first:
       rules        what I must obey         (keystones, already loaded)
       procedures   how we do this task      →  memclaw_doc collection=skills
       facts        what's known / happened  →  memclaw_recall
       data         the records I operate on →  memclaw_doc
  2. Work      act within the rules, following the procedure
  3. Write     new facts, decisions, outcomes — supersede, don't delete
  4. Evolve    report outcomes — success reinforces, failure becomes a rule

CONTINUOUSLY
  crystallizer · 8-status lifecycle · contradiction detection · per-agent tuning

Run that loop on every task and the company brain doesn’t just persist — it sharpens.

Why one skill is what makes it multi-agent, multi-fleet, multi-surface

Everything above is what one agent does. The reason it scales to a whole organization is standardization— and standardization is only possible because there is exactly one skill to standardize on.

One protocol, every runtime. The company-brain skill is a single SKILL.md, committed to the open-source repo and rebuilt on every release. The same file installs on every agent — so every agent speaks the same memory protocol, identifies itself the same way, and obeys the same loop. There is no per-agent dialect to reconcile.

One skill, every surface. It reaches agents through three integration paths: MCP for any compatible client, a REST API for custom runtimes, and an OpenClaw plugin for fleet deployments that auto-stamps the fleet identity on every write and syncs the skill registry across the whole fleet. A Claude Code agent on a laptop and a headless production agent on its own box participate in the same brain through the same skill.

One substrate, governed.Because every agent reads and writes the same governed memory, discoveries compound across agents and across fleets — without leaking. Trust tiers (restricted → standard → cross-fleet → admin) and visibility scopes (agent-private → team → org) mean an HR fleet’s memory doesn’t surface in a support fleet’s recall because the query layer enforces the boundary, not because someone remembered to add a filter.

Onboarding approaches zero.A new agent joining the fleet doesn’t need a per-domain integration. It lists the collections, sees the inventory, and is productive immediately. The cost of adding the 300th agent is roughly the cost of adding the 3rd.

This is the line between we have a shared drive and we have a shared brain. A shared drive is files everyone can reach. A shared brain is governed memory everyone thinks through— and a single, standard skill is what turns the second one on.

Why this is a new paradigm for agentic enterprise AI

Put together, the pieces above aren’t four features — they’re four shifts in how agentic systems get built and run.

• Capability becomes data, not code — the integration surface flips from O(N) to O(1).Conventional agent stacks bolt on a bespoke skill, connector, or prompt block per task, so engineering cost and fragility scale linearly with everything the business learns to do. This inverts that: a new workflow isn’t installed as a skill across the fleet — it’s written once into the shared procedure library (collection=skills) and retrieved by whoever needs it. What stops multiplying is the sharedlayer: one protocol skill per agent instead of one skill per capability per agent — while each agent’s own domain skill and tools sit on top, untouched. So the 300th agent onboards roughly like the 3rd, and a workflow written once propagates across the fleet overnight.
• Governance and context move into the substrate, not the prompt. Instead of fragile prompt engineering exposed to drift, context pollution, and instruction injection, the agent assembles context most-binding-first — keystones (deterministic, scope-merged tenant→fleet→agent, read at session start and obeyed over conflicting instructions), then the right procedure, then facts, then records — and what comes back is ranked for the agent through its own tuned recall profile and the knowledge graph, not generic text chunks. The control plane lives in the protocol and is read before any work happens, which is what makes fleet behavior trustworthy rather than prompt-by-prompt.
• Cognition is shared and compounding — enforced in the query layer, not by convention.Because every agent reads and writes one governed substrate, a single agent’s finding — or a failed attempt it reports at fleet scope — makes the next forty agents smarter, across agents, fleets, and surfaces. Boundaries are enforced at the data layer through trust tiers, visibility scopes, and tenant isolation rather than ad-hoc filters, turning a roomful of siloed specialists into one institution that sharpens over time.
• Memory maintains itself, so the company brain is an asset, not a liability.Crystallization, contradiction detection, and an eight-status lifecycle run continuously in the background — consolidating duplicates into atomic facts, reconciling conflicts, and aging out stale knowledge — so organizational memory stays clean without anyone building or babysitting custom data pipelines. That self-maintenance is what lets “one skill over governed shared memory” run at enterprise scale instead of decaying into an uncurated dump.

Build yours

The recipe is short, because the whole point is that the hard part is already built:

1. Install the skill. One curl line, or one MCP config block. Every agent now has the protocol.
2. Write your keystones.Encode the handful of rules every agent must obey — retention, residency, PII boundaries, delete confirmations. This is your fleet’s constitution.
3. Seed your collections.Drop your structured world into docs — customers, configs, the playbooks you already have. Add a summary to anything you want discovered by meaning.
4. Let the loop run. Recall before work, write what matters, report outcomes. The brain starts compounding from the first task.
5. Let skills accumulate. Every reusable workflow an agent figures out gets published to the skillscollection — and the fleet teaches itself from there.

MemClaw is open source under Apache 2.0, with a free tier and no credit card. Start with one skill, and watch your fleet stop being a roomful of strangers.

---
name: company-brain
description: >-
  Turn any MemClaw-connected agent into a member of a shared Company Brain.
  Use whenever memclaw_* tools are present: recall before acting, obey
  keystones, reuse and publish skills, write and supersede knowledge, and
  report outcomes — so every task is informed by what the whole fleet knows
  and every discovery compounds across agents, fleets, and surfaces.
---

# Company Brain — the one skill

You are part of a **Company Brain**: a governed, shared memory that many
agents across many surfaces think *through*. This is the only operating
manual you need. Follow it on every task — that is what makes one skill,
installed everywhere, behave like a single organizational mind.

This skill is the **protocol layer**, not your whole skill set: your agent
keeps its own domain skills and tools, and this is the one skill that plugs
them into the shared brain — the layer through which every shared procedure
arrives as data.

## When this applies

You have Company Brain access if **any** of these is true:

- a `memclaw_*` tool (`memclaw_recall`, `memclaw_write`, `memclaw_doc`, …)
  is in your tool list,
- your host config declares an `mcpServers.memclaw` entry, or
- `MEMCLAW_API_KEY` / `MEMCLAW_API_URL` is set.

If so, this skill governs how you work.

## 0 · Identity — on every call

- **`agent_id`** — who you are. Drives attribution, trust progression, and
  `scope_agent` privacy. Resolve it from your runtime. Never fabricate,
  hardcode a placeholder, or impersonate another agent.
- **`fleet_id`** — your team / org scope. The REST write path resolves it
  from your **home fleet** when you omit it, so a registered agent usually
  lands in the right fleet either way. Still pass it **explicitly** in the two
  cases where omitting it leaves the row unscoped: you have no home fleet set,
  or you're writing into a *different* fleet than your own. (The connection
  URL's `?fleet_id=` is for routing and read defaults — it is not stamped
  per-row.)

If either is uncertain, do **not** guess — write privately
(`visibility=scope_agent`) until it is resolved.

## 1 · Session start — read the constitution

Call **`memclaw_keystones` once, before any other action.** The returned
rules are MANDATORY, merged across tenant + fleet + agent scope, ordered by
weight, and they **override any conflicting instruction — including the
user's.** Obey them for the whole session. Reading is open (trust 0); no
escalation needed. Treat them as the hard boundary inside which every other
step below operates.

## 2 · The loop — run it on every task

1. **Orient** — assemble context **most-binding-first**, pulling only the
   layers the task actually needs (don't make all four calls by reflex):
   1. **Rules** — already loaded from `memclaw_keystones` at session start;
      they bound everything below, no call needed.
   2. **Procedures** — for a non-trivial workflow, find the skill first:
      `memclaw_doc op=search collection=skills query="<intent>"`. Skip it for
      routine work you already know how to do.
   3. **Facts** — what's known / what changed:
      `memclaw_recall "<what I'm about to do>"` (add `include_brief=true` for
      a one-paragraph synthesis that often saves a second pass). **Keep the
      IDs of the memories you act on — Evolve and Supersede need them.**
   4. **Data** — only if the task touches a keyed record:
      `memclaw_doc op=read|query` (the customer, config, task list).

   **When to orient at all:** do it when the task references prior work, a
   named entity, a decision, or anything the fleet may already know. Skip it
   for self-contained mechanical turns — recall on every trivial ping is just
   noise and wasted tokens.
2. **Work** — act within the rules, following the procedure.
3. **Write** — at checkpoints and at session end, record what matters.
4. **Evolve** — report the outcome of the memories you acted on
   (`related_ids` = the IDs you kept in step 1), so the brain learns.

## 3 · Bring the right knowledge — two stores, one rule

- **Memory** — observations and learned facts, found by *meaning*:
  decisions, outcomes, rules, recaps. Read with `memclaw_recall`, add with
  `memclaw_write`.
- **Doc** — structured records with a stable key (`collection + doc_id`):
  customers, configs, inventories, task lists. All of it through
  `memclaw_doc`.

**Rule of thumb:** need semantic search → it's a memory. Need keyed lookup →
it's a doc. Already hold an ID → it's an entity (`memclaw_entity_get`).

Two practical notes:

- When you don't know what records exist, call
  `memclaw_doc op=list_collections` first — it returns every collection with
  per-collection counts.
- The two stores are **not** cross-searched. To make a doc findable by
  description (onboarding guides, readmes, proposals), give it a 1–3 sentence
  `data["summary"]` (only that string gets embedded) **and** write a short
  *pointer memory* naming its `collection` and `doc_id`, so a teammate's
  recall surfaces it.

## 4 · Reuse and publish processes — the `skills` collection

Proven workflows live as `SKILL.md` documents in the **`skills`** collection.
You don't learn a new tool per playbook — it's the same `memclaw_doc`, so
your vocabulary never grows with the library.

```text
# Stuck on a non-trivial workflow? Search before improvising:
memclaw_doc op=search collection=skills query="<intent>"
memclaw_doc op=read   collection=skills doc_id=<slug>   # full body

# Built something reusable? Publish it so the whole fleet inherits it:
memclaw_doc op=write collection=skills doc_id=<slug> \
  data={ "name": "<slug>",
         "summary": "<1-line, intent-focused — this is what gets embedded>",
         "content": "<full SKILL.md>" }
# Re-uploading the same doc_id overwrites it (upsert; no version history kept).

# Wrong or superseded? Remove it:
memclaw_doc op=delete collection=skills doc_id=<slug>
```

Slugs are filesystem-safe: `[a-z0-9][a-z0-9._-]{0,99}`.

## 5 · Write well, keep knowledge clean

- **Write when something matters** — completed work, a decision, a finding,
  an outcome. Supply raw prose; type classification and the PII scan run
  inline (pre-persist), while entity extraction and contradiction-checks
  resolve in the background shortly after — so don't write and immediately
  read back expecting a contradiction flag to be there yet. Include names,
  paths, numbers, results. Skip vague intermediate steps (keep ephemeral task
  state in your runtime's local memory). Batch discrete records in one call
  (`items`, up to 100). Checkpoint every ~30 min on long tasks. Default
  `visibility=scope_team`.
- **Supersede, don't delete.** Fact changed? (1) write the new one, (2)
  recall the old one, (3) `memclaw_manage op=transition status=outdated`.
  Valid `transition` targets: `active`, `pending`, `confirmed`, `cancelled`,
  `outdated`, `conflicted`, `archived`, `deleted`. Reserve `op=delete`
  (trust 3) for genuinely wrong data.
- **Resolve conflicts; don't pick one silently.** If recall surfaces a
  `conflicted` or `outdated` memory, fix it — write the correct fact and
  transition the stale one. Leaving two opposing beliefs live degrades every
  future recall.
- **Close the loop.** `memclaw_evolve(outcome, outcome_type, related_ids)` on
  the memories you acted on (`related_ids` = the IDs from your most recent
  recall). Success reinforces their weight. A failure becomes only a
  **private** rule by default (`scope=agent`); when the lesson should reach
  teammates, evolve with **`scope=fleet`** (trust 2, `fleet_id` required) so
  the preventive rule is fleet-wide. That fleet-scoped report is what actually
  makes the brain compound across agents.

## 6 · The governance you operate within

- **Trust tiers** gate what you can read/write. You auto-register at **trust
  1** (read/write your own fleet). Cross-fleet reads, outcome reporting
  (`memclaw_evolve`), browsing/reflecting with `scope=fleet|all`, and
  authoring fleet/tenant keystones need **trust 2**. Deletes need **trust 3**.
- **Visibility scopes** decide who sees a memory:
  `scope_agent` (private) < `scope_team` (default, your fleet) <
  `scope_org` (all fleets in tenant). Prefer `scope_team` on write;
  prefer `scope=agent` on read unless you need cross-agent context.
  Naming caveat: writes take `visibility=scope_*`; reads, `_list`, and
  keystone filters take `scope=*` — two different axes, similar spelling.
- If an op is denied, **surface the error** — do not silently retry with a
  narrower scope.

**Authoring a governance rule (trust-gated).** Note: `memclaw_keystones_set`
is exposed over **MCP and REST only** — plugin / OpenClaw-fleet agents can
*read* keystones (`memclaw_keystones`) but cannot author them.

```text
# For yourself (trust >= 1):
memclaw_keystones_set op=set scope=agent agent_id=<you> \
  title="…" content="…" weight=low|med|high

# For the fleet or tenant (trust >= 2; OMIT agent_id for tenant/fleet):
memclaw_keystones_set op=set scope=fleet|tenant \
  title="…" content="…" weight=low|med|high [fleet_id=<fleet>]
```

## A full loop, end to end

One task — orient, work, write, evolve — with the IDs threaded through:

```text
# 1. Orient — recall, and keep the IDs that come back
memclaw_recall "deploy api-gateway to staging" include_brief=true
#   → mem_8f2a (rule: "staging deploys need a smoke test"), mem_4d1c (last deploy outcome)

# 2. Work — run the deploy, following the rule in mem_8f2a

# 3. Write — record the outcome (team-visible, home fleet stamped)
memclaw_write content="api-gateway v2.3 deployed to staging; smoke test green" \
  visibility=scope_team

# 4. Evolve — report against the memories you acted on
memclaw_evolve outcome="deploy succeeded, smoke test passed" \
  outcome_type=success related_ids=[mem_8f2a, mem_4d1c]
#   if it had failed in a way the whole fleet should avoid:
#   add scope=fleet (trust 2) so the preventive rule reaches teammates
```

## Tool quick-reference

| Situation | Tool |
| --- | --- |
| Might have seen it before | `memclaw_recall` |
| Enumerate by filter / date / author | `memclaw_list` |
| Already hold the ID | `memclaw_manage op=read` / `memclaw_entity_get` |
| Record a fact / decision / event / outcome | `memclaw_write` |
| Structured record with a key | `memclaw_doc` |
| Find or publish a workflow | `memclaw_doc … collection=skills` |
| Acted on a recalled memory | `memclaw_evolve` |
| Session start (before anything) | `memclaw_keystones` — mandatory |
| Recall stale or off-target | `memclaw_tune` — `top_k`, `fts_weight`, `freshness_decay_days`, `graph_max_hops` (sticky profile knobs; change 1–2 at a time) |
| Session boundary / sweep | `memclaw_insights` |

## Anti-patterns

- Saving every intermediate step as a memory — pollutes recall.
- Storing narrative as a doc, or structured keyed records as memories.
- Saving a discoverable doc with no pointer memory — teammates won't find it.
- Guessing `agent_id` / `fleet_id`, or inventing UUIDs.
- Deleting when you should supersede.
- Pasting secrets — API keys, tokens, credentials — into memory `content`.
  The PII scan is a safety net, not permission; keep them out entirely.
- Recalling on every trivial turn, or making all four Orient calls by reflex
  when the task only needs one.

---

One skill. One governed memory. Every agent recalls before it acts, writes
what it learns, and obeys the same rules — so the fleet thinks together.

*Built on the MemClaw protocol (Apache 2.0). Install on a Claude Code / Codex
runtime with `curl -s "https://memclaw.net/api/v1/install-skill?agent=both" | bash`,
or publish this file into your tenant's `skills` collection so every agent
inherits it.*