For SYSPRO sites that want AI on real data
Your team is already pasting SYSPRO exports into a chat window to get answers faster. We build the sanctioned version: AI that reads live SYSPRO data through the interfaces SYSPRO ships, scoped to what each operator is allowed to see.
Read only by default. Every request logged. Runs in your infrastructure.
The gap
It is that nothing safe connects the assistant to the order book.
Ask ChatGPT about your backlog and it will answer. Fluently, in a nice table, and completely made up, because it has no way to look at SYSPRO. Confident and wrong is worse than nothing.
Answers nobody can act on or check
Somebody needed an answer, the SRS report was going to take a week, and the tool on their phone could do it in ten seconds if it could see the data. So they helped it see the data.
Your costing data in a chat window nobody approved
IT is right to say no to the pasting. But saying no without providing an alternative just moves it somewhere less visible. The question is not whether AI touches SYSPRO. It is whether it does so through a door you built.
A policy nobody follows instead of a control that works
What we do
Three layers. Most sites start with the first and stop there for a while, which is fine.
The connection layer. MCP is the open standard that lets Claude, ChatGPT, or Copilot query a real system. We build one against your SYSPRO install.
In practice
Reads come through SYSPRO OData, which is read only by design and exactly right for this. Writes, when you enable them, go through e.net business objects so SYSPRO validation, costing, and the audit trail all run. On SYSPRO 8 that traffic uses the e.net communications load balancer, the same plumbing SYSPRO own services use.
The interface most people actually touch. Ask about stock, an order, a customer, or a job and get an answer from live records with links back to them.
In practice
Customer service asks "what is on backorder for this customer and when can we ship it." The answer pulls current stock, open purchase orders, and lead times from SYSPRO, and cites the records so anyone can verify it in ten seconds.
Once reading is trusted, the same connection can act. Reading emailed POs and posting them, chasing exceptions, flagging orders that are about to slip.
In practice
An emailed purchase order gets read, matched against SYSPRO pricing and stock, and posted as a sales order through the e.net business object. Anything ambiguous goes to a person with the reason attached. Nothing posts by direct SQL, ever.
A dashboard answers the questions you designed it around. An assistant answers the follow-up nobody predicted, without a new SRS report.
In practice
The dashboard shows on-time delivery slipping. Somebody asks which customers, which warehouses, and whether it correlates with a supplier. Three follow-ups, no ticket, no Crystal designer.
Custom form fields, your warehouse codes, your branch structure, the naming your shop actually uses. Off-the-shelf connectors do not know any of it.
In practice
This is why generic AI connectors demo well and fail in week two. If your team says "the Dayton line" and SYSPRO says warehouse 04, the assistant needs to know both.
The same server can expose your other systems too, so one question can span SYSPRO, the shipping portal, and the quality folder.
In practice
A customer asks where an order is and whether the certs are ready. That answer lives in three systems. The assistant can reach all three, which no single ERP report can do.
Not sure which of these matters most for your company? That is what the first call is for.
Under the hood
The engineering that matters here is the boundaries, not the model.
2 to 4 weeks
from first call to a working server your team can use
Read only
default posture, writes enabled one business object at a time
0
direct SQL writes, now or ever
Questions
It is, when it is built this way, and the safety is most of what we are actually selling. Reads come through SYSPRO OData, which is read only by design. Writes go through e.net business objects so SYSPRO validation and audit trail run. Permissions follow the operator asking. Every request is logged. The genuinely unsafe option is the one happening today, where somebody exports costing data and pastes it into a public chat window.
MCP is the Model Context Protocol, an open standard introduced by Anthropic in late 2024 for connecting AI assistants to real systems. An MCP server for SYSPRO describes what the assistant is allowed to ask for and answers those requests from live data. It holds no intelligence of its own. It is a controlled doorway, not a brain.
SYSPRO 8 is the smoothest path because OData and the e.net communications load balancer are both there. On earlier versions we work with whatever e.net and database access you have, which still covers reading, and reading is where nearly all the early value sits. We check your version on the first call and tell you plainly what changes.
It starts read only. When you are ready, we enable specific business objects one at a time, each with someone accountable for it. Every write runs through e.net so it is validated, costed, and audited like any other transaction. Most sites read for months before enabling a single write, and get plenty of value doing it.
Not meaningfully, and we design so it cannot. Reads are rate limited, heavy analytical queries come off views or a replica rather than the live transaction path, and the whole thing is small compared to a single SRS report run against production.
No, and that is the point of building on a protocol instead of a product. The same server works with Claude, ChatGPT, Copilot, and whatever your team standardizes on next year. Switching assistants does not mean rebuilding the SYSPRO connection.
They are complementary and they answer to different roadmaps. Vendor AI works inside the vendor product, on the vendor schedule, and reaches you when it reaches your version. This works across SYSPRO and everything running beside it, and it exists as soon as it is built. If SYSPRO ships something that replaces part of this, good, use it. The connection layer stays useful either way.
Let's talk
Thirty minutes. You tell us your SYSPRO version and the questions people keep digging for. We tell you what the server would look like and what it would take.
Read next