Writing
FrameworksAugust 22, 2026

By Tan Simin

The AI Product Decision Framework

The interesting part of AI product management isn't knowing how to use every AI technique. It's knowing where AI should and shouldn't be used.

One of the things I've found most useful when building AI products is learning to not reach for AI first.

When a product problem appears, there are usually several ways to solve it: deterministic logic, prompting, RAG, memory, fine-tuning, tools, or agents.

Here's the framework I use.

Start with the simplest thing that can reliably solve the problem

1. Deterministic logic

Use when: the rule is known, predictable and must be correct.

Examples:

  • Is this trip within the user's budget?
  • Is the date valid?
  • Does this destination exist in our database?
  • Calculate leave days.

If the answer can be expressed as:

If X, do Y

I'd usually keep it in code.

Why: LLMs introduce uncertainty where you don't need it.

2. Prompting

Use when: the model already has the knowledge and capability you need, but you need to shape its behaviour.

Examples:

  • Change response format
  • Make recommendations more concise
  • Ask it to prioritise certain criteria
  • Generate a rationale from information already provided

Prompting is usually the first AI intervention I'd try before adding infrastructure.

3. RAG

Use when: the model needs access to information that isn't reliably available in its context or knowledge.

Examples:

  • Company policies
  • Product documentation
  • A user's uploaded documents
  • A large destination knowledge base

The question I ask is:

Does the model need to look something up to answer this correctly?

If yes, retrieval may be appropriate.

4. Memory

Use when: information should persist across interactions because it improves future experiences.

Examples:

"I prefer boutique hotels."

"I usually travel with my family."

Memory isn't simply "more context".

The important product question is:

Is this information worth remembering?

If forgetting it has little consequence, I probably don't need a memory system.

5. Tools

Use when: the AI needs to do something outside the model.

Examples:

  • Search flights
  • Check live weather
  • Query a database
  • Calculate prices
  • Create a calendar event

A useful mental model:

RAG gives the model information.Tools give the model capabilities.

And again, I wouldn't use an LLM to perform something a reliable API can already do better.

6. Fine-tuning

Use when: prompting consistently isn't enough and the problem is primarily about how the model behaves, not what information it has.

For example:

  • A very specific output style
  • Consistent behaviour across many requests
  • Domain-specific patterns
  • Improving performance on a repeated task

I see fine-tuning as a later optimisation, not the default starting point. If better prompting, retrieval or architecture can solve the problem, I'd usually try those first.

7. Agents

Use when: the task genuinely requires multi-step decision-making and tool use, where the next action depends on what happened in the previous step.

For example:

Search destinations → compare options → check prices → discover a constraint → revise the search → validate → present the result.

That's fundamentally different from:

Give me a recommendation.

I wouldn't introduce an agent simply because something is called an "AI product". Agents add complexity, latency and new failure modes.

The framework in one view

If the problem is...Consider...
A known rule that must be correctDeterministic logic
Behaviour / instructionsPrompting
Missing or external knowledgeRAG
Persistent user contextMemory
External action or capabilityTools
Consistent specialised model behaviourFine-tuning
Dynamic multi-step taskAgents

But the most important principle sits above the table:

Choose the least complex mechanism that reliably solves the user's problem.

What this changed in how I build AI products

Working on the travel webapp made this framework much more concrete for me.

For example, the system shouldn't ask an LLM to determine whether a trip exceeds someone's budget when the backend can calculate it exactly.

Similarly, I shouldn't expect prompting alone to enforce an allowed destination list when the product can validate that deterministically.

And I don't need an agent just because the product has multiple steps. If those steps are predictable, a normal pipeline may be more reliable.

The interesting part of AI product management isn't knowing how to use every AI technique.

It's knowing where AI should and shouldn't be used.

Good AI product design isn't about adding more intelligence. It's about putting the right kind of intelligence in the right part of the system.