The hardest part of an AI project is usually the first decision: which kind of solution does this problem even call for? Pick wrong and you spend months building an agent where a simple classifier would have done. This is a decision tree I find myself walking through, four questions that move you from a business goal down to a concrete architecture.

Step 1: What's your goal?#

Start with the outcome the business actually wants. The goal points strongly toward a family of approaches:

• Predict labels (spam or not, churn or retain) leads to supervised learning.
• Find outliers (unusual transactions, anomalous sensor readings) leads to unsupervised methods.
• Forecast trends over time leads to time-series techniques.
• Understand or generate language leads to NLP and generative models.
• Answer domain-specific questions leads to RAG and semantic search.
• Decide over time, where actions compound, leads to reinforcement learning.
• Automate tool use leads to agents and function calling.

Naming the goal precisely is most of the work. "We want to use AI" is not a goal; "we want to predict which customers will cancel next month" is, and it points directly at supervised learning.

Step 2: What data do you have?#

The data you can actually get your hands on constrains everything. A perfect approach you can't feed is no approach at all:

• Structured, tabular data suits tree-based ML, which is reliable and interpretable on rows and columns.
• Unstructured data (free text, images) suits NLP or computer vision.
• Sequential data suits transformers or time-series models that respect order.
• No labels pushes you toward clustering and anomaly detection, which find structure without being told the answers.
• Sparse or few-shot data, where you have very little, favors retrieval or prompt engineering over anything that needs heavy training.

Be honest at this step. Teams routinely choose an approach that assumes clean labeled data they don't have and won't get, then stall.

Step 3: What control do you need?#

Different problems demand different kinds of control over the output, and this often matters more than raw accuracy:

• On-brand and factual output calls for RAG plus prompt guarding, grounding responses in approved sources.
• Reducing hallucinations calls for function calling, structured templates, and RAG, all of which constrain the model toward real data.
• Sensitive data calls for guardrails, human-in-the-loop review, and audit logs.
• Explainability requirements call for interpretable models, even at some cost to raw performance, because a decision you can't explain is one you can't defend.
• Continuous learning calls for retraining pipelines and active learning to keep the system current.

Step 4: Best practices for your context#

Finally, layer on the practices that match where this system will live:

• Regulated domains need human-in-the-loop checkpoints and audit logs as non-negotiables.
• Customer-facing systems need guardrails and graceful fallback messaging for when the model is uncertain or wrong.
• Enterprise settings need CI/CD for ML, a model registry, and disciplined versioning, so models are deployed and rolled back as carefully as any other production artifact.

Worked examples#

The framework is easiest to feel through examples. A few common shapes:

FAQ answering over your own documentation. The goal is answering domain-specific questions, the data is unstructured docs, and the control need is on-brand, factual responses. That lands you at RAG plus retrieval, with a retrieval-only fallback when confidence is low so the system can say "here are the relevant docs" rather than inventing an answer. Add fallback messaging for the customer-facing context.

Flagging unusual transactions. The goal is finding outliers, and you likely have lots of transaction data but few or no fraud labels. That points to unsupervised anomaly detection rather than supervised classification, with human-in-the-loop review on flagged cases given the sensitivity, and audit logs because money is involved.

Predicting customer churn. The goal is predicting labels, and the data is structured customer records with historical outcomes to learn from. That's classic supervised learning on tabular data, best served by an interpretable tree-based model so the business can understand why a customer is flagged at risk, with a retraining pipeline to keep it fresh.

Walking the tree#

The point of the four steps is to force the decisions in order: goal, then data, then control, then practices. Skip ahead and you'll fall in love with an architecture before you know whether your data can support it or your domain can tolerate it. Walk the tree in sequence and the right shape tends to fall out on its own, often simpler than you first imagined.