Custom AI is different because employees can write the skills

A lot of companies already “have AI.” Someone opens a page, pastes the job in, and pastes the answer back out. Ask a different colleague and the answer changes, because the instructions are typed again from scratch. The software has not learned how you work. It only remembers this one chat.

Custom work is about that gap. The procedure is saved as a skill people can run again. The lines that must not be crossed are saved as rules. The person who writes them is the person who does the job, not someone who interviewed them once at kickoff. The model follows the skill. If the skill is wrong, you edit the skill. If you later change the model, the skill stays.

Three things that get called the same project

People say “we rolled out AI” for all three. What staff actually hold is different.

A generic assistant is enough for a draft email, a translation, or turning meeting notes into a list. Those jobs do not depend on an internal rule.

The moment the job depends on your orders, your prices, or your pass/fail standard, a generic assistant depends on whoever remembered to type the rule today. This morning Chen includes “payment terms past 45 days need the finance manager.” Tomorrow the person on the next shift forgets, and the model still produces a fluent answer. Fluent is not correct.

Uploading policies into a knowledge base answers “is there a source.” Ask whether terms may pass 45 days, and it should cite your sales policy, or say it cannot find one. That is still answering. It does not match a delivery note, and it does not stop when quantity times price is wrong. Answering and doing the job are different layers. How to build the answering layer is in the knowledge-base guide. This page is the layer that does the job: the skill.

A rule is a limit. A skill is a procedure

Mixing the two is how nobody can change either of them later.

A rule says what is not allowed, and what a person must still decide. It is short, and it applies across jobs. For example:

• Unpublished prices and original contracts do not go into a chat that the whole company can open.
• A discount past a role’s limit is reported as “needs this person to approve.” The skill does not accept it on their behalf.
• Amounts, tax, and quantity times unit price are checked by calculation. The model does not do the arithmetic and then pretend it checked.
• An inspection result, or a decision to ship an exception, is signed by a named person. A skill can prepare the case. It cannot sign.

Once a rule is in force, every skill has to follow it. A finance skill cannot skip an approval because “this order is urgent.” A sales skill cannot drop a contract into a window the warehouse can read.

A skill says the order of steps for one job. It is longer, and it belongs to that job only. A skill usually has a name, who uses it, what the input is, where to look first, how to tell a match, when to stop and hand the case to a person, and what it must not invent. The person running it does not retype those instructions.

A prompt is the paragraph someone types this morning. A skill is a saved procedure with a name and an editor, used again tomorrow. Saving a prompt in a notes app is not a skill yet. Other people cannot find it, a change does not record which version changed, and the system will not force the money lines through a calculation.

What one skill looks like

The following is a format example. It is not a file from a real company.

Skill: match a delivery note to the purchase order
Used by: receiving, then finance review
Input: one delivery note, and the purchase-order number printed on it

Steps:

1. Read supplier, delivery-note number, purchase-order number, item, quantity, and unit price.
2. Find the order only by the purchase-order number. The same supplier name is not the same order.
3. Check quantity, unit price, and amount by calculation. The amount should equal quantity times unit price. Tax uses the rate on the order.
4. If every field matches, mark it passed and record the order number that was checked.
5. If one field does not match, write the field name, the value on the delivery note, and the value on the order. Do not propose a “corrected” number.
6. If there is no order number, one note covers several orders, or the units do not match (a case versus a piece), stop and hand it to a person.

Do not: pass it because “this is a long-time supplier”; fill in a plausible price when the print is unreadable; mark the receipt complete before a person has looked at the flagged lines.

Who may edit: the warehouse lead edits the steps. The finance manager confirms steps 3 and 5. Each edit records the date and the reason.

A receiver can read this, because it is how they already receive goods. It just was not written down for everyone else. The two lines finance cares about are named, so a change made “to speed up receiving” cannot quietly delete them.

When it runs, the person is not chatting. They submit this note and see either a pass or the flagged lines. A generic assistant will also say “I checked it, and it looks broadly fine.” A skill is not allowed to say “broadly.”

The people who do the job write the skill

Projects often start the other way. A consultant interviews for two days, draws the process, and engineering builds the drawing. After launch the staff say, “that isn’t actually how we do it.” The drawing is not wrong enough to reject. It missed the exceptions. The exceptions are the work: an old customer may short-ship, one material must be weighed, one supplier prints the order number on the second copy.

Interviewers do not catch all of those. The person doing the job does. So they write the skill, or at least edit it until they are willing to use it.

Start with one or two skills for one role, not a whole department. Receiving can start with “match the delivery note.” Write it against real notes, with customer names covered. Then try ten past notes: do the ones a person would pass still pass, and do the errors a person used to catch still get flagged? If one of the ten would be released by the skill and stopped by a person, change the skill. Do not add a “please remember” note beside it. The note gets forgotten. The skill does not.

A new hire then runs the same skill, not whatever mood the senior person is in that day. When the standard changes, the change is one line in the skill, with a reason. The next run uses the new line. That is different from a chat message saying “from now on, do it this way.” The message sinks.

Not everyone has to start from a blank page. The first version is often dictated by an experienced person, written into this structure by someone beside them, then edited until it feels like the real job. Later edits are adding one exception or deleting one outdated step. Training that only teaches “how to ask a prettier question” still leaves people to improvise after class. Training that belongs with a skill teaches how to run one, and how to change it. Starting from one real workflow is the same idea, before the procedure is saved.

What the custom build actually is

Letting employees write skills is not the same as handing them a chat box and calling it custom. For the delivery-note skill to run as written, there is a layer they should not have to hand-code:

• Skills live in a place the company controls, with versions. Who changed what, and why, can be looked up. They do not live in one browser bookmark.
• A run can only read the orders and documents that role is allowed to see. A sales skill does not see wages. A warehouse skill does not see a customer contract it was not granted.
• Quantity times price, and tax, go through calculation. The model reads the numbers off the page, then calculation checks them. A misread fails the check and is flagged. It is not “rounded” into a close answer.
• Each run keeps a record: which skill version, which document, what was flagged, who confirmed it.
• The run connects to the sheet, drive, or system you already use, so nobody downloads a file just to paste it into a chat. This is the part packaged software often cannot reach.

Whether the model runs on a public cloud or on your own machines is a deployment choice. It decides whether the material leaves the company. It does not decide whether the skill is right. Keep the model and the skills separate. Switching to another model should not make the warehouse lead rewrite the receiving steps.

That is also the difference from putting your logo on a packaged product. The packaged flow belongs to the vendor. An exception with no setting cannot get in. In a custom build, the exception is a line in a skill, and the people who do the work hold the edit. Engineering makes the skill runnable, logged, and calculated. The business method is not locked in a code comment, or every change from “short shipments up to 2% are acceptable” becomes another development cycle.

When the rule changes, edit the skill

Last month the term was 30 days. This month one group of customers moves to 45, and anything beyond that still needs the finance manager. With a generic assistant, that change is an email and a meeting. Some people remember. Some keep the old prompt. The model answers both versions fluently.

With a skill, it is two lines in “check payment terms before quoting.” The finance manager confirms the approval line. After that, every run follows the new lines. The old version is still there. If you need to see why something was accepted last month, you look at that version, not at what people remember now.

So custom work does not finish on launch day. Launch day is version one. After that, the business adds the exceptions they actually hit. A request that cannot be written as steps is usually a request for the skill to guess. Guessing should not be written in. What gets written is a method a person can already explain.

What may go into a skill, and who is responsible for the output, still needs a company-level rule. That is a separate one-page document: a staff AI policy. The policy is the boundary. The skill is how one job is done. A policy without skills leaves everyone improvising. Skills without a policy will pull in material they should not see.

A result means the business got larger

Fewer clicks is not a result. Cutting cost, or cutting people, is not the goal either. The same team is still there. A skill should show up as at least one of these: less overtime; more orders handled carefully on the same shift; fewer returns, penalties, or rework from mistakes; faster collection because documents and disputes are no longer stuck; the current team taking on more business.

A skill that matches none of those is a tidy document that did not make the business larger. Time saved that is immediately filled with another meeting does not count either.

FAQ

Isn’t a skill just a long prompt?

The words can look similar. The difference is a name, a version, a named editor, and a system that runs it every time, instead of hoping someone pastes the paragraph today. Steps that can be calculated are not left to the model.

What if frontline staff cannot write this?

The first version can be dictated and put into this structure by someone beside them, then handed back to be edited. The test is not prose. It is old documents: errors a person would stop must still be stopped. Later changes are one added exception, or one deleted step.

What is left for custom development?

The parts staff should not hand-write: storage and versions, reading data by role, calculation of amounts, a record of each run, and the connection to the sheet or system you already use. The business steps stay in the skill so the people who do the work can change them.

Does buying industry software count as custom?

Usually no. Industry software is a flow that is already decided. You choose among its options. A method with no option cannot be changed, or you wait for the vendor. Custom means your own exceptions can be written as skills, and your own people maintain them.

Do we need both a knowledge base and skills?

Ask whether the job is a question or a task. Asking about a policy or a pricing rule can be a knowledge base, with a source. Matching a document, or producing a result for a person to review, needs a skill. Many companies end up with both. The first one should be whichever happens every week.

What if staff write a wrong method into a skill?

That can happen, which is why there is a trial and a confirmer. Receiving can edit the receiving steps. The money line needs finance. Try it on old documents before other people use it. A skill is not policy the moment it is saved. It is a version you can roll back.