What should an AI-native SuiteCRM actually look like?

[ali.sageteck]

There’s been a lot of discussion recently about adding AI features to CRM, but I’ve been thinking about a slightly different question.

What would SuiteCRM look like if AI became another natural way of interacting with the CRM, rather than just another feature added to it?

A lot of SuiteCRM implementations have years of work behind them. Custom modules, fields, relationships, workflows, roles, permissions and business processes are already built around how each company operates.

Because of that, I don’t think companies should have to restructure their CRM just to make it work with AI.

Maybe AI should adapt to the SuiteCRM that already exists.

For example, could an AI layer understand the structure of each SuiteCRM instance dynamically, including its modules, relationships, custom fields and user permissions?

That could make it possible to ask questions across different parts of the CRM, analyze related information, create reports or visualizations, and potentially perform permitted actions without having to manually navigate through every module.

Of course, this also brings up some important questions around permissions, auditability, customizations, hallucinations and human approval for actions that change CRM data.

I’m curious how other SuiteCRM users and developers see this.

If we were designing an AI-native SuiteCRM today, what would you keep exactly as it is, what would you change, and where do you think AI should fit?

[rasel]

I would suggest having a SuiteMCP module that is managed by the suitecrm team to interact with AI.

[pstevens]

I have a different vision. I don’t think SuiteCRM should be AI native. It should have an AI data layer that’s easily accessible by other AI. That way its AI agnostic. SuiteCRM should be the memory not the intelligence.

I’m working on this now. I have a plan, hopefully it works out.

[BastianHammer]

Hello Ali,

that topic is so huge and impossible to answer here - it can and did fill books .
Additionally, there isn’t one universally accepted definition of what AI native means.

Some approaches that I’ve seen more often in projects and in other systems to “make CRMs more AI”:

• RAG: the search function is too limited and reports can’t handle questions and/or data isn’t properly structured
• Machine Learning: From a certain amount of data, patterns emerge and predictions for next steps / future data constellations are getting more reliable
• Voice interaction: Multiple business processes are implemented using a voice input layer
• Data generation / summarization: Based on states and signals in journeys and processes, data is being generated, summarized, structured

Overall, there are more questions like:

• Would it feature more generic approaches or specific ones?
• Are we focusing on a certain department?
• Is AI working with the customer / communication or the user / data entry?

So far, the biggest wins I’ve seen in user acceptance / adoption / benefits are agentic systems which work with the data and with the team together.

The MCP layers that I’ve tested so far, all disappointed. The first issue is, that not all modules are JSON API enabled currently, and the second issue is, that providing a chat interface or similar with a generic API wrapper to the CRM is non deterministic and expensive.
A mix of processes / rules + well defined targets / benefits / capabilities of AI have so far been much better, faster, cheaper.

I’m with Paul on where AI lives: The intelligence layer doesn’t have to be inside the CRM.
The benefits would be having an intelligent layer, real time decision making, reinforcement learning loops, guardrails, HITL protocols.

[pstevens]

I’ve got the md field logic down and working as an installable plugin. The API connection is my next project.

In general rather than an MCP, I’m thinking of an API that retrieves the knowledge layer. For each module it can return a list of md fields. This has a number of advantages. First, if you already spent the tokens to populate the md fields with “knowledge” about the account or contact, why would spend the tokens every time you ask a question by having to re-read all the meetings and call reports, etc.? With this model you don’t have to. Just query the md fields which has an intellegent summary of knowledge stored.

[ali.sageteck]

Thanks Bastian, I think this gets to an important distinction.

I’m with you that “AI native” probably shouldn’t mean putting AI everywhere inside the CRM. The direction I find more interesting is similar to what you described: SuiteCRM remains the system of record, while an intelligence layer works with its data, users and business processes from outside or alongside it.

I also agree on the MCP point if what sits behind it is essentially a generic wrapper around the JSON API. To me, MCP is only the interoperability boundary. The harder problem is deciding what capabilities should exist behind that boundary and how they are governed.

What I find more interesting is exposing narrower business capabilities with explicit contracts, SuiteCRM ACL context, validation before execution, deterministic workflow steps where possible, HITL for sensitive actions, and agentic reasoning only where it genuinely adds value.

That feels quite different from exposing generic CRUD operations and expecting the model to infer the business process itself.

Since you’ve actually tested several MCP layers, I’m curious about one thing in particular: were they mostly generic API wrappers, or did any of them expose higher-level business capabilities with constrained workflows as well? I’d be really interested in what changed, or still failed, when the capability surface became more structured.

[ali.sageteck]

I like this approach, Paul. I don’t necessarily see the knowledge layer and MCP as alternatives because they seem to solve different parts of the problem.

For an Account or Contact with years of calls, meetings and activity, repeatedly rebuilding the same understanding from raw records every time would be wasteful. What you’re describing feels like a persistent derived knowledge layer sitting close to the system of record, which an intelligence layer can use as a much better starting context.

Then the underlying CRM records can still remain authoritative whenever deeper detail, verification, or an action is required.

One part I’m particularly curious about is freshness and provenance. When a new meeting, call, note, or other relevant record changes the underlying context, what determines when those md fields are regenerated? And are you planning to retain references back to the records that contributed to that knowledge so it can be traced or verified later?

[pstevens]

Yes, I keep the context of where it came from and the probability of accuracy for each insight. Ie: Dave negotiates hard on price. Evidence: email of June 21st, Probability: strong.

There are two actions that impact knowledge:

1. Transactional - updates the knowledge on each email/meeting/call/Opportunity/quote

2. Consolidation, similar to how humans dream. Take the day’s information and merge it with the static record.

(there would probably have to be some starter process that is a combination of 1 & 2 on first run)

[ali.sageteck]

That’s a really nice design, Paul. Evidence plus a probability per insight, and “dreaming” consolidation alongside transactional updates, solves the freshness question I was asking about.

In the spirit of this thread, full disclosure: I’m the engineer behind SuiteBrain AI ( SuiteCRM inside ChatGPT, Claude, Gemini & Grok, Introducing SuiteBrain AI ), which is our attempt at the “SuiteCRM as system of record, intelligence alongside it” direction. Bastian’s point about generic API wrappers shaped a lot of it:

• Business-level tools, not just CRUD: convert a lead, close a case, move an opportunity stage, log a call, schedule a meeting
• It reads each instance’s own modules and fields at runtime, custom ones included
• Every user signs in as themselves, so SuiteCRM’s own ACLs apply to every call
• Write and delete tools are marked as such, so the AI app asks before acting

@BastianHammer, given you’ve tested several MCP layers, I’d value your honest view of where this one still falls short. Anyone curious can point it at a staging instance from suitebrainai.com.

And Paul, a knowledge layer like yours is exactly what a connector like this should read from first. I’d be glad to compare notes.

[pstevens]

With my method, you don’t need any special app or software. You simply use the V8 API connection method as a skill your AGENTS.md has access to, that’s it. If you ask a question about “dave” it just has to API the “dave.md” field with all the memory from Dave. That’s it. Since dave.md is aready currated and minified by cron at night, its not huge. This gives any agent Caude, Codex, etc. full memory context without MCP or any applicaton required. All you need to do is add the skill and the AGENTS.md to tell it what to do.

If you want to ask about the last email, the agent can perfectly well API the email and get that context to answer the question.

[ali.sageteck]

It’s a clever memory layer, Paul, and for a developer running Claude Code or Codex it’s lean and cheap.

SuiteBrain AI (suitebrainai.com) solves a different problem: a whole team working in SuiteCRM through the AI apps they already use. That changes the requirements:

• Anyone, any app. A sales rep in ChatGPT, Claude, Gemini or Grok, on their phone, can’t run a skill or hold API keys. With SuiteBrain they paste one address and sign in.
• Their permissions, not a shared key. Each person signs in as themselves, so SuiteCRM’s own roles decide what the AI sees and changes. A skill on one API credential sees everything that account can.
• Live, and it acts. It answers from live records, not last night’s summary, and it does the work: converts the lead, logs the call, moves the stage, with confirmation, recorded in SuiteCRM under the user’s name.

Your md fields would make a great input to that, so curated knowledge plus live action is where I’d love to see this go.

[pstevens]

Not necessarily. SuiteCRM’s API can authenticate users individually, so each person can connect Claude, ChatGPT, etc. using their own SuiteCRM identity. Their access would then be governed by their existing SuiteCRM roles and security permissions rather than a single shared API account.

[ali.sageteck]

Yes, agreed. SuiteCRM already provides the right foundation for per-user identity, ACLs and permissions.

This is also the direction we’re taking with SuiteBrain AI (https://suitebrainai.com). We’re building the AI capability layer on top of SuiteCRM’s existing security model, so ChatGPT, Claude and other AI clients can work with CRM data and actions while still respecting the user’s permissions, confirmations and audit trail.

We’re particularly interested in testing this with experienced SuiteCRM users. If anyone has a test or staging instance they’d be comfortable connecting, we’d be happy to help set it up so you can explore how agent-based interaction works with your own modules, roles and workflows.

I think testing this against real SuiteCRM implementations is the best way to understand both the potential and the limitations.