What to automate first with AI agents, and what to leave alone for six months

8 minute read · Written by the team that builds UtilitySpaces. More about UtilitySpaces.

Start with jobs that are high-frequency, low-stakes, read-mostly, and already written down somewhere. Leave alone anything irreversible, anything that needs judgement about a relationship, and anything nobody has ever described in writing. The first category pays back within a week. The second is where teams lose a month and their nerve.

The ordering below is the one we arrived at after handing an agent a job it should not have had. If you are still deciding whether the category applies to you at all, the piece explaining what an agentic workspace actually is is the better place to start.

How do I tell whether a job is a good candidate?

Ask whether you could hand it to a new starter on their first Monday with nothing but a written page. If yes, an agent can probably do it. That is the whole test, and it decomposes into five questions you can answer in two minutes per job, without a spreadsheet and without a consultant.

Call it the handover test. A job has to pass all five parts, not most of them.

• Frequency. Does it happen weekly or more often? Automation has a setup cost and a maintenance cost, both paid in your attention. A daily job amortises that in days. A quarterly one never does.
• Reversibility. If the output is wrong, what does it cost to undo? A mislabelled email costs a click; a refund to the wrong customer costs money and a conversation. Rank candidates by the worst plausible mistake, not the likely one.
• Shape of the input. Is what arrives structured, or at least consistent? Orders from a shop and submissions from a form are. A photograph of a handwritten note forwarded by a supplier is not, and every exception is a branch somebody has to specify.
• Checkability. Can a person look at the output and tell whether it is right in under a minute? This is the part people skip, and it decides whether oversight survives a busy week. If verifying takes as long as doing, you have not automated anything.
• Written down. Does a document exist describing how the job is done, in enough detail that a competent stranger could follow it? Not the ideal process. The actual one, including the bit where you check the address twice on large orders.

The fifth part does the real work, and it comes with a blunt corollary: if you cannot write the rule down, an agent cannot follow it, and the problem is your process, not your tooling. Buying software to skip that step is an expensive way to discover the step was the job. What you are missing is a standard operating procedure, worth having whether or not an agent ever reads it.

What should I automate in week one?

Pick one job that runs every day, reads more than it writes, and produces something a person glances at rather than acts on blindly. In practice that means order triage, inbound lead qualification, or a recurring report. All three are frequent, cheap to get wrong, and easy to check at a glance.

Order triage

For an online shop, the agent reads new orders as they land and posts a short summary into the channel where somebody already is, with the odd ones flagged and the reason stated. An address that does not match the billing country. A quantity well outside the normal range for that product. A payment method that fails more often than it succeeds. An order that looks like a duplicate of one placed ten minutes earlier by the same customer.

Nothing is cancelled, refunded or edited. The agent flags; the human acts. It passes on every axis: it runs constantly, a missed flag costs no more than having no flags at all, orders are structured, and the output is a list you scan in fifteen seconds. The flagging is what takes the attention anyway, not the clicking.

Inbound lead qualification

An enquiry arrives. The agent reads it, extracts what was asked for, checks that against the things you actually sell, notes what is missing, and drafts a reply. The draft stays in the thread until a person sends it. That last clause is not a nicety; it is the difference between a useful assistant and an unsupervised salesperson with your domain name.

This is where the write policy earns its place. Reads are never gated, because a wrong read is recoverable and a wrong write is durable, but a send through a connection left on “Ask a person first” waits until a person approves it — see what the approval queue does and does not cover. The mechanics of that boundary are the subject of a separate piece on agent permissions and the approval gate.

Recurring reporting

Every Monday morning, the numbers you would otherwise pull by hand, written into the same channel, with the anomalies called out rather than buried under the ones that are fine. Sales against the previous week. Stock that runs out before the next delivery. Anything that moved more than you would expect, stated as a sentence.

This is the canonical standing schedule that runs on its own timetable: a job the agent does every week without anyone asking, and the one with the most dangerous failure mode, covered further down.

Inbox and document triage, if you want a fourth

Sorting, labelling and summarising incoming mail or documents, with a hard rule that the agent never replies. Read-only by construction, and a wrong label costs a second to fix. Add it only after the first job has run for a week without surprising you.

Which jobs pass the test, and which only look like they do?

Most of the obvious candidates pass. The interesting rows are the ones that fail, because they fail for reasons that stay invisible until you apply the test deliberately. Below, six jobs scored against the five parts. Read the last two rows first.

Refunds are the trap. Every mechanical signal says automate it, and the single non-mechanical one says do not.

What should I leave alone for six months?

Anything that spends money without a person in the loop. Anything that talks to a customer unsupervised. Anything that deletes. Anything touching payroll, invoicing or refunds. Anything where the right answer depends on relationship history living in somebody’s head rather than a record. That list is not cautious; it is the list of things that are expensive to undo.

Two more, less obvious. First, anything you only do twice a year: the automation rots before it pays for itself, because the connected application changes, or your process does, and you find out on the day you needed it. Second, anything whose process changes every month. You will spend more time rewriting the rule than you ever spent doing the job.

Six months is not a magic number. It is roughly how long it takes to know what your agents get wrong and how you find out. Come back to the list then, with evidence, and promote one item.

Why does the recurring job cost money when a one-off does not?

Because the scarce thing is unattended work. In UtilitySpaces the metered, billable resource is standing schedules — recurring autonomous work that keeps producing output whether or not anyone asked for it this morning. Chat and one-off tasks are deliberately unmetered on paid plans. Pricing follows risk, not usage.

The thing that costs money is the thing that runs while you are asleep, which is also the thing that deserves the most caution. A one-off task has a person watching the result by definition; a schedule does not, unless you build the habit. Making the schedule the unit you pay for keeps its number visible, and a visible number occasionally gets pruned.

How should I actually start?

One job, one agent, one week, watching every single run before you stop watching. Not three jobs in parallel to see which sticks — when two misbehave at once you cannot tell whether the problem is the agent, the rule or the connected application, and you end up switching everything off.

Concretely: write the rule down before configuring anything, exceptions included. Give the agent scoped access to exactly the applications the job needs and nothing more — not your password, and not a credential reaching systems outside the job. Run it against real data but leave every connection on “Ask a person first”, even the ones you expect to allow every time, so every write it proposes waits for you to read it. Then read the thread each day and note every run where you disagreed with the output, and why. Ten such notes beat any amount of upfront specification.

How do I know when to widen the scope?

Two numbers, both of which you already have. The first is the approve rate on the gate: what proportion of the agent’s proposals you accept without editing. The second is whether anybody has had to redo the agent’s work — not reword it, actually do the job again. If the first is high and the second is zero, widen.

A high approve rate alone is not enough, because it might mean the gate has stopped being read. Rework is the honest signal and it is impossible to fake. If people are quietly redoing what the agent produced, the approve rate is measuring politeness.

When both hold for a fortnight, widen in one dimension at a time: a second job of the same shape, or the existing job running more often, or one connection set to run without asking after you have agreed with its proposed writes thirty times without changing them. Never all three at once.

Where does this go wrong?

Three ways, in ascending order of how long it takes to notice. You automate a broken process and it breaks faster. You create a schedule nobody reads. Or you quietly stop checking the output, at which point the system is still running and no longer trustworthy, and nothing on screen tells you which state you are in.

The first is survivable. Automating a bad process does not fix it; it industrialises it, and the mistakes arrive at machine speed. If your first week produces a burst of visibly wrong output, that is information about the process, and it was true before you automated anything.

The second is worse than doing nothing. A weekly report landing in a channel nobody opens manufactures the feeling of oversight without any of the substance: you believe you are watching the numbers, because the numbers are being produced. Delete any schedule nobody has referred to in a month. It is costing you a false sense of control, and on a metered plan it is costing you money too.

The third is the quiet one. The moment the agent’s output stops being checked is the moment it stops being trustworthy, and there is no alert for it. The defences are structural: keep connections on “Ask a person first” until they have earned more, keep the log append-only so what happened stays checkable, and keep the number of gates small enough that reading them stays realistic. A gate that fires on every trivial action teaches people to click through it, and then you have built a system that records rubber-stamps.

None of this requires committing to anything. A free demo workspace expires exactly sixty minutes after it is created, which is enough to point an agent at one read-only job and see whether the output is something you would actually read on a Monday. If it is not, you have lost an hour and learned something true about your process.