The most common way to build a bot is to start chatting and see what happens. The most reliable way is to start with a map.
This is our core theme. Before any bot, write down three things:
- The data. What information exists, where it lives, and who owns it.
- The process. What steps happen, in what order.
- The schema. What each step produces, in what shape, and what it hands to the next step.
Boxes and arrows
Engineers draw this as a graph. The words sound technical, but the idea is plain.
- A node (a box) is one job. "Pull this week's orders." "Check them against inventory." "Draft the supplier email."
- An edge (an arrow) is a handoff. Data passes from one box to the next.
| Term | Plain words | Example |
|---|---|---|
| Node | One job, one box | "Check orders against stock" |
| Edge | A real handoff of data | The list of short items |
| Schema | The shape of what's handed over | Part number, quantity short, due date |
Boxes do the thinking, arrows carry results
Each box should have a clear job and a clear output. Each arrow should carry something specific.
If a box's output is a wall of loose text, the next box has to guess what it means. A person can read it. Another bot might misread it. A fixed shape (a table, a list with named fields, a file) makes the handoff reliable.
The fake-arrow test
Here's one question that cleans up a lot of maps: does this step actually need the result of the step before it?
If not, the arrow is fake. The two steps can run side by side, or the arrow can go. Fake arrows make bots wait on each other for nothing, and they make long chains where one mistake spreads.
Make every output countable
A vague box turns into a bot you can't review. "Help with customers" can't be checked. "List every open order over 30 days old, with customer and amount" can. If you can count it, you can check it.
Old idea, new workers
None of this is new. Process maps, flowcharts and data definitions have run factories and software for decades. ISO calls it the process approach: manage the work as connected processes, each with inputs and outputs. See Map the process before you hire the bots.
What's new is the worker in each box.
A real example
Our AN Creation office files include a "routes and flow" skill and a list of project stages. Each stage has an owner and a defined record. The bots don't decide the flow as they go. The flow is written down, and the bots work inside it.
What this means for you
- Draw the boxes before you build the bots. Paper is fine.
- Name what travels on each arrow.
- Delete arrows that carry nothing.
- Pass files, not piles of chat.
- Make every output something you can count or check.
A bot is only as clear as the job you drew for it.