How To Write Rules For An AI Employee In Thirty Minutes
You can write a working set of rules for an AI employee in thirty minutes by splitting the time three ways: ten minutes writing down how you communicate, ten minutes writing down how you want the agent to communicate back, and ten minutes on a this-not-that list of substitutions. You then leave one section blank, the irritation list, and let it fill itself over the next two weeks. Do not try to write the perfect file. Write the honest file and hand it over.
Before you start: the one rule about writing rules
Write for a smart stranger who has never met you. Not for a machine, not for a programmer, for a sharp new hire who starts Monday and will read this on the drive in. If a sentence would be useful to that person, it belongs. If a sentence is you trying to sound like a software spec, cut it.
Open a plain text file. Title it "Rules for working with me." Set a timer.
Minutes 0 to 10: how I communicate
Describe yourself honestly. This is the part owners skip because it feels self-indulgent, and it is the part that saves the most time later. Answer these in plain sentences:
- Do you write in full sentences or fragments? Do you fire off five messages in a row that are really one instruction?
- When you say "fix it," do you mean the thing you just mentioned, or the whole area?
- Do you change your mind mid-stream and expect the latest message to override the earlier ones?
- Are you usually on a phone, in a hurry, between meetings?
- What do you never want to be asked twice?
A member on one of the Optimus Mastermind calls described his approach as front-loading: he answers every question before a build starts, and from that point the agent "just goes to work." His rules file says exactly that. The agent wrote chapters 7 through 16 of his book in his voice, because it knew to gather everything up front and then stop interrupting.
Minutes 10 to 20: how I want you to communicate
Now flip it. What do you want back? Most owners find they have strong opinions they never stated:
- Answer first, reasoning second. Or reasoning first if the answer is "no."
- Short status line at the end of every task: done, blocked, or needs you. Nothing else unless something broke.
- When you are blocked, tell me exactly what you need: a login, an env var, an API key. Do not describe the problem in general terms.
- When you truly cannot do something, give me the exact step-by-step and the links, and I will do it. Do not hand me a vague "you'll need to configure that."
- Never pretend you did something you did not do.
That third and fourth bullet come straight from the five phrases we teach alongside the template. The checklist is agent, then skills, then tools: when it stalls, the question is what does it actually need. Write that question into the file so you never have to ask it live.
Minutes 20 to 30: this, not that
The fastest section to write and the one the agent quotes back to itself most often. Each line is a substitution. Here are the ones that showed up on every call, which you are welcome to steal:
- Use the API or MCP, not a manual process for me to click through. If you are not sure one exists, read the docs. Do not guess.
- Ask every question you have now, then do not stop until it is done. No sandbagging.
- Do everything you can possibly do yourself. Only hand me the pieces that genuinely require me.
- When I say I am opening a fresh window, write me a handoff file first.
- When I tell you to load a skill or a document, confirm you actually read it.
Add three or four of your own. If you cannot think of any, you will after the first week; that is what the next section is for.
Minute 30: leave the irritation list empty
The last section is a heading with nothing under it: "Things you did that irritated me." You do not fill this in now. You fill it in live, one line at a time, every time the agent goes off the rails. Each line has two halves: what it did, and what it should have done.
This section is the whole engine. In my own experience, the agent went off track on roughly every third task before the list existed. After a few weeks of adding lines, it was a few percent. The agent reads the list before every shift, so each mistake is made once. That is better than most human hires manage.
Then: hand it over and stop editing
Put the file where the agent reads it before every job. For a coding agent that is usually a file in the project root or a system instruction. For a business agent on a platform, it is the standing instructions field. Then run a real task.
Do not polish the file for an hour. Honest and done beats perfect and unwritten. The seven-section checklist will tell you what you missed if you want to go deeper, and the list of rule mistakes founders keep making will tell you what to avoid. But both of those are second-week reading. The first-week job is thirty minutes and a file.
The free template at Rules For Working With Me gives you the skeleton with the headings already in place, plus three short lessons on using it. Fill in the blanks and you are done before your coffee gets cold.
FAQ
Do I need to be technical to write AI employee rules?
No. The file is written in plain English about how you work and how you want work delivered. One operator on the Optimus Mastermind calls had no technical background and now runs her own agent-built task board. The rules are about you, not about code.
What if I can't think of anything for the this-not-that list?
Start with the five phrases that come with the template: use the API not a manual process, ask every question now then finish, do everything you can yourself, write a handoff file before a fresh window, confirm you actually read the skill. Add your own after the first week of real tasks.
How often should I update the rules file?
Every time the agent does something that irritates you, add one line to the irritation list. Otherwise leave it alone. The three main sections rarely change; the irritation list grows a line at a time and is where almost all the improvement comes from.
Where does the agent read the file?
Wherever it loads standing instructions. For coding agents, that is typically a file in the project root. For agent platforms, it is the system or standing instructions field. The point is that it reads the file before every task, not once at setup.