Insights 2026 - After Action Report (The serious thread)

Kinetic ERP
41

So having written an MCP server now and spending a lot of time working through this exact problem space, I actually think Epicor is moving in the right direction here.

Giving an agent or an LLM completely unrestricted access to the entire Epicor API surface sounds great in theory, but in practice it turns into the model shotgun blasting random endpoints and BO methods based on probabilistic guesses. That gets dangerous fast, especially in ERP systems where context matters and where two endpoints that look similar can have completely different accounting or transactional implications.

The approach Epicor is taking now, and the same one we took with our own MCP implementation, is to expose curated tools/endpoints instead. Things like controlled BAQs, Functions, and selected BO operations that are intentionally designed for AI consumption. That lets you tightly control:

  • what data the model can see

  • how the data is shaped

  • what actions are allowed

  • and what business context accompanies the request

I know it feels counterintuitive because as developers we look at it and think, “I can already build BAQs myself, why do I need Prism for that?” But the value is less about the BAQ itself and more about creating reliable semantic tooling for the AI layer so that it can answers questions in an accurate and methodic way without infering too much or hallucinating.

One thing that’s important to understand is that these models operate within a limited context window and they do not natively understand Epicor’s full end-to-end accounting, manufacturing, fulfillment, and transactional ecosystem. Throwing 2,000+ loosely documented endpoints at an LLM and expecting it to infer the correct workflow consistently is honestly a recipe for hallucinations and bad data interpretation. This is what Epicor tried to do at first and it was abysmal in performance it gave it access to every BAQ in the system and the system just randomly picked one that looked ‘related’ to the topic at hand without understanding IF the content suited the question.

What works far better is having specialized tools and agents that each understand one or two things extremely well. A tightly scoped endpoint with good business context produces dramatically more reliable answers than unrestricted API access ever will.

The systems that work best are the ones built on curated, intentional data contracts rather than unrestricted raw API access.

Glad you enjoyed the session on the EpiUsers panel, it was super fun, and some of the tooling being built is really fun.

42

There was a lot of talk at Insights about Lux, Agent Foundry, and “agents.” I understand why that language is being used, but I also think some of it is still more marketing than reality at this stage.

What this appears to be in practice is closer to building LangChain- or n8n-style workflows natively inside Epicor. That is not without merit. In fact, I think that could eventually be very useful. But I do think calling everything an “agent” can be misleading if what we are really talking about is a curated workflow builder with controlled tools, BAQs, Functions, and selected operations.

That said, I would absolutely accept an “agentic” workflow builder inside Epicor. I think that has real potential once it matures.

Your points about governance, endpoints, BO methods, and unrestricted API access are all valid. The hallucination problem with AI is very real, and in an ERP system the consequences of a model guessing wrong can be serious. Inventory, costing, fulfillment, accounting, and manufacturing transactions are not areas where I would want an LLM wandering freely through endpoints and hoping it picked the right method.

I think the path forward is probably curated tooling, like you said. Purpose-built BAQs, Functions, and selected BO operations with strong business context wrapped around them. If someone is building their own harness outside of Epicor, that could mean using context files, documented business rules, and executable tools that the model is allowed to call in a controlled way.

For me personally, I’m not ready to let an AI harness execute transactional tasks inside my ERP yet. Not without a lot of guardrails, review steps, and auditability.

But using a headless/API-based harness to retrieve accurate Epicor data, summarize it, and display it in a useful conversational format? That I’m much more comfortable with today.

So I think I’m aligned with the curated-tool approach. My hesitation is more around the terminology and the maturity of the product. If it is a controlled workflow/tooling layer, call it that. If it eventually becomes a true agentic layer with reasoning, safe execution, context awareness, auditability, and governed action, then I think that could become very valuable.

45

Search on the ELC website for “System Flow - Hands On”. This runs through the whole Quote-to-Cash process using the Demo (or Education) database. It’s not perfect, but it at least shows you the major pieces and how they relate.

The actual implementation process is really all about… um… process. It’s HOW you do things that determine how well Kinetic (or any ERP system) accepts the data you give it and provides information in return. Don’t fight the system. If the system is designed to do things in a certain way (for example Engineer-to-Order vs Make-to-Order vs Make-to-Stock) there is a reason for that. Customize when necessary. DON’T customize when NOT necessary.

And don’t be shy… we’ll all be here!

46

One of my biggest takeaways is that anything around Prism feels like it’s still a year or two away from delivering real value. On top of that, they’re pulling the EDI AI features out and selling them as a separate product—which doesn’t make much sense. Why should you have to move to a different EDI solution just to get an AI map builder?

Starting in 2027, they’re moving to one major release per year. GOLD

Also, REST V1 deprecation is a concern. There’s no clear path forward, and right now I don’t see how we safely hand out API keys when someone could just switch the URL back to V1 and have open access.

47

There’s already competitors doing this, Cleo, etc. They have AI map builders as part of their product.

48

Is there any way you could elaborate on what you’re talking about when you say, “could just switch the URL back to V1 and have open access”? If the user account doesn’t have “allow api v1” to it, I thought it couldn’t use it?

49

Did you hear when this is actually happening? This will be a problem for our excel users

50

I thought someone on the forum showed us all how to use v2 or oauth with it? I thought it was you :joy:

51

I was able to get oauth to work. I have seen it somewhere, but V2 was much more involved (passing an api-key and a bearer token). Not sure if it would work with oauth.

52

Okay, good, I’m not losing my mind :joy:

53

Until they take V1 away from us at least. We have several Excel sheets using V1 to pull data… :grimacing:

54

Nothing yet, Epicor couldn’t really give us answers on it either.

55

You sir win the week!!

Was not aware that this existed.

Thank you thank you!!

56

Here’s what I don’t know… maybe the greats in here do… if you OAuth and get a token, can you then call any rest API v2 that you want?

57

If i understand your question correctly, the answer is “no”.. you would create an Access Scope within kineitc that then says what services and even down tot he methods that that access scope is allowed… this limits what can be done.

image
image2438×763 42.7 KB

58

It’s strange that v2 requires an api key AND user authentication (basic/azure/Idp/Windows).
Other software I’ve worked with use an api key that is scoped to a user or application. I don’t need to provide the user credentials again.

You can assign an access scope to a user to prevent what they can do. We use this for integration accounts.

Then you have menu security which you can apply to BAQs/menus and assigned to users/groups.

There’s also service security that apply to BOs and assigned to users/groups.

And don’t forget field security!

The whole security model is very convoluted.

59

The big gotcha here is… If you leave any of the Access Scope Tabs Empty, that means all access.

If you have an Access Scope and you give it access to let’s say 1 BAQ… They still have full access to Services and All Functions… You must add something, in each category.

If you give it access to 1 EFX, and you dont select any BAQs they have access to ALL BAQs. You must basically have something even if its some dummy BAQ, or Service or EFX for it to “disallow all”.

Also the UserService BO is always allowed atleast the ODATA Update.. and you can update your profile and remove the Access Scope from your user, it will let you – then you can just go back to v1 (no API Key required) and… access it all cough CVE.. waiting for @Mark_Wonsil to report it.

  const url = `https://url..../api/v2/Ice.BO.UserFileSvc/UserFiles`;

  body: JSON.stringify({
    "UserID": "my-service-account",
    "AccessScopeID": "",
    "AllowAPIv1": true,
    "RestrictIP": false,
    "RowMod": ""
  })
60

Thanks Haso, I haven’t had time to really play around with it yet, but I knew it wasn’t great.

Also @timshuwy, in the extended ed, I was told that assigning an access scope turned the user into an “integration user” where the password is never set to expire, so assigning an access scope to normal users seems like the right thing to do, but then I see features like “never expire password” and think we are trying to use the field to do too many things.

61

Yep. Absolutely deplorable design.