How Many AI Skills Does a Small Team Actually Need?

Most small teams need one to three AI skills, not ten. The right number is set by how many of your recurring jobs are genuinely written down and currently slipping, which for a team under fifty people is usually a very short list. Teams that start with one well chosen skill and add a second only after the first has run clean for a month end up further ahead than teams that configure six at launch.

The two ways this goes wrong

The first failure is stalling at one. A team automates a single job, it works, and then nothing else happens for a year because nobody owns the question of what is next. The agent becomes a single purpose tool and the surrounding work stays exactly as manual as it was.

The second failure is more common and more expensive: automating everything at once. Six skills go live in the same week. Three of them were scoped from a vague sense that the work was annoying rather than a clear description of what the job is. Those three produce output nobody trusts, trust leaks onto the other three, and within two months the whole thing is switched off and written up as a failed experiment. The technology was not the problem. The scoping was.

How to pick the first one

Run every candidate job through three questions.

Does it repeat on a knowable trigger? A schedule, an inbound message, a threshold being crossed. If the job happens when someone happens to think of it, there is nothing for an agent to attach to.

Could you write it down well enough that a new hire could do it from the page? Not perfectly, but completely enough that the steps are explicit and the edge cases are named. If writing it down keeps ending in use your judgment, it is not ready to delegate to an agent, and frankly it is also hard to delegate to a person.

Is it currently slipping? This is the one teams skip and it decides whether the project survives. Automating a job that already happens reliably produces a marginal efficiency gain nobody notices. Automating a job that keeps getting dropped produces a visible change in the first week. Pick the one that is failing.

The job that scores well on all three is almost always something unglamorous. A report nobody builds until someone asks. A list that needs cleaning before every campaign. An inbox that gets triaged on good weeks. That unglamorous quality is a signal, not a disappointment.

When to add the second

When the first has run for roughly a month without a correction that required a human to intervene unexpectedly. Not without escalations, escalations are the system working. Without surprises.

That month is doing real work. It is where you find out that the category list was ambiguous in one place, that the data source has a quirk at month end, that the output format needed a tweak. Discovering those things across six simultaneous skills means you cannot tell which skill is causing what, and debugging is where the project either builds confidence or burns it.

The signal that you have one too many

Nobody reads its output.

If a skill produces something every week and no one opens it, the job was not actually needed. That is a useful discovery rather than a waste, but it should end in turning the skill off. An agent running jobs nobody consumes is a cost and a false sense of coverage at the same time.

The second signal is softer: you start describing a skill’s scope with the word basically. Basically it handles the client emails. A skill you can only describe approximately is a skill whose boundaries nobody agreed on, and it will behave in ways that feel arbitrary because its definition is.

Why plans are priced by skill count

A skill is one scoped, named job. Pricing by skill count rather than by seat means the commercial conversation and the scoping conversation are the same conversation: you cannot add a skill without naming the job it does. Steward is 500 dollars per month for one skill, 1500 for up to three and 2500 for up to five, with LLM tokens and server cost passed through.

Per seat pricing makes the bill track headcount, which has nothing to do with how much work the agent is doing. Per task pricing makes it track volume, which makes the bill unpredictable in exactly the months you are busiest. Per skill tracks scope, which is the thing you actually control.

The honest answer

Start with one. Pick the job that repeats, that you can write down, and that keeps getting dropped. Run it for a month. Then look at what is still slipping and decide whether it is a second skill or something a person should own.

Most teams settle between one and three and stay there, and that is not a failure to adopt. It is an accurate read of how many of their jobs were genuinely automatable.

Related reading: what a managed AI agent is, an agent on a small team, and agent versus operations hire. Pricing is on the pricing page.