Founder/operator proof

Before you add AI, make the work understandable

A practical way for a small business to choose its first AI workflow, keep human judgement in the loop and know whether the change actually helped.

By Amrish Seunarain22 September 20264 min read

Updated 17 October 2026

Key takeaways ↓

Editorial illustration of a founder's desk with an abstract workflow on a laptop, a paper checklist and a pencil. — AI-generated editorial illustration. Not a photograph of a customer, operating site or live product interface.

Start with the job, not the model

There is a familiar pattern whenever a new technology becomes accessible: the conversation starts with the tool. Which model should we use? Which integration should we buy? Those questions are easier to answer once a more ordinary question has been settled: what work are we trying to make better?

An owner who spends part of every afternoon sorting supplier messages may have a useful first AI task. An owner who cannot explain where an approved order is recorded has a process problem to resolve first. Adding a fluent assistant to an unclear process can make the confusion move faster.

Across infrastructure, support and software, the underlying responsibility has stayed much the same for me: understand the job, make its handovers clearer and leave something that can be operated reliably. AI belongs inside that discipline, not outside it.

Choose something small enough to check

A sensible first workflow has a recognisable input, a limited task and an output somebody can verify. Summarising a support thread for a technician is easier to evaluate than asking a model to run customer service. Drafting a response for review is narrower than granting permission to send messages without oversight.

Take an illustrative supplier invoice workflow. The assistant could propose the supplier, invoice reference, dates, line items and category. A person then checks those suggestions against the original document. That is useful assistance without assuming that extracted text is correct or that a payment is authorised.

Keep the source attached to the record. If a number or category looks wrong later, the team should be able to return to the original material. A polished summary without a retrievable source is a weak foundation for business decisions.

Separate understanding from authority

Models can produce convincing text even when important context is missing. They should not decide their own access rights. Give the assistant only the services and records needed for the task, and let the application enforce those boundaries when an action is attempted.

A draft instruction to create a task is different from an approved instruction to change a live system. The same distinction applies to quotes, customer messages and financial records. Show the proposed change in understandable language before asking the responsible person to approve it.

Treat external material as information, not instructions. An email, invoice or web page can contain wording that asks an assistant to ignore its rules. It must not gain authority merely because the assistant reads it. The workflow's permitted actions should come from the operator and the application, not from an untrusted document.

Test an awkward day, not just the happy path

A demonstration often uses a clean example. Real work includes duplicate documents, missing pages, unfamiliar wording and records edited by another person while the assistant is preparing a response. Include those situations in the trial. They reveal whether the system is robust or merely persuasive.

Ask what happens if a provider times out, if the same request is retried or if the assistant is no longer permitted to access the record. A failed attempt should leave a visible state and a safe next step. It should not silently create the same expense twice or overwrite a more recent human edit.

Plan a manual route. The person doing the work should be able to finish the job without waiting for a model to recover. Keep a record of the proposal, the approval and the result so that a mistake can be understood and, where possible, reversed.

Measure whether the people are better supported

Before the trial, note roughly how long the ordinary task takes and what makes it difficult. Afterwards, compare the time spent reviewing and correcting the assistant's output, not just the seconds it took to generate an answer. A fast draft that requires extensive repair may not be an improvement.

Look for practical changes: fewer missed handovers, easier retrieval of information, clearer ownership and less repetitive typing. Ask the people using the workflow where they still feel uncertain. Their feedback may point to better form design or clearer wording rather than a different model.

Do not turn a small successful experiment into a broad claim that the business has been transformed. Expand one boundary at a time: another document type, another reviewed action or another team member. More autonomy should follow evidence and a deliberate permission decision.

For a South African founder building with limited time, a useful starting point is one repeated task, one responsible reviewer and a short set of test cases. The goal is not to look more automated. It is to make the next working day a little calmer and the business a little easier to run.