Agents are becoming the default request in every AI conversation, but most teams asking for one have no way of knowing whether their business can support it yet.
The request usually arrives fully formed. Someone has read about an agent that handles a whole process end to end, and the brief we receive is "we want that for our support inbox" or "we want that for our monthly reporting".
The conversation starts at the finished system and works backwards towards the business. That sounds sensible, until collectively with the customer we realise that process skips most of the important questions worth asking first.
It skips asking whether this business can run the process reliably before AI has even been introduced to the process.
The thing nobody wants to hear about their own business
In our world it's often groundhog day when someone describes what they want an agent to do for a process.
When they are asked to describe that process step by step, four people describe it four different ways. Nobody in the room is wrong, either. We all have different vantage points from which we operate.
But the process has never been written down as a Standard Operating Procedure (SOP), so each person has run a slightly personal version of it for years, and none of them had any reason to notice the difference to what their colleagues have been doing.
That is not an AI problem, it is a business problem that AI has just made visible.
An agent is basically choreography.
It decides what to do next across multiple steps, calls tools and applications, holds state (basically it keeps track of what just happened, so the next screen, request, or step does not start from scratch.) between them, and keeps running without a person nudging it along.
Lay that choreography over a process nobody has documented and the result is not an improvement in the process, or automation. It is an expensive system that confidently does the wrong thing at speed, and the failure usually surfaces when a customer or colleague not close to the build finds out rather than the owner of the agent.
The more difficult pill to swallow is that the useful question was never "what agent should we build". The useful question is what is the smallest piece of this work AI can be made to do reliably, and what does attempting that teach the business about itself.
That second half is the part almost everyone skips, and it's, in my mind, the most useful first step every business should take to kickstart their AI transformation journey. Here is another lens on how to implement AI across your business, a step by step guide.
What a skill is, and why it is not the beginner option
A skill is an ability the AI unlocks and then applies on its own. Think of it as special training that sticks, so once the AI has been taught the ability it knows that the ability exists, knows what it does, and reaches for it whenever the work calls for it, without anyone asking.
Build a presentation and the brand guidelines load themselves.
Analyse a dataset and the analysis framework is already running.
rite a report and the house structure shapes it before anyone mentions the structure.
Underneath the analogy it is a plain folder. Inside sits one instruction file written in ordinary English, describing how the task gets done, alongside whatever the task needs to hand: reference documents, brand assets, worked examples, and code scripts where a step has to run the same way every time.
A skill works across every platform that offers this (e.g. they're portable), and the shorthand is that a skill equals the prompt plus the tools plus the assets. I wrote a full breakdown of how skills work and how to build one when the feature first launched, so anyone wanting the mechanics can start there.
Two properties matter more than the rest.
Nothing loads until it is needed, so a skill can carry far more reference material than anyone could paste into a conversation.
A skill can also run actual code, which keeps the steps that must be exact exact, meaning the AI handles the judgement while code handles the certainty to remove hallucination risk.
That is what separates a skill from a saved prompt.
A saved prompt is wording somebody reuses.
A skill is a portable piece of a workflow, written in natural language rather than assembled in a drag-and-drop builder, that produces the same output from the same inputs every time it runs.
In Claude, ChatGPT and most major platforms this is now a literal product feature, meaning a non-technical person can build one without writing code. For example, to classify this case against these categories, summarise this call in our format, check this contract against our criteria, or rewrite this response in our tone. One job, performed the same way every time, with defined inputs and defined outputs, and shareable across teams.
People often hear that description of a skill and file it under 'basics', something a team does before the real work begins.
The trap is in thinking that skills are not the basic option at all. Building one is the most demanding thing a business can be asked to do, because a skill only runs once somebody has answered the questions the business has spent years avoiding.
Take a skill that classifies support tickets: where somebody has to decide what the categories genuinely are, which means admitting that three of the current categories overlap because a previous employee preferred it that way.
Take a skill that summarises a client call into the business's format: where somebody has to define that format, which means someone defining what their version of a good summary contains. That has never been written down, because two different people who do it well simply 'just know' and it's in 'their heads'.
Take a skill that checks a document against policy: where somebody has to produce the policy in a form, which tends to reveal that the real policy is a mixture of a document from four years ago, an email thread nobody can locate, and a manager's judgement.
None of that is a delay on the way to building an agent (the real perceived project). In fact, this is the work that will be completed in the project, but understood and identified earlier and more cheaply by the team involved.
In effect, it is the project work itself.
Skills make the implicit work explicit
This is the part that turns a technical practice into an AI transformation practice.
Every business runs on undocumented knowledge, meaning the decisions people make without noticing they are decisions, the exceptions everyone silently knows about, and the handoff that only works because two people happen to speak every morning. None of it is written anywhere or codified, and all of it is critical to the project's success.
None of it can be found by asking any one individual, either. Ask someone to describe their workflow and what comes back is the happy path, the one matching the process map on the wall, because the messy parts became automatic, workarounds by the human were built, and stopped registering as parts of the SOP years ago.
Building a skill breaks that open, since a skill has to be specified before it can run. Gaps cannot be left open in the hope that judgement fills them, and the moment somebody tries to codify the process in a skill, the gap appears for everyone to see.
Five findings often materialise the first time a business builds a skill for an existing process:
The data is not what anyone believed or understood, with fields half-filled, statuses meaning different things to different teams, and records living in two systems with two versions of the truth.
The decision rules were never written down, so the skill asks for criteria to reflect against and the business finds its criteria is really one person's accumulated judgement.
The handoffs are invisible, because work moves through habit, a shared inbox, or a Teams/Slack message, and none of those is a defined step anyone can point at.
The approvals are informal, so somebody signs off but nobody can say what triggers that sign-off, or what happens while that person is on leave. This creates inconsistency in approach. We've seen this repeatedly in processes like bid management or submission response workflows.
The exceptions outnumber the rule, and the standard process covers a minority of the cases that actually arrive.
Every one of those is a finding rather than a setback.
Each costs a fraction of what a discovery consulting engagement costs to produce the same list, because the business learned it by building something instead of interviewing people about what they believe they do.
That is the real argument for starting with skills, and it is not that they are quicker, though they are.
It is that building them is the cheapest way to find the gaps, and those gaps are the only dependable record of how the business actually runs.
The gaps are the roadmap
Once that list of gaps exists, the strategy stops being a guess.
Most AI roadmaps get built the wrong way round. Someone lists the processes that look expensive, ranks them by the hours they consume, and presents that as a prioritised backlog. The trap is that it looks rigorous in a steering meeting while every item on it remains an assumption, since nobody tested whether the underlying work is stable enough to be automated in the first place.
A roadmap built from skill-building findings behaves differently, because each item arrives with evidence attached of the work required to fix the underlying operation to facilitate the process and new agent.
The ticket classification is known to be fixable, because the classifier was built and it works.
The reporting process is known to be premature, because it was attempted and the source data holds three versions of every customer name.
The approval step is known to be a bottleneck, because the skill kept stalling there and somebody had to find out why.
Those findings sort themselves into three categories:
Work that is ready, where the skill runs reliably, the inputs are clean, the outputs are what people wanted, and automation pays off immediately.
Work that needs the business fixed first, where the skill exposed a data problem or an undocumented rule, so the automation waits while the repair goes to the top of the operational backlog.
Work that should stay human, where the skill revealed that the judgement involved is the actual value being delivered, and it hasn't been documented because it always resisted being documented.
That third category holds less weight in the AI era because people are throwing AI at everything without understanding the risks or erroneous decisions behind that thinking.
Identifying tasks should not be automated protects more money than most successful automations ever generate.
When the agent finally gets the greenlight
Now the original question can be answered properly.
The move from skills to an agent happens when the skills work individually and the only thing holding the process together is a person acting as glue to keep it running.
Once somebody's role has been reduced to triggering step one, copying the output into step two, checking a status, and pushing the result into step three, the coordination is the only work left. Coordination is precisely what an agent does well.
The practical test is five questions, which requires a yes for most:
Frequency, meaning does this run often enough that automating the coordination justifies building and maintaining it?
Stability, meaning do the individual steps already work on their own, or is the plan to automate a process that still breaks?
Decision branches, meaning are the if-this-then-that rules clear enough to write down, or does a person still judge each case?
System touchpoints, meaning does the agent have real access to the systems it needs, or will it hit a wall it cannot cross?
Risk controls, meaning is it known what happens when it gets something wrong, who sees the mistake, and how it gets caught?
If those pass the sniff test, build the agent. It will be a better agent than the one built six months earlier, because the inputs, outputs, edge cases and review points are all known from having done the work built as a skill first.
If those do not hold, the business is not ready, and the skill-building already identified which part is not ready and what needs to happen to next to fix it.
There is also a substantial middle ground that gets skipped in the rush.
Skills can be chained together, meaning one skill's output triggers the next, with rules governing what happens when a check fails and where the work returns to. That is a designed flow rather than an autonomous system, and for many business processes it is entirely sufficient.
Plenty of teams asking for an agent want chained skills, and would be better served by them, because a designed flow is easier to debug, easier to hand over, and easier to change when the process changes underneath it.
The maturity ladder to follow
Build the skill, reveal the system, then automate.
Laid out as a stack, the maturity ladder follows five layers:
Business context, meaning the documents, data, rules and examples the AI needs access to before it can do anything useful.
Mapped workflow, meaning the work written down as actual steps, with owners, inputs and outputs, rather than the version living in people's heads.
Reusable skills, the single capabilities built on top of that map, each doing one job the same way every time.
Chained skills, the designed flows where one skill's output triggers the next.
The agent, the autonomous layer that only works when everything beneath it already holds.
Teams try to start with an agent first, because the agent is the part that demos well. The work starts at the bottom, because the bottom two layers are the ones nobody has, and building the first skill is precisely what forces them into existence. A skill built without context and a mapped workflow fails immediately, and the failure points at exactly which foundation is missing.
The reason to start with skills is not that they are the beginner version of agents
It is that building them forces a business to identify how it operates by placing a mirror on itself, and very few businesses can currently do that. The findings are worth more than the skill itself, because they identify which parts of the business are ready to automate, which parts need repairing first, and which are better left alone.
Any business running an AI transformation needs that map, and there are two ways to get one.
The first is to pay somebody to interview the team and produce a document describing the work as the team believes it happens.
The second is to build one small thing and find out what is really there.
If an AI consultant quotes for an agent build before asking to see one workflow run end to end, that is the signal to find a different consultant.
Passionate about all things AI, emerging tech and start-ups, Mike is the Founder of The AI Corner.
Subscribe to The AI Corner
