Driving the
Working Horsesaying what you want, once
A horse that stops at every gate is safe. A horse that does the job you actually meant is useful. Today is the difference between the two.
By the end of today you will be able to describe a job so you get what you wanted, write your house rules into the folder once, and know which jobs to hand over first.
Presented by Emile du Toit
brainitconsulting.com
Last session was what it is. Today is how to drive it.
- It can act — read a file, write a file, run a command, search the web — inside the one folder you opened it in.
- It stops at every gate. Before any change it tells you what it plans to do and waits.
- You can take the reins back at any moment. Escape stops it, and saying no is steering rather than starting again.
- There is still no undo after the fact, which is why we work on copies until session seven.
So it is safe. Now let us make it useful.
Contents
- Before you startWhat #005 left you with, and the rules you kept repeating.
- Giving it a jobHow to say what you want, once.
- The saddle, fitted in the roomStop retyping yourself.
- Two working horsesClaude Code and Codex, briefly and fairly.
- What to hand it firstAnd what to keep well away from it.
- Before the next sessionOne small job, on a folder that doesn't matter.
Then the questions this always raises, the glossary so far, and the picture to photograph.
Before you start
- Workshop #005 done. The assistant working in your folder, and you have opened a gate and declined one.
- Your folder, with something real in it — the reference files and a couple of genuine requests from #003.
- The rules you found yourself repeating in #005. “Never invent a date.” “Always show the call-out separately.” Today they stop living in your head.
- About 45 minutes.
Nothing new to install. If you are on the free browser route, everything here still works — you paste the instructions file in at the top of each conversation instead of it being read automatically.
Giving it a job
The skill is describing work clearly. You already have it.
Dale has three estimates sitting in a folder from last session, and on Friday he wants to ring people back. What he actually wants is one sheet of paper telling him who is waiting, for how much, and which ones he cannot send yet. That is a job, and how you ask for it decides what you get.
You will get something. It may not be the thing.
Sort out my estimates.
You get the sheet Dale asked for.
Read every file in estimates/ and make me
a one-page summary called friday-callbacks.txt.
For each one: customer, total, and whether it's
ready to send. Put the ones that need me first.
Three things did that work, and they are the same three every time.
- Where to look. "Every file in estimates/" — it does not have to guess which files you meant.
- What done looks like. A named file, with named contents. Not "summarise them".
- What matters most. "The ones that need me first" is the sentence that makes the sheet useful on a Friday afternoon.
Describe the job the way you would to a capable new employee on their first morning — someone sharp, who does not yet know your business, and who will do exactly what you said.
You have written that instruction a hundred times in your working life. This is the same skill, and it is the skill that matters most.
One job at a time. Ask for the summary. Look at it. Then ask for the next thing. Handing over five jobs in one paragraph is how you end up with four you did not check and one you did not want.
Lab 1 — Write a proper instruction 10 min
The skill is describing work clearly, and you have it already — you use it every time you explain a job to somebody new. This is that, written down.
First, deliberately badly
Watch it either guess or ask. Both are informative. A vague instruction does not get a vague answer; it gets a confident answer to a question you did not ask.
Now with the four parts
Every instruction worth writing has the same shape. Read what to read, do the thing, put it here, and stop if unsure.
Nothing in inbox/ or reference/? Dale’s rate card, notes and three inquiry emails are in #003, chapter one, each with a copy button. Copy them in and this lab runs on a real job with numbers you can check.
Compare the two results
Same assistant, same folder, same files. The only thing that changed is how clearly you asked. Nobody needed to learn prompt engineering; you wrote a work order.
Notice the last paragraph did the most work. “Do not guess, stop and ask” is the sentence that turns a liability into an assistant.
The saddle, fitted in the room
You met this in session one. Here it lives in the folder.
In the first session the saddle was the standing instructions: who you are, what you always do, the facts it may rely on, and the nevers. You wrote them once and every ride started properly. That was in a browser, and it followed you around inside one product.
Down here it is simpler and better. The standing instructions are a file in the folder, in plain English, and the assistant reads it whenever it starts work there. Nothing to configure and nothing to log into — the saddle hangs in the room with the rest of the gear.
What this folder is. Dale & Son, a two-truck residential plumbing company. This folder turns inquiry emails into written estimates.
Always. Price from rate-card.txt. Labor and parts on separate lines. Show the service call separately. Add sales tax at the end.
Never. Never price gas work — flag it for Dale. Never promise a date. Never guess a price: list what we'd need to know.
Tone. Plain. The customer is not a plumber.
That is the file, in full. It is the same words Dale would say to a new apprentice, written down once.
The gain is not that it saves typing, though it does. It is that the rules stop living in your head. Anyone who opens that folder — you next March, your daughter covering the phones, whoever you eventually hire — gets a horse that already knows the house rules.
Write the rules down once. Then they belong to the business rather than to you.
Lab 2 — Hang the saddle in the room 20 min
This is the lab that matters today. You are taking the rules out of your head and putting them in the folder, where they belong to the business rather than to you.
Make the file
- In VS Code, make a blank file: Ctrl+N (Cmd+N on a Mac), or File → New Text File. If your File menu only offers New File…, that opens a list — choose Text File from it.
- Save it in the top of your folder. For Claude Code call it
CLAUDE.md. For Codex call itAGENTS.md. One tool, one file — that is all you need today. If you use both, the box below has a tidier answer than keeping two copies. - Write it in four parts, in plain English, the way Dale's is written above.
The four parts
- What this folder is. One or two sentences. What the business does and what this folder is for.
- Always. The steps you would tell an apprentice. Where prices come from, how things are laid out.
- Never. The rules you discovered in #005 by being annoyed. This is the most valuable section and it will keep growing.
- Tone. Two lines. Who the reader is and how you talk to them.
If you use Claude Code and Codex — one file, not two
Two files with the same words in them is fine for about a fortnight. Then you edit one and forget the other, and the two agents start working to different rules — which is the exact problem this file was meant to solve.
Put everything in AGENTS.md. Then make CLAUDE.md one line long:
Claude Code reads CLAUDE.md and that line pulls the other file in, so both tools read the same words and there is only ever one file to edit. Anything you want Claude to do and Codex not to, write underneath the line. Recent versions of Claude Code read AGENTS.md by themselves when there is no CLAUDE.md; the one-line file works on every version.
Anthropic’s own documentation describes this, and offers a symlink as the alternative — but a symlink on Windows needs administrator rights or Developer Mode, so the one-line import is the one to use here. The import does not save any memory: the file still loads in full. What it saves is the second copy, and the drift that comes with it.
Let it interview you instead
If writing it cold is hard, have it draw the file out of you. This is the same interview trick from #001, pointed at the folder.
Now prove it is being read
Start a brand new conversation in that folder and ask:
It should come back with your nevers. If it comes back generic, the file is in the wrong place or the wrong name — it belongs at the top of the folder, not inside a sub-folder.
On the free browser route, paste the file's contents at the top of each new conversation. Same effect, one extra paste.
Two working horses
Both are good. The choice matters less than the practice.
There are two of these worth your attention, and they do the same job in much the same way. Anything you learn on one transfers to the other in an afternoon.
The honest advice is the same as session one, for the same reason. Pick one, use it on real work for a month, and get good at it. The difference between the two is far smaller than the difference between someone who has driven one for a month and someone who has read about both.
Both come with the paid plan you may already have — around twenty dollars a month — and both eat sugar cubes as they work. A working horse eats rather more than a riding one: it is reading whole files and running things, not answering a question. Watch what a job costs you the first few times, the same as you would watch the meter on anything else.
What to hand it first
Start where being wrong is cheap and obvious.
The first job you give a working horse should be one where a mistake makes you laugh rather than reach for the phone. That rules out rather less than you would think, because most office work is recoverable and most of it is dull.
Good first jobs
- Turn a pile of things into one sheet. Estimates into a callback list, receipts into a total, a week of notes into a summary.
- Reformat something. Same information, laid out the way you actually want it.
- Read a long thing and tell you the three lines that matter. A contract, a spec, a supplier's terms.
- Draft the reply you always write. It goes in a file. You read it, change it, send it yourself.
- Tidy a folder. Consistent names, obvious structure — on a copy.
Not yet
- Anything with one copy. The only version of a document, the master price list, the folder you have never backed up. Not until session seven.
- Anything that leaves the building on its own. Emails to customers, invoices, anything with a price on it going to a real person.
- Work you cannot judge. If you couldn't tell a good answer from a bad one, you cannot check it, and you are not supervising — you are hoping.
- Your whole computer. One job, one folder. It was true last session and it is more true now that it can act.
Copy the file into the project folder and let it work on the copy. Leave the original where it lives. It is clumsy, it costs you ten seconds, and it makes every mistake in this session survivable.
Session seven fits a proper safety net and you can stop doing this.
Lab 3 — Hand it something where being wrong is cheap 15 min
The first real job should be one where a bad result costs you nothing and a wrong answer is obvious. That rules out invoices, anything a customer sees unreviewed, and anything with a number you would not spot.
Good first jobs
- Summarising a week of inquiries into a list
- Drafting a reply you were always going to read before sending
- Turning scrappy notes into a tidy record
- Pulling the same three fields out of twenty emails
Bad first jobs, and why
- Anything priced. A wrong number looks exactly like a right one.
- Anything that sends. Draft, always. You press send.
- Anything you cannot check in a minute. If verifying takes longer than doing it, you have not saved anything.
Run it, then grade it honestly
Pick one and run it now that the instructions file exists. Then ask yourself two questions:
- Did it follow the house rules without being reminded? If not, the rule is not written clearly enough — go and sharpen it.
- Was it faster than doing it yourself, including the checking? Be honest. If not, this is the wrong first job, not a failure of the tool.
Every time you correct it, ask whether that correction belongs in the instructions file. That is how the file grows into something worth having.
Before the next session
One small job, on a folder where nothing matters.
You opened a gate and said no to one in #005. The point of this week is different: it is to find out whether the instructions file actually holds up when you use it on real work several days running.
- Open the
tack-roomfolder you made last session. If you skipped that, make a folder anywhere and put two or three copied files in it. - Start the assistant in that folder — the panel down the side, or
claudein the black one. Either. - Check it's on Manual, the mode that asks every time. The mode is shown at the bottom of the box you type in, and a new session can start on Auto, which stops asking you. This matters more than anything else on this list.
- Ask it something harmless first: "What's in this folder, and what do you think it's for?" Nothing gets changed by a question.
- Now give it one small job. "Make me a file called notes.txt that lists what's in this folder and what each one seems to be." Small, checkable, and nothing of yours is at risk.
- Watch the gate. When it asks permission, read the prompt properly before you answer. That is the exercise.
- Say no once, on purpose. Decline something and see what it does. People are nervous of that button until they have pressed it.
- Stop there. Don't point it at your real work yet. That's session seven, once you have the undo.
What your folder should hold by the end of today:
If inbox/ or reference/ is still empty, Dale’s files are in #003, chapter one with copy buttons.
The class folder online has a marker at the end of each workshop too, if you would rather compare the whole thing. It is at github.com/brainit-consulting/ai-workshops — pick end-of-006 from the dropdown, then the green Code button and Download ZIP.
Lab 4 — Use it for a week, then sharpen the file 20 min, spread out
The instructions file is never right first time. It gets good by being used and corrected, and a week of small annoyances teaches more than an afternoon of careful drafting.
The week
- Use the assistant on that one job whenever it comes up. Not everything — one job.
- Every time you have to correct it, write the correction on a scrap of paper. Do not fix the file yet.
- Keep the gate on Manual, so it asks every time. All week. There is no hurry to turn it off.
Then, at the end of the week
Look at your scrap of paper. Anything you wrote down twice belongs in the file. Add it under Always or Never and delete anything in there that never came up.
What you should end up with
A file of maybe twenty lines that makes the assistant behave like somebody who has worked with you for a month. That file is worth more than any prompt you will ever write, and it is the thing you would hand to a new employee.
Do not point it at your real customer work yet. That comes in #007, once you have an undo.
Questions people actually ask
The ones that come up once you are actually driving.
Do I have to watch it the whole time?
You watch a green horse. You check on a proven one.
At the start, yes, and it is time well spent — you learn what it does with your kind of work. Once a particular job has gone right a dozen times you will find yourself glancing rather than staring. What should not change is checking the end of it. That is the part that stays yours.
It did something odd and I don't know why.
Ask it. It remembers the ride.
Type "what did you just do, and why?" and it will walk you through it. That is not a trick question — it is the ordinary way to work out where an instruction was read differently than you meant it. Nine times in ten the answer is that the instruction was looser than you thought.
What happens if I approve something and it turns out to be wrong?
Today, you fix it by hand. That's the honest answer.
Right now there is no undo beyond what your own computer offers, which is why we are working on copies. Session seven is entirely about this: keeping every previous version of everything so any mistake becomes a step backwards rather than a rebuild. If that gap makes you uneasy, good — that instinct is the reason session seven exists.
Couldn’t I just use one of those sites that builds the whole app for me?
You can. It is a rented horse, in a stable you do not own.
There is a whole category of these now, and they are genuinely impressive. You describe what you want in a browser, and a working thing appears in minutes with nothing to install. For a rough prototype, or for proving an idea to a partner on a Friday afternoon, that can be exactly the right call and I would not talk anyone out of trying one.
Understand the trade you are making, though, because it is easy to miss when the thing works on the first try. What you build lives on their platform, in their account, in their shape. You are renting the horse, the tack and the stable together. The monthly fee continues whether you ride or not, and it continues forever, because the day you stop paying is the day you walk home — frequently without the work.
The second cost is quieter. What you learn is their buttons rather than the craft. Move to a different one, or outgrow it, and much of what you knew does not come with you.
Everything in this series goes the other way on purpose: the files sit in a folder on your own machine, in ordinary formats, and every tool around them can be swapped for a different one. It is slower to begin and you end up owning the outfit.
The question worth asking before you commit: if that company closed tomorrow, or tripled its price, what would I still have? For a prototype, "nothing much" is a perfectly good answer. For the thing your business actually runs on, it is not.
Plain words
Everything the series has named so far. Today's are marked.
This list grows every session and always shows the lot, so you never need last week's notes to read this week's.
- Large language model (LLM) 001
- The engine that predicts the next word. The horse.
- GPT 001
- Generative — it makes new text rather than looking up a stored answer. Pre-trained — all its learning happened in advance. Transformer — the design of the machinery underneath. A breed name, not a job title.
- Knowledge cutoff 001
- The date its training stopped. It knows nothing after it, and doesn't know that it doesn't. The last day the horse was out in the world.
- Prompt 001
- What you type. A pull on the reins.
- Chatbot 001
- A model you can talk to, turn by turn. Horse plus bridle.
- System prompt / instructions 001
- Standing orders sent with every message, whether you type them or not. The saddle.
- Context window 001
- How much of the conversation it can hold at once. How far it can see on this ride.
- Token 001
- A chunk of a word — how length is counted, and how you're billed. Sugar cubes.
- Hallucination 001
- Making something up and sounding certain. Shying at a shed snakeskin.
- Tool 002
- A specific action it's allowed to take in the real world. A saddlebag.
- MCP 002
- An agreed standard for plugging tools into a model. Standard-size buckles.
- Agent 002
- A model given a goal, tools, and permission to keep going. A working horse, not a show pony.
- Agentic loop 002
- Look, decide, act, check, repeat. The ride itself.
- Human in the loop 002
- A person approves before something real happens. A hand on the reins.
- Automation 002
- The same work happening without you starting it each time. The horse knows the route.
- File 003
- A thing with a name and contents. A single piece of gear.
- Folder (directory) 003
- A box holding files, and sometimes other folders. A shelf.
- Project 003
- One folder holding one job's worth of everything. The room, with the door shut.
- Path 003
- The written address of a file — which boxes it sits inside. Directions to the shelf.
- Editor (VS Code) 004
- A window showing you one folder and everything in it. The tack room.
- Terminal 004
- A panel where you type an instruction to the computer directly. Talking to the stable itself.
- Install 004
- Putting a program on your own machine, once. Building the room.
- Permission prompt 005
- The stop before it changes anything, showing what it plans to do. The gate, and your hand on the latch.
- Approval mode 005
- Whether it asks every time, works on its own, or only shows a plan. How loose you're holding the reins.
- Interrupting 005
- Stopping it mid-job with the escape key. A pull on the reins. Ordinary.
- Project instructions 006
- A plain-English file of standing rules that lives in the folder. The saddle, hanging in the room.
- Run a command 006
- Doing something on the computer rather than writing words about it. Actual work, not conversation.
- Working on copies 006
- Duplicating a file so the original can't be harmed. Schooling in the paddock, not on the road.
Everything on one page
Photograph this before you go.
1 · Say where and what
Where to look, what done looks like, what matters most.
2 · Rules in the folder
Write them once. The business owns them, not your memory.
3 · Pick one, learn it
Claude Code or Codex. A month on one beats a week on both.
4 · Breadcrumbs
The undo. Every step a gate you can ride back through.
Next session is the safety net. Once you have it, you can stop working on copies and point this at work that matters.
#007 — Breadcrumbs
Everything so far has one hole in it: approve a change on Tuesday, realise on Thursday it was wrong, and nothing helps you. Next time we fix that permanently — a way of keeping every previous version of everything, so any mistake becomes a step backwards rather than a rebuild. It is the session that lets you stop working on copies.
Before you start it: do the small job above, and notice the one moment you wished you could undo something. And please install git first — go to git-scm.com, click Install, and accept every screen the installer offers. One download, and it saves us fifteen minutes in the room.
I do this for a living, and love to help people.
Thirty-plus years in enterprise software and a computer science degree — which mostly means I have watched a great many horses bolt, and I can usually tell you which ones are worth saddling before you spend money on the saddle.
In person
Your team, your room, your actual work on the whiteboard instead of somebody else's examples.
Over video
The same session, at your desks, with fewer chairs to stack afterwards.
Built for real
When the idea survives the workshop and somebody has to go and build the thing — that part I do too.
Fun fact — I rode to school on horseback as a kid in South Africa. So the metaphor isn't borrowed. I've done the falling off in person.
Emile du Toit brainitconsulting.com
Workshop #006 · Driving the Working Horse
© 2026 Emile du Toit, BrainIT Consulting · Print it, share it, leave my name on it.