Facts Flow, Meaning Accumulates

The Pushback, Stated Fairly

The feedback (Jason Maddern, ai-skills repo) is worth steelmanning because it is not the position it first appears to be. Their approach: skills pull context on demand through MCP servers . Jira, Confluence, the systems of record . And explicitly gitignore all working files. Nothing is stored that could go stale. Our approach stores knowledge in the repo they gitignore. His own conclusion: “we probably want to have both . Explicitly ignore working files, but have a brain store of the items we want to record permanently,” and he proposes a vertical/brain tree linked from the skills.

So the real disagreement is not MCP versus brain. It is where the boundary sits between fetched facts and stored knowledge. That is a boundary worth drawing precisely, because both camps are right about their own side of it.

MCP Is a Transport, Not a Context Strategy

The framing “context should be MCP-based” conflates two different questions. MCP answers how does an agent reach data. The brain answers what does the organization know. These are not rivals. The white paper already commits to MCP as the retrieval interface for the brain itself once the graph projection lands (Section 3.4, and the AKS plan’s knowledge_search/memory_recall tools). The brain is destined to be an MCP-served source. Arguing MCP against the brain is arguing the pipe against the reservoir.

What MCP-on-demand genuinely wins: facts of record. Ticket status, CRM fields, pipeline numbers, invoice state . Volatile, authoritative somewhere else, and wrong the moment you cache them. Fetch-time freshness beats a stored copy every time. On this the critics are simply correct, and the vault should never compete. (Our scorecard caches values with a 14-day stale flag . An acceptable interim, and the phase plan in scorecard-data-sources.md already points it toward MCP fetch.)

What MCP-on-demand structurally cannot do: an API call returns state, not judgment. No system of record serves “why we chose the hybrid pricing model,” “which of these two contradictory claims is current,” or “what we learned the last time we queried this warehouse.” Realtime access to systems that do not hold the knowledge retrieves nothing. And an MCP result evaporates when the session ends . No identity, no dedupe, no contradiction handling, no decay model. The four lifecycle stages that are the white paper’s core argument are exactly the machinery pipes don’t have.

The boundary rule: if a fact has a system of record, the brain stores the pointer and the interpretation, never the value. If knowledge has no system of record, the brain is the system of record. Working files gitignored . Agreed. Decisions, syntheses, and lessons . Committed.

The Registry: The Brain Should Describe the Data Plane

The proposal under review: the brain’s index should provide knowledge about the MCP servers and data that are available. Verdict: valid . And it is the bridge between the two camps. This is a data catalog for agents, and it is exactly brain-shaped knowledge: slowly changing, judgment-laden, expensively learned, and worthless if trapped in one person’s session history.

An agent facing five MCP servers needs to know what each one answers, which is authoritative when they overlap, what the gotchas are, how fresh the data runs, and what access gates exist. The server’s own tool descriptions cannot carry this . They describe one server from its author’s point of view. The registry carries cross-source, experience-derived judgment: which source wins when they disagree.

We have already paid for the evidence. The b2bkg build learned that rpt_account filtered to vertical = 'B2B' is Salesforce truth (8,329 accounts) while mart_account filtered to vertical = 'Business' is operational truth (537 customers) . A label mismatch that cost a session to discover. It learned that Payer_Name policy tags block company names pending a PII waiver, and that Zendesk’s cf_payables_client looks like a bridge to Payables clients but is actually EDU product slugs. Today those lessons live in memory files. A registry makes them first-class: every gotcha discovered once is never paid for twice, by any agent, driven by any user.

A registry entry carries: source/server, what questions it answers, what it is authoritative for, freshness expectations, known quirks, access notes, and an as-of date with a TTL . The same decay discipline as teardowns. Start as knowledge/data-registry.md, seeded from what the b2bkg, customer-graph, and scorecard work already learned. Graduate to graph nodes under AKS.

This lands as three layers with clean jobs:

| Layer | Holds | Freshness model | |. -|. -|. -| | Data plane (MCP servers, systems of record) | Facts of record . Fetched, never cached | Realtime at call | | Knowledge plane (the brain) | Meaning: decisions, syntheses, lessons . Plus the registry describing the data plane | Lifecycle: dedupe, contradiction, TTL | | Skills (thin) | How each function thinks | Versioned, self-updating |

The skill reads the registry to decide what to fetch, and reads the brain to know what it means. This is also the direct answer to the vertical/brain proposal: his skills gain a permanent store, our brain gains an explicit map of the on-demand plane. Same convergence, opposite directions.

Making /stuff Self-Learning

The skill already has learning loops . They just all land in content, not behavior: memory accumulation, query compounding, cascade on capture, teardown TTL auto-refresh, feedback.md, and self-update as the distribution channel. The gap is that the skill’s behavior is static between manual edits, and some organizational knowledge is embedded in SKILL.md where it cannot learn. The Strategic Intelligence Graph hardcodes the 2026 targets and the DRI table inside the skill . A quiet violation of thin-skills/thick-brain. When objectives change, the skill lies until someone edits it.

Three loops, in order of ambition:

L1 . Data learning: close the embedded-knowledge leak. Move the Strategic Intelligence Graph’s facts (targets, DRIs, strategic priorities) out of SKILL.md into the vault . Objectives.md and people/ already exist to hold them . And have the skill read them at runtime. SKILL.md keeps the judgment rules (how to weigh due dates against objectives). The vault holds the facts. The skill then learns whenever the brain does, with zero new machinery. STRATEGIC-REFERENCE.md half-does this today but ships with the skill. Finish the job by making it vault content.

L2 . Behavior learning: learned operating rules as vault content. Add memory/skill-learnings.md: agent-written operating rules distilled from feedback.md entries, in-session corrections, and wrapup patterns . Each rule citing its evidence (author, date, source). Loaded on Standard/Deep actions exactly like memory. The per-user version of this already works (“no ASCII diagrams” lives in Chris’s memory and changes agent behavior every session). This generalizes it to team level. Because it is vault content, a rule learned in one user’s session propagates to everyone on the next git pull . No version bump, no reinstall. Guardrails: user instruction beats learned rule, tidy prunes stale rules, lint checks rules for contradictions.

L3 . Skill evolution: the skill rewrites itself, gated. A periodic retro pass . A vault-lint extension or scheduled agent . Mines feedback.md, skill-learnings, memories, and observed friction, and proposes SKILL.md diffs as pull requests. A steward merges. The existing self-update mechanism distributes. This is the white paper’s governance answer applied to the skill itself: L2 learnings are open capture, SKILL.md is canon, and promotion runs through a steward. Git is the audit trail. The version number is the rollout gate.

The registry closes the loop between the two halves of this note: it is the L2 pattern applied to the data plane. Every MCP query that teaches something writes the lesson back. Every session starts smarter than the last one ended. MCP gives agents hands. The brain gives them memory. A skill with both compounds.

Implications for the White Paper

This extends rather than departs from the white paper, but two amendments are worth folding into the next revision: (1) Section 3.4/5 should name the data-plane registry as brain content . The brain describes the sources it does not replace. (2) Section 5 should state the boundary rule (pointer and interpretation, never the value) as the explicit division of labor between skills’ MCP calls and brain reads.