Building AI Pipelines
That Loop and Auto-Improve

The hard part was being fast and consistent at the same time. The app takes a recording, transcribes it, and returns a score against four Cambridge rubrics in about seven seconds. A parent will not wait much longer than that. A score that changes when you submit the same clip twice is worse than no score at all.

So the model no longer returns a score. It returns a transcript and four true or false answers: did the student cover each required point. Code turns those into the score, and caps it by length. Grammar and pronunciation stay with the model, because those are real language judgements. Same recording, same score tomorrow.

The hard part was running unattended code safely. A system that publishes to a real brand with nobody watching is a risk to that brand. So nothing reaches an audience until a person taps approve. The writer is fully autonomous. The publisher is not. That line is the whole design.

Why n8n runs the steps, and not the AI. The AI is not consistent about how it does a job. Ask it the same thing twice and it may take a slightly different route, and a slightly different route gives you a slightly different result. For writing a post, that variety is the point. For uploading an image, writing the row, waiting for the slot and calling the publish endpoint, it is a defect. n8n does those steps the same way every single time, and when one fails it fails in a named node I can open and read. So the model does the language, and n8n does the plumbing.

I built this inside a hardened container: a non-root user, no host folders mounted, no access to Docker itself, and a firewall that lets traffic out to about twenty domains it needs and blocks everything else.

# container egress: allowlist, then reject everything else
iptables -A OUTPUT -m set --match-set allowed-domains dst -j ACCEPT
iptables -A OUTPUT -j REJECT

# verified after every build:
#   example.com -> blocked   github.com -> 200   whoami -> claude

It also checks its own results. Twice a month the pipeline pulls the real engagement figures for the posts it published, compares each one against what it expected, and writes the answer back into the brief the writer reads next time. That is how it worked out that reels reach about four times as many people as carousels, and how it stopped chasing a Facebook reach figure that Meta had quietly retired. Nobody edited a prompt to teach it either. It measured, and the next brief changed.

The thing that mattered was never overwriting real data. The bot has to follow a conversation, work out what a repeating date rule means, and refuse to touch any slot that already has a booking in it. So the model never sees the calendar. It only turns a sentence into a rule. Turning that rule into real dates happens in ordinary code.

// "open Wednesdays 8pm through November"
{
  "action":   "open",
  "weekdays": ["WED"],
  "from":     "2026-11-01",
  "to":       "2026-11-30",
  "times":    ["20:00"]
}
// dates expand in JS, where a calendar bug is a failing test
// and not a parent booking the wrong evening.

The rule was that a reviewer must not be able to hide a problem. Every quality-control agent is defined without the tools to write files. It cannot fix what it finds, so it has to report it. Give a reviewer the ability to edit and it quietly patches the symptom instead. The report comes back clean, and the pattern never reaches the person who could change the process.

The field guide is generated from the real agent files, not written next to them, so it cannot end up describing a workforce that no longer exists. The illustration below is drawn from the same roster.

The problem is that a model starts every session knowing nothing. It works out again today what it already worked out yesterday. The obvious fix is to load the whole project at the start, and it is the wrong one. The vault is about 75,000 words. Loading it means paying to read all of it in order to use a paragraph of it, and that bill grows every week the vault does.

So there are two indexes, because two different kinds of question get asked. A knowledge graph answers questions about structure: what connects to what, which notes belong together, which few notes everything else hangs off. A vector database answers questions about content: what does the note on this subject actually say. Ask the graph which note. Ask the vectors what is in it. Think of the notes as the books and this as the index at the back that tells you which book to open. Retrieval gets more accurate as the vault grows, not less, because more notes give both layers more to sort on.

Two hooks make it automatic. One runs when a session opens and hands over the map and the open task list, so work starts already knowing the shape of the project. One runs when it closes and writes the session back out, so what was learned is still there tomorrow.

The store only rebuilds a note that is genuinely newer than the last build. The graph report opens by saying whether the vault is still small enough that I do not need a graph at all, which is the sort of thing a tool should be willing to say about itself.

$ python rag_query.py "how do we handle the human approval gate" --n 2

Top 2 results for: "how do we handle the human approval gate"

#1  [0.3927]  03-Claude-Brain/Social-Auto-Pipeline.md  (chunk 0)
    Goal: automate the work around a post, but never the
    decision to post. Every day n8n starts a run, a
    containerised Claude Code generates and self-QCs two
    posts, they land in the sheet as Pending approval, a
    human approves each from a phone, and n8n publishes
    only the approved ones.

#2  [0.3434]  2026-08-12b_hook-score-telegram-analyst....md (chunk 2)

The hard part is that print has no patches. A web page can be fixed an hour after someone notices. A print run cannot. Every claim in the book had to be true before the file left for the printer, and the layout had to survive being rebuilt from scratch late in the schedule.

The inside of the book is a text file. Typst turns it into a print-ready PDF, so a change from the editor is a small edit and a rebuild, not a person re-flowing 122 pages by hand. Four agents do the chapter work: one writes to the required Cambridge level, one reviews the writing, one places it into the layout, one checks the finished PDF. As everywhere else here, the reviewers cannot edit.

I did not write this book. The author is a former MOE teacher who runs the centre it came from, and the editor works with us. Their changes arrived as dated batches of marked-up screenshots, which I applied to the source. My side was production. The cover art was generated as two separate layers, the children and a faint Singapore skyline behind them, then put together in Photoshop, because the title area needed a person’s eye rather than another prompt. The back cover is built by the same pipeline as the rest of the book, barcode included.

Accuracy is where I was most suspicious. The pronunciation spellings for 158 words came out of a model, and eleven of them were wrong. A line claiming the book had QR linked audio was also invented, and cut, because the author’s material never mentioned audio. A “100 per cent placement” headline came down to the 97 per cent the records actually support.