TL;DR: Every time an agent gets something wrong, the correction has to go somewhere. It might become a written rule, a control that blocks automatically, a judgement delegated to another agent, or a fact with an expiry date. Working out which one it needs is a real skill and I spent months experimenting with how that classification actually works.
There is a framing going around at the moment that we are all managers now, managers of agents, and that you should onboard an agent the way you would onboard your best hire. Give it context, tell it what good looks like, check the work.
I agree with all of that. What I would add is that the interesting part starts after the onboarding, because "give it feedback" is doing a surprising amount of work in that sentence. Every correction has to go somewhere. In my system there are several places it can end up, they do different jobs, and putting a correction in the wrong one turned out to be its own kind of failure.
I run a system I call Juno, a supervisor that coordinates a set of agents across recurring workflows with review gates, validation, governance protocols and a memory layer. I've been building it since January. The loops are only weeks old, but the rules, reviewers, validators and accumulated decisions beneath them have been developing for months.
I eventually realised I wasn't building a workflow system so much as an architecture of judgement - a structure that determines which decisions become rules, which become controls, which are reviewed and which remain contextual. The more the system evolves, the less I think about prompts and the more I think about where judgement should live.
Where things actually go wrong
The mistakes themselves are rarely dramatic. One agent reports a piece of work as complete because the customer replied, even though the reply is asking for more work. Another assigns ownership to a collaborator nobody mentioned. A third encounters a genuine gap in the source material and quietly fills it with something plausible.
None of these are spectacular failures. They are the sort of things that look completely reasonable until someone checks them, which is probably why they are so useful. The system is constantly producing little thought experiments about what should have happened instead.
For a long time I treated all of these mistakes in roughly the same way. I added another instruction, rewrote the prompt, added another example, and occasionally convinced myself that this version would finally settle it. It usually did, for a few days. Then the same underlying problem came back wearing a different hat.
I eventually realised that I was solving the wrong problem. The issue wasn't that the agent had made an error, my mistake was that I had not decided what kind of correction it was.
One correction, several forms
Take the invented collaborator, because it is the one that taught me the most. An agent decides that a task probably involves two people and writes in a name nobody gave it. The confidence with which it invented this person was almost touching.
The obvious move is to tell it to stop. I did that, and it held until the next agent, or the next task shape, or the next week. Eventually that correction ended up in several different places.
Part of it became a written rule carrying the reasoning behind it, which is what allows the principle to travel to cases I never thought to describe explicitly. Part of it became a list of forbidden values, so words like "team", "engineering", or "various" could not be entered as owners at all. Part of it became a validator that failed the record and stopped the process automatically. And part of it became a reviewer's job: look for ownership that appears inferred rather than evidenced.
Nobody designed that as a set. It accumulated, one correction at a time, and the shape each one took was a decision I made in the moment, usually without noticing I was making it.
What surprised me was that the same correction was doing different work depending on where it lived. A written principle can explain itself. A control can enforce itself. A validator catches the patterns it already knows about. A reviewer catches the version nobody anticipated. Once I saw that, I stopped thinking about prompts and started thinking about judgement.
The correction that changed my mind
The clearest lesson came from a rule that was completely correct.
I did not want a particular kind of machine-sounding sentence getting into anything I publish, so I wrote a check that scanned every file and blocked the pattern automatically. For a while I was delighted with it. Then it started blocking long essays, and eventually it started blocking my own archive files, because they contained perfectly legitimate uses of exactly the same construction.
The check had identified the pattern correctly, which was what made the failure so confusing. It was catching exactly what I had told it to catch. What it could not do was judge whether the pattern had earned its place in that particular sentence, and that turned out to be the only question that mattered.
I had treated a judgement as if it were a rule.
Once I saw that, the fix was obvious. The check could warn, but it could not decide. It still runs, and it still warns, but the final judgement moved to a reviewing agent that reads the whole piece and argues with me in prose. The note I left in the file was short: the reviewer is authoritative, the pattern check is advisory.
I think about that distinction constantly now, because it applies to far more than writing. A surprising number of organisational problems are really judgement-placement problems.
The question I ask now
The question is no longer "can this be automated?"
It is "what kind of judgement is this?"
Some judgements are absolute. UK spelling. A field that must never contain the word "team". A date that has expired. Those are cheap to automate because there is no meaningful discretion to preserve.
Others are not. Does this sound like me? Is the customer actually finished? Is this number old enough to be dangerous? Those are contextual judgements. A competent reviewer could reasonably disagree, and that is precisely why they should not be reduced to a pattern.
The interesting thing is that the same system can contain both. The agent that checks factual freshness runs on the smallest, fastest model I use because that job is essentially a lookup against time. The agent that reads a whole essay and decides whether it sounds like me runs on a much heavier one, because it is doing the thing the regex could not.
That distinction has become more important to me than the distinction between automation and manual work. The real design question is not whether humans remain involved, it is where judgement should live.
When rules collide
The most interesting failures now are not missing rules. They are collisions between rules that are individually correct.
I have a rule that says not to validate the person whose post I am commenting on, because marking someone else's homework reads badly. The rule is right. Then a comment I genuinely wanted to leave on a peer's post came back to me six times with all the warmth stripped out. Nothing was wrong with the rule, it was firing in a context nobody had scoped it for.
The fix was not another rule. It was precedence. Some principles override others in certain contexts, and if you do not make that explicit, the system starts applying good rules in the wrong places.
This is how organisations end up with governance documents that appear to have been written by a committee trapped in a lift - every rule exists for a reason, and almost none of them were designed together.
That is what a mature rule set becomes. Not a list of instructions, but a body of precedent. The hard problems are collisions between principles that are each individually correct.
What should never become a rule
There is one part of this I still do not have a settled answer to.
Some corrections should not become rules at all. I have one note from the engineering side of the system that I keep coming back to: when an agent keeps getting the same thing wrong despite explicit instructions, stop patching the instructions. Either make the decision deterministic or accept a human review and document it.
Prompt-tweaking has a ceiling.
That is an uncomfortable conclusion because it means some knowledge should remain judgement. Not because it cannot be automated, but because automating it would move it into the wrong part of the architecture.
I started this work thinking I was building an agent system. I increasingly think I am building a catalogue of judgement placements. Every correction forces a decision: is this a rule, a control, a review, or a judgement? Where should it live? Those decisions accumulate, and over time they become the thing that is actually valuable.
The most distinctive part of the system is not that it uses agents. Plenty of people can build an agent workflow. What has proved much harder is extracting reusable design principles from the failures, because that is what changes the architecture rather than the implementation.
I thought I was improving prompts. What I was actually doing was deciding where judgement belonged and, once I saw that, I stopped thinking about the quality of the answers and started thinking about the architecture of the decisions.
Questions I get asked
What does it mean to route a correction?
Routing a correction means deciding what kind of correction it is before deciding where it belongs. Some corrections should become deterministic controls, while others should remain contextual judgements handled by a reviewer.
How do you decide whether to automate a check or use a reviewing agent?
Ask whether the thing can be wrong for a good reason. If it cannot, automate it. If a competent person could reasonably disagree, preserve judgement.
Why keep the same principle in several forms?
Because each form catches a different class of failure. Principles travel, controls enforce, validators catch known patterns, and reviewers catch novel ones.
What happens when two rules conflict?
That is usually a precedence problem rather than a missing-rule problem. The question is which principle should govern in that context.
How does this apply inside a bank?
Banks already have architectures of judgement. Hard controls, delegated authority, review mandates, policy exceptions, and committee decisions are all ways of deciding where judgement belongs. Introducing agents forces those choices to become visible again.
