What AI can automate in a business: six job types
Use-case lists are organised by department, which tells you nothing about whether it works. Six job types, sorted by how cheaply you can check the output.
You have used ChatGPT. It writes a decent email, it summarises a document, and somewhere in the back of your mind is the suspicion that this should be worth more to your business than a faster way to draft emails.
So you go looking, and every answer is a list. Sales, support, finance, HR, marketing, each with a bullet under it. The lists are all roughly the same list. None of them tells you whether any of it will work in your company, what it will cost to keep running, or which one to build first. So the project stalls in the interesting-but-unbudgeted pile, which is where most of them stay.
The problem is the axis. Sorting AI work by department is like sorting tools by which room of the house they live in. It groups things that behave nothing alike and separates things that behave identically.
We build these systems for clients and run them on our own business, including the daily agent that manages this websiteâs search visibility. We have also spent 18 years being the team other agencies hand their client work to, which means we get asked this question by people who have to give their own clients an answer. What follows is the sorting that actually predicts whether a piece of AI work will hold up: six job types, ordered by how cheaply you can check the output.
The short answer
AI does six kinds of job in a business: extraction (turning a mess into fields), classification (deciding which bucket something goes in), retrieval (answering from your own documents with the source attached), monitoring (watching a stream nobody has time to watch), generation (producing a draft a person finishes), and action (carrying out multi-step work inside live systems). What separates the ones that pay from the ones that stall is not the department, it is how expensive it is to check the output. Extraction and classification can be checked mechanically, which is why they are the cheapest reliable wins and almost nobody starts there. Generation, the thing the chat window does, is the only one of the six with no correct answer to check against, and it is where everyone starts.
The lists are organised by department, which is the wrong axis
Ask an answer engine what AI can automate beyond chatbots and you get a department list. We ran three phrasings of that question this week across the search-grounded models. The answers were near-identical: lead ops and sales admin, support triage, reporting, finance ops, HR and admin, document processing, marketing production, IT support. Reasonable items, sourced from a dozen different consultancy blogs, and every one of them organised by the org chart.
Watch what that hides. âFinance opsâ contains invoice data extraction, which works reliably today and can be checked line by line against the PDF it came from. It also contains cash-flow forecasting, where the output is a claim about the future that nobody can verify until it is too late to matter. Those two things share a department and share nothing else. A list that puts them under one heading has told you where to look and nothing about what you will find.
The same split runs through every heading. âSupportâ contains ticket routing, which is measurable to two decimal places, and it contains drafting the reply that goes to your biggest client, which is not. âMarketingâ contains audience segmentation and it contains writing the copy. Same department, opposite risk profiles, opposite verification costs, opposite answers to the question of whether you should build it.
Sort by the job instead and the picture is stable. Every AI system in a business is doing one of six things, and each one has its own way of being checked, its own way of failing, and its own honest verdict.
1. Extraction: turning a mess into fields
You have material in a shape a computer cannot use. Invoices as PDFs. Contracts as scans. Enquiry emails with the address and the delivery date buried in a paragraph. Call recordings that contain three facts worth keeping. Extraction reads the mess and returns structured fields.
How you check it. Against the source, field by field. The invoice either says 4,812.00 EUR or it does not. This is the cheapest verification in the whole list, because the correct answer exists, it is sitting right there in the document, and checking it needs no seniority and no judgement. You can also check it in bulk: run 200 historic documents you already have correct data for, and you have a measured accuracy rate before anything goes near production.
How it fails. Quietly, at the edges. A second page nobody expected. A supplier who puts the total in a different place. A comma where the rest of the world uses a full stop. The main line items are almost always right, which is precisely what makes the exceptions dangerous, because after two good weeks people stop looking.
Verdict. The most reliable category and the one with the clearest arithmetic. If somebody in your company retypes information from one screen into another, that is extraction, and it is usually the first thing worth building.
2. Classification: deciding which bucket something goes in
Given a thing, pick a label and route it. Is this enquiry a sales lead, a support request, or a supplier chasing an invoice? Is this ticket urgent? Does this CV meet the stated requirements? Does this expense belong to the client project or to overheads?
How you check it. With a labelled sample, which is the strongest position you can be in. Take 300 items your team has already sorted, run them through, and compare. You get a number. Better than that, you get the shape of the errors, so you can decide which mistake you would rather make. Routing an urgent ticket to the normal queue costs you a day. Routing a normal ticket to the urgent queue costs you a mild irritation. Those are not the same error, and a classifier can be tuned to prefer one over the other, deliberately, with the tradeoff written down.
How it fails. Predictably, and mostly on the categories that were vague to begin with. If two of your buckets overlap in the minds of your own staff, no model will separate them either. That is a definition problem wearing a technology costume.
Verdict. The most underrated of the six. It is unglamorous, it demos badly, and it quietly removes the triage work that eats the first hour of somebodyâs morning. It is also the only category where you can state your accuracy before you commit.
3. Retrieval: answering from your own material
The job everybody means when they say âan AI trained on our contentâ. The system takes a question, finds the relevant passages in your own documents, and answers from those, with the sources attached. Internal knowledge lookups, customer-facing assistants on a site, a support agent asking what the warranty terms are for a 2023 order.
The important word is grounded. A model answering from its own training is guessing at your business. A model answering from your documents is reading, and the passage it read is the thing that makes the answer checkable.
How you check it. Follow the citation. If the answer cannot show you the passage it came from, treat it as unverified, because that is what it is. This is why the citation is the product and the answer is the by-product. A grounded assistant without visible sources has thrown away the only thing that made it safe.
How it fails. Confidently, when the answer is not in the corpus. This is not a quirk you can prompt your way out of. The clearest published account of it comes from the researchers at OpenAI who set out the mechanism in Why Language Models Hallucinate (Kalai, Nachum, Vempala and Zhang, September 2025): âlanguage models hallucinate because the training and evaluation procedures reward guessing over acknowledging uncertaintyâ, and they persist âdue to the way most evaluations are gradedâ, since âguessing when uncertain improves test performanceâ. A model that says âI donât knowâ scores worse on the benchmarks it was optimised against. So the design job is not to hope for honesty. It is to build the conditions where abstaining is the easy path: a bounded corpus, a required citation, a confidence floor, and a clean handoff to a person when nothing good is found.
Verdict. Genuinely valuable, and the one most often built badly. The difference between a useful assistant and a liability is entirely in whether the retrieval and the abstention were designed, or assumed.
4. Monitoring: watching a stream nobody has time to watch
Something changes constantly and no human is going to sit and watch it. Prices on competitor sites. Mentions of your brand. Error rates after a release. Which of your pages an answer engine started quoting, which is now a real search visibility question rather than a curiosity. Anomalies in transactions. Monitoring reads the stream continuously and raises a hand when something crosses a line.
How you check it. Asymmetrically, and this is the important part. You can inspect everything it flagged, easily. You cannot see what it did not flag. False positives announce themselves and cost you an interruption. False negatives are silent and cost you the thing you set it up to catch. Any honest monitoring build includes a way to sample the unflagged stream on a schedule, precisely because the failure mode is invisible by construction.
How it fails. By going quiet and being mistaken for working. A monitor that has stopped receiving data looks exactly like a monitor with nothing to report.
Verdict. Worth it when the realistic alternative is nobody watching at all, which it usually is. Judge it against the status quo of no coverage, not against a hypothetical perfect analyst.
5. Generation: producing a draft a person finishes
Copy, code, images, replies, first-pass reports, proposal boilerplate, the summary of a meeting. The category the whole world formed its opinion of AI from, because it is what happens in the chat window.
How you check it. You do not, in any mechanical sense. There is no correct answer sitting somewhere to compare against. There is only judgement, and the judgement has to come from somebody qualified to have produced the work in the first place. That is the entire economics of this category in one sentence: the check requires the same seniority as the task.
How it fails. By being plausible. Extraction fails visibly, classification fails measurably, generation fails by producing something that reads well and is subtly wrong, in the specific way that survives a tired skim at 5pm.
Verdict. Real value, particularly for volume and variation work where the alternative was not doing it at all: forty ad variants, thirty product descriptions, the first draft of a report that used to start from a blank page. But it is the hardest of the six to measure, it is the one where the saving is most often imagined, and it is a strange place to start a companyâs AI programme. It is also, being the chat window, where every company starts.
6. Action: multi-step work inside live systems
The agentic category. Not âdraft a replyâ but âread the enquiry, check availability in the calendar, book the slot, send the confirmation, update the CRMâ. Multiple steps, real systems, actual consequences.
How you check it. Not afterwards. Once an email has gone to a customer or a record has been overwritten, review is archaeology. Verification in this category means an approval gate placed before the effect, a hard limit on what the system can reach, and a log good enough to reconstruct what happened. The right question is not âhow accurate is itâ but âwhat is the worst thing this can do before a human sees it, and can I undo thatâ.
How it fails. Expensively, and in compounding fashion. Six steps at 95% each is 74% end to end.
Verdict. The category with the highest ceiling and the shortest usable leash. Which brings up the thing the vendor material never mentions.
Reliability is shorter than it looks
METR, a research organisation that evaluates model capability, publishes a metric called the time horizon: the length of task, measured in how long a human expert takes, that a model can complete at a given success rate. It is the most useful public number for anyone deciding how much work to hand over unattended.
The headline figures you see quoted are the 50% horizon. On METRâs published data as of their May 2026 update, the strongest model measured had a 50% time horizon of roughly 17 hours of expert work. The same modelâs 80% horizon was roughly 3 hours. That ratio is not a fluke of one model: across every frontier model on their recent list, the 80% horizon runs about 4 to 6 times shorter than the 50% one.
Translate that into a business decision. A 50% success rate is a coin flip and no process runs on it. Even 80% means 1 job in 5 goes wrong, which is still far below the bar for anything a customer sees. So the amount of work you can hand over without a person in the loop is a small fraction of the impressive number, and the gap between the two is not a shortcoming to complain about. It is the space your verification design has to fill.
This is also why âthe models will be better next yearâ is a bad reason to skip the design work. The horizons do keep extending, and the ratio between reliability levels has stayed roughly constant while they extend.
The arithmetic the lists leave out
Every use-case list quotes hours saved. The actual value of an automation is:
time it removes, minus time to check its output, minus time to fix what checking catches, minus what it costs to run.
The lists give you the first term and none of the other three. That is why a pilot can look excellent and die on contact with production: nothing was wrong with the first number, it was just the only one anybody calculated. If checking the output takes a senior person nearly as long as doing the work, the automation saves nothing no matter how good the demo was. This is the same fixed-cost trap that makes small web projects lose money for agencies, where the build shrinks and the wrapper around it does not.
The second and third terms are also the ones you cannot estimate by feel, and there is good evidence that feel is actively misleading here. In 2025, METR ran a randomised controlled trial with 16 experienced open-source developers across 246 real issues in their own repositories. Developers expected AI to speed them up by 24%. Measured, they took 19% longer. Afterwards, having lived through it, âthey still believed AI had sped them up by 20%â.
The honest update matters as much as the finding. METR re-ran it and published the results in February 2026: a speedup of -18% for the returning cohort, confidence interval -38% to +9%, and -4% for newly recruited developers, interval -15% to +9%. They then say plainly that âthe data from our new experiment gives us an unreliable signal of the current productivity effect of AI toolsâ, because âwe have observed a significant increase in developers choosing not to participate in the study because they do not wish to work without AIâ. Between 30% and 50% of participants declined to submit tasks they did not want to do without AI.
Read that second finding carefully. A dedicated research organisation, paying 50 dollars an hour, could not reliably measure whether these tools help, in the one domain with the most enthusiastic users, largely because the users would not give them up long enough to find out. Attachment to a tool is not evidence that it works. If the people best placed to measure this find it hard, the confident hours-saved figure in a vendor deck deserves no benefit of the doubt at all, and neither does your own impression.
None of which means the tools do not work. It means the only opinion worth holding is a measured one, on your work, with the before-number written down first.
What we run on our own site
The reason we sort the six categories by verification cost is that we run five of them on this website and watch what breaks.
Search visibility here is managed by an agent on a daily schedule. It reads Search Console, scores the opportunities against a goal file a human writes, edits pages or publishes an article within a fixed budget, builds, deploys, and writes a ledger entry for every change with the before-metrics attached. Each entry is re-measured at 14 and 28 days. Anything that regressed gets reverted automatically, which is why every change is its own commit. That is categories 1 through 6 in one system: extraction from the search data, classification of what is worth touching, retrieval over the siteâs own content, monitoring of positions, generation of the draft, and action that ships it.
Three things it has taught us, all of them in the ledger:
The check catches what the enthusiasm misses. On 27 July 2026, a probe reported zero citations of us across the answer engines, as it had every week before. It was wrong. Perplexity was citing greenwiremedia.com as its first source on one of our target queries, 4 days after that article published. The probe matched our brand as the literal string âgreen wire mediaâ, which never appears in the domain âgreenwiremedia.comâ. A monitoring system had been quietly returning a false negative, exactly the failure mode described above, and only the manual read of the answer text caught it.
The blast radius is the real design problem. On the same run, the build picked up unrelated work in progress that was sitting uncommitted in the working tree, and would have published unfinished pages. The system stashed what was not its own, rebuilt clean, verified the unwanted content was absent from the output, deployed, then restored the working tree and checked the files against their original checksums. Nothing unfinished shipped. That check exists because of category 6, not because of a clever model.
The measurement is the product. The reason we can tell you any of this is that every change went into a ledger with a date and a number before it went live. Without that, we would have a strong feeling and no evidence, which the METR result suggests is worth close to nothing.
When AI is the wrong tool
We would rather you skip a build than run one that never pays. Five cases where the answer is no:
- A rule would do it. If the logic can be written as a condition, write the condition. It is free, instant, deterministic, and it does not need checking every quarter. A model is for when the input is genuinely variable, not for when writing the rule is boring.
- You cannot say what a good output looks like. If two people in your company would disagree about whether a given result is correct, no automation can be evaluated, so it can never be signed off. Settle the definition first. Often that conversation turns out to be the whole project.
- The check costs as much as the task. See the arithmetic above. This kills more generation projects than any technical limit.
- The data is not there. Retrieval over documents that are out of date, contradictory or scattered across four systems will faithfully return out-of-date, contradictory answers. The unglamorous prerequisite is usually the actual work.
- The volume is too low. Every automation has a build cost and a running cost. Twelve invoices a month does not amortise anything. Twelve hundred does.
Where to start
Not with the biggest time sink. With the job whose output is cheapest to check, because that is the one you can prove and therefore the one that survives contact with the business. In practice that means three questions, in this order:
- What is the job type? If you cannot place it in one of the six, the task is not defined tightly enough to build yet.
- How would you check 100 outputs, and who would have to do it? If the answer is âa senior person, by readingâ, the saving is smaller than it looks.
- What is the worst thing that happens if it is wrong and nobody notices for a week? That answer sets how much gate you need before you need it.
Everything else is implementation, and implementation is the easy part.
This is the first piece in a series working through the six job types one at a time, with the build details, the running costs and the failure modes for each.
If you want a straight read on which of these is worth building in your business, or you are an agency whose clients have started asking, that is what we do in AI and automation. We audit the process first and say so when a workflow will not earn its keep, which is more often than the market lets on. Agencies looking for a delivery partner on this can start at how we work with agencies.
Quick answers
What can AI actually automate in a business beyond chatbots? Six kinds of job, and it helps to think in those rather than in departments. Extraction turns unstructured material into fields (invoices, contracts, forms, call notes). Classification sorts and routes things (tickets, leads, inbox). Retrieval answers questions from your own documents with the source attached. Monitoring watches a stream nobody has time to watch. Generation produces drafts a person finishes. Action carries out multi-step work inside live systems. The department a task sits in tells you nothing about whether AI will work there. The kind of job tells you almost everything, because it determines how you check the output.
Which AI automation should a business build first? The one whose output is cheapest to check, not the one that saves the most time on paper. Extraction and classification come first because both can be verified mechanically: extraction against the source document field by field, classification against a labelled sample that gives you an error rate before you ship. Generation feels like the obvious start because it is what the chat window does, but it is the only one of the six with no correct answer to check against, so the review has to be done by somebody qualified to have done the work. That review is the cost that decides whether the automation pays.
Why do so many AI pilots never reach production? Usually because the verification cost was never counted. The value of an automation is the manual time it removes, minus the time to check its output, minus the time to fix what checking catches, minus what it costs to run. Use-case lists quote the first number and none of the others. The second common cause is that nobody defined what a good output looks like before building, which makes the automation impossible to evaluate and therefore impossible to sign off.
How much work can you hand to an AI agent unattended? Much less than the headline benchmarks suggest, because the numbers people quote are set at a 50% success rate. METR measures a modelâs time horizon as the length of task, in human expert time, it can complete at a given reliability. On their data published to May 2026, the strongest model measured had a 50% horizon of about 17 hours and an 80% horizon of about 3 hours, and that ratio of roughly 4 to 6 times holds across every recent frontier model listed. Even 80% means 1 job in 5 goes wrong. For anything touching live systems, design an approval gate before the effect rather than a review after it.