A founder hires an AI agent implementer. The workflow is explained on a call, live examples are pulled up, it makes sense in the room. Six weeks later, the agent is still producing outputs the team corrects daily. Three more discovery sessions followed the first. The implementation ran four months instead of the expected six weeks — not because the workflow was complex, but because nobody had written it down before the engagement started.
Implementation speed is determined before the first call
The variable that most affects implementation timeline is not the implementer's experience or the complexity of the workflow. It is whether the client can describe their process step by step before the engagement begins.
A business that arrives at the first call with a written procedure — trigger defined, inputs named, output format specified, exceptions listed — reaches a working agent in two to four weeks. A business that explains the workflow by showing it live, or by saying "let me send you an example," typically iterates for two to three months before the agent runs reliably.
The difference is not the workflow's complexity. It is the documentation work, and whether that work happens before or during the engagement.
What undocumented processes cost in a live engagement
When a process isn't documented before the engagement starts, documentation becomes the engagement. Every session of "let me show you what I mean" is a session where no building happens. The implementer is observing, taking notes, and assembling a specification from a live demonstration — work the client could have done before the first call.
At a typical implementation rate, each additional discovery session adds one to two weeks to the timeline. A business that needs four sessions to specify a workflow that could have been written down in an afternoon has paid for that afternoon many times over.
The cost is not abstract. It shows up as an extended timeline, a higher invoice, and — frequently — an agent that still needs corrections after launch because the discovery sessions missed edge cases that a written procedure would have surfaced.
The cost of undocumented processes falls on the client, not the implementer. Every round of "let me show you what I mean" adds time and cost before a single line of agent code is written.
What a documented process looks like before you engage
A process is ready for implementation when a new person could follow it correctly, given only the written version and no other context. That test — the new-employee test — is the clearest measure of whether a process is specified enough for an agent to run from it.
In practice, a documented process means four elements are written down before the first call.
The trigger. A specific, observable event that starts the workflow. Not "when a client needs an update" — "when a project's last status email is more than seven days ago." The trigger must be testable: either it fires or it doesn't.
The inputs. The exact information available when the workflow runs. Field names, data sources, which fields are always populated, which may be empty. An agent cannot use information it was not given.
The output. The specific deliverable the workflow produces. Not "a follow-up email" — a follow-up email with a defined subject line format, a maximum length, and a specific next step offered.
The exceptions. The cases where the workflow behaves differently, each named explicitly. Not "it depends" — "if the client replied within forty-eight hours, skip this cycle." A workflow with fifteen documented exceptions is specifiable. A workflow answered with "it depends" is not.
A process with these four elements written down gives an implementer what they need to build. A process without them makes the implementer the one who writes the specification — at the client's cost.
How to check if your process is ready to document
Before sitting down to write the procedure, it helps to know whether the process is stable enough to document. A process that is still changing week to week will produce a specification that is outdated before the agent is built. A process that the team executes consistently is documentable.
The checklist below identifies whether a workflow is ready to specify:
| Question | Ready | Not ready |
|---|---|---|
| Is this workflow run the same way by everyone on the team? | Yes — or it would be with a written procedure | No — each person does it differently |
| Has this workflow been run at least twenty times in the past three months? | Yes | No — too new or too infrequent to have a pattern |
| Can you describe the trigger without using the word "usually"? | Yes | No — "usually when a client calls" is not a trigger |
| Are the exceptions finite? | Yes — you can name them all | No — new ones keep appearing |
| Does the output have a defined format? | Yes — same structure every time | No — it varies based on context |
A workflow that answers "ready" to all five is documentable today. A workflow with one or two "not ready" answers needs another month of consistent execution before documentation produces a reliable specification.
How to document a process you know but haven't written down
Most founders know their processes well enough to execute them. Fewer have written them down, because the writing itself takes time and the process has always just worked. The following method turns process knowledge into a specification in two to three hours.
Start with a recent instance. Open the last time this workflow ran. What triggered it? Write that down. What information did you use to complete it? List each piece and where it came from. What did you produce? Describe the exact format and content.
Identify the decision points. Look at the workflow again and identify every point where you made a judgment call. "If the client replied, I skipped the follow-up." "If the invoice was over a certain amount, I called instead of emailing." Each judgment call is either an exception (handled differently) or an indicator that the trigger condition needs refinement.
Run through twenty more instances. Go through the last twenty times the workflow ran. Flag every one that was handled differently from the standard path you just wrote. For each difference, write one sentence explaining why. Those sentences are the exception rules.
Write the output definition. Describe the output as if writing instructions for someone who has never seen the workflow before. What does a correct result look like, specifically — length, format, content required, tone? Write it down in one sentence.
The result of this exercise is a rough brief. It is not polished. It does not need to be. An implementer can refine a rough specification quickly. An implementer cannot build from nothing at all.
Three things to have ready before the first call
An implementer can build anything you can describe precisely. The bottleneck is almost never the technology.
Preparation does not require a technical background. It requires sitting with the process and writing it down.
Write the procedure. Take the workflow and document it from trigger to output, step by step, without assuming prior knowledge in the reader. Wherever you find yourself writing "then you check..." — write what you are checking, what each outcome determines, and what happens next in each case.
List the exceptions. Go through the last twenty instances of the workflow and flag every one handled differently from the others. For each difference, write why. Those reasons become the exception rules. This is the step most clients skip — and the source of most corrections after launch.
Define what done looks like. Write one sentence that describes a correct output. If evaluating the agent's output as correct or incorrect takes more than thirty seconds, the output definition is too vague. Tighten it until the check is instant.
A business that arrives at the first call with these three documents gets a working agent on a short timeline. One that arrives without them gets a specification project that costs more than the agent build itself. The documentation work is unavoidable — the only choice is who does it and when.
Frequently asked questions
What should you have ready before hiring an AI agent implementer?
Three things written down before the first call: the workflow procedure (trigger to output, step by step), the exception list (every case handled differently from the standard path, with the reason), and the output definition (one sentence describing what a correct result looks like). These three documents remove the specification phase from the engagement and cut implementation time by more than half.
Why does documentation before the engagement matter?
When a process isn't documented before the engagement starts, documentation becomes the engagement. Each discovery session — observing the workflow live, assembling a specification from examples — adds one to two weeks to the timeline at the client's cost. The documentation work is unavoidable; doing it before the first call means paying for it once instead of across the entire engagement.
What is the new-employee test for process readiness?
The new-employee test asks: could a new person follow this process correctly on day one, given only the written procedure and no other context? If yes, the process is specifiable and the agent can be built from it. If the answer requires prior knowledge, judgment about exceptions, or checking with someone first, the specification is incomplete — and the agent will fail on the same gaps.
How long does it take to document a workflow before engaging an implementer?
A single workflow with clear trigger, defined inputs, a specific output, and a moderate number of exceptions typically takes two to three hours to document fully — including a review of recent instances to surface edge cases. That time investment removes weeks of discovery work from the engagement and produces a brief the implementer can build from directly.
What if the workflow changes frequently — should you wait until it's stable to document it?
Yes. A workflow that is still changing week to week will produce a specification that is outdated before the agent is built. The documentation test is not whether the workflow runs correctly, but whether it runs consistently — the same way, by everyone on the team, with a finite set of exceptions. If it does not, that inconsistency is the problem to solve before the implementation begins. An agent built on an inconsistent process will systematize the inconsistency.
Do you need to solve every exception before the engagement starts?
No. The goal of the exception list is to name the exceptions, not solve them. An exception that is clearly named — "client replied within 48 hours: skip this cycle" — can be built into the control layer. An exception that is vague — "it depends on the client" — cannot. The difference between a solved exception and a named exception is the difference between something an agent can execute and something an agent will mishandle.
What should you not bring to the first call?
A live demo of the workflow. Live demonstrations are the least efficient way to transfer process knowledge — the observer sees one instance, at one point in time, performed by one person. They miss the exceptions, the edge cases, and the decisions that happen differently on the twenty-seventh instance than on the one being shown. A two-page written procedure contains more actionable specification than an hour of live observation.