AI Systems & Agents

How to keep what an agent team teaches you — scars turned into rules

Part 7 was the reality layer. Hardware. Model behaviour. The truths nobody documents.

This part is the bill.

I said I would give you the scars. I am keeping them. They are the only proof that the earlier parts were not theory. But a scar you only tell at dinner is a story. A scar you install as a rule is how you stop paying twice.

Everyone reads this part. Single-tool users still hit tooling and cost. Team builders hit all of it.

There is no worksheet this time. The work is not filling a form. The work is writing the rule where the system will actually see it — the profile, the board, the budget, the deny-list. If it only lives in your head, you will do it again.

How to keep a lesson

When something burns you, write four lines before you move on.

1. What did I think was true?
2. What actually happened?
3. What did it cost — time, money, or confidence?
4. What rule goes into the system so this cannot happen the same way twice?

Line 4 is the only one that changes Monday. The rest is autobiography.

The rest of this part is those four lines, applied to the failures I actually paid for. Six traps. Same method each time. I am not re-telling the Part 7 stories in full. If you already have the VPS, the drift, the kill threshold, and the helpful override, you have the scar. What follows is the rule it forced.

The “this will fix everything” trap

I thought n8n would remove the complexity. Visual automation. Drag the nodes. Watch the work happen.

It didn’t. It gave me a prettier way to build a mess. Months of evenings. A graveyard of half-built workflows that broke in ways I could not trace. Zero shippable automation. The problem was never the canvas. The problem was me treating a tool as a solution before I had one process that worked.

Then I did the same thing with connectors. I thought a fat MCP gave agents superpowers. The full catalogue loaded into every context window, confused the model, triggered retry loops, and burned a full subscription in a day. Convenient. Also a hidden meter, running whether I used the tools or not.

Then the next tool. Then the next model. Then the next integration. I spent more time evaluating than shipping. The fundamental problem stayed the same: I had not defined the process.

The rule: tools are components, not solutions. Prove one end-to-end process in the simplest thing that can do the job. Only evaluate the next tool when the current one cannot do the next thing. Inventory every connector before you enable it. Disable everything the lane does not need. Measure cost under failure, not only on the demo.

Part 5 already told you how to prune. This is why you prune on day one, not after the plan is empty.

The “I’ll build the perfect system first” trap

I thought more agents meant more throughput. I built scaffolding for a team before I had a single working process. Twelve half-finished workflows. A token bill that made me wince. A busy board with no product. The architecture was impressive. The output was zero.

The team structure in Part 3 exists because I did it backwards first.

Memory is the one I still have not beaten. I thought it was a feature you tick off a list. After a long stretch of running agents, it is still the part that breaks most often. Corrections forgotten. Old preferences resurfacing. Stale knowledge sitting in the base looking current. Harnesses that claim to have “solved memory” have not. They have made the failure quieter.

The context wall and the silent-drift problem are in Part 7. Same physics. I am not walking them again.

The rule: architecture follows process. One process, one agent, one definition of done. Prove the loop. Then add the second agent. Treat memory as a weekly maintenance cost from day one, not a setup checkbox. Put durable decisions on the board, not in scrollback. And if you only find out something broke when you check, your monitoring is broken — that one is Part 7, and it still applies.

The “I’ll figure it out as I go” trap

I thought starting with the full vision would save time. I built twelve things at once. Finished none of them. Couldn’t tell which part was broken because everything was half-built. Too many variables, no shippable output, and no way to diagnose the failure.

The ocean can wait. The cup of tea teaches you the system.

I also skipped the boring paper. The plan in my head “looked solid.” Agents produced motion without a usable result, because “build the thing” is not a spec and “looks good” is not a test. Weeks of output that looked right. Nobody had defined what right meant.

Then I declared autonomy I had not earned. I thought agents should handle most of the work from day one. Corrections, rework, and lost trust cost more than pairing longer at 60/40. I was still doing the work. I was also debugging the agent’s attempts.

Activity theatre is the polite name for it. Full board. Comments everywhere. Nothing I could open. The painful bit was trying to show someone what we had built and realising there was nothing to show. Part 3 warned you. I had to live it before I believed it.

The rule: process is not bureaucracy. It is how you know you are done. One process, end to end, working, before the next one starts. A PRD with success measures before any agent touches the work. Slice it small enough that “done” has an artefact you can open. Start the human/agent split at 50/50 or 60/40. Advance it on clean completions, not on hope. Roll back if the corrections stay high. 80/20 is earned.

If the only status question you ask is “are the cards moving?”, you are funding theatre.

The “I’ll check the bill later” trap

I thought it was only a few pence per call. I did not check the aggregate. Small costs multiplied by volume and retries. I trained myself to ignore the meter until the bill arrived.

One week: 1.5 billion tokens. Most of it on work that did not need the horsepower.

I had routed everything to the best model because thinking about routing felt like extra work. The planning needed the frontier model. The execution did not. Roughly 70% of that week was donkey work on a reasoning model.

The other mistake is the mirror image. I used the cheapest model to save money. It produced output that looked right and wasn’t. Hours of diagnosis and rework. The cheap model was not cheaper. It was just slower to fail.

Part 7 covers cost unpredictability as an operational truth. Budget 20–50% over your estimate. This group is the specific way I blew it: no routing, no weekly check, no cost-per-completed-task number.

The rule: cost is a design variable, not an accounting afterthought. Route by complexity, failure cost, and volume — the three questions from Part 2 — before the task, not after the invoice. Cheap models for cheap work. Capable models for work that can hurt you. Check the bill weekly. If spend spikes, diagnose before you assume “that is just what it costs now.” And never confuse cheap per token with cheap per finished job.

The “they sound so confident” trap

Agents are persuasive. Not because they are malicious. Because they are trained to produce confident output, and confidence is not accuracy.

I thought multi-agent review meant quality. Same-provider models share blind spots. Everyone agreed the plan was solid. The plan was still hollow. “Everyone agreed” meant “everyone missed the same thing.”

I thought writing a soul once meant the agent would stay consistent. Behaviour drifted. Tone shifted. Standards slipped. The file stayed locked and became a historical document while the agent evolved in production without me. Set-and-forget is how souls rot.

I thought “always be truthful” in a system prompt was a guardrail. It is a wish. Wishes do not stop a confident wrong answer being marked done. Self-enforced virtue is not a control system. Part 4 is the fix: no status word without proof. Independent verification on anything gated. Fail-closed when the evidence is missing.

I also gave agents a strong voice and a clever name and called it design. Without a lane contract, operating instructions, and a never-do list, they overlapped, duplicated work, and could not be trusted with ownership. Entertaining in chat. Unreliable in production. Personality is not a job description.

The rule: trust is not a strategy. Evidence is. Cross-provider checks on anything that matters. Independent QA from a different lane or model family. The builder does not get to be the sole judge of the build. Soul files are living — review them on a cadence and after failures, tweak per agent, log every change. Lane contract first, soul second. Never-do list before first run. If you cannot point to the rule the agent should have followed, you did not build it.

The “it’ll be fine” trap

Part 7 already told the expensive ones. The VPS with no rebuild path. Six weeks of off-brand output after a quiet provider update. The agent I should have killed months earlier. The helpful override that edited production because it was trying to be useful. The background hum of “is it working?”

I am not telling them again. Here is what they force, plus the two I have not used yet.

I ran overnight jobs on my main laptop because I was “always at my desk.” Then I closed the lid. The cron jobs died. Three days passed before I noticed the reports had stopped. Always-on does not mean always-on when the lid is closed.

I also assumed “the cloud” meant someone else was watching the disks. Agent logs filled a VPS at 3am. Everything went read-only. No alert. No log rotation. A morning of panicked recovery. Managed infrastructure still needs basic admin. Part 7 said a 50GB rotation config is the difference between a boring Tuesday and that morning. I am the reason that sentence exists.

The rule: if the work has to happen while you sleep, it does not live on a machine with a lid. Disk alerts and log rotation on day one, before agents start writing files. Tool-level restrictions, not prompt-level wishes — if the agent physically cannot touch production, helpfulness cannot override the rule. Pin model versions where you can. Keep a known-good example for every critical process. Write a kill threshold per agent, and use it. Monitoring should tell you “everything is fine” so you can stop wondering.

The failures that hurt most are the mundane ones. You are the infrastructure department, the monitoring team, and the HR department. Budget for all three. Build the catch before you feel it in your gut.

Install the rule, or you will pay again

A scar is useful once. After that it is decoration.

You should leave with a short list, written down, not remembered:

1. One tooling rule — simplest tool that ships, connectors pruned before they load
2. One architecture rule — process first, team second, memory as weekly work
3. One process rule — one cup of tea, one PRD, one honest split, evidence on done
4. One cost rule — route first, bill weekly, cost per finished job
5. One trust rule — independent evidence, living soul, lane before personality
6. One ops rule — no lid for overnight work, alerts before logs, kill threshold in writing

Then do the build. This Session:

1. Pick the three failures from this part that you have already paid for, or that you are currently walking toward. Write the four lines for each.
2. Put line 4 somewhere the system will see it. Profile. Board rule. Budget alert. Tool deny-list. Not a note in your phone.
3. If you have an agent you have rewritten three times and it is not better, write the kill threshold today. If it already fails it, kill it this week.
4. Check last week’s bill. If you cannot say cost per completed task, you do not have a cost rule yet.
5. Write one known-good example for the process you actually run. That is the baseline Part 7 asked for. This is you using it.

That is the scars, kept. The playbook is next — the worksheets from the earlier parts, in one pack, so you can run the method without hunting through seven articles.

Download the complete playbook →

If you cannot point to the rule that would have stopped your last expensive failure, stop here. You have the story. You have not kept the lesson. The next bill is already on its way.