Most AI agents I used to build were frozen on day one. I write a system prompt, the agent produces drafts, I correct the drafts, and the next day the agent makes the exact same mistakes. All my feedback improved one output and then evaporated.
I’ve been reading Thinking in Systems by Donella Meadows, and it gave me a better way to see this problem. My agents don’t have a learning problem. They have a missing feedback loop. The information exists (my corrections), but it never flows back into the thing that decides behaviour (the system prompt).
So here’s the idea this post works through: let user feedback edit the system prompt itself. A second agent reads the feedback, compares it with the current prompt, and adds, removes or rewrites specific lines. Every round of feedback leaves the agent slightly better than it was. I’ll map it in Meadows’ language of stocks, flows and loops, then sketch how I’d build it in n8n for a YouTube script-writing agent.
Meadows in two minutes
Meadows describes every system with three building blocks:
- Stock: something that accumulates and can be measured at a point in time. Water in a bathtub, money in a bank account, trust in a relationship.
- Flows: the rates that change a stock. The tap is an inflow, the drain is an outflow. A stock only changes through its flows.
- Feedback loops: information about the stock that adjusts the flows. A balancing loop pushes the stock towards a goal (a thermostat). A reinforcing loop amplifies whatever is happening (compound interest).
Two more ideas from the book matter here. Stocks change slowly, so they act as buffers and give a system memory. And the information in a loop always arrives with a delay, which is where most system misbehaviour comes from.
Mapping it: what flows where
My first mapping was wrong, and the way it was wrong is instructive. I said the system prompt is the stock, user requests are the inflow, and the outflow is “% of outputs that came out right”.
Meadows gives a simple test: a flow must change the stock. A user request doesn’t change the prompt. An output doesn’t drain the prompt either, because the prompt is read, not consumed. Requests and drafts are a separate pipeline that the stock drives. And “% correct outputs” isn’t a flow at all. It’s a measurement of how good the stock currently is, which makes it the information a feedback loop reads.
The cleaner picture has two stocks, chained together:
- Feedback backlog. Inflow: comments the user leaves on each draft. Outflow: comments the editor agent has processed, either turned into a prompt change or set aside as a one-off.
- The system prompt (its rules and examples). Inflow: lines added or rewritten. Outflow: lines removed because they were wrong, outdated or superseded.
The prompt then drives draft quality, draft quality decides how much the user has to correct, and that sets the inflow of feedback. That closing link is the loop.
Requests and outputs don’t appear here at all: they pass through the system without changing either stock.
Two loops, not one
I started out calling this a reinforcing loop. Looking closer, the main loop is balancing, and that’s good news.
The balancing loop (the engine). The goal is a draft I’d use without edits. The gap between that goal and the actual draft produces feedback. Feedback produces prompt edits. Edits shrink the gap, so feedback slows down. It behaves like a thermostat: lots of correction early, then a system that settles near my taste. If the feedback rate isn’t falling after a few weeks, the loop is broken somewhere.
The reinforcing loop (the fuel). Better drafts make me use the agent more. More use means more drafts, more feedback and more edits, which makes drafts better again. This is the loop that decides whether the system grows or quietly dies. An agent that’s annoying in week one never gets enough feedback to become good.
There’s a second reinforcing loop hiding in here, and it’s the dangerous one: every correction adds a line, and lines rarely leave. Left alone, the prompt grows until rules contradict each other and the model starts ignoring half of them. That’s why the outflow (removing lines) has to be designed in from day one, not bolted on later.
Worked example: a YouTube script agent
The script agent takes a topic plus research notes and writes a first-draft script. The trick that makes automated editing safe is to write the prompt as numbered, addressable lines grouped into sections, so every change is a small, reviewable diff rather than a rewrite.
[ROLE]
R1. You are a YouTube scriptwriter for an educational channel.
[STRUCTURE]
S1. Open with a hook in the first 15 seconds.
S2. Use three main sections, each ending with a mini-payoff.
[VOICE]
V1. Write in plain, conversational English.
[EXAMPLES]
E1. Good hook: "Most people practise guitar wrong, and it's not their fault."Here’s how four pieces of feedback from one week would flow through the editor agent:
| Feedback on a draft | Editor’s reading | Change to the prompt |
|---|---|---|
| “Hook is a question again. I hate question hooks.” | Durable style rule | Add S1a. Never open with a question; open with a claim or a surprising fact. |
| “Too formal. Sounds like a textbook.” | Durable, conflicts with nothing, sharpens V1 | Rewrite V1. Write like you’re explaining to a friend over chai: short sentences, contractions, no jargon. |
| “This one should be 4 minutes, not 10.” | One-off, specific to this topic | No change; logged and discarded. |
| “Third time: the sections don’t connect.” | Repeated, structural | Add S3. End each section with a line that sets up the next. Add E2, an example transition from an approved script. |
Notice the range. Some edits are tiny (one example), some sharpen an existing rule, and in a month a pattern of feedback might justify changing R1 itself, say from “educational channel” to “guitar teacher talking to self-taught players”. The editor’s most important skill isn’t writing rules. It’s telling a durable preference from a one-off request.
Building it, and why I chose n8n
This loop doesn’t depend on any one tool: you could build it on another automation platform or in plain Python. I chose n8n, a visual automation tool where you connect boxes on a canvas instead of writing code, because it’s easy to follow and a non-technical person can build and change it too. Three things make it a good fit:
- You can see the loop. The whole system sits on one screen as boxes and arrows, which looks a lot like a Meadows diagram.
- Agents can be chained. One AI agent’s output can become another agent’s input, so a writer agent and an editor agent can work as a pair.
- The prompt lives outside the agent. Instead of being typed into the agent, the system prompt sits in a simple table. That one choice is what lets a second agent read it and change it.
The system is three small workflows:
- The writer. I send a topic on Telegram. n8n pulls the current prompt from the table, the writer agent drafts a script, and the draft comes back to me.
- The listener. I reply to the draft with what I didn’t like. n8n saves that comment to a feedback list. This is the backlog stock filling up.
- The editor. Once a night, the editor agent reads the new feedback, the current prompt and the drafts the feedback was about. It proposes changes in plain language, like “add a rule: never open with a question” or “skip the 4-minute request, it was a one-off”. I get a yes/no button on Telegram, and only approved changes go into the prompt table.
A few simple guardrails keep it honest: no more than three changes a night, and any change to the agent’s core role always needs my approval. Every change is also logged with the reason behind it, so a bad edit can be undone and I can read the prompt’s history like a diary.
The traps Meadows would warn me about
The book’s most useful chapters are about how systems misbehave. Four of them map almost exactly onto a self-editing prompt.
- A stock with only an inflow (prompt bloat). If the editor only ever adds, the prompt grows without limit. Fix: give the outflow equal status. Every run, the editor also asks “which line hasn’t been relevant to any feedback in 30 days?” and “which two lines say the same thing?” Set a hard ceiling, say 40 lines, so adding a line past it forces a merge or a removal.
- Overshoot and oscillation. Meadows’ thermostat examples show what happens when a balancing loop reacts too strongly to delayed information. Here: “too long” → editor slashes length → “too short” → editor adds length back. Fix: batch feedback instead of reacting to each comment, cap changes per run, and have the editor read the changelog so it can see when it’s about to undo its own previous edit.
- Drift to low performance. If I get lazy and stop giving feedback, the balancing loop goes quiet and the system looks converged when it’s actually just unwatched. Fix: track the feedback rate and the share of drafts I use without edits. A falling feedback rate is only good news if usage is steady.
- Seeking the wrong goal. A system optimises for what it measures. If the editor’s only goal is “fewer complaints”, it can learn to write bland, safe scripts nobody complains about and nobody watches. Fix: keep a handful of golden topics and re-run them after each change, judging them against what I actually want (hook strength, retention structure, voice), not just the absence of criticism.
One more Meadows idea worth stealing: the leverage points. Tweaking examples is a low-leverage change. Changing the role line, or the goal the editor is optimising for, is high leverage. That’s exactly why those changes should need a human’s approval.
Closing thought
The biggest shift Thinking in Systems gave me is this: a system prompt isn’t a document you write once. It’s a stock, and like every stock, its level is set by its flows. If corrections never flow in and stale rules never flow out, the agent stays exactly as smart as it was on day one.
I’m building this first for my own script-writing agent. The plan is to run it for a month and watch two numbers: how much feedback I give per draft, and how many drafts I use without edits. If the theory holds, the first should fall and the second should rise. I’ll share what actually happens, including where the loop misbehaves.