Context by patterns: one fact, one place, five layers
Sergei Pak · designs AI operating systems · русская версия
What breaks a system is copies of the same knowledge scattered across different places. Two wordings of one term, three versions of one schema, a project status kept in four documents. Each copy drifts on its own, and a month later the system argues with itself. I build AI operating systems and keep them whole with one rule: every fact has one canonical home, and every level of logic has its own form of record. That's context by patterns.
One fact, one place
The definition of the term AIOS lives in a single config file on my side. The site, the schema.org markup, the blog posts, the pages for the finance lead and the accountant all read the wording from there. Nobody paraphrases it: a paraphrase is already a second version, and two versions of a term crumble its meaning for the reader and for search engines alike.
The same pattern runs lower in the stack. The database schema exists only as migration files, 52 of them right now. You can't write CREATE TABLE straight in the code: an automatic guard blocks that commit. The site's colors and typography sit in one token file; when I needed a dark footer over the «paper» pages today, I didn't repaint the footer. I declared a ten-line token island, and everything inside recolored itself.
The rule is boring, but a change gets made once and lands on every surface, consistently.
A map, not the content
The second pattern: the top level of the system stores pointers, not texts. The root file of my working system, read at the start of every session, is 87 lines. The reference docs count 93 files. The map holds routes only: editing a connector, open this doc. Content loads when needed, and tokens don't burn on ballast.
Project memory works the same way. Each project's status is one line in an index, the body sits in its own file. A project snapshot for the headquarters is capped at 35 lines: status, role, risks. The full operations, contacts and correspondence live in the project's own module, and the headquarters queries them on demand instead of keeping a copy.
Layers create consistency through boundaries: each one knows where to ask and doesn't drag someone else's knowledge home.
Five layers of one system
I assemble an AIOS in a fixed order of layers: context, data, intelligence, automation, assembly. The order encodes dependencies: intelligence without a data layer hallucinates, automation without context automates chaos.
On my own system it looks like this. The data layer is 64 connectors, and applications reach the databases only through them. The intelligence layer is a single gateway for all LLM calls: it picks the model by task complexity, caches, and logs the cost. Because of that single entry point, a local model on an ordinary Mac handles 81% of requests, and the weekly bill for cloud calls stays around a dollar and a half. The automation layer is decisions: everything built and waiting for my «yes» gets collected by a script into one inbox and lands in Telegram at 8:45 every morning. The list holds 23 items today, and I close them with one tap instead of digging through four chats to recall what's stuck where.
The pattern repeats at every zoom level
The most useful property: the same patterns work at any scale. The repository as a whole is «a map plus content», a single project inside it is too, so is a single document. The request form on my site is one component with two skins: a strict one for the classic view and a handwritten one for the pinboard. The submit logic is shared; only the presentation layers differ. When I fixed seven site defects in one session today, each fix went into one place and didn't break the neighbors: layer boundaries keep changes local.
Client installs rest on the same thing. A personal AIOS lands on a laptop in one day because the client's context is assembled from a ready template: who the person is, which processes, where the data lives, who decides. A division head from the road-construction industry was building the financial model for a new plant inside the system by week two. The one-day install comes from layers laid out in advance: knowledge about the business drops into a ready structure, and nobody invents the structure on the fly.
Context assembled by patterns makes the system predictable: it acts as one whole because it stores no contradictions. And the final word stays where it always was: the person leads, the system works.
FAQ
- What does «context by patterns» mean?
- Every kind of knowledge in the system has a canonical home and a fixed shape: definitions in one file, the data schema in migrations, project statuses in snapshots of a set size. Every part of the system reads the fact from the canon instead of keeping its own copy. Change it once and it changes everywhere, consistently.
- Why split the system's logic into layers?
- A layer is a boundary of responsibility: the map apart from the content, data access apart from the apps, the definition apart from the presentation. The top layer holds pointers only and stays short; details load on demand. That's how the system grows without sprawling.
- What does this give you in practice?
- Cheap changes and predictable behavior. One example: all LLM calls go through a single gateway, so a local model handles 81% of requests and the bill stays around $1.5 a week. A client install takes one day because the context is assembled from a ready template rather than from scratch.