Right Tool, Right Job · Page 3 of 3

How to Choose — A Practical Decision Framework

The goal isn't to use AI. The goal is to solve a problem well. Sometimes AI is the right answer. Sometimes a specific kind of AI is the right answer. Sometimes AI isn't the answer at all. Here's how to think through it.

Start With the Output, Not the Tool

The most common mistake in AI adoption is starting with the tool: "We have access to ChatGPT, what can we use it for?" This produces a list of use cases shaped by the tool's availability rather than by actual problems worth solving.

Start with the output instead. What does success look like? What does the output need to be — a document, a decision, an alert, a database query, a transformed dataset, an image? What properties must that output have — accurate, precise, timely, auditable, explainable?

Once you know what you need, the tool selection follows naturally. Often a text model is part of the answer. Often it's not the whole answer. Occasionally it's not the right answer at all.

The Decomposition Habit

Most real-world tasks that seem like "one thing" are actually several things. "Analyze our network logs for threats" decomposes into: ingest and parse logs (structured data processing), identify statistical anomalies (purpose-built ML or rule engine), summarize findings in plain English for the security team (text model), and escalate high-confidence findings (workflow automation). The text model belongs in exactly one of those four steps. Knowing which one is the skill.

The Decision Map

Work through these questions in order:

Is the task fundamentally about language?

The output is text that a knowledgeable human would produce. The input is text or can be fully described in text. Accuracy is judged by human assessment rather than deterministic verification. If yes → text model is likely appropriate.

Does correctness require precision or determinism?

The answer is either right or wrong, not approximately right. Errors have downstream consequences — financial, operational, safety. The output feeds into other systems that expect exact values. If yes → use deterministic tools (code, calculators, SQL) for the computation; text model only for language wrapping around it.

Does it require real-time or live data?

The answer depends on what's happening right now, not on general knowledge or retrieved documents. The system needs to monitor, trigger, or respond continuously. If yes → streaming systems or monitoring platforms handle the real-time layer; text model may assist with summarization or response drafting downstream.

Does it require domain-specific pattern recognition at scale?

Anomaly detection in specialized data, image classification, audio fingerprinting, network behavioral analysis. Tasks where a general model lacks the specific training data to perform reliably. If yes → purpose-built or fine-tuned model trained on domain data, not a general text model.

Does it require non-text modalities?

The input or output is images, audio, video, structured numerical data, or signals. If yes → multimodal models or specialized architectures; text model only as interface or coordinator.

The Hybrid Architecture

Most robust AI systems in production aren't a single model doing everything. They're architectures where different components handle what they're good at, and a text model — often as the user-facing interface — coordinates between them.

A network security assistant might look like this in practice:

The text model is genuinely valuable in this architecture. It's just not doing the detection, the scoring, the policy enforcement, or the real-time monitoring. It's doing what it's actually good at: language.

Evaluating AI Claims in the Wild

When a vendor says their AI "analyzes network traffic," "detects fraud," "diagnoses medical images," or "predicts equipment failures" — the architecture question is the right first question to ask.

Is the core capability a purpose-built model trained on domain data, or is it a general text model being asked to narrate outputs from other systems? The first is a genuine capability. The second is a UX layer with a language model as the face. Both can be valuable. They're not the same thing. The distinction matters when you're evaluating reliability, auditing decisions, or assigning accountability for errors.

Questions to Ask

What was the model trained on? What's the evaluation benchmark and what data was it measured on? What happens when the model is wrong — how is that detected, and what are the consequences? Can I see examples of failures, not just successes? Is the AI making the decision, or informing a human who makes the decision?

The Underlying Principle

A text model is a powerful, flexible tool for tasks that live in the domain of human language. That domain is larger than it might first appear — because so much human knowledge, reasoning, and communication happens through language. But it has edges. And the edges are where over-reliance becomes a problem.

The practitioners who get the most value from these systems are the ones who have a clear model of what the tool is doing underneath — not because they need to understand the math, but because they need to know where to trust it, where to verify it, and where to reach for something else entirely.

That understanding is what this entire course has been building toward.

Final Thought
  • Think of a project or decision in your work that involved — or could involve — AI. Map it against the decision framework above. Where does the text model belong in the architecture? Where does it not?
  • What would you tell someone who is enthusiastic about AI but applying it indiscriminately — replacing specialized tools with text models for tasks that require precision or domain-specific training?
  • What's the one thing from this course that most changes how you'll evaluate an AI tool or claim going forward?
← The Mismatch Problem Course Home