02 Projects / Process sheet PS-03
AI-Brain Agent System
A private multi-agent system in daily operation: 19 recurring workflows, each with exactly one scheduled owner, executed by three LLM runtimes and a self-hosted n8n server on a single Markdown rule set, across two deliberately independent machines.
Purpose & scope
The question is not "can an agent do this"
A job search, a full-time data programme and several personal admin domains generate the same shape of recurring work: gather from a source, deduplicate against history, judge each item, write the result to the right file, lose nothing between sessions. By hand it does not scale. Handed wholesale to a chat assistant it fails differently, because an assistant has no memory between sessions, repeats work that is already done, and produces a plausible answer rather than reporting that it could not get one. So the design question was always the other one: how do you stop it from silently doing the wrong thing? That is what most of this system is made of.
Operation sequence · Routing
Six design decisions, in the order they matter
Each row is a rule that was written down first and enforced afterwards. The architecture is the deliverable, not the code.
| Op. | Decision | What it prevents |
|---|---|---|
| 10 | Rules live in plain Markdown | Any agent, any provider, reads the same canonical files at session start. No workflow is hostage to one vendor |
| 20 | One scheduled owner per workflow | Several agents write the same files with no database lock. Ownership is what stops two runs producing two conflicting versions of one report |
| 30 | Deterministic layer under the semantic layer | Python does the fetching, parsing, deduplication and writing; the model is handed only the judgement that needs judgement |
| 40 | Bounded agents | The agent gets the facts deterministically and decides inside a stated set of options, instead of being asked to both find the facts and decide |
| 50 | Gates that can fail the run | An output is not trusted because an agent said it was done. A run is finished when the checks pass |
| 60 | Watchdog on a fate-independent machine | A watchdog that fails together with the thing it watches reports nothing exactly when it matters |
Measured values · Countable from the system itself
What is actually running
What the five gates check
That every identifier claimed in a report exists in the registry and the archive. That no encoding corruption shipped. That a generated PDF is machine-readable in the right reading order. That no document claims a skill the source-of-truth file does not carry. That the prose does not read like a template.
Where the judgement stays human
Nothing is sent, submitted or published by an agent. The system prepares, verifies and records; the decisions that reach another person stay mine. That boundary is a rule in the same Markdown the agents read, not a habit.
Non-conformances · Found in operation
The failure modes are the real result
None of these came from reading about agents. Each was found by running one, then written into the rules so it cannot recur silently.
| No. | Failure mode | Corrective action |
|---|---|---|
| 01 | Fabricated metrics | An assistant generated specific, confident, quantified achievements that never happened, and offered them as interview material. Rule: a number is usable only if it exists in the source-of-truth file. Gate: flag any figure carrying a unit that appears nowhere in it. Specificity is what a fabricated metric looks like, not evidence against one. |
| 02 | Source echo | A drafting agent absorbs the vocabulary of the input document into its description of the person. Four documents shipped that way before a dedicated content gate existed; the sharpest check is three-way, matching a term present in the draft and in the source but absent from the master file |
| 03 | The verb escalates, not the noun | A documented method upgraded to "investigations I led" passes every keyword check, because the gates match terms and the claim lives in the verb. No automated check catches this class. It is recorded as a stated limit of the system, not as a solved problem |
| 04 | Silent scheduler outage | A dead scheduler and a healthy machine with no network produce the identical signal. The heartbeat has to distinguish the two rather than alarm on staleness, or it trains you to ignore it |
Acceptance · Stated limits
What I claim, and what I do not
The honest boundary
I designed, specified and operate this system: the architecture, the ownership model, the rules, the gates and the diagnosis of every failure mode above are mine. The code was written largely with AI assistance, not typed from scratch. Claiming to have developed a hundred-odd scripts would be false and would collapse in the first technical question. For work that is about making AI usable by other people, the accurate claim is also the stronger one.
Why there is no repository
The system operates a private vault holding personal and job-search data, so it is not published and will not be. It is demonstrable live by screen share: the workflow registry, a scheduled run's dated output, the gate scripts and their pass or fail result. The numbers on this page are countable from the system itself and move as it grows.
The interesting part is the guardrails.
Anyone who builds agents asks the same first question: how do you stop it from silently doing the wrong thing? That is what I would rather talk about, and it is what I can show running.