Over the past three months, there has been an undercurrent in enterprise AI circles: while everyone is still comparing model parameters on the surface, in practice they are quietly doing something clumsier—feeding their own business rules, historical records, customer definitions, and approval workflows back into the system bit by bit.
This isn't sexy, but it's becoming increasingly critical.
At TechEd at the end of October, SAP upgraded Knowledge Graph into a platform capability with an Ontology Manager; NetEase Zhiai added the “Wandian” knowledge engine and a smart badge capable of collecting on-site data to “King Crab” in Wuzhen; Glean teamed up with implementation service provider Emergys to connect knowledge scattered across ERP, CRM, and tickets into a graph, specifically to solve the problem of agents getting stuck in pilots. Three routes, one conclusion: When general models are available to everyone, the differentiation of enterprise AI comes from the depth of understanding of one’s own business, knowledge, and processes.
This is not a new slogan. Last year IBM already said, 'customers have 19 definitions and products have 29 definitions,' and semantic inconsistency slows AI progress by 30%. But at that time it was still an insight in a report. By the fourth quarter of 2026, it had become products that three vendors actually launched with real investment. From 'principle' to 'tool,' what lies in between is exactly where most enterprises are stuck now.
1. SAP makes the knowledge graph a platform foundation, rather than a feature
The most memorable takeaway from SAP TechEd 2026 is not that there are a few more agents, but that it engineered the matter of “getting agents to understand the business.”
Joule Studio now supports both no-code and pro-code building approaches, offers a choice of more than 70 AI models, and early trial customers can even run n8n workflows directly in it. But the real key is that Knowledge Graph has launched Ontology Manager: enterprises can define the relationships between SAP and third-party data as a set of “ontologies.” In plain terms, the system finally knows what the relationship actually is within your company between “a sales order” and “a delivery” and “an account receivable,” rather than leaving them as isolated fields.
The significance of this move lies in turning the "business process blueprint" that consulting firms previously sorted out manually into an asset that can be configured and reused. Based on this ontology, the agent's reasoning will not mistakenly treat "Customer A's return" as "Customer B's new order".
SAP also conveniently included an AI Governance Assistant to help customers comply with the EU AI Act. Note this combination: the knowledge graph is responsible for "letting the agent understand the business," while the governance assistant is responsible for "keeping the agent in line." The former determines whether the agent can be used; the latter determines whether the agent dares to be deployed.
II. NetEase Uses a Work Badge to Stuff the "On-Site" Into Context
NetEase Smart Enterprise's most counterintuitive move this time was releasing a piece of hardware—a smart work badge.
The badge itself is nothing unusual; what is unusual is that it directly connects offline information—such as customer visits and on-site service—that has long been buried in paper, WeChat, and memory into the AI system. Then, paired with the knowledge engine “Wandian”: it connects documents, emails, work orders, CRM, and on-site communication, and also combines the logical and temporal relationships of information to provide a basis for the agent’s judgments. Agent Team, meanwhile, has multiple specialized agents divide work, discuss, and verify, to drive complex cross-role tasks.
Duan Yuzheng of NetEase Zhiqi said something very down-to-earth: after model capabilities become widespread, the difference in enterprise AI comes more from understanding the enterprise's own business, knowledge, processes, and ways of doing things; these long-term accumulated contents together constitute the "enterprise context".
Put another way, the veteran in your company who has done sales for ten years, who knows which client is in a good mood on Wednesdays and who needs to sign off on each deal—his brain is the asset you should digitize most. The work badge merely moves this part of the asset from "the veteran's brain" into "the system's context."
III. Glean's Graph plus implementation services, specifically designed to cure 'pilot death'
The partnership between Glean and Emergys points to the same pain point: enterprises buy the core platform, but critical knowledge remains fragmented, so agents are forever stuck in the demo stage and can never make it to production.
Glean's three pillars are the enterprise platform, knowledge context graph, and intelligent architecture, which can connect knowledge scattered across ERP, ESM, and CRM into a network; Emergys is responsible for bringing these capabilities into business-critical systems. It claims to reduce token usage, but there is currently no quantitative benchmark, so this point is questionable.
But the direction is right. Too many enterprise agent projects die from knowledge not being connected properly: ask it about a return policy that only our company has, and it recites generic terms; ask it to find the root cause from tickets, and it can only see ticket titles and not the customer history behind them. If the graph isn't connected, the agent is just a fast-talking intern.
IV. What does this mean for Odoo users
As an Odoo implementation partner, I would rather discuss this from a “can be implemented” perspective.
Odoo's architecture is actually friendly to building a "context layer": REST API, native MCP connectivity, and modular data models mean you don't have to start over to gradually consolidate the relationships among objects such as orders, inventory, customers, and projects into a queryable knowledge foundation. Odoo 20 also opens up the ability for external AI agents to read and write the database via MCP servers—provided your data itself is clean and structured.
But here's a brutal truth: open source and platforms only give you 'containers for holding context'; what to put in and how to put it in is up to you. The semantic layer won't grow automatically. I've seen too many projects where the system went live and a pile of fields were filled in, but 'customer type' has three different ways of being filled in across three departments, and 'delivery status' relies entirely on manual notes. Feeding this kind of data to even the strongest agent just makes it 'make mistakes intelligently'.
So here are three pieces of advice for Odoo users, in order:
First, consolidate the knowledge foundation, then roll out agents. Don’t start by shouting “deploy agents.” First, make master data governance, approval workflow mapping, and unified field definitions solid. Context quality is the ceiling of agent capability, and you set that ceiling.
Second, knowledge sovereignty must be in one's own hands. Whether it is SAP's ontology, NetEase's Wandian, or Glean's graph, the core is all about "the enterprise's own context." When selecting a solution, write into the contract "whether the data is 100% owned, can be exported, and can be migrated." Models can be changed, but your business knowledge cannot be changed, nor should it be locked down.
Third, treat context quality as an ongoing operational activity, not a pre-launch project. The business is changing, and definitions must change with it. It is best to designate a role (not necessarily the CIO; it can be a business owner) to regularly maintain this “enterprise dictionary.”
Models will become cheaper and more alike. What truly sets you apart is whether you are willing to put in the painstaking effort to turn decades of the company's business intuition into context that systems can understand and agents can use. There is no shortcut to this, but once it is built, it becomes a moat that others cannot copy.
