Most teams automate tasks. The value sits one level up, in the sequences that span several systems and currently depend on a person to carry work from one step to the next. A task is “send the follow-up email”. A process is “qualify the lead, enrich it, assign it, book the meeting, send the prep, log it”. The steps below are the order we use, and the last section walks one real process through all six.
Step 1: Which process should you automate first?
Pick the process that runs most often, follows a recognisable pattern, and already has a digital footprint in systems with APIs. Frequency is what makes the build worth doing; pattern is what makes it possible; API access is what makes it buildable at all. A process that runs twice a year, or lives entirely in phone calls and paper, fails at least one of the three and should be left alone.
One more filter: prefer a process where you can tell, from the outside, whether a run was correct. If nobody can look at the output and say yes or no, you cannot verify the agent and you will end up supervising it forever.
Step 2: How do you map a process an agent can run?
Write down every step, every decision, every system touched, and every point where work waits for a person. Most teams have never actually done this — the process exists in the heads of the people running it. The map is the specification; if two people on the team describe the process differently, that disagreement is a bug you have to resolve before any code is written.
Mark each step with what triggers it, what it needs as input, what it produces, and how long it currently waits. The waiting is the part an agent removes first.
Step 3: Which steps should the agent decide, and which stay deterministic?
Go through the map and split it. Steps with one input, one transformation and one output should be code or an existing automation tool — they will be cheaper and more reliable than a model. Steps that require reading something unstructured and choosing what happens next are the agent's job. A process where every step is deterministic does not need an agent at all, and saying so is part of the work.
This split is also what keeps the system debuggable later. When a run goes wrong, you want to know immediately whether a judgement was wrong or a script was.
Step 4: How does the agent reach each system?
Every system in the map needs a typed contract: what the agent can call, which arguments are valid, what comes back, and what the tool refuses to do. Write the contracts before the prompts. This is whatModel Context Protocol standardises, and it is also where access scoping belongs — read-only where the process only reads, write access only on the steps that genuinely write.
Step 5: Where does a human still approve?
Put a gate in front of anything irreversible or externally visible. In our own systems the gate is an agent whose only job is to approve or reject before work reaches the build stage; nothing proceeds without passing it. The gate is not a review of the finished output — it is a check on the input before effort is spent, which is what keeps it fast enough that people actually use it.
Step 6: How do you verify the process actually ran?
Two separate checks, and most teams only build the first. The first is verification: an independent step that reads the acceptance criteria itself and can block a result. It cannot be the same agent that produced the work, because a producer already believes its output is correct. The second is a delivery check: did the finished work reach its destination? A job that completes successfully and delivers nowhere looks healthy in every model-level metric and is worth nothing to the business.
A worked example: our own publishing process, end to end
This is the process running on our own host, in the order the six steps above describe. It publishes this blog.
- Trigger. A scheduled job fires twice a week — Tuesdays and Fridays at 09:00 — and can only select a topic from a pre-approved set of niches, after checking the topic is not a duplicate of something already published.
- Approval gate. The operator agent is the hard gate between idea and build. Nothing reaches the drafting stage without passing it.
- Draft. The content-studio agent turns the approved topic into a publishable draft. It has logged 457 sessions, more than any other agent in the fleet.
- Verify. A separate QA agent checks the draft against the manifest. It does not know what the drafting agent intended, which is the entire point — it reads the criteria itself. A daily sweep catches anything sitting unverified.
- Ship. The publisher agent posts only QA-verified work. It refuses to publish anything unverified and refuses to silently skip a platform that failed, so a delivery failure surfaces as a failure rather than as silence.
- Watch. A continuous watcher moves verified work forward, a daily publisher health check confirms the chain is alive, and a second client track runs the same pipeline on Mondays and Thursdays.
The architecture and the constraints are written up in full in thecontent publishing pipeline case study. The same shape — gate, do, verify, deliver — is what thelead qualification agent build uses, with scoring in place of drafting.
When not to automate a business process with AI agents
- It runs less than monthly. The build and the maintenance will outlast the benefit.
- Every step is deterministic. Use a workflow automation tool. It will be cheaper and it will not surprise you.
- The process is genuinely creative. Strategy, design and relationship work are not chains of steps.
- The tools have no API. Digitise first. No framework can reach a system that does not expose one.
- Nobody can define the process. Map it first. An agent built on a process nobody agrees on automates the disagreement.
If the first two apply, a hosted tool may be the whole answer — theno-code AI agent platforms comparison covers where those stop being enough. If you are trying to size the work,how long it takes to build a production AI agentbreaks the timeline down by stage.