Applications of AI that are worth building

Applications of AI that pay back: prediction first, language second, agents last

The applications of AI that pay back most reliably are prediction models on structured data and language tools that read your own documents. Vision pays back where the camera setup is controlled. Agents that act on your systems pay back last, and only with tight controls. All of them need a specific task, data you can reach and a named person who checks the output.

An application of AI is a task where software learns patterns from data instead of following hand-written rules, then uses them to predict, classify, generate or decide. Fraud scoring, drafting a contract summary and spotting a cracked part on a conveyor belt all qualify.

Adoption is no longer the question. Stanford's 2025 AI Index reports that 78% of organisations said they used AI in 2024, up from 55% the year before.

The harder question for a buyer is which applications turn that adoption into something measurable. Industry-by-industry lists rarely help with that, because the industry matters less than the task. This guide sorts uses by what they need from you: data, review effort, and tolerance for error.

Four families cover nearly every use case

Almost every production system fits one of four families: prediction on structured data, language work with large language models (LLMs), computer vision, and agents that take actions on your behalf.

The families differ in what they need. Prediction wants clean historical records. Language work wants documents and a way to check answers. Vision wants labelled images from your own cameras. Agents want all of that plus reliable access to your internal systems.

Anthropic's engineering team draws a similar line in Building effective agents. They separate fixed workflows, where code decides the steps, from agents, where the model decides.

That split matters when you scope a project, because the second kind is harder to test and harder to predict.

Language work is where most teams begin

LLMs read, summarise, extract and draft, so the first projects are usually document-heavy:

• Pulling fields from invoices
• Answering staff questions from policy documents
• Triaging support tickets

The pattern behind most of these is retrieval-augmented generation (RAG). The model looks up relevant passages from your own content before it answers. The idea comes from Lewis et al. at Facebook AI Research, and it remains the standard way to keep answers tied to your sources.

Extraction from scanned or messy files is its own discipline, covered by document AI work. The model is rarely the weak link there. Layout, handwriting and bad scans are.

Support chatbots deserve a caution. A bot that answers from your help centre is a sound first step. A bot that issues refunds needs the controls described in the agents section below.

Prediction models quietly pay back the most

Fraud scoring, demand forecasting, churn prediction and credit risk run on tabular data, and they have paid back for years before LLMs arrived.

Gradient-boosted trees and similar classical models often match or beat large neural networks on this kind of data. Grinsztajn and colleagues benchmarked the two on medium-sized tabular datasets and found tree-based models still ahead. They are also cheaper to run and easier to explain to a regulator or a finance director.

In practice the pattern repeats from project to project. The lift comes from joining the right tables, such as orders, refunds and support history, not from a fancier algorithm.

Prediction has one real limit: it needs history. A new product with six weeks of data cannot support a forecast model, and a supplier who says otherwise is selling a demo.

The upside is that evaluation is simple. You hold back last quarter's data, run the model on it, and compare its guesses with what happened.

Vision suits businesses with physical output

Computer vision checks products on a line, reads meter dials, counts stock and flags defects in surfaces such as solar panels or welds.

It works when the camera setup is controlled. Fixed lighting and a consistent angle give you a system that holds up. A phone photo taken by a technician in a car park gives you a research project.

Budget for the labelling. As a typical range from practice, expect to need a few hundred examples of each defect type, more when the defects are subtle. They must be tagged by someone who knows what a real defect looks like. That person is usually your best inspector, and their time is the real constraint.

Edge deployment adds another layer. Running inference on a small device at the site needs different engineering from calling a cloud API, and it is worth deciding early which one you need.

Agents promise the most and need the most control

Agents are LLMs that decide which tools to call, such as searching a database, sending an email or updating a record. They fit workflows with many steps and no fixed order.

The industry is split on how much freedom to give them. Vendors often pitch autonomous agents that run whole processes. Anthropic's own guidance says to find the simplest solution first and add agentic complexity only when it demonstrably helps.

We side with the cautious reading. An agent that sends one wrong email is an annoyance. One that updates a thousand records wrongly is an incident.

Build agents with narrow permissions, a log of every tool call, and a human approval step on anything that cannot be undone. Our AI agent development work starts from those controls rather than adding them after a scare.

Which applications of AI pay back: the four families compared

The comparison below sorts the four families by what they need and where they fail, so you can match a candidate project to the right level of caution.

Prediction

• Typical use: fraud, forecasting, churn
• Data you need: months or years of labelled history
• Main failure: drift when behaviour changes
• Review effort: low, because the metrics are clear

Language (LLM)

• Typical use: extraction, search, drafting
• Data you need: your documents and a set of test questions
• Main failure: confident wrong answers
• Review effort: medium, through sample review

Vision

• Typical use: inspection, counting
• Data you need: labelled images from your own cameras
• Main failure: fails on new lighting or angles
• Review effort: medium, per defect type

Agents

• Typical use: multi-step workflows
• Data you need: all of the above plus system access
• Main failure: wrong action taken, no error raised
• Review effort: high, with approval gates

Read the review effort line as a warning about how much human time the system will keep consuming after launch. A cheap build with high review effort is rarely cheap for long.

When to build now, wait, or hire in-house

AI projects suit teams with a specific, repeated task, data they can reach, and someone who owns the outcome. They suit badly teams that want to "do something with AI" before a use case exists.

• Build now if people on your team spend hours each week reading, copying or sorting information, and you can name the person who would check the output.
• Wait if your data lives in nobody's system, or if the process itself changes every month. Automating a process that is still being invented hardens the wrong thing.
• Hire in-house when AI is the core of your product and you can keep a team for years.
• Bring in a partner when you need the first production system quickly. A fractional CTO can also help you judge model and vendor choices before you commit headcount.

What AI projects cost after the demo works

The visible cost is the build. The ongoing costs are model usage fees, monitoring, evaluation sets that go stale, and the human review time described in the comparison above.

We do not publish rates, because scope decides the price and any figure here would be invented. Work is scoped per project after a discovery call.

What you can ask for is the commercial shape. A fixed-scope MVP, such as the one on the Moonship page, caps your exposure while you learn whether the idea holds. Larger programmes can run on a fractional basis instead.

Ask every supplier to list what recurs after launch. Usage fees, retraining, on-call and review time should all be named. If a quote covers only the build, you have half of it.

How to test an AI system and question a supplier

The most useful evaluation is a pass mark agreed before work starts and scored on at least 100 real cases from your own files, not the supplier's sample.

Write down what counts as correct for each case. For extraction, that is the right field value. For a chatbot, it is an answer that matches your policy and cites the right page.

Then put three questions to every supplier:

1. Who monitors the system after launch?
2. How do they detect quality drift?
3. Which failure from an earlier project did they find late, and what changed afterwards?

Suppliers who have shipped can answer the last one in detail, for example by naming the metric that slipped and the check they added. Those who have only demoed will talk about the model instead.

Most AI failures start with data and ownership

Projects fail less often because a model is weak and more often because the data is incomplete, nobody owns the output, or nobody checks it once the pilot team leaves.

Three patterns recur:

• Training data does not match live data.
• The person who understood the process was never in the room.
• Quality quietly decays because nobody reruns the test set.

Risk frameworks help here. The US NIST AI Risk Management Framework gives you a vocabulary for mapping and measuring these risks. If you sell into Europe, the EU AI Act sets obligations that vary by risk tier, and some applications of AI, such as hiring tools, sit in the stricter tiers.

A 30-day plan to pilot one workflow

Start with a single workflow where a person copies data between systems or reads the same kind of document all day, and where a mistake is cheap to catch. A month is enough to learn whether it holds.

• Week 1: Pick the workflow, name the owner, collect a hundred real cases and write down what counts as correct for each.
• Week 2: Agree the pass mark, then build the simplest version that could meet it.
• Week 3: Score it against the hundred cases, fix the failures that repeat, and rescore.
• Week 4: Run it live with a person approving every output, and track where they overrule it.

Keep that approval step until the numbers hold for a few weeks. Then widen the scope. That is the sequence behind our AI development projects, and the models change far less often than the discipline does.

If the workflow touches existing systems, plan for AI integration early, because connecting to an old ERP takes longer than calling a model.

If you are not sure which workflow qualifies, the broken workflow assessment walks through where your process loses time and whether AI is the right fix.