CoreWise Academy

Agents & Automation · Layer III / Broad

Every new repo starts with your lessons

AI Firmware is a boot layer of kernel rules, installable skills, and committed memory that makes every new agent repo start senior instead of relearning old lessons.

Nº 012 · Vol. I·7 min read· Updated July 2026

Read firstExpertise you can install (Assumes you know what an installable skill is. Firmware is the whole boot layer, not a single skill.)
“one repo learns; the next should not start dumb”

Watch what happens to agent setups over 6 months. One repo learns a better debugging loop. Another learns a deployment gotcha that cost 3 hours. A third learns which standing rules are worth their token weight and which are not. And all of it stays where it happened: folklore, locked in transcripts and one-off prompt files, relearned from scratch by every new project. AI Firmware is the counter-move: a portable boot layer that sits under the work, small enough to stay out of the way, structured enough to shape how an agent boots, remembers, checks itself, and ships.

01The firmware split

The design answers a tension every agent setup hits. Put everything in the prompt and every turn gets heavier: always-loaded instructions are a tax paid on 100% of requests. Store nothing and every project repeats every mistake.

“Always-loaded instructions are a tax paid on every single request.”

Firmware splits the difference by giving each kind of knowledge the cheapest home that still works: a kernel of standing rules that stays small and always loaded (safety and process rules that apply everywhere, only); skills that hold the long playbooks and load only when a task triggers them; committed reference memory that keeps project knowledge out of the chat transcript and inside the repo, where it travels with every clone; session hooks that run cheap startup checks; and sync scripts that move reusable improvements between projects. The template even ships a script that measures the always-loaded token weight, so the cost of a fat kernel is a number; auditing and shrinking that same per-turn tax is the job of Stop hitting your token limit. Two of these layers have whole guides of their own: Expertise you can install on skills, and Give your agent a memory on memory that persists.

The split in one view:

LayerWhen it loadsWhat belongs there
KernelEvery turn, so it stays smallSafety and process rules that apply everywhere
SkillsOn demand, when a task triggers themLong playbooks and repeatable procedures
Reference memoryWhen consulted, committed to the repoProject quirks, pitfalls, commands
Session hooksAt bootCheap startup checks and drift nudges
Sync scriptsWhen you run themImprovements moving between projects

The sorting rule that falls out of the split: when a lesson proves durable, ask which layer it belongs to. Discipline that applies everywhere goes in the kernel (rarely). A repeatable procedure becomes a skill. A project quirk goes to reference memory. Getting this wrong in either direction costs you: always-loaded rules you rarely need, or on-demand files the agent forgets to consult.

02What ships in the box

The template arrives with thirty-four skills, the installable playbooks an agent loads and follows (Expertise you can install covers them in full). The most important ones: recall, which routes durable project knowledge (pitfalls, commands, architecture) into committed reference files and consults them before unfamiliar work; verification-before-completion, which demands evidence before any claim that something works; systematic-debugging, which forces reproduction before fixes; caveman, the token-saving prose mode that Thinking on a budget unpacks; and init-project, the guided setup that configures a fresh project. Around the skills sit the session hooks: every boot re-asserts the active defaults and quietly checks whether the template has improved since the repo was spawned.

The box also holds a second agent. Claude Code gets the full system: kernel, hooks, skills, automation. Codex gets a deliberate boundary: its own instruction file and thin adapters that point to the same master skill files, generated by a sync script rather than maintained by hand. One source of truth for the playbooks; no leaked automation. Codex shares the same master skill files but not the automation, so it cannot inherit an auto-commit or hook rule that is unsafe in its runtime.

03Start fast, learn as a group

Setup is deliberately near-instant: create a repository from the template, open it, run one command, and be working inside 5 minutes. The initializer detects the languages and tools, asks a short round of questions about verification and deployment, seeds the reference files, prunes the skills that don’t apply, and commits the result. From the first turn, the new project has the full discipline installed. It starts senior.

The part that compounds is the sync. Spawned projects freeze the template at spawn date, but the template keeps improving, so a hook checks every 7 days whether the shared setup has drifted, and the sync skill closes the gap in both directions: pull the template’s improvements into the project, or push a lesson that proved generic back up to the template, where every future spawn, and every synced sibling, inherits it. That is the whole thesis in one loop.

“A gotcha hit once, in one repo, becomes firmware everywhere.”

Folklore evaporates; firmware accumulates.

Further reading

FAQ

Why keep the kernel small when the model could easily read a much larger rules file?

Because always-loaded files are a per-request tax: every rule in the kernel rides along on every single request, whether or not it is relevant. The discipline is keeping the level right: only safety and process rules that apply everywhere stay always-loaded; topical detail moves to skills and reference files that load on demand, and the template ships a script that measures the always-loaded token weight so bloat is visible.

What breaks when lessons live in chat transcripts instead of committed memory?

They stop traveling. A transcript stays on one machine and is gone when the session ends; the next session, the next repo, and the cloud sandbox all start dumb and relearn the same gotcha. Committed reference files travel with every clone, survive memory resets, and are read by whichever agent opens the project next.

Why does the template draw a hard boundary between the Claude Code and Codex agents instead of sharing everything?

Because automation is only safe in the runtime built for it: session hooks and auto-commit rules that are correct under Claude Code become unsafe commands if another agent inherits them blindly. So Codex gets its own instruction boundary and thin adapters that point to the same master skill files. The playbooks are shared; the automation stays with Claude Code only.

For your agent

A distilled, agent-ready version of this guide, not a skill. Copy it below, or point the agent at corewise.academy/guides/firmware-not-folklore.md.

file · guide.md firmware-not-folklore 81 lines · markdown
# AI Firmware as an agent boot layer Consult when setting up a new agent repo, or when deciding where a durable lesson should live soevery future project inherits it instead of relearning it. AI Firmware is a portable boot layer:a small always-loaded kernel, on-demand skills, committed reference memory, session hooks, andsync scripts. Distilled from the CoreWise guide `firmware-not-folklore`. Template lives at`github.com/ryanportfolio/AI-Firmware`. ## The five layers and where each thing goes Each kind of knowledge gets the cheapest home that still works. Always-loaded instructions are atax paid on every request, so keep the kernel small. | Layer | When it loads | What belongs there || --- | --- | --- || Kernel | Every turn, so it stays small | Safety and process rules that apply everywhere, only |

+ 65 more lines · the copy includes all of them

then save as .claude/reference/firmware-not-folklore.md
Sources

Original work by the editor, no video source.