A general assistant knows nothing about your business
Ask it which jobs are running over quoted hours and it will produce a confident, well-formatted, entirely invented answer. It has no way to look inside abas.
Answers nobody can act on or check
For abas sites that want AI on real data
AI for abas ERP: MCP servers, chatbots, and agents
abas has something most ERPs do not: a REST API that runs your core logic and your company-specific customizations on every call. That makes it an unusually good foundation for AI, because the assistant sees your abas, not a generic one.
- abas REST API
- Runs your customizations
- Scoped per user
- Fully logged
Read only by default. Every request logged. Runs in your infrastructure.
The gap
The data is in abas. The answers are still three days away.
Which is exactly the gap people close by pasting exports into a chat window.
Every real question still needs the abas person
Real-time reporting is the most common gap abas users name. So the questions that get answered are the ones somebody already built a report for, and the rest turn into exports.
A queue between every question and its answer
Your customizations are the whole point, and generic tools ignore them
abas shops customize heavily. That is why you chose it. A generic AI connector reading raw data has no idea what your company-specific fields and logic mean.
Tools that demo well and are wrong about your business
What we do
What we build on abas
Three layers. Most sites start with the first and stay there a while, which is the right pace.
An MCP server for abas
The connection layer. MCP is the open standard that lets Claude, ChatGPT, or Copilot query a real system. We build one over your abas REST API.
In practice
Because the abas REST API executes the ERP core logic plus your company-specific customizations, the assistant sees data the same way the client does. That is a genuinely better starting point than the raw-table access most ERPs force you into.
A chatbot grounded in abas
Ask about a job, an order, a customer, or a part and get an answer from live abas records, with links back so anyone can check it.
In practice
Inside sales asks what a customer ordered last time and what it shipped at. The answer comes from live abas records and quote history in seconds, instead of from whoever remembers.
Agents that do the boring part
Once reading is trusted, the same connection can act. Reading vendor confirmations, matching them to POs, flagging jobs about to slip.
In practice
A PDF confirmation arrives, gets read, matched to the purchase order in abas, and posted through the REST API so your validation and customizations run on the write. Exceptions go to a person with the reason attached.
It understands your abas, not stock abas
Custom fields, custom screens, and the FOP logic somebody wrote years ago. The assistant is built against your configuration.
In practice
If your shop calls it a traveler and abas calls it something else, the assistant knows both. This is the difference between a tool people keep using and one they abandon in week two.
Answers the reports cannot anticipate
A report answers the question it was built for. An assistant answers the three follow-ups, without another report request.
In practice
Margin is down on a product line. Which customers, which jobs, and was it material or labor? Three questions, one minute, no ticket.
abas plus everything beside it
The same server can reach the spreadsheets, the quality files, and the systems abas does not cover, so one question can span all of them.
In practice
The scheduling spreadsheet and abas disagree about a promise date. An assistant that can see both can tell you that, which no abas report can.
Not sure which of these matters most for your company? That is what the first call is for.
Under the hood
How we connect AI to abas safely
The engineering that matters here is the boundaries, not the model.
- abas REST API
- Real time reads and writes that run abas core logic and your customizations. The assistant gets your business rules for free rather than reimplementing them badly.
- abas Connect
- Where message routing and conversion between abas and outside systems is already in place, we use it rather than building a parallel path.
- Scheduled exports, for older installs
- If the REST API is not available to us, CSV, XML, JSON and XLSX exports still support reading. Answers are as fresh as the last export, which usually still beats three days.
- Scoping, logging and limits
- Each tool the assistant can call is defined explicitly, access follows the user asking, and every request is recorded.
What we will not do
- We do not modify your abas core. What we build sits alongside it, so your next upgrade is not our problem to survive.
- We do not write around the API. Writes go through the REST API so abas validation and your customizations still run.
- We do not enable writes by default. A new server is read only, and each action gets turned on deliberately.
- We do not send your abas data anywhere for training. It moves between your system and the assistant your team already uses.
2 to 4 weeks
from first call to a working server your team can use
Read only
default posture, with writes enabled one operation at a time
0
changes to your abas core or upgrade path
Questions
AI for abas ERP questions we get asked
It is, when it is built this way. Read only to start. Every request scoped to what that user may see and logged. Writes, if you enable them, go through the abas REST API so validation and your customizations run. Nothing touches the abas core. The unsafe option is the one already happening, where somebody exports and pastes 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 abas describes what the assistant may ask for and answers those requests from live data. It holds no intelligence of its own. It is a controlled doorway.
It should, because we do not touch the abas core. We work through the REST API and abas Connect, which are supported interfaces. An upgrade changes what sits behind the interface, not the interface itself. We test against your sandbox before anything goes live.
Yes, and this is where abas has a real advantage. Because the REST API executes ERP core logic and company-specific customizations, the assistant reads data the way your client does. On top of that we build against your actual field names and terminology, which is what generic connectors cannot do.
Then we start with scheduled exports. Answers are as fresh as the last export rather than live, which is less good and still a large improvement on waiting days for a report. We check what your install and licensing actually expose on the first call.
No. The same server works with Claude, ChatGPT, Copilot, and whatever your team standardizes on later. Building on a protocol rather than one vendor product is the point.
Usually only briefly, to confirm API access and licensing. We are not competing with them for the ERP work. This sits outside what a partner typically builds.
Let's talk
Want your team asking abas questions in plain English?
Thirty minutes. You tell us your abas version and what people keep having to dig for. We tell you what the server would look like and what it would take.
No commitment and no pressure
We will tell you straight if we cannot help
The invite lands in your calendar right away
From first call to live in 2 to 4 weeks
Loading available times
Read next