SAP's Company Memory, built on Signavio, is a context-graph layer that continuously learns your policies, processes and communications so agents act on what your business actually knows, not on generic assumptions. It is the right fix for hallucinating agents. It is also not the same thing as making the right decision.
At Sapphire, SAP's chief executive Christian Klein recast the company as a business AI company, and put four pillars under the claim: the Autonomous Suite, Joule Studio 2.0, centralised agent governance, and, the most interesting of the four, Company Memory. Built on SAP's Signavio foundation, Company Memory is a knowledge-management and context-graph layer that learns continuously from policy documents, process models and team communications, including chats and emails. Joule Studio 2.0, the development environment that sits on top, lets partners and customers build agents that are, in SAP's words, natively grounded in live business data, end-to-end processes and the business semantics already in your SAP landscape.
What Company Memory actually is
The plain description is a grounding layer. Instead of an agent reasoning from its generic training plus whatever fits in a single prompt, it draws on a persistent, structured memory of how your company actually operates, encoded as a graph of context rather than a pile of documents. The problem it solves is specific and familiar to anyone who has deployed an agent in a real business: an agent that does not know your policies, your process, or your history will answer confidently anyway, and confidently wrong. Company Memory is SAP's name for the thing that stops the guessing, a shared substrate the agents stand on so they reason from your reality instead of a plausible average.
Why grounding is the real unlock for enterprise agents
It is worth saying clearly, because the industry spent two years talking about model quality: the main reason enterprise AI disappoints is rarely a weak model. It is an ungrounded one, a capable model untethered from the specific facts of the business it is supposed to serve. Grounding, through retrieval, knowledge graphs and now persistent memory, is what turns a clever generalist into a useful colleague. It is the same reason structured retrieval graduated from nice-to-have to default. SAP giving the pattern a memorable name and a first-class place in its stack is a sign the enterprise market has internalised the lesson: context beats raw cleverness for the work that actually runs a company.
It is the same move the whole industry is making
Company Memory does not stand alone. It slots next to the other layers vendors have been racing to build: governance and certification for agents, a register of which agents exist, and a cockpit to supervise them. Grounding is simply the fourth pillar of the same structure, the one that makes sure the agents are reasoning from the truth. Put together, the message from every major vendor is consistent: capability is assumed now, and the hard, valuable work is the scaffolding around it, memory so agents know, governance so they are allowed, a register so they are accounted for, a cockpit so they can be watched.
The distinction: knowing is not deciding
Here is the line to hold, because it is easy to blur a memory with a mind. Company Memory tells an agent what is true about your business, your policy, your process, your history. It does not tell the agent what is best. Grounding stops the agent from being wrong about the facts; it does nothing, on its own, to make the agent's decision optimal. An agent perfectly grounded in your reorder policy will faithfully and accurately execute a mediocre reorder policy. An agent that has read every pricing document you own still does not know the margin-optimal price unless something computes it. Memory is necessary, and it is emphatically not sufficient. Knowing the situation and choosing the best move are two different capabilities, and only the first is what a memory layer provides.
Memory feeds the decision; it is not the decision
The useful way to picture it is a pipeline. The memory is the input: it supplies the demand history, the cost structure, the constraints, the policies, everything true about your operation. The optimisation is the output: it takes that grounded picture and computes the action that is actually best, the price that maximises margin without losing the customer, the safety stock that protects service without trapping cash, the pick path that is genuinely shortest through your building. Grounding makes the inputs trustworthy. It does not produce the output. The better the memory, the more valuable a real decision layer becomes, because now it is optimising over an accurate picture instead of a guess.
The layer above the memory, for Dynamics teams
The pattern is identical whichever platform you run. Ground the agent in your data, on SAP that is Company Memory, on Microsoft Dynamics it is your records in Dataverse and the context around them, and then put the system of intelligence on top to actually decide. On Dynamics that runs as a companion app in tandem on Dataverse and Power Platform, shipped through AppSource, drawing on the grounded data the platform already holds, and it is where Cognilium works. SAP just gave its AI a memory, which every serious deployment will need. The intelligence that decides what to do with that memory is a separate layer, and the one that changes the number at the bottom of the page, the same thread we followed across Business Central's agents.
Share this article
Weekly AI engineering brief
One email a week. New model releases, agent patterns, and lessons from production systems we ship.
No spam, no client data sales. Unsubscribe any time.

Ali Ahmed
AI Business Analyst & Product Owner, Cognilium AI
Ali Ahmed
AI Business Analyst & Product Owner, Cognilium AI
Ali Ahmed is an AI Business Analyst and Product Owner at Cognilium AI, where he owns the product…
