Which AI buzzwords are worth knowing?

While writing up AI-native recently, I also went through the AI terms I’ve kept running into over the past couple of years.

Agent, MCP, context engineering, harness, evals, long-horizon, Skills, memory, multi-agent…

There are a lot of them, and more keep coming.

I don’t think there’s any need to memorize a 50-word glossary.

For PMs, builders, or anyone who just wants to understand AI products better, what’s more useful is this: when you hear a new term, being able to roughly judge whether a new capability or product structure has really appeared behind it, or whether it’s just an old thing with a new AI name.

If I only look at the batch most worth knowing right now, I’d remember these first:

Agent / agentic workflow: AI doesn’t just answer questions; it can call tools, decide the next step and keep executing. One of the most important product paradigms right now, but with plenty of hype.

Long-horizon: whether AI can keep a complex task going for tens of minutes or even hours. Increasingly worth watching in 2026.

Context engineering: managing which instructions, history, tools, retrieval, memory and other information the model should see at each step.

Harness / scaffolding: the runtime system built around the model, including tools, the execution loop, the environment, permissions, state and feedback.

Agent Skills / Skills: packaging professional processes, instructions, scripts and resources into capabilities an agent can call on as needed.

Agent memory / memory: letting an agent keep, organize and reuse information from past interactions and tasks, rather than starting from zero each time.

MCP: letting AI applications connect to tools, data and external systems in a more standard way. Important, but what it solves is connection; it doesn’t make the model itself smarter.

Evals: first define what “doing well” means, then measure it systematically. Already a core capability of AI product engineering.

A few other terms are worth knowing too, but I won’t expand on them here:

reasoning models, multi-agent, grounding, guardrails, RAG.

The first two are still very hot; the last three are already closer to basic concepts in AI products.

Looking at these terms together is actually more interesting than memorizing definitions one by one.

Because together they reflect one thing:

the questions the AI industry cares about are slowly expanding from “how smart is the model” to “how do you turn a smart model into a reliable system.”

From chat to agent: the basic unit of work has changed

When using ChatGPT before, the most common unit was one interaction:

I ask a line, it answers a line.

Agents are starting to turn that unit into:

a task.

Once the user gives a goal, the system can look things up, call tools, change files, run code, and keep executing based on intermediate results.

Discussing the impact of agents on work this year, OpenAI described this shift as moving from brief chatbot interactions toward delegated, long-horizon tasks.

Long-horizon here doesn’t only mean “the model can think a bit longer.”

What’s really hard is:

• after working through dozens of steps, does the agent still remember the original goal?
• what happens when the intermediate state changes?
• can it recover after a step fails?
• what happens when the context is nearly full?

Once a task goes from tens of seconds to tens of minutes or longer, all these problems get magnified.

So as agents and long-horizon move forward, context, memory, harness and evals all become more important together.

They didn’t become popular at the same time by accident.

Prompt → context: the question is no longer just “how to ask”

When people talked about getting the most out of LLMs a few years ago, prompt engineering was hard to avoid.

Prompts still matter, of course.

But once agents really start working, what needs managing goes far beyond one prompt.

Context engineering is about:

what exactly should the model know at this moment?

That may include:

system instructions, user history, the current task state, available tools, retrieved data, memory, and the intermediate results left by the previous dozens of steps.

The longer an agent works, the more obvious this problem becomes.

You also can’t simply keep stuffing all the history into the context. Too much information can itself hurt the model’s performance.

That’s why a whole set of approaches has appeared: compaction, structured memory, just-in-time retrieval, subagents.

I think context engineering is one of the few new terms of recent years worth understanding seriously.

It describes a real change:

before, we mainly optimized “how should I tell the model”; now we also have to design “what should the model know at this moment.”

Skills and memory: how agents learn specific ways of working, and how they use past experience

I think these two terms are increasingly worth watching too.

Agent Skills / Skills

General models know a lot, but real work often has its own processes and methods.

A company’s coding standards, review methods, data analysis process and internal procedures shouldn’t have to be rewritten into a long prompt and stuffed into the agent every time.

The idea of Skills is to organize these instructions, scripts and resources, and load them when the corresponding task needs doing.

So what it actually solves is:

how to turn a general-purpose agent into one that better understands a specific way of working.

That isn’t the same thing as “whether the model has the knowledge.”

A model may know how to write code, but it doesn’t necessarily know:

how this team writes code, how it reviews, which steps can’t be skipped, which tools must be used.

Skills are more like adding a reusable layer of method on top of general capability.

Agent memory / memory

Memory handles a different problem:

of the things an agent has done before, which are worth keeping?

When should they be brought out again later?

This isn’t just “saving chat history” either.

Feed the model all the history as is, and it quickly becomes long and messy.

Really useful memory has to consider:

• what’s worth remembering?
• how to organize it?
• when to retrieve it?
• which information has expired?
• what should be forgotten?

As an agent slowly goes from a one-off tool to a system you work with over the long term, memory naturally turns from a small feature into a system design problem.

So when I think about agent memory now, I’d rather see it as:

turning past interactions into context that’s genuinely usable later.

Rather than simply “the more AI remembers, the better.”

Model → harness: much of the difference between products actually happens outside the model

Harness is a term I’ve recently found especially worth knowing.

Roughly, it means:

the runtime system around the model that lets it actually work as an agent.

For example:

• which tools can the model call?
• how does it loop through execution?
• what environment does it run in?
• when does it need the user’s approval?
• how is state saved?
• what happens when the context fills up?
• how does it retry after a failure?
• how is what it did recorded?

None of these are capabilities of the model itself.

Even if two AI products call the same base model, their final performance can differ a lot.

Because they may give the model:

different context, different tools, different permissions, different feedback loops, and completely different execution environments.

This is also something I care about more and more when looking at AI products now:

seeing a line like:

Powered by OpenAI / Anthropic

already tells you rather little.

What’s more worth asking is:

what has been built around the model?

Everyone can buy similar frontier models.

What often decides whether a product works reliably, and whether you dare hand it to real users, is the whole system around it.

So many of the differences in AI-native actually happen outside the model.

MCP matters, but what it solves is connection

MCP isn’t really a new AI term anymore.

The problem it solves is fairly clear:

how to let AI clients / agents connect to tools, data and external systems in a more standardized way.

Before, different AI applications connecting to Google Drive, databases, GitHub or internal systems usually each built their own integration.

MCP wants to standardize this layer of connection somewhat.

That matters, because if an agent can only stay inside a chat box, what it can accomplish is ultimately limited.

But it’s also easy to hype here.

A product saying:

“we support MCP.”

doesn’t mean it suddenly has some AI moat.

MCP solves connection and interoperability.

Being connected to a system and knowing how to get things done well are two different layers of problem.

A bit like how supporting HTTP is of course important for internet products, but supporting HTTP in itself says nothing about whether your product is good.

Demo → evals: once it runs, how do you know it really got better?

Evals may be the least buzzword-y term in this batch.

What it does is very plain:

first define what success means, then measure it in a repeatable way.

The trouble with AI systems is that they aren’t as easy to test as traditional deterministic software.

Run the same task a few times, and the results may differ.

Switch models, change a passage of the prompt, add a tool, and some cases may improve while others regress.

Agents are more complex still.

They may call tools and change the environment across many turns, and a mistake at any step can affect what comes after.

So when evaluating agents, it’s no longer only the final answer that’s looked at.

It may also include:

• what trajectory did it take?
• were tools used correctly?
• was the final task completed?
• what state is the environment in at the end?

That’s also why I increasingly feel:

evals aren’t only done at final QA.

They’re actually part of the product definition.

A team first has to make clear:

what exactly do we mean by “AI doing well”?

If this question stays vague, later optimization easily turns into:

“I tried it, and it seems fine.”

What about reasoning and multi-agent?

I still keep these two terms in mind, but won’t put them on this post’s main thread.

Reasoning models are a real change in model capability: the model puts more inference-time compute into answering complex questions.

But that’s more about the model layer.

What I care more about in this post is: once model capability is already strong, what starts happening at the product layer.

Multi-agent is a real thing too.

Several agents can divide work, run in parallel and check each other, and some complex tasks really do suit this.

But it’s also very easy to over-engineer.

A problem one agent can solve doesn’t need to be forcibly split into five agents holding a meeting just to sound advanced.

So when I see “multi-agent system,” I don’t naturally assume it’s more advanced than single-agent.

It still comes down to:

why are several needed? What specific problem does it solve?

Buzzwords can actually be read as a map of the industry

Putting these terms in time order, I think you can see a fairly clear shift.

A few years ago there was a lot of discussion of:

prompt engineering

The focus was how to get the model to answer better.

Later there was a lot of discussion of:

agents / tool use / MCP

Models started needing to move from “answering” to “acting.”

What’s increasingly common now is:

context engineering / harness / long-horizon / Skills / memory / evals

The questions of concern have become:

• how to get the agent the right information;
• how to have it master a particular way of working;
• how to have it keep genuinely useful experience;
• how to keep it working continuously;
• and how to know whether it has actually done the job well.

So buzzwords aren’t necessarily just marketing.

Some terms suddenly get discussed by lots of engineering teams because, once technology takes a step forward, new bottlenecks really start blocking products.

From this angle, new terms themselves can serve as a map of the industry.

They tell you:

what problems people are working on right now.

How do you judge whether an AI buzzword is worth learning?

I roughly look at four things:

• what new capability does it describe that didn’t exist before?
• which real constraint does it solve?
• has it changed a product’s workflow, architecture or economics?
• if I were really building a product, would this concept change one of my design decisions?

If the answers are all vague, it may for now just be a nice-sounding label.

If it affects how you organize context, grant permissions, connect tools, save state or test quality, it’s worth taking more seriously.

AI terms will probably keep multiplying fast.

There’s not much need to remember them all.

What’s more useful is slowly being able to see what real change is actually happening behind the new words.