When Did Everything in AI Become a “Skill”?

There is a word that has been bothering me in the rapidly evolving world of AI agents:

Skill.

It sounds perfectly natural.

After all, humans have skills. Organizations have skill frameworks. HR teams hire for skills, assess skills and develop skills.

But when we look at how the word is being used in the AI-agent world, something interesting is happening.

“Skill” is becoming a catch-all word for almost anything an AI agent needs to know or do.

And I think we should be a little more careful about that.

In the human world, skill has a fairly clear meaning

In recruitment and HR, we might say that a person has:

• Python programming skills

• negotiation skills

• project management skills

• financial analysis skills

• communication skills

We can assess those skills.

We can map them to roles.

We can identify skill gaps.

We can create development plans around them.

The same is true in project management and engineering.

We have words such as:

Roadmap. Plan. Process. Methodology. Solution. Architecture. Design principles. Role. Responsibility. Skill. Tool.

These words exist at different levels and serve different purposes.

A roadmap is not a plan.

A plan is not a process.

A process is not a methodology.

And a skill is not a solution.

This distinction is not just about language. It helps us think clearly about how work is actually organized.

AI is blurring these boundaries

Now consider an AI agent.

A vendor may call something a skill even when it contains a combination of instructions, context, domain knowledge, procedures, workflows, rules and access to various capabilities.

A coding agent might have a set of project instructions.

A recruitment agent might have a methodology for evaluating candidates.

A finance agent might have a set of procedures for analysing financial information.

All of these may be packaged and presented as “skills.”

There is nothing inherently wrong with that.

But we should recognize what has happened.

The word “skill” has become an abstraction chosen by the AI platform, rather than necessarily meaning “skill” in the traditional human sense.

And that is where I think the confusion begins.

Why should HR and business leaders care?

Because terminology influences how we design systems.

If everything is called a skill, we can very quickly start thinking that everything is the same kind of thing.

It isn’t.

Take a recruitment agent as an example.

We may actually be dealing with very different concepts:

A recruitment objective.

What are we trying to accomplish?

A recruitment process.

What are the steps through which the work is performed?

An evaluation methodology.

How should candidates be assessed?

Business rules.

What rules or policies must be followed?

A workflow.

What should happen after a particular event or decision?

Knowledge.

What information does the agent need?

Access to systems and data.

What information can it retrieve or update?

And perhaps, finally, an AI skill that packages some of these things into a reusable capability.

These are not necessarily the same abstraction.

If we don’t distinguish them while designing the agent, we may still produce something that works.

But we may not produce something that is easy to govern, explain, improve or scale.

This is where clear thinking becomes important

Agentic AI is moving very quickly.

New platforms introduce new terminology. New frameworks introduce new abstractions. Vendors package capabilities in different ways.

It is tempting to simply adopt the vocabulary supplied by the platform.

I think that is a mistake.

Before choosing the technology, we should first understand the problem and decompose it properly.

What is the business objective?

What is the process?

What decisions are being made?

What knowledge is required?

What rules must be followed?

What should the AI reason about?

What should it be allowed to do?

What should remain under human responsibility?

What capabilities should be reusable?

And only then:

What should we package as a skill?

That way, “skill” becomes a useful implementation concept rather than a substitute for thinking.

The next wave of enterprise AI needs this discipline

For organizations adopting AI agents, this distinction will become increasingly important.

The question should not simply be:

“How many skills does our AI agent have?”

A better question is:

“Have we designed the capabilities of this agent at the right level of abstraction?”

That is a very different question.

And this is where I think we need to be careful about the current enthusiasm around AI development.

It is relatively easy today to vibe-code an internal AI tool and get something impressive working quickly.

The difficult part comes later.

If the underlying abstractions are wrong — if the responsibilities, processes, capabilities and boundaries have not been thought through properly — those design decisions can become very expensive to correct in the long run.

An internal prototype can tolerate quite a lot of ambiguity.

A system that is going to be used across an organization, integrated with business processes and maintained for years cannot.

That is why I believe the people involved in designing and building enterprise AI agents need more than the ability to make an agent work.

They need to be able to think through the problem properly, recognize design issues, accept when something needs to change, and iterate through multiple release cycles.

And perhaps most importantly, there needs to be long-term commitment to the product and the problem, rather than treating the first working prototype as the finished solution.

Some of the most important design problems are not discovered while building the first version.

They emerge when real users start using the system.

They emerge when business processes change.

They emerge when the system has to handle cases that were never considered in the original design.

That is why building an enterprise AI agent is not simply a matter of selecting a model, connecting some tools and writing some instructions.

It is a product and systems-engineering problem.

The technology will continue to change.

The models will change.

The frameworks will change.

Even the terminology — including the word skill — will probably change.

But good system design will remain important.

AI agents may need skills.

But the people designing those agents need something else first: clarity, discipline and the commitment to keep improving the system.