TL;DR
- If you cannot explain it, do not implement it: you have to be able to explain what the agent does from start to finish first.
- The manual process comes first: your rules are what the agent and the automation are built from.
- Written for people: if you have been documenting your process, it was probably written for people. It has to be turned into instructions an agent can follow.
- Once the agent is automated: it goes out and does things on its own, so you need to know how it decides.
- We keep a person who can stop it: and a record of what it did and why.
Part of what we teach is simple. If you cannot explain it, do not implement it.
If you want to implement an AI agent, and you cannot explain what that agent does from start to finish, do not go ahead and implement it yet.
What does “if you cannot explain it, do not implement it” mean?
Before you do automation, you need to know what happens within the automation. That way it is no black box.
If I was looking at an agent, I would want to know exactly what happens across each step, from what comes in to what it does next.
If you cannot say that out loud, the agent is going to be doing something you do not understand, on your behalf.
Key point: Whatever you can explain about the process becomes the agent’s instructions. The parts you cannot explain become guesses.
Why does the manual process come first?
I said this while we were teaching people to build agents. If you do not even know the basics of doing the task yourself, how are you going to create an agent that is going to do all of that for you?
So what we show first is the manual process. Everything that needs to happen.
Your rules are the agent
In the trading sessions we ran, the first thing was your own rules. What is your risk appetite? What is your entry? What is your exit?
Those are the things that form into your agent and your automation. If you do not know that part, it is going to be hard to do the next part.
A business process works the same way. Who approves what. What price goes on which job. When a follow-up goes out. That is your rule book, and it becomes the agent’s settings and instructions.
Your documentation still has to be rewritten for AI
I do not know how many people document their process. And if anybody has been documenting so far, it is not something documented for AI.
So part of the work is converting whatever you have into instructions an AI can follow. The spreadsheet with your rules, the notes, the way you actually do it.
What happens once the agent is automated?
Once that thing is automated, it goes out and starts doing things on its own.
That is the whole point of an agent. The person who set it up does not want to sit at a laptop and chat with a chatbot every time. They set the criteria, and the agent works from them.
That is also why you have to know exactly how the agent goes about deciding. At the end of the day, you are responsible for what it does in your name.
Key point: The agent acts for you. If you cannot explain how it decides, you cannot stand behind what it did.
How do we take a process from explained to automated?
Here is how we take a process from a person’s head to an agent:
- We walk the manual process with the team. Every step, start to finish, the way it runs today. This is what FusionMap is for.
- We write the rules down. The limits, and the point where a person has to approve. Whatever the agent is allowed to decide on its own, and what it is never allowed to do.
- We lock the logic before any code. On our AI estimating agent build, the contractor’s rates were locked in before any application code, and the price comes from those rates. On the AI client profiling engine, the scoring logic was locked before a line of code.
- We run it by hand with the AI first. You chat with it connected, you see what it can and cannot do, and you fine-tune. After that back and forth, the AI helps write the instructions for the automated agent.
- We automate it with a kill switch and a record. A person can disable the agent at any time, and we keep a record of what it did and how it chose.
The rules about what an agent can and cannot do are the job of FusionGuard. I wrote about the never-do side of that in my post on the never-do list for agents.
How do you know the agent is still doing it right?
We need to know when the agent is doing the work, and exactly how it is performing. Is this good? What was the thought process behind how it chose?
On the estimating agent we built, a person reviews the price before it is sent, and live jobs now go through the agent. That is published on the case study page.
The record also feeds the next round. After every run, what it did and why goes back into the data, and that helps improve the next thing.
Key point: Autonomous still has a person watching. A person can switch the agent off, and every action leaves a record of what it did and why.
Takeaways and Next Steps
If I was looking at the process you want to hand to an agent, this is what I would ask:
- Can somebody on your team explain it from start to finish without opening a system?
- Are the rules written down, with the numbers and the exceptions?
- Has anybody run it by hand with the AI before it is automated?
- Who can switch the agent off, and where do they see what it did?
If any of those is a no, that is where I would begin. FusionMap is where we map the process first. I also covered the difference between chatting with AI and running an agent in the move from prompting to agents.
Common Mistakes
1. Automating a process nobody can explain
- Why it fails: The agent does what it was told, and nobody told it the real process.
- Better approach: We walk the manual process with the team before anything is built.
2. Treating old documentation as agent instructions
- Why it fails: Documentation written for people skips the steps everybody already knows. An agent does not know them.
- Better approach: We convert what you have into instructions an AI can follow, with the rules spelled out.
3. Going straight to the autonomous agent
- Why it fails: You skip the round where you learn what the AI can and cannot do with your setup.
- Better approach: We run it by hand with the AI connected first, then automate.
4. Leaving the rules in somebody’s head
- Why it fails: The limits and approvals are the agent. If they are not written, the agent guesses.
- Better approach: A written rule book with the numbers and limits in it.
5. No kill switch and no record
- Why it fails: Once it is automated, it acts on its own. Without a record you cannot see how it chose.
- Better approach: A person who can disable it, and a log of every action and the reason behind it.
Frequently asked questions
What does "if you cannot explain it, do not implement it" mean?
It means you should be able to explain what an AI agent does from start to finish, step by step, before you build it. If you cannot, the agent will be making decisions you do not understand.
Why should I do a process manually before automating it with AI?
Doing it manually shows you every step and every rule the agent will need. Those rules become the agent's instructions, settings and limits.
Can I use my existing process documents to build an AI agent?
You can start from them. Documentation written for people skips the steps everybody already knows, so it has to be converted into explicit instructions an agent can follow.
What should an AI agent's instructions include?
They should include the steps, the rules with their numbers and limits, what the agent can decide on its own, what it must never do, and when a person reviews the work.
How do I keep control of an autonomous AI agent?
We keep a person who can switch it off at any time, and a record of every action and the reason the agent gave for it.
Who is responsible when an AI agent makes a mistake?
You are. The agent acts on your behalf, which is why you need to understand how it decides before you let it run.
Key terms
- AI agent
- Software that uses AI to take actions on your behalf from a set of instructions and rules, without a person prompting each step.
- Manual process
- The way a task runs today when a person does every step by hand.
- Rule book
- The written rules an agent follows, with the numbers, limits, approvals and exceptions.
- Black box
- A system whose steps you cannot see or explain, so you cannot tell why it did what it did.
- Kill switch
- A control that lets a person disable an agent immediately.
- Audit trail
- The record of what an agent did, when, and the reason it gave.




AI Readiness Checklist: 7 Questions Before You Build
The Agent Never-Do List