Start with the job
The order that works starts with the job. Find the work you repeat every week, the piece that stalls whenever one person is on holiday, and write it out in plain sentences a new starter could follow. Only then is the tooling question worth asking: whether that job needs an agent, a script, or a better checklist. Automation projects that begin with the tool end up looking for something to point it at.
The word agentic has been stretched to cover everything from a chat window to a fully autonomous system. For a business with five, ten or twenty people, the useful meaning is narrow and practical: work that starts itself, moves through several systems, and arrives on a person's screen ready to approve.
Workflow, agent, and why the difference matters
Anthropic's engineering guidance draws the line plainly. A workflow is a system where language models and tools are orchestrated through predefined code paths. An agent is a system where the model directs its own process and decides for itself which tools to use along the way. Both count as agentic systems. They behave very differently once a real business depends on them.
Workflows are predictable and cheap to test, which is what you want for work that follows the same shape every time. Agents absorb variety, and they pay for it in latency, cost and supervision. The same guidance recommends finding the simplest solution that works and adding complexity only where the simpler version falls short. For a small business, that advice is worth more than any tool comparison.
The four parts of anything worth building
A working agentic workflow has four parts. Pilots that quietly die are usually missing one of them.
A trigger
Something starts the run without a person deciding to start it. A form submission. A new order. A date in the calendar. An email landing in a shared inbox. While starting it remains somebody's job, you have built a tool, and tools get forgotten in a busy week.
Tools with narrow permissions
The model needs access to specific systems, scoped tightly. Read the enquiry record. Draft in the mail client. Write one row into the sheet. Broad access is the common failure mode. A workflow with the run of your systems will eventually do something correct in form and wrong in effect, and you will find out from a customer.
A checkpoint
A named person sees the output before it reaches a customer, a supplier or a filing. OpenAI's guide to building agents makes the same point from the other side: actions that are sensitive, irreversible or high stakes should trigger human oversight until confidence in the system has been earned, with cancelling orders, authorising large refunds and making payments given as examples.
A record
Every run leaves a trail. What triggered it, what the model was given, what it produced, who approved it, and what happened afterwards. Without that trail you cannot improve the workflow, defend a decision, or explain to a customer why they received what they received.
What this looks like in a business of five people
Take a hypothetical commercial cleaning firm with five staff and one person handling quotes. An enquiry arrives through the website. The workflow reads it, pulls the site size and postcode into a standard shape, checks them against the published price bands, drafts a quote and a covering email, attaches the insurance documents, and stops.
The owner opens the draft, corrects one figure, and sends it. Nothing left the building unread. That is the whole design, and the division of labour inside it is the point: the model does the assembly whenever the enquiry arrives, and the person keeps the judgement and the signature.
The example is illustrative and carries no claim about hours saved, because that depends on the business and the systems it already runs. What it does show is where the work moves. Run the same pattern across three or four jobs and the owner reviews routine output rather than producing it, which is a different use of an afternoon.
Where the human has to stay
UK law has a view here, and it moved recently. The Data (Use and Access) Act 2025 replaced Article 22 of the UK GDPR with new Articles 22A to 22D, and the principal data protection provisions were commenced on 5 February 2026. A decision counts as based solely on automated processing where there is no meaningful human involvement in it.
Where such a decision carries legal or similarly significant effects for a person, safeguards apply. Tell them it is happening, give them a route to obtain human review, and let them contest the outcome. The ICO is firm about what meaningful involvement means: it has to be active, and a review that approves whatever the screen shows has reviewed nothing. The regulator consulted on updated automated decision-making guidance between 31 March and 29 May 2026, so the detailed interpretation is still settling.
For most small businesses this rarely bites. Drafting a quote, sorting an inbox, updating a stock figure: none of those produces a legal or similarly significant effect. Rejecting a job applicant, refusing credit or closing an account can. Work out which side of that line each workflow sits on before you switch it on, and write the answer down where your team can find it.
Choosing the first job
Three tests settle it. Frequency: does it happen at least weekly? Sameness: does it follow the same shape each time? Reversibility: if the output is wrong, can you catch it before anyone outside the business sees it? A job that passes all three is a good first build. A job that fails the third needs its checkpoint designed before anything else gets built.
Ordinary workflows that never forget, never take a holiday and never leave a customer waiting until Monday are the place to start. Build them first and run them for a quarter. The case for a model-driven step then comes from your own exception log rather than from a vendor's demonstration.
The limits worth stating
Unattended running is a separate decision, taken deliberately and kept to low-risk actions such as filing a copy of an invoice or tagging a record. Everything else keeps its review step, and that review step is what makes the rest of the design defensible to a customer or a regulator.
The jobs that suit this treatment are the ones nobody wanted: rekeying, chasing, formatting, checking that two systems agree. The jobs that stay are the ones customers pay for, and the ones where a person's judgement is the whole value of the output.
A prompt is one part of a system that also includes triggers, credentials, error handling, logging and an owner. Businesses that treat the prompt as the product spend their second month rebuilding, because the parts that keep a workflow running were never designed in the first place.
The tooling question
Platforms matter less than design, and they are easier to change than most people fear. Zapier connects applications through triggers and actions and, on its own how-it-works page checked in September 2026, advertises connections to more than 9,000 tools. Make builds automations as visual scenarios assembled from modules, with routers, iterators and error handlers, and its product page, checked the same week, lists over 3,000 app integrations. n8n describes itself as an AI workflow automation platform, offers self-hosting alongside a managed cloud, and ships under a fair-code licence.
Choose on two criteria. Where does your data sit while the workflow runs, and who can read the logs. Everything else is preference. A workflow you can explain to your accountant costs less to keep running than one that needs a specialist every time it breaks.
Security and access, before go-live
Give the workflow its own account, never a person's. Grant the narrowest permission set that lets it finish the job, and review that set when the job changes. Keep credentials out of documents and spreadsheets. Decide in advance what happens when a run fails: who is told, how quickly, and what the customer sees in the meantime.
Confidential material deserves an explicit rule. Decide which systems the workflow may read from and which it may never touch, and record that decision alongside the workflow itself, so the next person to edit it inherits the boundary rather than guessing at it.
Knowing whether it worked
Write the baseline down before you build. How many quotes went out last month, how long each one took, how many needed chasing. Measure the same three numbers a month after go-live. Automation that cannot move a number you wrote down in advance has not yet earned the next build.
Count the exceptions too. Every run the model handled badly is a specification you were missing. Feed those back into the instructions, tighten the permissions, and run it again. Repeat that until the exceptions stop being interesting, because a workflow nobody has to think about is the thing worth owning.
Where to start this week
Pick one job. Describe it in ten sentences a new starter could follow. Name the trigger, name the tools, name the person who signs, and name the record. Build the version with no model in it at all and see how far plain automation gets you. Add model-driven judgement only at the points where the plain version keeps getting it wrong.
That sequence keeps the cost small, the risk visible and the result explainable. It also gives you something your competitors' pilot projects tend to lack: a workflow that still runs in six months, because somebody owns it and everybody understands it.