Skills, tools, and your ERP: where AI should actually touch the data

Most AI conversations in manufacturing start in the wrong place. The question is usually "what can it do," when the useful question is "what should it be allowed to know, and what should it be allowed to touch." Once you separate those two, the way to use AI with an ERP gets simple.

Three things you can give an AI

Its own general knowledge. Out of the box, a model knows what a bill of material is and roughly how a month-end close works. It does not know your part-numbering rules, your customers, or that job 4471 is on hold. On its own it is a well-read new hire on day one.

Skills. A skill is written know-how the model reads before it works: how your shop acknowledges orders, what counts as a rush, how you classify a support request, the steps of your close. It is a document, not a connection. The model gains your judgment without gaining access to anything.

Tools. A tool is a controlled connection to a live system. "Look up on-hand quantity for this part." "List open orders for this customer." "Create a ticket." Tools are how the model learns what is true right now instead of guessing. The standard most vendors are converging on for this is MCP, the Model Context Protocol, which is just a clean way to describe what a tool does and what it is allowed to do.

The order matters. Skills first, read-only tools second, anything that writes last.

When a skill is the right answer

Use a skill when the hard part is judgment and the facts are already in front of the model.

• Triage. An email comes in asking for a change to an open order. A skill tells the model how your shop decides whether that is a new line, a revision, or a quote. It drafts the response for a person to send.
• Documentation. Your shop has a way of writing work instructions. A skill holds the format and the rules, and the model turns an engineer's notes into a draft that matches.
• Consistency. Every quote, acknowledgment, or ticket note comes out the way you want it, because the rules are written down once instead of living in three people's heads.

Skills are cheap, fast to change, and safe. If a skill is wrong, the worst case is a bad draft. Keep them in version control the way you keep code, because they are the part of your process that survives staff turnover.

When a tool is the right answer

Use a tool when the answer depends on what the ERP says right now.

• "Can we ship this order Thursday?" needs on-hand, allocated, and open job status. No skill can know that.
• "Which invoices are missing a PO?" needs a query against live AP and purchasing.
• "What changed on this BOM since the last revision?" needs the revision history out of the system.

A read-only tool answers all of these without any risk to the data. The model can look, compare, and explain, and a person decides what to do with it. Most of the value in a shop sits here, and most of it is still untouched.

Skills and tools together

The useful work usually needs both. The skill supplies the policy. The tool supplies the facts.

• AP triage: the skill knows your matching rules. The tool pulls the PO and receipt. The model produces a list of exceptions for the AP clerk with the reason beside each one.
• Quoting help: the skill knows your margin and lead-time rules. The tool pulls current cost and capacity. The model drafts the quote. A person sends it.
• Month-end: the skill is your close checklist. The tools query WIP, labor, and shipments. The model returns the places that do not reconcile, and why, before anyone opens a spreadsheet.

In each case the AI reads, reasons, and proposes. It does not post.

Writes go behind a gate

Eventually someone asks for the model to create the sales order, release the job, or post the journal. That is a write, and writes are where a mistake costs real money.

The pattern that works is the one we use in our own ticketing: the model proposes the exact change, a person approves it, and only then does the tool execute it. Every proposal and every execution is logged. The tool that writes has the narrowest access that still does the job. Nothing writes to production until it has run against a copy.

Done that way, a write tool is just a faster version of what your team already does, with a clearer audit trail than most ERPs keep on their own.

What to avoid

• Do not hand the model a database dump and hope. Give it a tool that answers specific questions.
• Do not let the first project be one that writes to the ERP. Start where failure is cheap.
• Do not keep the rules only in a chat prompt someone typed once. Put them in a skill, in version control, with a name on it.
• Do not send your data to a service you do not control. Every deployment we run keeps the data in your tenant.

Where to start

One skill and one read-only tool. Pick a question your team answers by hand every day, write down how you answer it, connect the model to the one system that holds the facts, and measure it for a month. If it holds up, the next one is obvious. If it does not, you spent weeks, not quarters, and you have a written process you did not have before.