The AI Taxonomy: From Opportunity to Implementation
Amidst AI hype, structure is your best friend
Dear AI friends,
Since launching our AI Radar, we have received many questions about the categories we use to model the AI landscape. What is an AI task, and how is it different from a use case? Why do we need model families, architectures, modalities, and engineering methods? And how do all these pieces come together in a concrete AI product?
These questions are less about terminology and more about facilitating decisions in a structured, aligned way. This episode unpacks the taxonomy behind the AI Radar. Using a simple example, we will follow the journey from business problem to AI system and see where the different categories enter the picture (cf. Figure 1 for an overview). I will also situate them within some of the most important debates and challenges in enterprise AI today.
1. Use cases: the business problem as your starting point
Imagine a customer service team on a Monday morning. Over the weekend, hundreds of new support tickets have arrived. Some are simple password resets, some are billing complaints, and a few are really urgent. The team already has a process for this. Agents read each ticket, assign a category, estimate urgency, and route it to the right team. Sometimes, they also search the internal knowledge bases to inform their actions and answers.
This works for a while, but as volume grows, inconsistencies and delays set in. The operational bottleneck slowly becomes a people problem. Agents get frustrated and leave. Customers wait longer, and team leads lose visibility. The organization becomes slower at reacting to material customer issues.
One of the team leads spots an AI opportunity: Can we use AI to help the support team understand, prioritize, and route incoming tickets faster?
In the AI Radar, this is represented as a use case: a concrete application of AI in a business process, such as Customer Service. The use case library contains more than 200 proven AI use cases, classified by business function and industry. For each use case, you also find real-world case studies describing how other companies have implemented it.
At this stage, the use case is not yet something an engineering team can build. Engineers will need to know what the input is, what the system should produce, what kind of data is available, and what needs to happen when the AI is uncertain or wrong. So the next step is translation: the business problem needs to become a set of technical capabilities.
2. Translating use cases into AI tasks
As you map the customer service workflow, several concrete AI tasks appear. The system may need to do:
Classification: classify tickets by topic
Information extraction: extract product names or error codes
Anomaly detection: detect urgency
Semantic search: retrieve relevant help articles
Text generation: generate a draft response
Think of AI tasks as primitive, reusable AI capabilities. Clarity on tasks is important because they define the shape of your AI solution. They tell you what kind of input the system receives, what output it should produce, and what kind of processing needs to happen in between. This often narrows down the relevant data, models, and engineering patterns.
Common pitfall: Staying too long at the use-case level. “Improve customer service with AI” sounds good in business terms, but it does not yet tell the team whether they need classification, retrieval, generation, anomaly detection, or a combination of these tasks.
3. Feeding your AI system with data
Data is the fuel of any AI system. It can be used offline to train, fine-tune, test, and evaluate models, or online to dynamically provide context during interaction. In mature AI products, user feedback and interaction data also become part of the learning loop.
In the AI Radar, there are three categories that focus on data:
Modalities (available as filter) describe the type of data the system processes or produces. In our support-ticket example, the primary modality is text. But over time, the system may also need to work with screenshots, call recordings, screen-share videos, or structured customer metadata. Each modality narrows down the relevant techniques and model types.
Datasets provide the material for training and evaluation. In most enterprise settings, you will need construct custom datasets to reflect the individual needs of your business. In our example, the support team may have five years of historical tickets, including the original customer message, assigned category, priority level, routing destination, and final resolution. However, for many standard AI tasks, existing public datasets can also be used as a starting point.
Implementation tip: Manual processes that are well documented in historical data can be a low-hanging fruit for supervised learning.
Knowledge representations determine how data is structured for AI use. Sometimes, basic cleaning and preprocessing are enough. In other cases, raw data is too noisy, fragmented, or complex, and needs a more purposeful structure. For example, knowledge graphs can connect products, features, known issues, teams, and dependencies. Vector embeddings can represent documents in a semantic space, making it possible to retrieve similar content even when different wording is used.
4. Building the intelligence of your AI system
Once the tasks and data requirements are clear, the next question is which models can perform the task reliably enough, fast enough, and at a reasonable cost. In our example, this might be a classifier for routing, an embedding model for semantic retrieval, and a language model for drafting responses.
You can reuse models that were pre-trained by AI labs, cloud providers, or open-source communities - this is the most common scenario in today’s AI landscape. However, you can also train or fine-tune models specifically for your company. For example, if your company uses a very specific classification scheme for tickets, a smaller custom model trained on historical tickets may be more effective, cheaper, and easier to control than a large foundational model.
In the AI Radar, several categories help you navigate AI models without the bias of vendor marketing pages:
Model families group related pre-trained models that share a common architecture, training approach, or lineage. Examples include LLaMA, Gemini, and Mistral.
Algorithms describe the mathematical procedures used to train, optimize, or run models. Examples include Logistic Regression, Random Forests, and Support Vector Machines. Their knowledge is especially important if you plan to train your own models.
Model architectures describe how a model is structured internally: which components it contains, how they are connected, and how information flows through them. Examples include Transformers, LSTMs, and Mixture of Experts.
Feasibility check: Models are often the main feasibility bottleneck. If you cannot find or build a model that provides the right combination of capability, reliability, latency, cost, and deployment fit, the whole solution may become unrealistic.
Further reading:
In Chapter 5 of The Art of AI Product Development, I go deeper into pre-trained models and methods for evaluating and selecting the best models for your AI system.
5. From model to AI system
By now, our use case has been translated into tasks, data needs, and models. But this is still not the full system. A production-ready solution needs to integrate these pieces into a working system - and it might also need other components, such as data pipelines, retrieval layers, and feedback loops.
Common pitfall: One of the biggest challenges in AI is getting from prototype to production. Often, teams put too much focus on the model and don’t plan the overall system architecture upfront. The demo proves that the model can do something useful, but production requires a system design that makes it reliable, measurable, secure, and maintainable.
Many principles from traditional software architecture, such as modularity and maintainability, still apply. But AI also adds some special challenges. AI systems produce uncertain outputs, depend heavily on data quality, and need continuous iteration as user behavior, data, and model capabilities change.
In the AI Radar, three categories help you move from model to system:
Architectural patterns capture recurring system designs for common AI use cases. For example, Retrieval-Augmented Generation is often used when an application needs to answer questions based on internal documents. Agent harnesses keep agents on track as they execute multi-step workflows.
Engineering methods help solve AI-specific development challenges. Thus, context engineering focuses on dynamically constructing the right context for language model inference. Evaluation-driven development turns evaluation into a continuous process, helping teams align system behavior more closely with user needs over time.
Tools and frameworks provide reusable abstractions and out-of-the-box functionality. For example, agentic frameworks such as LangChain or LlamaIndex can help with retrieval, tool calling, memory, orchestration, and other components that are common in compound AI systems.
A note of caution on tools: We tend to overreact to vendor marketing. Many teams see a powerful framework, a new agent platform, or a polished demo, and start shaping their application around it. In the worst case, they even reverse-engineer the whole “AI opportunity.” Remember that tools are implementation aids. Before selecting them, make sure you understand the architectural requirements of your system. Aim for an architecture that is abstract enough to let you substitute tools and models as better options become available.
6. Delivering AI value to users via the UX
So far, we have focused mostly on how to create value behind the scenes: through data, models, system architecture, and engineering methods. AI projects are technologically demanding - teams spend weeks or months selecting models, testing frameworks, and designing pipelines. In this technical rush, the user experience can become an afterthought, and the result is simply exposed through a chatbot or a “magic” AI button. But if this doesn’t meet user expectations, the value of your AI system remains trapped in the backend.
In our support-ticket example, the AI system might classify a ticket, detect urgency, retrieve similar cases, and draft a response. But the user still needs a way to see, understand, verify, and act on these suggestions. Should the AI output appear as a simple category label, a draft message, or a recommendation? Or should the system quietly automate some steps in the background?
In the AI Radar, interaction patterns help you explore these choices. They describe recurring ways in which users interact with AI capabilities. For example, prompting gives users a structured way to instruct an AI model, while human-in-the-loop interaction keeps them involved in reviewing, correcting, approving, or overriding AI outputs.
Further reading:
Chapter 10 of The Art of AI Product Development provides guidance on AI-specific design aspects, incl. trust, control, and feedback collection.
Building and calibrating trust in AI for an overview of techniques to support user trust in AI systems.
From taxonomy to better decisions
In the AI Radar, the taxonomy is not a glossary for its own sake, but a structure for making better decisions:
The use case describes the opportunity. The associated performance areas clarify the value you expect to create.
The task translates the business problem into the technical capabilities required.
The modality, dataset, and knowledge representation define what the system can learn from and work with.
The algorithm, model architecture, model family, and model type help you choose the right kind of intelligence.
The architectural pattern, engineering method, and tool or framework help you turn that intelligence into a working system.
The interaction pattern determines how the value reaches the user.
Together, these categories form a path from “AI could help here” to “this is what we need to build.” That path is not always linear, and the right starting point depends on context. An incumbent may begin with internal automation to free up resources, while an AI-native product in a fast-moving consumer market may need personalization and a fluid AI interface from day one. The framework does not prescribe a fixed sequence but helps you surface trade-offs and bottlenecks.
This is the role of the AI Radar: to provide a structured map of the space, so you can move through it deliberately instead of being pushed around by hype, vendor claims, or the latest model release.
Our taxonomy is still a work in progress. If you have questions, feedback, or want to help us improve it, please get in touch!
Best regards
Janna
PS: If you’ve read this far, you’re probably ready for something fun. Take a look at the early preview of our Knowledge Graph - a playful and dynamic way to explore the AI taxonomy!