Ask anyone on your team how a sales call turns into a proposal. Ask how a new hire ends up with a laptop on their desk the morning they start. You will get one of two answers. A shrug, or a story.
The story goes something like this: "Usually one person sends it over, unless they are traveling, then I do it, and then somebody has to remember to update the deal board." That is not a process. That is a memory, held by whoever has been around longest, and it works right up until the week it does not.
This is Day 9 of the 30-day 8 Edges season. Day 8 gave every fact in the company one home. Day 9 takes the second gap we named on Day 1, the undesigned workflow, and writes one down. There are no research figures in this episode. The framework is ours, and the workflow I walk through below is running inside Edge8's own Company OS right now.
The process lives in people's heads
The process lives in people's heads; nobody wrote down who does what, so every workflow runs on memory and goodwill and the busiest week decides what slips.
Nobody wrote it down. Nobody decided who owns each step. So every workflow in the company runs on two things: memory and goodwill. Memory, because the steps live in someone's head. Goodwill, because the person who picks up the slack does it out of care, not because it was ever their job.
That holds in a quiet week. In the busiest week, something slips. The proposal goes out late. The laptop arrives after the start date. The client record never gets updated, and the next person who opens it is working from a version of the truth that is weeks old.
Here is the quieter cost, and it is the one most founders miss. When a step slips, nobody can even ask why. There is no design to hold the slip against. You cannot say "this was supposed to happen here and it did not," because "supposed to" was never written anywhere. So the conversation becomes about people instead of the workflow, and it ends with someone feeling blamed and nothing changing.
Now add AI to that company. You hand a tool a job inside a workflow nobody has drawn, and you have just added one more actor to a process with no map. The AI does not know which steps are its. Your people do not know which steps are still theirs. The shrug gets bigger.
The playbook, written twice
The fix is a playbook. Not a binder. A playbook for one workflow, and it is written twice.
The first version is human-readable. Plain language, the kind anyone on the team can scan and say "these three steps are mine." It tells a person what they own and what they are expected to decide at each of their steps.
The second version is agent-executable. Same workflow, same steps, but written so an AI agent can run its part. An agent, in plain terms, is a piece of software that can be handed a step and will carry it out without a person pushing each button. The agent-executable version tells it which steps are its and what it must produce at each one.
Two versions of one design. Same steps, same order, same names. One for the people, one for the software. If the two versions ever disagree, the design is wrong, and you fix the design rather than blaming the person or the tool.
One name on every step. Never "the team."
This is the rule that does the work.
Every step in the playbook carries one name. A person, or an agent. Never "the team," never "sales," never "ops." The moment a step says "the team," you are back to memory and goodwill, because "the team" means whoever notices first, and in a busy week that is nobody.
One name per step is what turns a story into a design. It is also what makes the playbook honest. If you cannot put a single name on a step, you have found the exact spot where your workflow has been breaking, and now you know where to look.
Humans decide, the AI produces, the design says which
Humans decide, the AI produces, and the design says which is which.
Here is the split in one line: humans decide, the AI produces, and the design says which is which.
Where a person owns a step, the playbook says what they decide. Not what they do. What they decide. The decision is the reason a human is on that step at all.
Where the AI owns a step, the playbook says what it produces. A draft, an updated record, a moved deal, a written summary. Output, not judgment.
That is the whole anatomy. You look at each step and ask one question: is this step a decision or a product? If it is a decision, it gets a person's name. If it is a product, it can get an agent's name.
This is how a company hands half of its work to software without losing control of any of it. Control does not come from keeping humans on every step. It comes from knowing, in writing, which steps are human and which are not. On Day 5 I argued for frameworks over prompts. The playbook is the framework. Prompting an AI to "help with proposals" gives you a different result every time. Giving it a named step with a defined output gives you the same result every time.
"This sounds like paperwork"
I hear this objection every time, and it is fair. Founders have been handed process documentation before. Thick standard operating procedures that nobody read, nobody updated, and nobody could find when it mattered.
So here is the guidance: one page per workflow. That is not a measurement, it is a discipline. If the playbook for one workflow does not fit on a page, you have either bundled two workflows together or you are writing instructions instead of ownership. The page is not meant to teach someone how to do their job. It is meant to say whose job each step is and what comes out of it.
What that one page buys you:
- Every person on the team can point to the steps that are theirs.
- The AI has a written list of the steps that are its, and what each one must produce.
- When something slips, you can point to the line and ask why, without it becoming a fight about people.
- Bringing someone new into the workflow means handing them the page.
- You can hand steps to software one at a time, because each step already has a name and an output, and the handoff is a change on a page rather than a reorganization.
One page, written twice. That is the entire cost of entry.
The real one: a call becomes a proposal at Edge8
The human no longer writes up, formats or chases; the AI never touches the relationship, the price or the judgment.
This is not a diagram we drew for the camera. The call-to-proposal workflow, the deal board, the logged transcripts and the proposal page on our own domain are all live inside Edge8's Company OS. The Day 9 film shows the page itself. Here is how it reads.
The human's steps. I take the call. I own the conversation, the relationship, what gets promised, and the price. These steps carry my name, and they stay on the human side of the page permanently. Nothing about them is scheduled to move.
The one administrative act. After the call, one action puts the transcript into the system. That is the line on the page. Everything above it is human. Everything below it belongs to the AI.
The AI's steps. It reads the call. It updates the client record with what was discussed. It moves the deal to the right place on the deal board. It drafts a proposal page on Edge8's own domain, built from the call and from the records it already has.
What the human no longer does. I do not write up the call. I do not format a proposal. I do not chase anyone to update the record or move the deal. Those were never decisions. They were products, and products belong to the agent.
What the AI never touches. The relationship. The price. The judgment about whether this client is a fit and what we should offer them. Those steps have a person's name on them, and the design says so in writing. The AI drafts the proposal page. I decide whether it goes out and what it says about money.
I hold every AI claim, mine included, to the same two questions: what did the AI just do, and what does the person still decide? In this workflow the AI read the call, updated the record, moved the deal and drafted the page. The person owns the call, the relationship, the price and the judgment. If a vendor, a consultant or anyone else cannot answer both questions about a workflow they are proposing, you do not have a design. You have a demo.
Start with the worst workflow you have
Most founders I talk to want to put AI into a workflow before they have a single page like this. They end up with something impressive built against a workflow nobody agreed on, and before long the team has quietly gone back to the old way because nobody knew which steps were theirs anymore. The page comes before the tool. Whoever writes it has to sit with the founder and the operator, draw the line between decision and product, and put a name on every step. That is the work. The tool is what you do after the work.
So start with the worst workflow you have. Not the flagship. Not the one you are proud of. The one everyone complains about. The one that slipped last month and nobody could say why.
Take that workflow and write one page. List the steps in order. Put one name on each, a person or an agent, never the team. For every human step, write what that person decides. For every AI step, write what it produces. If a step will not take a single name, that is the step that has been failing you, and now it is on paper where you can fix it.
Then write the same page a second time in the form your agent can run. Same steps, same names. Hand the AI its steps one at a time, and watch what your people stop doing.
Day 8 gave every fact one home. Day 9 writes one workflow down, with a name on every step. Day 10 shows what becomes cheap once both of those exist. Day 12 runs this exact call-to-proposal workflow end to end against the clock, which is why I am not quoting a duration here. You will see it, timed, on Day 12.
Your next step: watch the Day 9 film and look at the page. Then reply to this post with the worst workflow in your company, in one sentence. I will tell you where I would draw the line between decision and product, and what belongs on the human side of your page.
FAQ
How do I write down who does what in a workflow so my people know which steps are theirs and the AI knows which steps are its, without creating a mountain of paperwork?
Write one page per workflow, and write it twice: a human-readable version your team can scan and say these three steps are mine, and an agent-executable version that tells the AI which steps are its and what it must produce at each one. Both versions carry the same steps in the same order, and every step carries exactly one name, a person or an agent, never the team. If the playbook for one workflow does not fit on one page, you have bundled two workflows together or you are writing instructions instead of ownership. This is the Day 9 framework from the 30-day 8 Edges season, and the call-to-proposal page it describes is running inside Edge8's own Company OS.
Which steps in a workflow should I hand to an AI agent and which should stay with a person?
Ask one question of every step: is this a decision or a product? If it is a decision, it gets a person's name and the playbook says what that person decides; if it is a product (a draft, an updated record, a moved deal, a written summary), it can get an agent's name and the playbook says what the agent produces. In the live call-to-proposal workflow in Edge8's Company OS, one administrative act after the call puts the transcript into the system, and everything above that line is human (the call, the relationship, the price, the judgment) while everything below it belongs to the AI (reading the call, updating the client record, moving the deal, drafting the proposal page). That one split is how a company hands half of its work to software without losing control of any of it.
Why do my team's processes keep slipping in busy weeks even though everyone seems to know what to do?
Because nobody wrote them down, every workflow in the company runs on two things: memory and goodwill. Memory, because the steps live in whoever has been around longest; goodwill, because the person who picks up the slack does it out of care, not because it was ever their job. Ask anyone how a sales call turns into a proposal and you get one of two answers, a shrug or a story, and neither is a design. The quieter cost is that when a step slips, nobody can even ask why, so the conversation turns into blame about people instead of a fix to the workflow.
How long should a process document be for a small company so people actually read and use it?
One page per workflow, and that is a discipline rather than a measurement. The page is not meant to teach someone how to do their job; it says whose job each step is and what comes out of it. Written twice, once for people and once for the AI agent, that one page is the entire cost of entry, and it is what lets you hand steps to software one at a time as a change on a page rather than a reorganization.
Which workflow should I document first before I put AI into it?
Start with the worst workflow you have, the one everyone complains about and the one that slipped last month when nobody could say why, not the flagship. List its steps in order, put one name on each (a person or an agent, never the team), write what each person decides and what each AI step produces, and if a step will not take a single name you have found the exact spot that has been failing you. Then write the same page a second time in the form your agent can run and hand the AI its steps one at a time. The page comes before the tool; putting AI into an undrawn workflow just adds one more actor to a process with no map.