Twelve AI specialists, one memory, and nothing forgotten between sessions.

Think of a small office where every desk has an expert: money, legal paperwork, the car, school, the next career step, software projects. They never talk over each other, they all write in the same notebook, and nobody is allowed to say "done" until an independent checker has seen the proof.

Lintel is that office, built from AI agents. You talk to it in normal language, from a desktop, from a phone, or over Telegram. It decides which expert should answer, that expert reads the notebook first, and whatever matters is written down before the conversation ends. Come back a week later, ask "where were we?", and you get the exact next step.

The router is the main session itself. An instruction file that loads in every session, in every working directory, holds the routing table: each specialist with its topics and the everyday phrases that should reach it even when the topic word never comes up. "Which job should I take" is career; "the light came on" is the car.

Two rules keep it predictable. When a request touches two domains, the one carrying a legal or payment deadline goes first. And the router never writes a specialist's memory file. It can read anything; it may only write the shared state.

Memory is a folder of Markdown files in git. Every project, area and long-running thread is one file with machine-readable front matter: status, priority, revenue, last_touched, next_step. The project board is generated from those fields and never edited by hand, so it cannot drift from its sources.

A session-start hook injects the live-state file into the model's context before the first word. It is capped in size and fails silently: a broken memory must never break a session. Anything older than 21 days and still "active" is flagged as stale.

The one rule the whole system enforces: if it wasn't written down, it didn't happen. Decisions go into a log with their reasoning the moment they are made, not at the end. A session closes with a fixed sequence: journal entry, update every touched file's next_step, update live state, commit. That is how desktop sessions, remote sessions from a phone and background jobs all share one memory without a database or a sync service.

More than one person in the house uses the system through Telegram, so it is multi-user in practice. Each person's Telegram account is routed to their own entry point, either a full assistant with its own file scope and its own conversation, or the AI-free notes inbox, and all of them sit on one shared memory. Telegram was chosen because the family already lives there; the interesting part is the contract in front of it: an inbox with three verbs.

No agent needs channel credentials, and swapping the channel means rewriting one adapter, not twelve agents. If the assistant judges a moment wrong for a question, the item is retried 30 minutes later instead of being dropped. Messages longer than one short sentence are sent as a Markdown attachment, a rule enforced in one shared module.

The assistant behind that channel runs with the least privilege that works: a fixed allowlist of files it may read, a single file it may write per shared specialist, no shell, none of the owner's settings, hooks or plugins loaded, and only messages from one known account are processed. The owner's own notes bot goes further and has no AI at all. It appends what it receives to a file and replies "noted"; the next session processes the notes. A chat account that can only write into a queue has nothing to leak.

The QA agent exists because of a specific failure. In a mobile project a memory leak was "fixed", the check reported zero, and the app still died on the device for two more builds. The test double didn't behave like the real library, so the test was testing itself.

So the gate is independent of the session that wrote the code, and it works to fixed rules:

• A fix is proven by a failing test. In a throwaway git worktree the fix is reverted, the test is run, and it must fail. A test that never fails is blind, and blind means FAIL.
• Read the real thing behind every stub. A mock has to model the library code it replaces, not the library's function names.
• Run the tests yourself. "Tests pass" from the developer session is a claim, not evidence.
• Hardware-only evidence gets an honest verdict. When proof needs a hand on a device (touch, sound, a purchase), the gate writes one precise test scenario for a human and records UNPROVEN until the result comes back.

In its first 12 days the gate logged more than 100 verdicts across apps, sites and the system's own scripts. About 4 in 10 were FAIL and another 2 in 10 UNPROVEN. That ratio is the point: a gate that always says PASS is decoration.

The memory holds a family's real life, so privacy is architecture, not a setting.

• No remote. The git repository has none, by rule. Backup is a full git bundle, verified, then AES-256 encrypted with file names hidden, written to an external disk. The last six are kept. The password is never written anywhere the system can read.
• No secrets in memory. Passwords, keys and card numbers never enter the vault. A reference file records only where a secret lives, never its value.
• Least privilege per agent. Each specialist writes one file. Shared specialists reach another household member's assistant through scoped sub-agents with their own allowlists.
• Read-only automation. The school-portal watcher drives a headless browser like a parent would and listens to the JSON the pages already load. It never opens a message, because opening leaves a "seen" mark. It compares the unread count before and after every run and raises an alarm if the count drops.
• Narrow egress. Children's data never goes into a web query. Outbound news alerts carry public headlines only. No API keys anywhere in the system: agents run on a consumer subscription through the official CLI.

A recurring line through the system: if a step must be identical every time, it is code. The daily news scan lets the model do one thing, search and return JSON; deduplication, file writes and notifications are deterministic Python. The portal watcher and the statement parsers use no model at all. Where behaviour is a policy rather than logic, the rule lives in Markdown that the specialist owns and the script reads at run time, so changing a rule never means changing code.

Claude Code (sub-agents, session hooks, slash commands) on a consumer subscription · Markdown and YAML front matter · git · Python, mostly standard library, about 14k lines including tests · Playwright, headless · OS task scheduler · Telegram Bot API as today's chat channel · iCalendar feeds.