How to add AI agents to Macola
Short answer
Add AI agents to Macola by wrapping its supported data paths (read-only SQL views or the Progress/ODBC layer, plus the vendor's web services or SDK for writes where your version has them) in a small set of audited tools. The agent reasons over those tools, proposes actions, and a planner approves anything that changes data.
Macola shops tend to be small and mid-size discrete manufacturers and distributors who have run the same system for fifteen or twenty years. The knowledge of why a job is late lives in a planner's head and in three spreadsheets next to the ERP. That is exactly the kind of multi-step, judgment-light work agents can take off a planner's desk.
The catch is that Macola is not a cloud-native API platform. Depending on whether you run Macola 10 (the Progress-era product line) or Macola 100 (SQL Server based), your integration surface differs, and many customers are on-prem with customizations and Crystal Reports layered on top. An agent project in Macola is mostly an integration project: get a trustworthy read path first, then add narrow, approved write paths.
This page describes a build pattern that works for either flavor, how to scope the first three agents, and where the real risks are. Treat exact table and service names as version dependent and confirm them against your own data dictionary.
What teams use it for
Late purchase order expediting
An agent scans open PO lines past promise date, checks the on-hand and the demand it feeds, ranks which late lines actually threaten a customer order, and drafts the supplier chaser for the buyer to send.
Shortage triage before a production release
Before a work order is released, the agent compares the bill of material against on-hand, allocated and inbound quantities and returns a plain list of what will stop the job, with the PO that would fix each shortage.
Quote and order status for inside sales
A sales agent answers where an order stands by combining the order header, shipment records and invoice status, so reps stop interrupting the planner for status.
Reorder point review
Weekly, the agent compares reorder points and lead times against the last twelve months of usage and proposes changes as a reviewable list, never updating the item master itself.
Month-end exception sweep
The agent looks for received-not-invoiced items, negative on-hand, orphaned allocations and unposted batches and hands the controller a checklist before close.
Macola integration surface
- Database access: Macola 100 sits on SQL Server, so read-only views and a dedicated low-privilege login are the cleanest read path. Macola 10 deployments built on a Progress database are commonly read through the vendor ODBC driver; confirm what your install uses.
- Vendor web services or SDK: later Macola releases expose business-object style services for creating and updating documents. Availability and names vary by version, so check your release notes before designing writes around them.
- Crystal Reports and exports: most Macola sites already have trusted reports that encode the company's definition of 'late' or 'on hand'. Reusing those query definitions keeps agent answers consistent with what finance already believes.
- Batch and posting model: many Macola transactions go through batches that must be posted. An agent should create or propose into a batch and never post it.
- Customizations: custom fields and user-defined tables are common. Inventory them first, because agents that ignore them quietly give wrong answers.
How it works
- 1
Inventory the data you will actually use
List the 15 to 25 tables or views behind items, BOMs, orders, POs, receipts and inventory locations. Write down the business definition of each status field with a planner, not from the schema.
- 2
Build a read-only access layer
Create a dedicated database login with SELECT only on curated views. Do not let the agent write ad hoc SQL against base tables on day one.
- 3
Define tools, not queries
Expose functions such as get_open_po_lines(days_late), get_bom_availability(item) and get_order_status(order). Each has a typed input, a row cap and a log line.
- 4
Pick the model and where it runs
For on-prem Macola, an open-weight model served with vLLM or Ollama on a local GPU keeps data inside the network. A cloud API is workable if policy allows and you pass only the fields a tool returns.
- 5
Add an approval queue for writes
Proposed changes (a PO date change, a reorder point) land in a review list with the evidence shown. A named person approves, and a separate service account performs the write through a supported path.
- 6
Run in shadow mode for two to four weeks
Let the agent produce recommendations that planners compare against what they actually did. Fix definitions before anyone relies on it.
Example flows
Weekly late-PO expedite run
Trigger: Scheduled Monday 6 AM job.
- Tool pulls open PO lines past promise date.
- Agent joins each line to the demand it supports and drops lines with no near-term need.
- Agent ranks the remainder by customer order impact.
- Agent drafts a supplier email per vendor with the line list.
- Buyer reviews, edits and sends from their own mailbox.
Result: A ranked expedite list and ready-to-send drafts, with nothing written to Macola.
Release-time shortage check
Trigger: Planner asks 'can I release work order for this job?'
- Agent resolves the job and its exploded BOM.
- Tool returns on-hand, allocated and inbound by component.
- Agent flags components short within the lead window.
- Agent suggests the inbound PO to chase or an approved substitute from the item notes.
Result: A go or hold answer with the specific shortages and the evidence rows.
Keeping data on-prem
Most Macola customers are on-prem, and that suits an agent design well. Run the model server, the tool service and a small audit database on a machine in the same network as the Macola database server. The agent never needs inbound internet access: the tool service connects to the database over the LAN with the read-only login, the model is served locally, and the approval UI is an internal web page. If you must use a hosted model, restrict it to tool outputs that exclude pricing and customer identifiers, and keep the full prompts and responses in your own log. Plan GPU sizing from the number of concurrent planners, not from the number of agents.
Security checklist
- Use a dedicated read-only database login limited to curated views, never the application admin account.
- Keep write credentials in a separate service that only executes approved items, so a prompt cannot trigger a write directly.
- Log every tool call with user, input, row count and timestamp for audit.
- Mask cost and margin fields for roles that cannot see them in Macola itself, because the database login will not enforce application roles.
- Treat text from supplier emails or notes as untrusted input to the model to limit prompt injection.
Ways to get it done
Build in-house with a small tool layer
Effort: Roughly 4 to 8 weeks for one agent with an approval queue.
You have a developer who knows SQL and Python and a clear first use case.
Use the vendor's or a partner's packaged AI features where available
Effort: Days to weeks, but check whether data leaves your network.
Your Macola version has a supported add-on that already covers the use case.
Work with a partner such as Netray
Effort: A scoped pilot of a few weeks, then iterate per agent.
You want on-prem models, a tested tool pattern and Macola domain experts involved.
Pitfalls
- !Letting the agent read base tables without the planner's definitions, so 'on hand' disagrees with what the shop trusts.
- !Ignoring custom fields and user-defined tables that carry the real promise dates.
- !Giving the agent a write path early, before shadow mode has proven the logic.
- !Skipping the batch and posting model and creating transactions that sit unposted.
- !Underestimating data quality: stale lead times in the item master produce confident but wrong expedite advice.
Frequently asked questions
Does Macola have a REST API for agents?
It depends on your version. Newer releases expose web services or an SDK for business objects, while older installs are integrated through the database and ODBC. Check your release documentation. Either way, a read-only database path is the safest starting point for an agent.
Can an agent safely write to Macola?
Yes, if writes go through a supported path, are limited to specific actions, and are executed by a service after a human approves. Start with read-only recommendations and add narrow writes later, such as a PO line date change.
Do we need the cloud for this?
No. An open-weight model on a local GPU is enough for the tool-calling and summarizing in these agents. Cloud models are optional and mainly worth considering for harder reasoning if your data policy allows it.
Macola 10 or Macola 100, does it matter?
It matters for the data layer. The agent logic and approval design are the same, but table names, drivers and write options differ. Confirm your database platform and release before scoping.
How is this different from Crystal Reports?
Reports show fixed views. An agent chains several lookups, explains what it found, drafts the follow-up and asks for approval. It can reuse your report definitions so the numbers match.
Want AI agents working on your Macola?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment