What it is for
I describe a task the way I would hand it to a colleague, and the agent carries it through: it reads the trackers, reconciles what disagrees, builds the deck or the message, and checks its own work. The goal I gave it on day one was to execute the whole workflow, not to suggest steps for me to do by hand.
The aim is that most of what comes back needs no editing. That is why so much of the file is not about tools at all. It is about judgment: what to verify, when to ask, what a good answer looks like for the person reading it.
How the instructions are organised
The file is grouped into sections: mission, my writing voice, how I work, an execution policy for risky actions, how to analyse data, how to build deliverables, how to build other agents, output standards, and a learning loop. A rule sits in the section where it will be applied. The rules that took the most care are the ones about when to stop and ask.
- Execution policy. For anything that sends a message, notifies someone or changes a system, the agent first shows a dry run of the planned actions and waits for my explicit approval.
- Reuse before building. Before proposing a new setup for a new data source, it checks whether a credential or pattern I already have would work.
- Self-check before delivery. Logic, data consistency and completeness are checked before a result is handed back.
How a correction becomes a rule
Most of what I tell the agent is a one-off: change this row, shorten that sentence. If every correction became a rule the file would be noise. So each correction goes through the same four questions before it is written down.
- General. Will it help in future sessions, not just on this task?
- Specific. Is the fix a concrete step the agent can follow?
- Has an example. Is there a right-versus-wrong case?
- Not already covered. If a rule exists, strengthen it instead of adding a duplicate.
You can run this triage on seven real kinds of corrections in the learning-loop lab.
Two further rules shape the loop. First, the agent does not wait for me to say "learn this": after a correction it checks the bar itself, writes the rule if it passes, and tells me in one line what it captured so I can veto it. Second, my behaviour counts as feedback. If I ignore a draft and write my own, that is a signal, and the agent compares the two to see what it got wrong.
When edits stop converging
One rule came from a long drafting session. A paragraph was rejected several times, and each fix only swapped a word or a clause. The real problem was structural: one sentence was carrying three separate points. The rule now says that after two rounds of surface edits that still get rejected, stop and look for a structural cause before trying another tweak.
Rules, and what went wrong first
- Don't batch an edit and the command that tests it.Independent calls in one block can run in parallel. A check "passed" because it ran before the change had landed.
- Don't add features nobody asked for.I once offered an option I had invented. Now: restate an ambiguous phrase back before building from it.
- Change only the exact text asked about.Asked to remove one phrase from a subtitle, the agent deleted the whole subtitle and a useful note with it.
- Don't state platform behaviour as fact unless it was verified.The agent told me a chat could not switch agents. It could. Now an inference has to be labelled as one.
- Verify a formula against the source's own definition.A rule written from a verbal description would have deducted a quantity twice.
- After debugging that wrote to a live system, look for what was left behind.Trial-and-error writes leave test rows. The check is now a standard last step, not something I notice later.
- Before regenerating a file, read the live copy for manual edits.A rebuild from a script can silently overwrite changes I made by hand.
- Treat the text "None" as blank.Old exports left the four-letter word in cells, which passes a simple "has a value" check and hid empty fields for months.
What I reused for the team agent
The team agent is the same pattern with a different audience. The approval rule, the verification rules and the structure of the instructions came across almost unchanged. What the team version added was domain knowledge, tools for Power BI and Snowflake, and a report template. See the team AI analyst.
What this page doesn't show
- I am the only user, so there are no usage numbers and nothing to compare against. The evidence is that I keep using it and keep adding to it.
- The rules are checked by use, not by an automated test suite. The next step is to turn past corrections into cases for the harness in the playbook.
- The real file is private. The rules above are rewritten without names, systems or data, and the method and a template are public.