Section 1
Five words you actually need
Skip the vocabulary that does not change a decision. These five do. Trigger: the event that starts an automation. A form submitted, an email arriving, nine o'clock on a Monday. Action: what happens next. Send, create, update, notify. Prompt: the instruction you give the model. In practice it is a brief, and the same rules apply as when briefing a contractor: context, task, format, constraints. Context: the information you hand the model along with the instruction. Most quality problems are context problems, not model problems. Human in the loop: a step where a person approves before anything leaves the building. This is your main safety control and the reason most first automations are safe to run.
Section 2
Start where a mistake is cheap and visible
The instinct is to start with the customer-facing thing, because that is where the excitement is. It is the worst place to learn. Errors are public, irreversible, and land on the people whose opinion matters most. Start internal. Meeting notes into action items. Enquiry emails classified and routed. Invoice data extracted into a sheet. Weekly numbers pulled into a summary you already write by hand. The filter is three questions. Does this happen at least weekly? Is there a clearly right answer, so you can tell when it is wrong? If it fails, do you find out the same day? Anything clearing all three is a good first build. Anything failing the third is not, whatever it saves.
Section 3
The two hour test
Give any candidate automation two hours. Not two weeks. In two hours with an orchestration tool and a model, you can usually build a rough version of a genuinely useful workflow. If two hours produces nothing that works at all, the task is more complicated than it looked, and that is worth knowing before you commit a fortnight. Build it badly on purpose the first time. Hard-code things. Skip the edge cases. Run it on ten real examples and read every output yourself. Ten outputs teach you more about whether the idea is sound than any amount of planning, and they surface the exceptions that never appear in how you described the process. Only once the rough version proves useful should you invest in making it reliable.
Section 4
Where the ceiling is without an engineer
Being honest about this saves months. You can go a long way alone: connecting standard tools, classification, drafting, extraction, summarising, scheduled reports, routing, approvals. That covers a large share of the friction in a small business. You will hit a wall in four places. Custom logic more complex than a few branches. Writing to a system with no ready-made connector. Anything needing reliability guarantees, because handling failures properly is engineering work. And anything touching sensitive data, where the configuration is a legal exposure rather than a technical one. Recognising the wall is the skill. The failure mode is not stopping too early. It is spending three months on an increasingly fragile workflow an engineer would have done properly in a week, and that nobody but you can maintain.
Section 5
Safety rules for someone who is not technical
NIST frames AI risk management around trustworthiness, design, evaluation, and use, which for a founder building alone comes down to a short list. Nothing sends without you until it has been right for a month. Draft, review, send. Keep customer identifiers, payment details, and anything confidential out of prompts unless you have checked what the vendor retains. Give every connection the narrowest permission that works, read-only wherever possible. Write down what each automation does and how to switch it off, because in six months you will not remember. And check what your tools do with your data before you connect the system that holds your customer list. None of this is onerous. All of it is much cheaper now than after an incident. The employment side of the question is covered in [AI Automation and Job Displacement: What Founders Should Know](/blog/ai-automation-and-job-displacement-what-founders-should-know).
Section 6
Knowing whether it worked
Measure the thing you were annoyed by. If the complaint was that quoting takes all Friday, measure how long quoting takes. Not tokens, not runs, not tool count. Useful numbers: hours the task consumed before and after, how often you correct the output, how long it takes to notice a failure, and whether anyone other than you can run it. You are ready to start if you have a task that repeats weekly, a clear definition of a right answer, and two hours. You are not ready if the plan begins with choosing a platform, or if the first candidate is customer-facing and irreversible. Start with something dull, get one working, and let the second idea come from what the first one taught you. For the tool landscape, see [Top AI Automation Tools for Startups in 2026](/blog/top-ai-automation-tools-for-startups-in-2026); on explaining the change to your team, [Storytelling in the Age of AI and Automation](/blog/storytelling-in-the-age-of-ai-and-automation).