A task is a generative AI task when three things are true: the output is new content rather than a lookup, the input is unstructured language or images, and more than one good answer exists. Drafting, summarising, classifying, translating and extracting all qualify. Arithmetic, record keeping and anything requiring a guaranteed identical result do not.

The test we use before building anything

An appropriate task for generative AI passes all four of these. If it fails one, ordinary software is usually cheaper, faster and more reliable.

  1. The input is messy. Free text, email, a call transcript, a scanned document. If the input is already a clean database field, you do not need a model.
  2. The output is language or a judgement. A draft, a summary, a category, a suggested next step.
  3. Variation is acceptable. Two slightly different summaries can both be correct. Two different invoice totals cannot.
  4. A wrong answer is survivable. Either a human checks it, or the cost of being wrong is low.

Tasks generative AI genuinely does well

  • Summarising. Call transcripts into notes, long threads into a decision, documents into a brief.
  • Drafting. First drafts of replies, proposals and descriptions that a person then edits.
  • Classifying and routing. Deciding what an inbound message is about and who should get it.
  • Extracting. Pulling structured fields out of unstructured documents, then handing them to normal software.
  • Translating and rewriting. Between languages, or between registers such as technical to plain.
  • Conversation. Answering questions from a defined body of knowledge, which is what a retrieval backed assistant does.
Source code on a monitor
If the logic fits in a policy document, write the rule. Code is faster, cheaper and auditable.

Tasks that are not generative AI tasks

  • Calculation. Totals, tax, payroll, stock levels. Use code. A model that is right most of the time is worse than a formula that is right every time.
  • Systems of record. Storing and retrieving exact values is a database problem.
  • Deterministic rules. If the logic fits in a policy document, write the rule. It will be faster, cheaper and auditable.
  • Decisions needing an audit trail. Anything where you must show exactly why an outcome happened.
  • Real time control. Latency and predictability matter more than fluency.
A connected workflow diagram on a screen
The model handles language. The code handles truth.

The pattern that works in production

The systems that survive contact with real businesses rarely use a model end to end. They put the model where the mess is and ordinary software everywhere else.

A working example: an inbound email arrives. The model extracts the customer, the request and the urgency. Deterministic code looks up the account, checks entitlement and calculates the price. The model drafts the reply. A rule decides whether it sends automatically or waits for a person. The model handles language. The code handles truth.

If you can write the rule, write the rule. Use a model for the part you cannot write a rule for.

How to pick your first one

Choose a task that is high volume, low risk and currently done by a person reading something and typing something. Triage, summarising and first draft replies almost always qualify. Measure the time it takes today, then measure it after. If you cannot state the before number, you will not be able to prove the after number.

We build these as agentic and automated systems inside the tools a business already runs, and the scoping conversation usually starts by ruling out the tasks that should not use AI at all.