Fifth page in Operation Scarecrow. If you haven't read The Company Brain Is Four Different Problems yet, start there. Source citations at the foot of this piece.
The production codebase. CI/CD pipeline definitions. The deploy runbook, the incident-response runbook, the customer-onboarding runbook. The design system and component library. Sales battlecards. Support macros. All of it is executable "how" rather than declarative "what" — behavior encoded so it can be run, not a fact that gets read and reasoned about. Getting this tier wrong doesn't look like a misunderstanding. It looks like a bug, which is exactly why it belongs under the same review discipline a codebase already gets, rather than under product or content review.
The split that's already there, hiding in plain sight
At Meridian — the illustrative mid-market SaaS company this section's worked example uses throughout — this tier reveals something none of the other three do as clearly: it's already split into two governance realities, and almost nobody notices because both halves share one label. The code half — the production codebase, CI/CD pipelines, the component library — is well-governed: PR review, automated tests, version history, a clear owner for every piece of it. The runbook half — deploy runbooks, incident-response runbooks, onboarding runbooks, sales battlecards, Zendesk macros — lives in Confluence, Notion, and admin panels, with no version control, no review gate, and no test, even though it's the exact same kind of artifact: executable "how we do this," sitting three tools away from code that gets treated far more seriously.
Procedural memory isn't a tier organizations have ignored. It's a tier they've already solved half of, without realizing the other half needed the identical treatment.
What's already built
Anthropic's Agent Skills is the closest thing on the market to a purpose-built implementation of this tier's newest slice: a SKILL.md-centered directory with scripts and resources, discovered and loaded on demand, distributed through ordinary version control — shipped specifically as an open standard so organizations wouldn't have to build this scaffolding themselves. That's a narrower claim than it might sound. It's not procedural memory in general — production code and CI/CD were already doing this tier's job, in the most literal sense, long before any AI framing existed. What Agent Skills adds is specifically the agent-facing, on-demand-discoverable packaging this tier didn't have before: a way to expose runbook-style "how" as something an agent can find and invoke, not just something a human can read. Access follows the same shape procedural memory already has in engineering: read by any agent or service invoking the skill, write gated by ordinary code review and CI rather than a content process.
The pre-AI precedent for the runbook half is Google's own SRE practice: version-controlled, often wired directly into CI/CD, and credited with roughly a 3x reduction in mean-time-to-recovery compared to improvising a response live. That's real evidence, from the team that arguably invented modern operational discipline, that codifying procedural knowledge and reviewing it like code — not like a wiki page — is what makes it trustworthy under pressure.
Palantir's Kinetic Action Layer covers this tier too, and it's worth naming both for what it gets right and for the specific mistake it repeats. It bundles the reusable, versioned action type itself — procedural — together with each action's individual log entry — a permanent, dated fact about one specific use of it, which is episodic — under one governance model. That's the same conflation the original ProductHarness backplane made at the organizational level, recurring one layer down, inside a platform that gets almost everything else about this framework right.
Bring the ungoverned half up to the bar the governed half already sets
The fix isn't complicated to state, even if it's tedious to execute: runbooks, playbooks, and support macros get the same PR-review-plus-CI bar production code already gets, owned by the same people who own the systems those runbooks describe. Version it. Review it like a pull request. Test it wherever a step is actually scriptable. This is what packaging tribal knowledge as a skill or a callable tool — rather than a wiki page someone might read — actually buys an organization.
There's a deeper shift underneath the mechanical one. The right consumption model for this tier isn't reading, it's executing. A runbook an agent can only read is still procedural memory trapped in episodic-style packaging — a document about a process, not the process itself. A runbook an agent can invoke as a callable tool is procedural memory finally doing its actual job. That distinction is this tier's whole leverage case: direct automation, the only one of the four tiers where the payoff is an agent doing the work itself, rather than a human or an agent deciding faster because better information was available.
Where AI writing its own memory doesn't work yet
Every other tier in this section has at least a plausible case for AI generating its own entries — a working-memory compaction step, an auto-summarized episodic record, a proposed semantic fact awaiting a steward's approval. Procedural memory is the exception, and it's worth stating plainly rather than assuming a pattern that works elsewhere carries over. Voyager remains the reference model for the idea: an agent writes a code-based skill, validates it through actual execution, and adds only verified skills to a persistent library. Real follow-on work has extended that pattern to general-purpose agents. But a direct benchmark of the approach, SkillsBench, found that self-generated skills currently perform 1.3 percentage points worse, on average, than having no skill library at all — with what success there is concentrated specifically in narrow environments that offer deterministic execution verification.
Outside those narrow, checkable domains, an agent writing its own procedural memory is not yet a clear win, and treating it like one would be the exact opposite of this tier's whole argument: the tier that most needs engineering-grade review is also, right now, the tier where letting AI author its own entries has the thinnest evidence behind it. Procedural self-authorship gets the same review bar as human-written code, not a lighter one, until that changes.
What the standard doesn't cover yet
The open standard covering this tier's storage format is real and already adopted, but the standard's own long-term stewardship — who evolves a shared skill across organizations that don't report to each other — isn't settled, even though the file format itself is. And the AI self-generation finding above is recent enough to be a correction rather than settled background: this project's own earlier framing of procedural self-generation was more optimistic than the evidence currently supports, and this page states the corrected version rather than the original one.
Sources. Anthropic Agent Skills: platform.claude.com/docs/en/agents-and-tools/agent-skills/overview; governance and stewardship note via theaitrack.com/anthropic-open-agent-skills-standard. Google SRE runbooks and MTTR data: Google SRE Book, sre.google/sre-book/introduction. Palantir's Kinetic Action Layer: Palantir Foundry documentation, palantir.com/docs/foundry/ontology/overview. Voyager and skill distillation: "Voyager: An Open-Ended Embodied Agent with Large Language Models," arxiv.org/abs/2305.16291. The SkillsBench self-generated-skill performance figures: "SoK: Agentic Skills — Beyond Tool Use in LLM Agents," arxiv.org/html/2602.20867v1. Meridian is an illustrative, composite company invented for this section — not a real business — standing in for the shape most mid-market software organizations are already in.