The most common reason an AI deployment underperforms is not the model. It is that nobody told the system how the business actually works.
Most owners approach this backwards. They evaluate tools, compare vendors, and worry about which model is best — then hand whichever one they chose a vague instruction and are disappointed by the result. The leverage is almost entirely in the instruction.
A skill is that instruction, written down properly: a documented procedure an AI agent loads and follows. If you have ever written a standard operating procedure for a new hire, you already know the format. The difference is that this one executes.
What a skill actually is
Think of the difference between telling a new employee "handle the incoming invoices" and handing them a page that says:
Invoices arrive by email to accounts@. For each one: match the vendor against the approved list. Match the amount against the purchase order. If both match and the total is under $2,500, code it to the department in the PO and queue it for payment. If either does not match, or the total is $2,500 or more, flag it for review and do not queue it. If the vendor is not on the approved list, flag it regardless of amount.
The second version is a skill. It names the trigger, the steps, the decision thresholds, and — critically — what to do when something does not fit.
An AI agent given the first instruction will do something plausible. An agent given the second does the thing you actually wanted, repeatedly, and you can tell when it has not.
Why this is the highest-leverage work
Three reasons, in order of how much they matter.
It is the part that does not transfer. Anyone can buy the same tools you can. The model you use will be better in six months and it will be better for your competitor too. What does not commoditize is the accumulated, specific knowledge of how your business runs — which vendors get exceptions, which customers are handled differently, what "urgent" means in your operation. Written down, that is an asset. In your head, it is a bottleneck.
It converts a vague brief into a testable one. Once the procedure is explicit, you can check whether the system followed it. Without that, "is it working?" has no answer, and you end up either trusting output you should not or discarding output that was fine.
It is the cheap part. Writing a good skill takes an afternoon. Rebuilding a deployment that failed because the brief was thin takes weeks, and most first attempts do fail — ours did, more than once.
How to write one
The structure that works, in the order it should appear.
1. Name the trigger. What starts this? An email arriving, a form submitted, a time of day, a phone call. Be specific: "an email to accounts@" not "when we get an invoice."
2. State the goal in one sentence. What does success look like? If you cannot write this sentence, stop — you are not ready to automate this yet, and that is the finding rather than a setback.
3. List the steps in order. Plain language, imperative. The test is whether a competent stranger could follow them without asking a question.
4. Give the decision rules with actual numbers. "Escalate large invoices" is not a rule. "Flag anything $2,500 or over" is. Every threshold you leave vague is a decision the system will make differently from you.
5. Say what to do when it does not fit. This is the section people skip and the one that determines whether the thing is usable. What happens with an unknown vendor, a duplicate, a partial match, a missing field? The default should almost always be: stop and flag, do not guess.
6. Define done. How does the system know it finished correctly, and what evidence should exist afterwards — a record created, a field populated, a number matching a source.
What separates a good skill from a bad one
| Weak | Strong | |
|---|---|---|
| Scope | "Manage our scheduling" | "Book inbound service calls into the Tuesday–Friday calendar" |
| Thresholds | "Escalate if it's a big job" | "Escalate if the quote exceeds $5,000" |
| Edge cases | Unstated | Named, with a default of stop-and-flag |
| Success | "Handled correctly" | "Appointment exists in the calendar with customer, address and service type" |
| Length | Two lines or ten pages | One page, usually |
The test: hand the skill to someone who does not work in your business and ask them to follow it. Every question they ask is a gap the AI would have filled with a guess.
Where they fail
Too broad. A skill covering "customer service" will underperform three skills covering "answer questions about opening hours and location", "book an appointment", and "take a complaint and escalate it". Narrow scope is not a limitation, it is the mechanism — fewer decisions means fewer places to go wrong.
Written once, never revised. The first version is a draft. Run it, watch what it gets wrong, and the corrections are your second version. Most of ours changed substantially in the first fortnight and barely at all after.
Describing intent instead of procedure. "Be helpful and professional" tells the system nothing it can act on. "If you cannot answer, take a name and number and say someone will call back within one business day" does.
No verification step. A skill that ends without saying what evidence should exist is a skill you cannot audit. We learned this the expensive way: a system reporting a task complete having done most of it, and a system reporting failure having finished correctly. Both are the same problem — the report is generated by the same thing that did the work. Every one of our procedures now ends with a check against the artifact itself.
What to write first
Not your most complicated process. Your most repeated one.
Look for work that happens daily or weekly, follows roughly the same shape each time, has a clear right answer, and currently sits with someone whose time is worth more than the task. That is the first skill. It will be boring, and boring is the point — every reliable deployment we run is boring by design.
Write it, run it for a fortnight, correct it, then write the next one.
The part that pays twice
Here is what most owners miss. The document you have just written — the procedure, the thresholds, the exception handling — is exactly what a buyer's diligence process asks for, and exactly what reduces the owner dependence that suppresses valuations in founder-led businesses.
You are not only automating a task. You are converting knowledge that lived in your head into an asset that transfers with the business. Those are the same work, and only one of them usually gets budgeted for.
We cover that overlap properly in The Process Documentation Dividend.
Related
What Is an AI Agent? covers the underlying distinction between agents, chatbots and automations. How to Choose Your First AI Automation covers selection. Running AI Agents in an Advisory Firm is our own account of what worked and what broke.
This guide is for informational purposes only and does not constitute investment, financial, legal or technology advice.