Build
Map the workflow before you build
Tobiloba Odejinmi · 14 Jul 2026 · 6 min · 1,096 words
Direct answer
Map the workflow before you build so the AI employee has a job, not a vibe. The map lists steps, tools, fields, exits, and the cases a person still owns. Days 2 and 3 of the week exist for this. If you skip it, you will spend days 4 to 6 discovering the process while pretending you are implementing it.
- The map is the build spec. Prompts come after.
- Every branch a human already takes needs a name.
- Tools and fields are part of the map, not a later integration ticket.
- Unmapped exceptions become silent misses in production.
Why map the workflow before you write any prompts?
A prompt is not a process. A process is a sequence of checks and actions with an owner at each exit. If you start with a prompt, you will hide the exits inside paragraphs of instruction, and nobody will be able to test them. I have watched teams tune tone for three days while the refund rule was still a rumour.
Days 2 and 3 of my week are mapping for this reason. The build on days 4 to 6 is faster when the map is ugly and complete. Ugly means it includes the shortcut people take, the tool they are not supposed to use, and the case they quietly send to a founder. Complete means we can point at a step and say what done looks like.
What belongs on the map?
Trigger, intake, lookup, decision, action, record, and exit. That is enough structure for almost every first process I take. Trigger is what starts the work: a ticket, a form, a CV, a call, a row. Intake is the fields you must have before you act. Lookup is where the truth lives. Decision is the rule or the handoff. Action is the thing that happens in a tool. Record is what you write back so the next person is not blind. Exit is done, waiting, or escalated.
If a step cannot be put in one of those buckets, it is usually two steps glued together. Split them. 'Look up the customer and decide if we refund' is lookup plus decision. Those fail in different ways. One is a missing ID. The other is a policy argument.
- Trigger and the volume you expect in a normal week.
- Required fields and what you do when one is missing.
- Systems of record, including the spreadsheet you wish was not one.
- Hard gates a model may not cross.
- The person who owns an escalated case, by name.
How do you write the cases a person still owns?
Write them as entry conditions, not as a feeling. 'Amount over X.' 'Customer mentioned a lawyer.' 'Candidate was referred by a hiring manager.' 'The document is not the type we trained the first pass on.' Each one needs the handoff payload: working state plus a decision brief. Not the raw thread. The person should not have to reconstruct what the employee already knew.
Separate agent-to-agent moves from agent-to-human moves on the map. Passing a cleaned record to a second workflow is not the same as waking a reviewer. If you mix those triggers, you will either spam people or let an agent chain wander into a promise nobody approved.
What tools and fields do you record?
Every tool the human currently touches, even the ones they are ashamed of. Especially those. If the real lookup is a search in last month's export, write that down. I can often still plug into the real system. I cannot plug into a step you hid because it looked unofficial.
Fields get a type and an owner. Who types them today. Who must see them tomorrow. What happens if they are blank. This is the unglamorous part that makes day 6 testing possible. At Zeeh we learned that banks will use you if they can plug in before lunch. The same rule applies inside your own company. If the map requires a new schema nobody agreed to, we are not mapping a process. We are designing a product.
How detailed does the map need to be?
One page most teams will not write, plus a list of examples. I want ten recent cases annotated against the steps. Happy path. Missing field. Escalation. Duplicate. Angry customer. Referral. Out-of-scope request. If we cannot find those in the last month, volume is too low or the process is imaginary.
I do not want swimlanes for every department. I want the path the work actually takes. Cross-team politics can sit in a footnote. If the work cannot move without a meeting, it is not a first process. Map it later, after you have a win people can copy.
What happens if you skip the map?
You will build a confident first draft that fails on the third real item. Then you will call it a model problem. Then you will add more instructions. Then the employee will start refusing work it should take, because you buried the exits in prose. Then someone will turn it off.
I have run enough production systems to know the pattern. At 10mg, the paths that matter are the ones a stranger will shout about. Mapping is how you find those paths before they shout. The week is short. Skipping days 2 and 3 does not make it shorter. It moves the pain into week two, when the team has already told people it is live.
Questions people ask
How detailed does the map need to be?
Detailed enough that someone who did not do the work can run a case without asking Slack. Not so detailed that you are writing a novel about every mood a customer might have.
Who writes the map?
I write it with the person who does the work. I do not write it from a manager's memory of the work. Those are different documents.
Do we need a formal process already?
No. We need recent examples. The map is how an informal process becomes something you can test. If there is no pattern in the examples, there is no employee to build.
What if the process lives in one person's head?
Then days 2 and 3 are interviews and shadowing, not a workshop with stickies. We write it down. If they will not sit with us, we do not have a process owner.
Can we map two workflows in the same week?
Not in the $5,000 or $7,500 week. One map, one build. The $15,000+ work is for when you already know you want more than one and you need someone on the architecture.
Written by
Tobiloba Odejinmi
Head of Engineering at 10mg Health. I have run engineering at Zeeh Africa and sold Insurpass and Shopl. I still write the code. If you have one process that still runs on people copying things, we can look at it in thirty minutes.
