Which AI Do You Actually Need?

General AI, specialists, coding agents, local models — or maybe nothing new.

The AI market is extremely efficient at giving every new capability a name, a category, and a pricing page.

Your problem usually has fewer moving parts.

You need a report. Working code. A completed presentation. Less repetitive work. A way to process sensitive data. Or a job that was not practical before and now might be.

So the useful sequence is not brand → model → plan.

It is:

Purpose → Means → Tool.

AI tools are multiplying faster than most reasons to use them.

This is good for launch calendars. Your budget is allowed to have a different strategy.

1. First ask whether AI belongs in the solution

Some work does not need an AI layer.

If a standard process already works, a human decision is the bottleneck, or the task happens twice a year and takes ten minutes, adopting another tool can create a recurring system for avoiding a non-recurring problem.

Manual, human and keep the current process are all valid outcomes.

The goal is not to maximize the number of AI-assisted steps. It is to finish the work under acceptable cost, risk and effort.

2. Start with one broad AI surface

If AI helps, first see whether one general AI can complete the highest-frequency work.

General AI is our editorial label for a broad product surface that covers multiple classes of knowledge work such as writing, questions, files and analysis. It is not a formal technical category.

For most buyers, the relevant question is not which model is globally smartest.

It is which product repeatedly gets them from input to usable output with the least unnecessary friction.

That includes the surrounding product:

• files and connected context;
• research tools;
• work surfaces;
• ecosystem access;
• memory or project context;
• the effort required to move the result into the next step.

If one general AI gets the recurring work done, buying more AI is optional rather than inevitable.

3. Look inside the subscription before adding another one

The major general AI products already bundle narrower workflows.

OpenAI documents deep research in ChatGPT. Anthropic documents Research in Claude. Google documents Deep Research in Gemini Apps. Their current limits and availability differ and change, so those details belong in dated fact checks rather than timeless claims.

The decision point is simple:

Does your current general AI already include the specialist function you were about to buy elsewhere?

If yes, test whether it completes the purpose.

If it does not, you now have a much better reason to evaluate a dedicated product: you know what is missing.

4. Describe the gap in operational terms

Before opening another pricing page, identify the failure mode.

Quality

The output needs to be materially better.

Workflow

The current process still has too many manual handoffs.

Completion

You need the finished artifact, not a draft or ingredient.

Context

The system does not retain or reach the information the work depends on.

Capability

The tool makes a previously unrealistic task practical enough to attempt.

The US software market is particularly good at turning a useful feature into a category before lunch. That does not make the category unnecessary. It does mean the problem should survive contact with a sentence explaining what is actually missing.

5. Add a specialist when it changes the economics or the outcome

A specialized AI product earns another subscription when it clearly changes something that matters:

• better output;
• fewer steps;
• a completed deliverable;
• persistent context;
• a new capability that creates enough value to justify review and operating cost.

It is not automatically better because it has a narrower landing page.

If the general product is sufficient, keep it. If the specialist breaks the bottleneck, add it. If two tools are needed for different jobs, combine them deliberately rather than collecting them accidentally.

P04 handles that upgrade test in detail.

6. Coding agents are a different kind of product decision

Software development makes the which AI? question more complicated because the model is only one layer.

A coding product may include a model, an agent harness, repository context, shell access, tests, git operations, review controls, an IDE surface, cloud execution, or several of these at once.

OpenAI describes Codex as a coding agent for writing, reviewing and shipping code. Anthropic documents Claude Code as a coding-focused development surface. Those are product/workflow facts; they are not evidence that either product universally wins coding.

If the purpose is software development, decide the interaction model first: assistance while you work, delegated repository tasks, model choice/control, or finished app production.

Then compare products.

P05 starts there.

7. Local, cloud and API answer different constraints

Local AI can make sense when the constraint is real: confidential data, offline use, infrastructure control, repeatable model versions, predictable workloads or open-model experimentation.

It is not the premium difficulty setting.

Local runtimes such as LM Studio can run downloaded models on-device and can operate offline once the required assets are available. But local does not remove the need to inspect networking, logging, application behavior, model licensing, updates and security.

And some products historically associated with local models now also offer cloud paths. Verify where the work actually runs.

API access solves a different problem: software integration, programmable routing and control.

Hybrid is often the practical answer. Sensitive work can stay local while harder or less sensitive reasoning goes to a cloud service. Architecture is allowed to be boring when boring fits the constraints.

8. The decision map

You want writing, analysis, file help or normal research

→ Start with one general AI.

You repeatedly need deeper, sourced research

→ Check the research capability already bundled in the general product.

A specific output or workflow is still weak

→ Evaluate a specialist.

You need repo-aware code execution, tests or delegated development

→ Evaluate coding agents / IDE surfaces.

The real problem is data location, offline use or infrastructure control

→ Evaluate local / hybrid.

You need the capability inside a product or internal workflow

→ Evaluate API / routing.

You cannot state what another tool would improve

→ Do not add another tool yet.

There will always be another launch next week. This makes waiting unusually well-supported by the roadmap.

9. What would change our mind?

The categories should move when the economics and product boundaries move.

If general AI products absorb more specialist workflows, separate subscriptions become harder to justify. If dedicated tools complete jobs much more reliably, they become easier to justify. If local inference becomes dramatically easier to operate, the cloud-first default weakens for more users. If secure/private cloud options improve, some local use cases shrink.

Coding products may also converge: model, agent, IDE and cloud task surfaces can become less distinct.

FineInTheory will update the product facts when that happens.

The decision rule stays simpler: identify the constraint, then buy the smallest amount of machinery that removes it.