Intelligence at the core, for one person

The files every agent reads

Every tool gives you somewhere to put this and every one calls it something different: custom instructions, project files, a rules file, memory. Mine is a folder of plain text files that all of them read.

All ten load before I type anything: who I am, how I write, what I won't write, what's protected, what I refuse, and the checks on finished work. 249KB, every session.

That is a deliberate trade. I want every tool to start from the complete identity layer. The deeper context beneath it still loads only when the task calls for it.

I counted 443 instructions in the seven-file load on 20 August. All ten now load, so the current count is higher.

~/os/
├── identity/    10 files. All 10 load every session (249KB): who · direction ·
│                comms · boundaries · energy-and-rhythm · situational-rules ·
│                values · writing-blacklist · draft-check · interests.
├── context/     on demand: the IP, the people, the tool stack, the
│                page doctrine, and a corpus of my own sent writing by register.
├── skills/      the procedures
├── agents/      the specialists
└── templates/   reusable structures

One core, two roots

Work and the rest of life run off the same core, into separate roots. The wall is one-directional: personal detail never surfaces in a work artefact or on a public page.

That wall is a written rule in the always-loaded layer. Nothing enforces it.

Reading a rule is not running one

I read my own writing rules end to end, then drafted 1,245 words and sent 721. Reading them changed nothing about what got written.

So they stopped being a document and became small programs that run on their own, at fixed moments. Six of them.

Two are reflexes: they run automatically, at the start and the end. One loads the record before I type. One files anything worth keeping when I finish, and saves the day's changes.

Four are gates: they sit in the way of anything leaving. One won't let the private files be pushed anywhere from this tool. The other tool I run has no equivalent. One won't let a page go live if it's missing a version stamp or the right privacy setting. Two check what I've written against my own writing rules before it goes out, including email, which never gets saved as a file to check.

SessionStart            → session-context.sh      loads ~/os/identity/ + today's date

Stop                    → session-reflect.sh      proposes durable filings;
                                                  git-commits ~/os. Loop-guarded,
                                                  debounced to once / 30 min.
                        → comms-gate.sh           scans the finished turn for an
                                                  unsent draft. High-precision
                                                  markers only (a sign-off, a
                                                  quoted draft, a Subject line).

PreToolUse(Bash)
  if Bash(git *)        → git-push-guard.sh       DENY  push or remote-add in ~/os
                                                  ASK   any other git push
  if Bash(git commit*)  → artefact-audit-guard.sh audits the working tree across
                                                  the three site repos; DENIES the
                                                  commit on a failed house standard.
                                                  Fails OPEN on its own errors so it
                                                  can never brick committing; closed
                                                  only on a real audit failure.

PostToolUse(Write|Edit) → draft-check.sh          injects the checklist the moment an
                                                  outward artefact is written.
                                                  Silent on notes, memory, code.

The loop needs something to reflect on

A reflex with nothing to read files nothing. Through the day, observations, decisions and loose ends go to a daily note, a running log, a signal inbox and a jobs list. The end-of-session filing goes to a memory store: one fact per file, a one-line description on each, links between them, under an index that loads at the start of every session.

The methods load with the task

The procedures sit dormant until their task comes up: how I draft an email, scope a proposal, design a teaching session, write a long piece, plan a day, run the Friday audit. The specialists get called by hand for a specific job: a reviewer, a sparring partner, a financial view, an academic panel, a researcher. Flat, with nothing routing between me and them.

Writing one of these does not install it. Authoring is not installing.

Then wire it to where the work is

Notion, mail, calendar, the drive, the books, the domains, the sites. A connection amplifies whatever the setup already is.

What comes out is a page

Output is a page. Owned, addressable, version-stamped, routed by who should see it, from fully public down to gated behind a login. This one is an instance of it.

Keeping it true

It all sits in version control. When a fact sharpens I overwrite the one live source and let history hold what it used to say. No stale second copy quietly steering the work.

This page has been wrong. On 6 August it described three hooks while six were running, claimed a specialist that had never been installed, and left the memory store out entirely.

The record travels and the guards don't. Hooks and permissions are configuration, and configuration stops at the tool it was written in. Run your core through a second tool and it arrives with none of them.

One of mine doesn't run in the tool it was written in. The rule that every outward draft gets reviewed before I see it needs the tool to call a second agent, and a session that won't do that on its own leaves the rule written and not running. I found it on 20 August, in a session that had just rewritten this page's opening.

Run it against yours

This whole page is a file. Put it into your AI and have it score your setup against the nine checks: where you sit on each, and what to build next.

1. The record. Outside the tool, in files you own, with a small always-loaded layer separate from a deeper on-demand one?
2. The wall. One core covering everything, with your domains held apart by a rule rather than fragmented into separate systems?
3. The reflexes. Context loaded at the start and durable facts filed at the end, without you asking?
4. The gates. Your own standard running against finished work, before anything publishes?
5. The journal. Something real for the loop to reflect on, and a linked store the filing goes to?
6. The methods. Recurring moves packaged to load on demand, and specialists you call by hand?
7. The connections. Wired to where the work already is, and wired after the core was right?
8. The output. Arriving as an owned, addressable, version-stamped page?
9. Canonise. One live source, overwritten when it sharpens, no stale second copy?

10. The discipline of the core itself. I left this one out because nobody had finished it. Measuring my own for two weeks gave it a shape, and I fail four of the five parts today.

• A budget. The seven-file load counted 443 instructions on 20 August, against the 150 to 200 a current model follows well. All ten files now load. Failing by deliberate choice.
• A ceiling. The index that loads every session sits 1,525 bytes under the point where its tail stops loading, and nothing tells you when it does. Close.
• A copy somewhere else. Mine is on one machine, deliberately, because the core holds confidential material. It is still one machine. Failing.
• Enforcement in every tool you run. The guard that stops the private core being pushed exists in one of the two tools I use. Failing.
• A link check. Two procedures written three days ago are invisible to every session, because writing a file into the folder is not the same as installing it. Failing.

Then run it again once it has grown

The nine checks ask whether you have the thing. Later the question is whether you have too much of it. These files grow one rule at a time: the agent gets something wrong, you add a rule, nobody takes one out.

Same move. Put this page into your AI and ask for the cut.

1. Count what loads every session. Instruction units, not files. Under 150, stop here.
2. Find the contradictions before cutting anything. Two rules that can't both hold make the agent unpredictable, and they are why people say it ignores them.
3. Keep only what changes most answers. The rest moves to the layer that loads when its task arrives.
4. Delete four kinds. Already said elsewhere. Vague. A file path, which will drift. And anything the model already does on its own, which you test by running it, because arguing about that one is arguing about the default.
5. Delete a ban with nothing beside it. Naming what to avoid makes it more available. State the target instead.

When the agent gets something wrong, ask it why it decided that before you write the rule. Half the time what was missing is a fact.