The AI Periodic Table — A Grammar for the Age of Intelligence (Part 1)
There is a particular kind of meeting that happens in engineering teams right now, and if you have sat through one, you know exactly what I mean. Someone says "agent." Three people nod. Two people picture something completely different. One person is too embarrassed to ask. The whiteboard fills with boxes and arrows, and by the end of the hour you have not built clarity — you have built the illusion of it.
Part 1: The Architecture — Building the Table from the Ground Up
RAG gets thrown around like a magic word. Embeddings are somewhere between "vectors" and "vibes." Guardrails means whatever the speaker needs it to mean. Multi-modal, fine-tuning, chain-of-thought — the vocabulary of AI is expanding faster than shared understanding can keep up with it. And in that gap between words and meaning, bad decisions get made. Systems get built on mismatched assumptions. Products get pitched with borrowed terminology that no one stops to question.
Chemistry had this exact problem, and for centuries. Alchemists named things whatever they liked. Elements were confused with compounds. Phlogiston was a theory held with enormous confidence by serious people who were completely wrong. Then, in 1869, a Russian chemist named Dmitri Mendeleev sat down and did something that sounds almost too simple: he organized what he knew into a table. Rows and columns. Patterns that forced themselves into view. And in the gaps — the places where an element should exist but hadn't been found yet — he made predictions. Gallium. Germanium. Scandium. All discovered later, exactly where he said they would be.
The periodic table was not just a filing system. It was a grammar. Once you had it, you could read chemistry you had never seen before.
AI needs the same thing.
Standing on Shoulders
I should be honest about where this started. A few days ago I watched a video by Martin Keen — IBM Master Inventor, holder of over 400 patents, and one of the clearest technical educators working in AI today. His video on the IBM Technology YouTube channel proposed exactly this idea: organize AI like chemistry organizes the elements. The framework clicked immediately.
Martin Keen — The AI Periodic Table (IBM Technology, YouTube)
But watching it, I felt the itch that engineers feel when something is right but incomplete. The original table included Orchestration — RAG and Framework both appeared — but as elements without a dedicated column, without the full weight of that concern being represented. Other pieces were missing entirely: a proper Orchestration column as a first-class citizen, interpretability, alignment, a coherent home for emerging capabilities like multi-agent systems and synthetic data. A symbol collision quietly undermined two elements that shared the same abbreviation. I could not leave it there.
What started as watching became building. Martin planted the seed with the precision and generosity that characterizes everything he makes. This article — and the expanded table it describes — is what grew from it. I am not improving on his idea so much as continuing it, the way every scientist who ever added an element to the periodic table was continuing Mendeleev's idea.
Knowledge is supposed to travel. Land somewhere new. Grow.
The Architecture of the Table
The original table organized AI into rows representing maturity and columns representing functional families. That instinct was exactly right. What I kept coming back to was the column logic — whether the families were capturing the right questions.
Because that is what a column in this table really is. Not a category. A question you must answer about any AI system you encounter or build.
Does it have a way to direct and constrain the AI's behavior? That is the Control column. Does it have a way to store and retrieve knowledge? That is the Memory column. Is there a structural model at its core — the actual architecture of what processes information? That is the Architecture column. Can its pieces connect and coordinate, passing results between them? That is Orchestration. Do its components communicate through defined standards? That is Protocols. Can you see what it is doing, trace why, and measure whether it is working? That is Observability. Is there anything stopping it from doing harm? That is Safety. And can it learn from new information, adapt to your domain, get better over time? That is Adaptation.
Eight questions. Eight columns. Every real AI system in production must answer all eight, whether its builders thought about them deliberately or not. The ones that got skipped do not disappear — they show up later as incidents, compliance failures, or systems that are quietly wrong in ways nobody can diagnose because nobody built in the tools to look.
The rows tell a different story. They are levels of abstraction, stacked the way a building is stacked — you cannot put the roof on before you pour the foundation.
Row 1, Infrastructure, is the physics of AI. Tokenization. Vector space. The attention mechanism that makes transformers work. These are not things you typically interact with directly, but they govern everything above them. Row 2, Primitives, is where you first touch the system — prompts, embeddings, a base model, an API. These are the atoms. Row 3, Compositions, is where atoms combine into molecules: tool calling, vector databases, multimodal architectures, RAG, evaluation, guardrails, LoRA. Row 4, Systems, is full deployed production — agents, knowledge bases, thinking models, frameworks, observability stacks, red teaming, RLHF. And Row 5, Emerging, is the frontier: multi-agent networks, synthetic data, interpretability, alignment. Real and happening now, but still rapidly evolving, still without settled best practices, still full of open questions.
Five rows. Eight columns. Forty possible positions. Not all of them are filled — and that, as we will come back to in Part 2, is the most important thing about the table.
The Element That Is Not an Element
Every serious conversation about AI production systems eventually arrives at the same question: where does context fit? It is one of the most used words in the field, and almost nobody stops to ask what kind of thing it actually is.
Context is not an element. It is the substance that flows through the elements — the way energy flows through a chemical reaction without being the reaction itself. It is present at every level of the table simultaneously, which is precisely why it does not belong in any single cell. Put it in Memory and you have misrepresented it. Put it in Architecture and you have missed half of what it does. It refuses to be pinned down because it is not a component — it is the medium through which AI reasoning travels.
Look at how it manifests at each row. At Infrastructure, the context window is a hard physical constraint — the fixed number of tokens the model can attend to in a single forward pass. This is a property of the Architecture column, baked into the model's design, not something you configure at deployment. At Primitives, context is what you put into a prompt: system instructions, conversation history, user information. That is the Prompt element (Pr) doing its job — deciding what context to hand the model before it generates anything. At Compositions, context becomes a retrieval problem. RAG (Rg) exists precisely because the context window has limits and you need to choose intelligently what goes in it, pulling the right chunks from a vector database at the moment they are needed. At Systems, a Knowledge Base (Kb) is a curated, maintained store of context the system can draw from across many interactions — context made persistent and authoritative.
Now look at it column by column. Control decides what context to give the model. Memory decides what context to store and retrieve. Architecture determines how much context fits and how it is processed. Orchestration moves context between components. Protocols define the contracts over which context travels. Observability watches what context was actually used. Safety filters harmful context before it enters. Adaptation changes what context the model can use effectively. Every column is, from a certain angle, a different strategy for managing the same underlying substance.
This is why context feels like it should be on the table but keeps slipping off. It is not an element. It is what the elements act on.
A future element — call it Context Management (Cx) — is conceivable at Compositions/Memory: the deliberate assembly, compression, and prioritization of what enters the context window. Systems like MemGPT and long-context compression libraries are early signals pointing in that direction. But the field has not yet settled on a canonical form for this concern, which makes it a gap prediction rather than an established element. Watch that space.
The Elements
What follows is not a glossary. It is a walk through the table, chosen to show you how the logic works — why each element sits exactly where it does, and what that placement tells you.
Infrastructure: What Everything Else Is Built On
Tokenization (Tk) — Control, Infrastructure. Before a language model reads a single word, it converts text into tokens — discrete numerical units, roughly corresponding to word fragments. "Unbelievable" might become three tokens. A space matters. A capital letter matters. This sits at Infrastructure/Control because it is the most fundamental way the system represents and responds to your input. Change how you tokenize and you change everything above it. Most people never think about this. The engineers who build production systems think about little else.
Vector Space (Vc) — Memory, Infrastructure. Meaning, in AI systems, is geometry. Words, sentences, documents — all of them get converted into points in a high-dimensional mathematical space, where proximity means similarity. "Dog" and "puppy" land near each other. "Dog" and "mortgage" do not. This is the foundation of how AI systems remember and search. Everything in the Memory column above it — embeddings, vector databases, knowledge bases — is built on this geometric intuition.
Attention (At) — Architecture, Infrastructure. The mechanism at the heart of every modern transformer model. When a model processes a sequence of tokens, attention computes weighted relationships between them — mathematically, softmax(Q·Kᵀ/√d)·V, where queries, keys, and values interact to determine which parts of the input the model should focus on when generating each output. It is why transformers can handle context in ways earlier architectures could not. You do not interact with attention directly. But it is why the models work at all.
Logging (Lg) — Observability, Infrastructure. Logging as applied to AI systems is a structured capture of system events, inputs, outputs, and state transitions. Unglamorous. Non-negotiable. Every distributed system that ever failed in a way nobody could diagnose failed partly because someone skipped logging in the early days and never went back.
Filtering (Fl) — Safety, Infrastructure. The first and most basic safety layer: input and output sanitization using regex, blocklists, or classifier-based rejection of harmful content. It is not sophisticated. It is also necessary, because no matter how aligned your model is, someone will try to feed it something it should not process.
Weights (Wt) — Adaptation, Infrastructure. The learned parameters — tensors, billions of numbers — that encode everything the model knows from training. When people talk about "the model," they are largely talking about its weights. Fine-tuning, LoRA, RLHF — everything in the Adaptation column is ultimately about changing or augmenting these numbers.
Primitives: The Atoms
Prompt (Pr) — Control, Primitives. The structured text you give a model to define its task, context, format, and constraints. It sounds simple. It is not. A one-word change in a prompt can reverse an output entirely. Prompt engineering is a real discipline, and the fact that it sounds trivial is one of the field's most persistent misconceptions.
Embeddings (Em) — Memory, Primitives. Dense vector representations of text, mapping semantic meaning to geometric proximity. You take a sentence and convert it to a list of numbers — typically hundreds or thousands of them — such that sentences with similar meaning produce similar numbers. This is the primitive on which all semantic search, all RAG, all knowledge retrieval is built. Without embeddings, you are doing keyword search. With them, you are doing something closer to understanding.
Base Model (Lm) — Architecture, Primitives. A pre-trained transformer with frozen weights and no task-specific adaptation. GPT before fine-tuning. Claude before RLHF. The raw capability, unspecialized. It is a primitive because it is the atomic unit of modern AI architecture — you either use one or you do not, and everything else is layered on top.
API (Ap) — Protocols, Primitives. The standardized interface that exposes model capabilities to external systems via HTTP and JSON, as a proposed protocol. API is the most primitive communication contract in the stack — point-to-point, synchronous, bespoke for every integration. It belongs in the Protocols column because it describes how components talk, not how they coordinate or compute. Before you have MCP or A2A, before you have frameworks or agents, you have an API call. It is the single point at which your code touches the model, and therefore the single point at which most things can go wrong in the most boring and fixable of ways.
Tracing (Tr) — Observability, Primitives. Causal logging of execution paths, decisions, and data lineage. Where logging captures what happened, tracing captures why — the chain of causes that led from input to output. In a simple system, you can reason about this in your head. In a system with agents, tool calls, and retrieval, you absolutely cannot.
Schema (Sc) — Safety, Primitives. Structured output constraints — JSON Schema, Pydantic models — that enforce format compliance on what the model produces. This is safety at the data contract level: the model cannot return something malformed because the schema will reject it. Unglamorous. Catches an enormous category of production bugs.
Fine-Tuning (Ft) — Adaptation, Primitives. Continued training on task-specific data, updating all model parameters. The most thorough way to specialize a model — and the most expensive, because you are rewriting every weight. It is a primitive of adaptation: the baseline approach before you consider more surgical methods.
Compositions: Where Patterns Emerge
Tool Calling (To) — Control, Compositions. The model calls a function before giving an answer. It invokes a weather API, queries a database, runs a calculation. This is how the model reaches out to affect the world — structured, typed function invocation with arguments it constructs itself. The composition that turns a language model from a text generator into something that can interact with systems.
Vector Database (Vx) — Memory, Compositions. A specialized datastore built for approximate nearest-neighbor search on embeddings — finding the most similar vectors to a query vector, at scale, in milliseconds. You compose embeddings into a vector database, and suddenly you can search millions of documents by meaning rather than keywords. Pinecone, Weaviate, Chroma, pgvector — this category has exploded because it is the missing piece that makes memory practical.
Multimodal (Mm) — Architecture, Compositions. An architecture that processes multiple modalities — text, images, audio, video — in a unified latent space. It is a composition because it combines encoders for different data types with a language model backbone. The practical implication is that the input to your system no longer has to be text, which changes what problems AI can address.
RAG — Retrieval-Augmented Generation (Rg) — Orchestration, Compositions. This is the element that most clearly illustrates why the Orchestration column matters. RAG is not about retrieval. It is not about generation. It is about the coordination between them: a query arrives, embeddings locate relevant chunks in a vector database, those chunks augment the prompt, the model generates an answer grounded in retrieved context. RAG is pure orchestration — it exists only because multiple other elements are being coordinated. Putting it in Memory, as some frameworks do, misses the point entirely.
Model Context Protocol (Mc) — Protocols, Compositions. A standardized protocol — designed by Anthropic and now increasingly adopted across tool-integrated agent systems — that lets AI agents discover and consume external tools, data sources, and services through a consistent, capability-negotiating interface. MCP is built on JSON-RPC 2.0, making it lightweight and familiar to anyone who has worked with language server protocols. To understand why it belongs in Protocols rather than Orchestration, compare it to what sits below it. API (Ap) at Primitives is point-to-point, unstructured, bespoke for every integration. MCP is what happens when you take that primitive and evolve it for the agentic world: bidirectional, self-describing, composable across any agent and any tool. Without MCP, every agent-to-tool connection is custom code. With MCP, you write one server and any MCP-compatible agent can use it — the same conceptual leap that HTTP made for web services. It describes how things communicate, not how they coordinate or compute. That is the Protocols column.
Evaluation (Ev) — Observability, Compositions. Systematic measurement of model performance using benchmarks, metrics, and human review. The step that turns "I think it's working" into "I can demonstrate it's working." Without evaluation, you are flying blind. With it, you can compare models, catch regressions, and have a conversation about quality that does not rely on vibes.
Guardrails (Gr) — Safety, Compositions. Runtime validation enforcing policy boundaries — content filters, output constraints, topic restrictions. Where filtering at Infrastructure is static and simple, guardrails are dynamic and compositional: they wrap the model's behavior in real time, checking outputs against policies before they reach the user. The difference between "block this word" and "ensure this response complies with our terms of service."
LoRA (Lr) — Adaptation, Compositions. Low-rank adaptation: instead of rewriting all the model's weights during fine-tuning, LoRA injects small trainable matrices into the frozen layers. The rank r is much smaller than the model's hidden dimension d, which means you are updating a tiny fraction of the parameters while achieving most of the specialization. Dramatically cheaper than full fine-tuning. Dramatically better than prompt engineering alone for domain adaptation.
Shaped in collaboration with Claude, an AI assistant by Anthropic, during rainy Pacific Northwest afternoons where engineering problems meet philosophical questions.