Introduction “Symbolic AI vs generative AI” gets framed as a historical comparison — the old approach that lost vs the new approach that won. The framing is misleading. Symbolic AI failed in the way it did because its knowledge-acquisition costs grew faster than its useful coverage; generative AI works in the way it does because it learns from data the symbolic approach demanded humans encode. But neuro-symbolic AI is now bringing back the symbolic strengths (explicit reasoning, verifiability, composable rules) by combining them with the neural components that handle perception, fuzzy matching, and generalisation. This article is the working taxonomy practitioners need to scope a GenAI project without spending half the scoping conversation negotiating labels. See generative AI for the broader practice. The naive read is “GenAI is the new AI and symbolic is obsolete.” The expert read is that the families serve different problem classes and the productive 2026 systems often compose both — the neural front-end producing structured representations the symbolic reasoner operates on. What this means in practice Symbolic AI didn’t fail because the approach was wrong; it failed because human knowledge-encoding doesn’t scale. Neuro-symbolic AI is the genuine 2026 advance — hybrid systems that get reasoning verifiability with neural perception. LLMs and GenAI are subsets of deep learning; the taxonomy levels matter for engineering decisions. Pick by problem class first, then decide whether composition adds value. Why did symbolic AI fail in the way it did, and what does neuro-symbolic AI bring back? Symbolic AI in the 1980s and 1990s encoded human knowledge as rules and logical structures. It failed at two scales: knowledge-acquisition (encoding every rule a domain expert uses exhausts the experts faster than the system reaches usefulness; rule sets become unmaintainable), and brittleness (rule-based systems handle the cases the rules cover and fail abruptly on the cases just outside, with no graceful degradation). The 1990s “AI winter” partly reflected the limits of this approach for real-world domains. Neuro-symbolic AI brings back the strengths — explicit reasoning, verifiable steps, composable rules — by combining them with neural components that handle perception, fuzzy matching, and generalisation. The pattern: a neural front-end extracts structured representations from messy inputs; a symbolic reasoner operates on the structured representations; the result has the generalisation of the neural part and the verifiability of the symbolic part. The hybrid is harder to build than either purely, but it solves problem classes (theorem proving, program synthesis, structured planning, formal verification of AI-generated artefacts) that pure neural approaches still struggle with. How does a working taxonomy of ML, deep learning, LLMs, and GenAI map to real engineering decisions? ML (machine learning): models that learn from data. Encompasses everything below. Classical ML (logistic regression, gradient-boosted trees, SVMs, random forests): tabular data, structured features, problem sizes where deep learning is overkill or under-data. Still the right call for most enterprise tabular prediction. Deep learning: neural networks with many layers. Handles unstructured data (images, audio, text) where classical ML struggles. LLMs (large language models): a specific deep-learning architecture (transformers) trained on text at scale. Generative by default, also strong on text classification, extraction, and reasoning when prompted appropriately. GenAI (generative AI): models whose primary output is new content (text, image, audio, video). LLMs are one GenAI family; diffusion models for images are another. The engineering decision: pick by the problem’s data, output, and scale. Tabular classification on 100k rows: classical ML. Image classification on 1M labelled images: deep learning (fine-tuned ViT). Open-ended text generation: LLM. Image generation: GenAI (diffusion). The labels are operational, not academic — they map to different tooling, different evaluation discipline, and different deployment patterns. What is the key feature of generative AI that separates it from classical ML for a production team? Generative AI’s output is content; classical ML’s output is a label, a score, or a structured prediction. The operational consequence: GenAI output is harder to evaluate (open-ended, no ground truth in most cases), harder to monitor (output distribution shifts mean something different when outputs are creative), and harder to constrain (the output space is not a fixed set of classes). Classical ML benefits from decades of MLOps infrastructure for evaluation, monitoring, and rollback. GenAI benefits less; the same patterns need to be re-engineered for open-ended outputs — LLM-as-judge evaluation, semantic-similarity drift detection, structured-output schemas to constrain the output space, safety layers against off-policy or injection-driven outputs. A team adopting GenAI typically discovers the production engineering it needs is recognisably different from the classical-ML engineering it has. Where do transformers sit in the taxonomy, and why do they keep dominating across modalities? Transformers are a deep-learning architecture characterised by self-attention. They started in text (the 2017 “Attention is All You Need” paper), spread to images (Vision Transformers, 2020), audio, video, time series, and structured data. The dominance across modalities comes from three properties: they handle variable-length input naturally, they scale predictably with model size and data (the “scaling laws”), and they enable cross-modal training (text+image, text+audio) that makes joint-embedding spaces practical. The practical consequence: a 2026 engineering team building a new model in almost any modality should default to a transformer architecture unless there is a specific reason not to (extreme latency constraints where smaller architectures fit better, very small data regimes where other architectures are more sample-efficient). The investment in transformer infrastructure — training stacks, inference optimisations, serving patterns — carries across modalities, compounding the architectural advantage. How does applied AI differ from general AI in terms of what an engineering team should build today? Applied AI: models trained for specific tasks (image classification for product inspection, text classification for support routing, language generation for a domain-specific assistant). The model is fit-for-purpose, the evaluation is bounded, the deployment is straightforward. This is what almost all production AI is. General AI (often “AGI”): the speculative idea of a single model that performs across the full range of human cognitive tasks. The 2026 reality is large foundation models (LLMs, multi-modal models) that approach general behaviour on text and increasingly across modalities — but they remain tools applied to bounded tasks in production deployments. The framing “is this AGI” is mostly a marketing discussion; the engineering question is whether the foundation model is a better starting point than a from-scratch task-specific model for the task at hand. Frequently yes; not always — task-specific small models still win on latency, cost, and domain accuracy in many production settings. Which technologies have actually advanced LLM operation in the last 24 months, and which are noise? Real advances: long-context models (1M+ token context windows that genuinely work for retrieval and reasoning), reasoning models (chain-of-thought built into the model, useful for problems that decompose), tool-use protocols (model-side function-calling that integrates with engineering systems), structured-output guarantees (schema-constrained generation that lets downstream code consume model outputs reliably), and inference optimisations (speculative decoding, KV-cache compression, quantisation) that reduce production cost. Noise: “agentic” framings that re-label what was already prompt engineering plus tool use, prompt-injection scares that were always known to security engineering, hype cycles around specific benchmark numbers that do not translate to production behaviour, and the proliferation of frameworks that wrap underlying APIs without adding durable value. The signal-to-noise ratio is improving as the field matures, but the engineering team’s discipline is the same: evaluate against the production workload, not the marketing surface. How TechnoLynx Can Help TechnoLynx works with leadership and engineering teams to disambiguate the AI/ML/LLM/GenAI taxonomy before the first vendor RFP, and then to scope production systems that compose the right families — including neuro-symbolic hybrids where appropriate — for the problem class. If you are starting a GenAI initiative and need the taxonomy fixed before scope creep does it for you, contact us for a feasibility audit. Image credits: Freepik