A Practical Taxonomy for Designing AI Systems
Amidst AI hype, structure is your best friend.
Since launching our AI Radar, we have received many questions about the taxonomy behind it: What is an AI task, and how is it different from a use case? Why distinguish between model families, architectures, modalities, and engineering methods? And how do these categories translate into the design of an actual AI product?
These questions may sound terminological, but in practice, they help you discuss, align, and structure the decisions in your AI projects.
This article uses the taxonomy behind the AI Radar as a practical lens for that decomposition. Starting from a simple example, we will move from business problem to AI tasks, from tasks to data and knowledge representations, from there to models and architectures, and finally to the product and interaction layer. You will see how the taxonomy can help make better decisions about feasibility, cost, risk, and implementation strategy.
1. Use case: 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. Human 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. In our example, this could be Ticket Classification and Routing. This framing is useful because it keeps the discussion anchored in business value. The goal is not to “use an LLM” or “build an agent,” but to improve a specific (and painful) process.
However, a use case is not yet a technical specification. It doesn’t tell an engineering team what the input looks like, what the system should output, which data is available, or what should happen when the AI is uncertain or wrong.
That is why the next step is translation. The business problem needs to be decomposed into the technical capabilities the system must provide.
2. Translating a use case into AI tasks
Once we map the customer service workflow more closely, the use case starts to break down into several familiar AI tasks, as illustrated in the following table.
AI tasks are primitive, reusable capabilities. They describe what kind of transformation the system performs: from text to label, text to structured fields, query to retrieved documents, pattern to anomaly score, etc.
This distinction is important because tasks define the shape of the AI solution. They clarify the in- and outputs and narrow down the relevant data, models, evaluation methods, and engineering patterns. For example:
- Classifying tickets by topic may require labeled historical tickets and a supervised classifier.
- Retrieving help articles may require document embeddings and a search index.
- Drafting a response may require a language model, grounding context, and human review.
3. Feeding your AI system with data
Data can play several roles in an AI system. It can be used offline to train, fine-tune, test, and evaluate models. It can also be used online to provide context during interaction, for example, when a retrieval system fetches relevant help articles before a response is generated. In mature AI products, user feedback and interaction data may also become part of the learning loop.
In the AI Radar, three categories are especially relevant here:
- Modalities describe the type of data the system processes or produces. In our example, the primary modality is text: support tickets, comments, help articles, and agent replies. Later, the system may also need to handle screenshots, call recordings, or structured customer metadata.
- Datasets provide the material for training, testing, and evaluation. The support team may have years of historical tickets with customer messages, assigned categories, priority levels, routing decisions, and final resolutions. Public datasets can help with prototyping, but enterprise workflows usually require custom datasets that reflect the company’s own language, products, and rules.
- Knowledge representations determine how data is structured for AI use. Sometimes cleaning and preprocessing are enough. In other cases, an intentional representation of the data can significantly improve the performance. For example, embeddings can support semantic retrieval, knowledge graphs can connect products and known issues, and structured metadata can capture customer segment, contract type, or product version.
Once we understand the data landscape, model selection becomes less speculative: we can choose models based on the task, modality, available examples, and representation strategy rather than on popularity and generic benchmarks.
4. Models and algorithms: matching capabilities to tasks and data
The next step is figuring out which model can perform a specific task reliably enough, fast enough, and at a reasonable cost.
Get Dr. Janna Lipenkova’s stories in your inbox
Join Medium for free to get updates from this writer.
In our support-ticket example, different tasks call for different model capabilities. Ticket routing may require a classifier, semantic retrieval needs an embedding model, and drafting a response may require a full-fledged LLM. If screenshots or call recordings become part of the workflow, vision or speech models may also enter the system.
Today, most teams rely on models that were pre-trained by AI labs, cloud providers, or open-source communities. But don’t forget that you can also train or fine-tune models for your own context. For example, if a company uses a highly specific ticket taxonomy, a smaller custom model trained on historical tickets may be more effective, cheaper, and easier to control than a large, general-purpose model.
In the AI Radar, several categories help make these choices more transparent:
- 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. This category becomes especially relevant when teams train their own models or compare classical machine learning baselines with newer approaches.
- 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 architectures.
Model choice should follow from the task, data, and constraints. A large language model may be useful for drafting a response, but it can cause huge overhead for a stable classification problem with good labeled data. Conversely, a simple classifier is inappropriate if the system needs to synthesize information from several documents and produce a natural-language answer.
5. System design: turning models into a product
By now, the use case has been translated into tasks, data requirements, and model choices. A production-ready AI product needs to integrate these pieces into a reliable workflow. It may also need other components such as data pipelines, retrieval layers, evaluation infrastructure, monitoring, fallback paths, and feedback loops.
Many AI projects struggle to cross the chasm from demo to production. The prototype may show that a model can do something useful, but users require a system that is reliable, measurable, secure, and maintainable.
Many principles from traditional software architecture, such as modularity, clear interfaces, and testability, still apply. However, AI systems also introduce additional challenges. Their outputs are probabilistic, their performance depends heavily on data quality, and their behavior may change as prompts, context, models, user behavior, and underlying data evolve.
In the AI Radar, three categories help connect models to production systems:
- Architectural patterns capture recurring system designs for common AI use cases. For example, Retrieval-augmented generation is used when an application needs to answer questions based on internal documents, while agent harnesses help constrain and coordinate agents as they execute multi-step workflows.
- Engineering methods address AI-specific development challenges. Thus, context engineering focuses on constructing the right context for model inference. Evaluation-driven development treats evaluation as a continuous process, helping teams align system behavior with user needs over time.
- Tools and frameworks provide reusable abstractions and implementation support. For example, agentic frameworks such as LangChain or LlamaIndex can help with retrieval, tool calling, memory, orchestration, and other components common in compound AI systems.
A common pitfall is to let tools drive the architecture. Teams see a powerful framework, a new agent platform, or a polished demo and start shaping the application around it. In the worst case, they reverse-engineer the AI opportunity from the tool.
Tools should be implementation aids, not the starting point. Before selecting them, you need to understand the architectural requirements of the system: what needs to be retrieved, generated, verified, monitored, and handed off to a human or another service. A good architecture should also remain abstract enough to substitute tools and models as better options become available.
6. Delivering AI value to users via the UX
So far, we have focused on what happens behind the scenes: tasks, data, models, architecture, and engineering methods. These layers are technically demanding, and teams often spend weeks or months selecting models, testing frameworks, and designing pipelines.
In that technical rush, user experience can become an afterthought. The result is often exposed through a chatbot, a generic assistant, or a “magic” AI button. But if users cannot understand, verify, correct, or act on the system’s output, much of the value remains trapped in the backend.
In the AI Radar, interaction patterns help explore these needs. 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 and adjusting AI outputs.
For the support-ticket system, a good design might combine several patterns: suggest a category and urgency level, retrieve relevant previous cases, draft a response, and route only high-confidence tickets automatically. Low-confidence or high-impact cases should remain human-reviewed.
From taxonomy to better decisions
The point of this taxonomy is not to create more terminology, but to align and improve decision-making:
- The use case frames the business opportunity.
- Tasks translate it into technical capabilities.
- Modalities, datasets, and knowledge representations define the available evidence and operating context.
- Models and algorithms provide the computational capabilities and make the system “intelligent”.
- Architecture, engineering methods, and tools determine how these capabilities are composed, evaluated, and maintained.
- Interaction patterns shape how the system’s output enters the workflow.
Together, these categories help move from “AI could help here” to a concrete design space: what needs to be built, evaluated, integrated, and governed. This process is rarely linear. Data constraints may force a different task formulation; evaluation results may change the model choice, and new UX requirements may reshape the architecture. The value of this framework is not to prescribe a sequence, but to make these dependencies visible early enough to act on them.
