A polished AI demo is not ready for customers if someone must quietly repair its output before every delivery. The real test is whether the workflow can expose uncertainty, recover from bad output, and still produce a result you are willing to send.
At 8:12 a.m., the shortlist email arrived.
For this illustrative composite, I will call the founder Ama. She was sitting in a small coworking room in Accra, holding a paper cup of coffee she had already forgotten to drink. Her procurement assistant had made the final round for a pilot with a regional distributor. The evaluation call was that afternoon.
Then she opened the demo history.
The assistant had produced a confident recommendation from an incomplete supplier record. A contractor had spotted the missing field, searched the original document, corrected the answer, and reset the demo before the prospect saw it. The screen looked polished because a person had repaired the evidence underneath it.
If the evaluator uploaded a similarly incomplete document during the live call, the assistant could recommend the wrong supplier. Ama could lose the pilot that afternoon.
She had a shortlist email. She did not yet have a workflow she could trust.
The invisible work behind the polished answer
The model was doing what Ama had asked. It extracted terms, compared suppliers, and wrote a short recommendation. On clean sample documents, the result looked ready.
The trouble lived between extraction and recommendation.
A missing delivery date became a blank value. The comparison treated that blank as if it carried no consequence. The final answer then sounded more certain than the underlying record allowed. Every stage worked according to its narrow instruction, yet the combined workflow created a business decision from incomplete evidence.
The contractor’s manual correction had hidden this weakness during earlier demos. That work mattered, but it had never been named as part of the product. It happened in a private message, followed by a database edit and another run.
This is common when founders move quickly. Manual work helps us learn what the product needs before we spend runway automating it. The danger begins when we mistake that manual work for a temporary inconvenience instead of treating it as evidence about the product’s actual boundaries.
I saw a related issue while thinking through what malformed records do to a delivery test. The record that breaks the workflow often tells you more than the hundred records that pass.
The decision was smaller than rebuilding the product
Ama had a few hours before the call. She could cancel, run the polished path and hope, or narrow what the demo promised.
Rebuilding the extraction system before lunch was fiction. Adding more instructions to the model might improve the example in front of her, but it would not create a reliable recovery path for the next incomplete record.
So she changed the decision the workflow was allowed to make.
When required supplier information was missing, the assistant would stop before recommending a winner. It would identify the missing evidence and place the record into a review queue. Ama also added a visible status to the demo so the evaluator could see which comparisons were complete and which required a person.
That reduced the apparent magic. It also made the product more honest.
The product could still read and compare documents. It could still prepare the evidence for a purchasing decision. It would no longer pretend that an incomplete record supported a final recommendation.
This distinction matters in AI product building. Model quality receives most of the attention because it is easy to demonstrate. Workflow quality determines what happens when the model meets a damaged PDF, an ambiguous request, or a field the customer assumed would always exist.
Manual repair should leave a product trace
After the call, Ama kept the review queue.
Each correction now had to record three things: what the system received, why the output could not be used, and what the reviewer changed. That turned private rescue work into material for product decisions.
If the same missing field appeared repeatedly, Ama could decide whether to improve extraction, require the field during upload, or keep human review at that point. If failures varied widely, she would know that another narrow rule would create confidence without much coverage.
This is where manual operation earns its place. A person can protect the customer while the team studies the failure. But the intervention must leave a trace. Otherwise, the product dashboard reports success while someone carries the real workflow in their head.
The same principle surfaced in Ama’s WhatsApp procurement workflow: the useful product boundary appears where information becomes a decision, not where the model finishes writing.
What I check before calling an AI workflow ready
I now look beyond the best output on the cleanest input.
I want to see the damaged document, the missing field, and the request that could mean two different things. I want to know whether the workflow detects the problem, who reviews it, what the customer sees, and whether that intervention is recorded.
A founder on limited runway does not need to automate every exception before selling. They do need to know which exceptions can produce a harmful decision. Those deserve a stop condition before they deserve a clever prompt.
At the end of the afternoon, Ama’s demo contained one extra status and one less promise. An incomplete supplier record entered the workflow. The assistant declined to rank it, named the missing evidence, and sent it for review.
The evaluator saw the pause.
Ama left it on the screen.
Comments
No comments yet.