An open spec for agent-loadable organizational memory — a strict superset of Anthropic Agent Skills that adds tenancy, audience, provenance, and temporal validity.
Status: RFC v0.1 — Comments and PRs welcome. Not v1.0; the format will change based on community feedback.
SKILL.md (Anthropic, Dec 2025) standardized how agents load capabilities. Adopted by 32+ runtimes. The format war is over.
What's still unstandardized: how agents load organizational knowledge — the procedural skills that encode "how Acme Corp handles refunds," "how the support team escalates incidents," "how this company decides pricing exceptions."
Tom Blomfield's Summer 2026 YC RFS named this primitive: "a system that pulls knowledge out of fragmented sources, structures it, keeps it current, and turns it into an executable skills file for AI agents."
brain-skill-bundle is a proposal for what that file should look like.
Take an Anthropic-compatible SKILL.md and add five frontmatter blocks any organizational-knowledge use case needs:
| Block | Purpose | Why standard |
|---|---|---|
tenant |
Which company/team this skill applies to | Multi-tenant runtimes need it; spec leaves it DIY today |
audience |
internal / client_safe / public view discriminator |
Regulated industries (legal/healthcare/finance) need view enforcement at the artifact layer, not just ACLs |
provenance |
Source-of-truth pointers (Gmail thread IDs, Slack channel IDs, meeting transcripts) | Auditable knowledge in regulated industries; debugging hallucinations |
validity |
Bitemporal validity windows (valid_from, valid_to) |
"What did we believe on March 1?" — required for legal/medical replay |
evolution |
Schema version + confidence + last-evolved timestamp | Brain systems with auto-evolving schemas (BizBrain OS, future Letta variants) need versioned schema metadata |
Every existing SKILL.md parser ignores unknown frontmatter. A brain-skill-bundle is a valid SKILL.md — runtimes that don't speak the extension still get a working skill. Runtimes that do (via the reference parser here) get tenancy enforcement, audit trails, and view-aware loading.
---
name: refund-handling
description: How refunds are handled at Acme Corp's customer support team
allowed-tools: ["mcp__crm__*", "mcp__email__*"]
brain-skill-bundle:
spec_version: "0.1.0"
tenant:
id: "acme-corp"
display_name: "Acme Corp"
audience: client_safe
provenance:
sources:
- { type: gmail, thread_ids: ["abc-123", "def-456"] }
- { type: slack, channel_ids: ["C0123ABCD"], message_count: 47 }
last_updated: "2026-04-29T10:00:00Z"
validity:
valid_from: "2026-01-15"
valid_to: null
evolution:
schema_version: "0.3.1"
confidence: 0.92
last_evolved: "2026-04-12T14:32:00Z"
---
# Refund Handling at Acme Corp
When a customer requests a refund within 30 days of purchase:
1. Verify the order in the CRM (use `mcp__crm__get_order`)
2. Check the customer's lifetime value against the LTV threshold of $500
3. ...See SPEC.md for the full specification and examples/ for three real-world skill bundles (refund handling, pricing exceptions, incident response — Tom's three named use cases).
A minimal TypeScript reference parser lives in parser/. It validates a brain-skill-bundle against the spec, exposes typed access to the extension blocks, and emits a plain Anthropic-compatible SKILL.md for runtimes that don't speak the extension yet.
cd parser
npm install
npm run build
npm test # 16/16 passing
node dist/cli.js ../examples/*.skill.md # validate all 3 examplesVerified working: parser typecheck, build, all 16 tests, and CLI validation against all three example bundles pass clean as of v0.1.0 release.
If you run an agent platform across many customers, you're already hitting these problems:
- Tenant collision — your skill file leaks knowledge between Customer A and Customer B
- Audience leakage — your "internal pricing strategy" skill ends up loaded into a customer-facing chatbot
- Stale knowledge — your refund SOP changed in February, but the agent is still operating on the December version
- Hallucinated authority — the agent can't cite where the rule came from
- Schema drift — your customer's brain evolved a new entity type ("Patients" for the dental client) and the skill bundle has no way to express the schema version
brain-skill-bundle doesn't solve these for you. It gives you a place to put the answer in a portable, parseable, vendor-neutral way.
If you're a runtime author (agent platform, IDE assistant, MCP server author): the parser in this repo is MIT licensed. Drop it in. Read the extension blocks where they exist; ignore them where they don't. You're already 90% there.
If you're a brain platform (Letta, Mem0, Zep, Glean, Graphiti, BizBrain OS, custom in-house): the spec defines what coming out the other end of your brain should look like. Emit brain-skill-bundle files and any compliant runtime can load them.
If you're an enterprise buyer: ask your AI vendors whether they emit portable skill bundles. If the answer is no, you're locked in.
- v0.1 (now): This RFC. Five extension blocks, one reference parser, three example bundles, MIT.
- v0.2 (target Q3 2026): Schema for entity-record bundles (so the brain itself, not just the skills it emits, can be exported).
- v0.3 (target Q4 2026): Cross-runtime adoption — at least three independent implementations.
- v1.0: Stable spec, governance handed off (Linux Foundation Agentic AI Foundation if they'll have it; otherwise an independent working group).
This spec was extracted from BizBrain OS, a multi-tenant company-brain platform running across paying clients. BB1 emits brain-skill-bundle files as the natural output of its entity graph + comms ingestion + schema evolution.
MIT. Use it, fork it, propose extensions, or write a competing spec — the goal is the standard, not the brand.
Open an issue. Open a PR. The bar is "would this make the spec more useful for organizational memory across vendors?" The bar is not "does this match BizBrain OS's internal architecture?"