As enterprise platforms continue to evolve, an interesting question is emerging: if an ERP already has a mature framework for documents, workflows, permissions, business rules and security, should an AI agent create a separate system around it?
Perhaps the more sustainable approach is for AI to work within the systems businesses already trust.
This is particularly relevant as we extend our work from ERPNext to Microsoft Dynamics 365 Business Central. While these platforms have different architectures and ecosystems, the principle remains the same: the existing ERP should continue to govern its data, processes, permissions and business logic.
The AI layer should complement that foundation rather than compete with it.
This also opens an important possibility for organisations with customised ERP environments. AI integration should be capable of adapting to the existing application and its business context, rather than requiring organisations to redesign the way they operate.
With this approach, AI becomes an additional intelligence layer across established enterprise systems, while the ERP remains the source of truth and the organisation remains in control.
This is an important direction for enterprise AI, and one we are continuing to explore across different platforms and business ecosystems. You can find Noviz AI in our marketplace
You can down
Couple of days back, google cloud launched “Google Cloud Gemini Agent, a single agent for enterprise work” which integrates with business systems (SOR) and in-turn introduces an AI Layer on top of SOR.
So just wondering about the future of Noviz AI in context of the competition by big boys (Claude, Gemini, xAI, openAI) of enterprise AI?
Thank you for comments …
They started long before, actually. Last year, I was part of the model evaluation team at Outlier.ai, where we tested and evaluated models for LLM companies on business applications like QuickBooks, Linear, CRM systems, and so on.
I see two ways this market can evolve. One is a standard agent that works everywhere. Large LLM companies will always focus on common agents, whether it’s a support ticket agent, a mobile phone task agent, or even an enterprise agent.
But the question is, will a standard agent be enough to handle the comprehensive operations of ERPNext and other ERP systems, especially in highly customised ecosystems? These systems have interconnected modules, complex workflows, business rules, and organisation-specific customisations. Can all of this be handled easily just by configuring a standard agent?
That is where I see the opportunity for Noviz AI. We are not looking to be part of just one or two domains. Maybe our ambition is to become part of a much larger ecosystem, working across different enterprise systems and business domains.
The market is huge. The big players will have their portion, and there is room for others to have theirs too. We don’t necessarily have to compete with them at the model level; we can build value at the operational layer.
No doubts about below points:
- LLM layer is almost stabilized and mostly not feasible without big money.
- Agentic Harness layer is the battleground of present and future.
Standard Harness built by a big players has to maintain breath & scale hence depth penetration is probably doubtful.
Specialized Harness like ERPNext-Harness have a gap to fill probably until big players are busy to make their standard harness to capture the breath.
Continuing the discussion..
Keeping all bells and whistles aside generally required by any saas & Agentic AI Scaffold/Harness, What approach has been been taken for the intelligence (not exactly artificial but knowledge artifacts driven in Scaffolds) building of the Noviz? Is the intelligence layer fixed/static or growing/dynamic? what design strategy has actually been adopted for that particular aspect?
In Noviz, the core execution methods are predefined and classified based on their purpose: DocType tool calls, custom queries and execution, email, analytics engine , notifications, and reports.
The knowledge artifacts include company policies and rules for each module, along with manuals that define workflows and business processes for each customised or non-customised ERP implementation.
So, the execution layer is structured, while the business knowledge layer can evolve as company policies, rules, and manual and workflows change.
Also, the architecture is designed to support a certain level of standardisation that works across different businesses, while also allowing specific services and workflows to be customised based on the domain, ERP workspace, and individual business requirements.
