AI for Infor M3
AI that builds things M3 can run.
Most AI arriving in Infor M3 answers questions about your data. Loupe Code does something else. You describe an H5 app, an H5 script or an XtendM3 extension, and it builds one from your live M3 metadata, ready to run in your own environment.
Two kinds of AI for M3
It is worth separating them, because they solve different problems and they get bought for different reasons.
The first kind reads. Agents and assistants that summarise an order, look up an item, answer a question about a work order, or draft an email. Useful, and Infor is building plenty of it. Nothing changes in your M3 when you use it.
The second kind builds. Every M3 site has a backlog of small things the standard screens do not do. A list a planner keeps rebuilding in Excel. A warning nobody gets until the order is already wrong. A field the business needs on a screen that does not have it. That backlog is where the money goes, and it is where the waiting happens, because each item needs a developer, a specification and a slot in a sprint.
Loupe Code is the second kind. It writes the app, the script or the extension, and what it writes is ordinary M3 extensibility: an H5 app, an H5 script, an XtendM3 transaction. Your M3 keeps governing the business rules, the data, and who is allowed to do what.
Three things it builds
The same sentence to working thing loop, across the three ways M3 is extended.
H5 apps
H5 scripts
XtendM3 extensions
Why a general AI cannot do this
Ask any capable model for an M3 screen and it will write you something plausible. Plausible is the problem.
It reads your metadata, live
Loupe Code is connected to the environments you have already set up in Loupe. It looks up the real programs, transactions and fields before it writes anything, including the custom fields your business added.
It knows how H5 actually behaves
H5 scripting has its own event loop, its own way of cancelling a command, its own grid. Generic code looks right and breaks paging. Loupe Code is built around the patterns that hold up in a real client.
It asks instead of guessing
When two transactions could both do the job, it stops and asks you which one, then carries on. You approve a plan before a build starts, so nothing is invented quietly.
Hard checks, not good intentions
Everything generated runs through automated checks first. Patterns that are unsafe in M3 are rejected and rebuilt before you ever see the result.
How a build actually goes
An afternoon, with you in the loop at every point where it matters.
You describe it
You approve a plan
It builds against your environment
You try it on your live M3
You refine it by saying what is wrong
You publish it, and it is yours
Compare that with a low code platform or a development project
Run it in your environment.
Bring an environment. We will show you what one sentence can build.