Webinar | Building Enterprise Memory for AI Agents

Opening and Introductions (00:06-05:06)

Pete Youngs (00:06):
Hello everyone. Welcome to this Ortecha webinar, which is all about building enterprise memory for AI agents. Thank you for giving up your time, and thank you to the incredible guests joining me today. We'll come to introductions shortly. Just a bit of background on Ortecha: we're a human-first consulting firm providing data, AI and technology solutions for how people actually work. This is the third in a series of webinars focused on data foundations, data and AI governance, and now enterprise memory.

This one looks at a problem many organizations discover when AI moves beyond controlled demos and pilots into real business processes and workflows: an agent can retrieve information and produce a fluent answer, yet still misunderstand the business context behind it and behind the organization. We believe agents don't fail because they can't read enterprise content. They fail because they don't really understand the business meaning, the relationships, the context, the lineage, the provenance - Jessica, I know we'll get into that today - the ownership rules and the exceptions behind all that information.

True enterprise memory gives agents connected, governed business context, not just access to a corpus of documents that describes what an organization does, such as a policy. We've recently published an article on this. I think Louise will drop that into the chat. Louise is also online and will share information as we go through. The core question for today is: what does AI need to know about an organization, and not just read, in order to be accurate and reason reliably?

I'm really thrilled to be joined by three amazing guests, who come at this from complementary and slightly different angles. Let's start with introductions. Jessica, over to you.

Jessica Talisman (02:57):
Hi, my name is Jessica Talisman and I'm the founder of Ontology Pipeline, which is a framework for building semantic infrastructures and knowledge graphs. I've been in the field for about 30 years - not to date myself - and I've worked in large enterprises as well as cultural heritage institutions. I live in California. Thanks, Pete.

Pete Youngs (03:20):
Thank you for joining, because we do realize it's slightly early there. And over to you, Peter.

Peter Crocker (03:31):
Sure. I'm Peter Crocker, chief executive and one of the co-founders of Oxford Semantic Technologies. We're a spin-out of the University of Oxford here in the UK, and the company behind a product called RDFox. We were acquired by Samsung back in 2024, after many years of building and deploying knowledge-based AI solutions at scale for many clients. We work with clients across a wide range of industries, helping them connect complex data, apply business rules and automate their reasoning - really capturing the knowledge that exists within an organization and bringing faster, more consistent results and decision-making to the heart of what an organization does.

Hopefully we'll be talking about plenty of that today. Thanks, Pete.

Pete Youngs (04:30):
Thank you. And over to my lovely colleague Charles.

Charles Ivie (04:34):
Hi, I'm Charles Ivie, Head of Data and AI Engineering at Ortecha. I've been working in neurosymbolic AI solutions, which is basically this stack, for about 15 or 20 years. I've been at places like the BBC and AWS, working with the Amazon Neptune team. Now we design and execute solutions for a wide range of customers in this space.

Defining Enterprise Memory (05:06-09:13)

Pete Youngs (05:06):
Great. Thank you very much. That's amazing experience to bring to bear in this conversation. To ground the discussion, let's start briefly with your own perspectives: what do we mean by enterprise memory, and perhaps what is it not? Jessica first, then we'll go to Peter and Charles.

Jessica Talisman (05:26):
One of the core tenets of knowledge graphs, knowledge in general and knowledge management is the idea of repeatable processes, reusable artifacts, persistence and workflows. Memory means you have a sustained representation of systems that can capture the who, what, when, where and why of things like workflows and artifacts. There's also provenance attached to objects and resources within your environment and workflows. That's instrumental to creating a persistent memory or history of objects and resources within an environment. Memory is also about what falls out of patterns when new patterns are introduced. That's one of the critical core elements of enterprise memory.

Pete Youngs (06:32):
Okay. Thank you. Peter.

Peter Crocker (06:35):
I'd phrase enterprise memory as the ability for an organization to make what it knows explicit in a digital context: explicit, connected and usable by both people and AI. What it's not is just storing more documents or more memories in textual form. That would simply hand the problem over to the LLM, which can't cope with the amount of context you would need to provide at enterprise scale. The real value comes from capturing the relationships, the rules, the content, the context and the provenance around the data, so you can get your AI and your people to really understand it. It's not just the data or information itself, but what it means. It brings meaning to that data.

Another element is that, just like our memories, enterprise memory is dynamic. It isn't something you train once. This isn't about training an LLM on a snapshot in time and forgetting about it. It updates incrementally with new data and as you and your organization learn. For our clients, it's what turns AI from something that can retrieve plausible answers into something that can address the pressing questions of the business in a consistent, explainable and, most importantly, trustworthy manner.

Pete Youngs (08:29):
Okay, thank you. And over to you, Charles.

Charles Ivie (08:33):
For me, enterprise memory is an attempt to record in a repeatable, replayable way the things that the enterprise deems most important to remember and to be able to replay and reuse in a way that is communicable to both people and machines alike - or any sort of agent if you like. And yeah, I think that'll do. I think the other two have said it very well.

Why Document Access Falls Short (09:13-17:52)

Pete Youngs (09:13):
Yeah, at least it's fairly consistent here. We'll see if we drift as we go through the conversation. So I think we touched on it quite a bit there like access to documents, the ability to read, humans can read, we know agents can read. So coming to you first on this one, Jessica. We know an agent could retrieve a paragraph, summarize a policy, produce a convincing answer, even a plausible answer. Why does that fall short in terms of understanding the business?

Jessica Talisman (09:43):
That's an interesting one because LLMs, especially the commercial frontier models most people access, are trained to give an answer no matter what. Very rarely do they say, 'I don't know.' If an answer doesn't exist, the plausibility can be questionable. It's difficult to assess or assume reliability based on that. Trustworthiness comes from having auditable resources - and when I say resources, I mean ontologies, knowledge graphs and semantic assets within your organization. The idea of memory is absolutely to drive reliability, and that goes back to reusable, repeatable patterns. It's also about auditability.

When you design your system, you can have competency questions and turn those into SPARQL queries to make sure your systems still capture and cover everything you intend them to. You need to be able to detect when the system is not being truthful, and memory helps with that when it's architected well. You need an architecture and a strategy for what the system is intended to do. That end-to-end strategy often gets lost in implementations. You need to bookend the strategy so you can make sure the system is working as intended.

Pete Youngs (11:34):
Okay. Yeah. I think we're all using the frontier models aren't we? And they're very affirming, aren't they? They will always give you an answer. So I think that ability to say that it doesn't know is a really important part of this isn't it? For anyone listening, there's a key takeaway: An answer isn't always a good thing.

Jessica Talisman (11:54):
No. And they're people pleasers. I mean, it is a product and product is meant to please people. And so, of course, it will always generate an answer unless you know, unless there's triggers and ways to capture the 'I don't knows' within a system. And those become hallmarks for further development of a system, right? You realize where you don't have that, right? So you want that feedback loop. It's instrumental to building.

Pete Youngs (12:23):
Coming to you, Peter, from a semantic technology perspective: What has to be made explicit before an AI system can actually reason with that business meaning? We've touched on part as we've kicked off today, but a few key points about what it really needs.

Peter Crocker (12:40):
We found this before the advent of the current wave of AI systems and large language models: the process of applying semantic technologies can be very useful for a business. What you have to do as a business - and this is amplified by the current wave of making it applicable to AI systems - is make the meaning of the business explicit. That can involve quite a lot of internal conversations, sometimes disagreements and arguments, but collectively you're getting together and formally representing what you understand as the meaning for your business.

That can be how you define entities, how they relate to each other, the rules that govern the relationships between them, the rules that derive new insights from them and the like. That applies to any semantic technology application and is just as important for getting value out of these AI systems. Another distinction comes back to Jessica's point about these models being people pleasers. An LLM will often reason convincingly, but we have to remember that these are probabilistic models. With semantic technology, you can achieve rule-based or logic-based reasoning in a deterministic and explainable way that gives you trust in the answers it provides.

Pete Youngs (14:41):
Thank you. So then coming to you Charles I think we've touched on it there probably in terms of deterministic and probabilistic models and the access to information and understanding that information. How does that gap come through? Have you seen examples where people are caught out by that? Obviously not just us using the frontier models like personally or even shadow AI dare I say within organizations but in a real sort of business context.

Charles Ivie (15:09):
Before that, I was thinking about enterprise memory and an interesting human trait: memory changes over time by accident, and people don't know that it has changed. Ask somebody what they did at an important event the day after it happened, and their answer will be materially different a year later. One thing that won't change is that person's conviction that they are correct. They'll be just as convinced a year later that what they're saying is 100% correct, even though it's almost certainly different. In some ways, you could argue that this is a sort of time-based hallucination. Based on a set of non-deterministic factors, the reasoning you come to is different in the end.

A modern, statistically based language model may answer the same question differently five times in a row. That's not too dissimilar in its nature. If you put enterprise memory in place based on a structure - an ontological construct that frames and shapes the understanding of your meaning and gives it meta-meaning - then when you ask the same question a year later, you're going to get the same result. Even if you're using a language model to interpret the data, it will use the same frames of reference, schemas and ontological references as it did before.

Pete Youngs (17:24):
So that repeatability, I guess, drives trustworthiness and consistency.

Charles Ivie (17:29):
Exactly. Consistency drives reliability, authenticity and trust. It gives people trust in what they're getting. If you ask the same question two minutes or a year later, you expect to get the same response.

Knowledge Sprawl, MCP and Context (17:52-27:11)

Pete Youngs (17:52):
Indeed. Thank you. Thinking about enterprise knowledge sprawl, I guess we touched on how information changes over time. Jessica, we also touched on this the other day. Enterprises already have policies, process documents, catalogues, data catalogues, dashboards, Power BI, Tableau, wikis, CRM and, dare I say, SharePoint - with an immense amount and many years of information. People seem to be saying - and this is clearly an education point we need to get across today - that you can 'just point your internal LLM' at your corpus of information, including SharePoint. So, Jessica, why is that not automatically enterprise memory? Without any ontology, people think they can just point it at the documents.

Surely we can just plug it into SharePoint using the connector and we're done.

Jessica Talisman (18:58):
A lot of it has to do with the lack of structure. Interestingly, few people know that SharePoint has a crosswalk to SKOS/RDF published on the Microsoft Learn site. It's almost hiding in plain sight, so that's a start. But in terms of structuring and adding context, LLMs need descriptive access. They first need to understand the description, the metadata and the aboutness of objects and resources: the basic metadata that says something was published or modified, and that there is an owner and a publisher. That gives you persistence over time. Then there's what's contained within the documents.

This may be a salacious comment, but the word 'context' has been abused to the point where context can be anything from a sentence, to a paragraph, a table or a document. We pat ourselves on the back for having context, but the quality and type of context are instrumental. You have the description of the objects themselves and the contents within those objects. Surfacing that descriptive access beyond the object itself is really important. There are other tools for those levels of context, such as corpus analysis, tagging systems and structuring the content within the objects. There's a little more complexity in the approach and how we represent these things.

The most important thing for memory is persistence over time in describing those objects and resources. From there, it's a different workflow and body of work to break apart the documents and extract the goodness - the context - within them.

Pete Youngs (21:16):
Okay, thank you. Charles, coming to you. What patterns or types of knowledge sprawl do you repeatedly see in organizations? Do you see patterns and do you see ones that create the greatest risk? I think Jessica's probably touched on points within that, but any specific experiences around risks of how and frankly how the technology we're talking about today, I guess, can be used to mitigate those risks.

Charles Ivie (21:41):
Many people on this webinar can probably sympathize with seeing this in their own organizations. As with any exciting new technology that consumes the zeitgeist, everybody is trying to do something with AI - as teams, individuals and organizations. Some are great ideas, some are terrible, and some are somewhere in between. What this creates is a mesh - or perhaps a data mush - of things connected through technologies such as MCP, without an enterprise-understood structure behind them.

If we use standards and propagate those standards through organizations as much as possible, these things are far more likely to interoperate for each other's benefit rather than create new data silos that must be maintained on their own. A team might create a new MCP server that does something great, but if that's the only interface point and you don't have metadata access to where its structure and reliability come from, can you trust it? I'd say you can probably trust it even less than a well-defined API providing access to the same data. The dangers are similar to those we've always had when people get excited and adopt new technologies too quickly.

There may be a boom and bust before people realize they need good structure and good ontological thinking to understand the meaning of the things that come together.

Pete Youngs (24:02):
That's got to be a key takeaway: ontological thinking. When I'm thinking about how I'm connecting to all my data, am I really thinking about it in that way? And Charles, are we saying that MCPs can introduce risk? Because the response seems to be, 'Let's just get an MCP connected to our data.' We can just plug it into our frontier model. We can give it access to everything. It feels like it solves something. But it can actually introduce risk because it's not necessarily the meaning or understanding of the data and probabilistic models therefore will introduce risk.

Charles Ivie (24:38):
Yes. And then probably an even bigger bit of risk is when some organization comes to you and says yes we have an MCP server to access how risky our MCP servers are or something like that. You know what I mean.

Pete Youngs (24:50):
Right. You get the point. It's a barrier to understanding what lies beyond, isn't it?

Jessica Talisman (25:02):
There's a huge risk. Just jumping in on Charles's point: we tend to throw in anything and everything, which takes us back to the context problem. And it becomes very noisy like any other sort of data ecosystem when you just have a dump of information or knowledge. And so you know I've had to tell organizations, 'No, you don't include your email server as training data,' just because you know out of that desperation like we still have similar sort of you know considerations for privacy and core software development you know there's huge risk in just dumping everything into an LLM and calling it context.

Pete Youngs (25:51):
There is, isn't there? From a conventional platform or warehousing perspective, 'all data' is never a good thing, is it? And that stands true today. Yeah. Yeah.

Peter Crocker (26:02):
Just like a person staring at a massive entity diagram - I've been in organizations where one spans the walls of a building - they will navigate down rabbit holes before finding what they're actually looking for. An LLM is going to do exactly the same thing. If that diagram doesn't have the layer of knowledge that explains what those entities exist for, their purpose and their meaning, the LLM is going to get just as lost as the expert human staring at that wall.

Where to Start: Use Cases and Semantic Foundations (26:42-30:44)

Pete Youngs (26:42):
Yeah, it's interesting you say that Peter and it's you know you get to that point and you see that massive diagram, you're designing a new system and after about a week of trying to work out how you can use whatever you've got there on your whole infrastructure to use for this new project, you think, well, I suppose we're just going to have to do it all from scratch because nothing fits anyway. So then you add to it, right? And systems running like that on an LLM are going to get very expensive very quickly. This is a great segue.

So Peter, from a semantic technologies perspective, and I think that people must be thinking this without asking the organization to replace every repository or every model from scratch. How do we tackle this?

Peter Crocker (27:26):
Where do you start? As with many successful projects, you start with a pain point or an opportunity. What are the really useful questions to answer? Those have to be your guiding lights. Then approach it with the pragmatism to ask: have I got the data to support answering those questions? You look at how you meet in the middle. You meet in the middle by focusing on those useful questions, structuring your understanding of the business and its meaning, and then mapping from the data to that. As you do so, build it in a way that is reusable by grounding it in a structure that has meaning and is recognizable to the business. That way, you can incrementally add and expand to the next set of useful questions.

Jessica Talisman (28:42):
Yeah. And I think that touches on Charles's point about ontological thinking. If the industry moves towards intentionally designing systems by asking, 'What questions do I need the system to answer?', that can proliferate into other design heuristics throughout your organization. It's really important from both a design and systems-thinking perspective. You may end up with more than one knowledge graph and more than one ontology that serves different purposes within a system, so organize and architect a system that's built for purpose. Again, you're looking at token spend and efficiency, and the internal architecture is very nuanced.

Peter Crocker (29:43):
And just to add you know what you don't do and many early semantic technologies failed in this aspect. What you don't do is try and model everything. So don't approach the business and say right we're going to bring in a you know multi-million pound project bring all the experts into a room and bash out how the whole business can be modeled. That's absolutely you know the worst place to start. You're going to you're going to exhaust any enthusiasm for this project and spend a lot of money and end up not answering the critical questions for a very long time. So start small.

Pete Youngs (30:20):
Yeah. So use-case-focused design clearly is really important. So we need to design solutions and a knowledge graph and ontology are a great way to possibly implement the right solution but still think about the design and the systems thinking and I think with AI we can get a bit distracted and we forget some of those core disciplines that we should never forget I believe.

RAG, Vector Search and Structured Knowledge (30:44-38:02)

Pete Youngs (30:44):
So we need to cover some other points that I know people will be thinking about. So a common response to the context problem seems to be RAG - retrieval-augmented generation. It gets mentioned a lot. Connect a model to documents, retrieve relevant passages and generate a grounded answer. It's valuable but again it's not the same as enterprise memory and then people will talk about vector search. So Peter perhaps help us understand some of these terms and how we move into the world of true enterprise memory in the context of RAG and vector search and so on.

Peter Crocker (31:18):
Vector search is really about looking for similarity, and this can be useful when you're interfacing with humans, where many words or phrases can have similar meanings. Vector search is fantastic at solving that problem. But it provides the entry point into the structured knowledge we would advocate building with semantic technology. Similarity is not necessarily the same as the meaning you give something within your organization. It doesn't establish the things semantic technologies can capture around authority, whether something is current, ownership, relationships, rules and exceptions. RAG - particularly document-based RAG - can be useful and find relevant passages in things that are naturally documents.

But a knowledge graph can provide meaning and the interconnectivity of those elements for a full solution. Graph products such as RDFox can link this information, and pretty much all graph-based products now embed or connect to vector indexes to take advantage of both.

Pete Youngs (33:11):
Okay. And Jessica, I'm mindful we walk into a meeting with business leaders, directors of an organization. Should we be saying vector index RAG?

Jessica Talisman (33:24):
I'm apprehensive around that. My approach to scoping and scaling a project is you know obviously competency questions but I also conduct an audit like you actually have to audit your systems and figure out where your assets are in what format and what shape. So I mean there's like a step before the step often I reach for. So when I hear 'vector' first of all I don't know if you want a machine classifying or organizing things or you know grouping things according to what the machine thinks if you already have some conceptualization of that. So I tend to recommend that we use our own sort of tree structures in terms of being able to organize or group things accordingly.

But oftentimes that's overkill and you may just need corpus analysis and you may just need clustering. You know, there may be techniques that seem lower fidelity but actually do more to work with your internal conceptualization of these things because often, you know, we have to remember that a lot of these frontier models are trained on the open internet and so their groundings are according to the Wikidata and the Wikipedia and the Getty and the, you know, the sorts of open sources. And so, you know, part of the challenge is customizing, fine-tuning and orienting an LLM around your internal structures.

And that's where I see vectors, vectorization, vector indexes, vector classification to be somewhat dangerous as a starting point.

Pete Youngs (35:00):
Okay. Thank you, Charles. Coming to you and still on the initial topic of RAG: are you seeing and considering what Jessica and Peter have talked about there? When you're working with client teams, are people asking RAG to do too much and how do we potentially take them on that journey to say it's a stepping stone which, as we've described, can lead to doing this better with true business meaning, enterprise memory and real knowledge foundations you might say?

Charles Ivie (35:31):
I think it links back quite neatly to some of the other topics we've discussed: having structure behind the questions and the data you want to serve to consumers of your RAG product. Many RAG products could be very valuable. For example, you could have a chatbot on your website that answers questions about your terms and conditions, with a disclaimer that it might not be 100% correct, before a customer goes through to customer services. A traditional RAG service like that, where perfect accuracy is less critical and important actions are not taken directly from its answers, could be very valuable. I'm simplifying it, and I'm sure there are many other scenarios where simple RAG systems are valuable.

But where there has been no abstract thought or structure over how those documents should be classified, organized or linked to existing data and models, people like Jessica, Peter and me try to take it to another level. We use ontological models and an understanding of meaning that sits outside the documents, and align vectors and other things found within them to elements represented more structurally in the organization. We try to combine these technologies to get the best of both worlds. Vectors are very useful, as Peter said, for identifying similarity in language, but they cannot necessarily tell you that you're talking about the same John Smith as in another application.

Having that abstracted enterprise-memory ontology outside the documents can provide a first grounding for organizing vector-based RAG systems into something more structured for your purposes.

Ontologies, Knowledge Graphs and Standards (38:02-47:07)

Pete Youngs (38:02):
Okay, thank you. I feel like we need to level up a little with some of the terminology: semantic layers, ontologies, controlled vocabularies and knowledge graphs. Let's do a bit of a round robin. Charles, coming back to you, let's start with ontology and help people understand it. I'm conscious that people here will have different levels of experience and expertise. What is an ontology, and what is its business value? Then we'll come to you, Jessica, for knowledge graphs, and Peter for controlled vocabularies.

Charles Ivie (38:44):
The practice of building an ontology is often described as defining the nature of being, which sounds incredibly abstract and useless to this conversation. But when you think about it, it makes a lot of sense. It's essentially drawing a mind map of how you understand entities that interact with each other and the properties they have. You might say people live in places. I'm not saying who lives where; I'm saying we understand that people live in places. From an organization's perspective, I might care that customers buy widgets. I'm not saying which customers buy which widgets, but I am saying that, as a business, we care about selling widgets to customers.

Then they have properties: how much were they sold for, when were they sold, and so on. Designing an ontology means drawing out and defining that as a structure for your business to work within. You create an abstracted meta-model that can inform everything else. If you want to create AI agents, they can refer to it and say, 'We care about selling widgets to customers. Don't forget that's the structure we care about.' Ontology design is about defining the shape of the data outside any actual data, application or use, so that you have that meta-understanding.

Pete Youngs (40:31):
Okay, so it's the model not the data is the key point and we have to start with that otherwise we can't explain the data. Surely?

Charles Ivie (40:38):
For those from a relational database background, the idea of a schema will be very familiar. An ontology is essentially a schema, but it isn't bound to restrictions such as tables, join keys and foreign keys, which are imposed by the application of the database. An ontology sits outside that. We don't need a database. We don't need a tool. We don't actually need anything to design an ontology apart from the people who understand it: the business.

Pete Youngs (41:06):
Okay, cool. Okay, Jessica, building on that knowledge graph. I feel like that's the next section that sits with the ontology and business value.

Jessica Talisman (41:16):
Yes, I mean I think ontology is starting to become somewhat controversial in the same way. I completely agree with Charles there. On knowledge graphs, and I may have a unique perspective here but recently I would say within the past few years the term 'knowledge graph' has been used to encompass much more than ontologies or ontology-based systems; we have property graphs as well that are being described as knowledge graphs. My definition is that a knowledge graph is an architecture. So we were talking about vector databases - or, sorry, vector indexes and different you know controlled vocabularies which Peter will talk about in a second. And a knowledge graph is an architecture in that it's very nuanced.

It can differ depending on a person's unique architecture. It can include a vector index. I could include a knowledge base. It might include a taxonomy. Maybe a couple of ontologies. You're building a knowledge graph for a purpose. So, as people have started to learn more about ontologies and the ontology version of knowledge graphs, it's really interesting because I think people are starting to realize and what I mean by people is like generally people that are starting to build these systems within organizations that yes indeed there are different types of knowledge graphs. There are different architectures. It's very nuanced. So, you'll hear people say, "Oh, well, this is a context graph.

Is that a type of knowledge graph? Sure - it's built for a certain purpose. I'm not sure of the exact distinction; I think the market is still trying to figure it out. You might have a document knowledge graph, right? You might have, and I'm just throwing this out there that people will customize, tailor, architect a knowledge graph for a specific purpose. We're here today talking about memory. So you may have, you know, designed a knowledge graph in a system that is specifically built for purpose in order to be a memory system for LLMs. That architecture is going to be nuanced and unique to your organization.

Pete Youngs (43:24):
Okay. Interesting. Peter, Charles, do you agree? Jessica started that with she may see it differently. Anything contentious there?

Charles Ivie (43:30):
One of the things we've touched on lightly is that we're all proponents of a particular way of manifesting knowledge graphs and ontologies, because we believe in following well-understood and documented standards. For people who are new to this conversation, we've been following W3C standards to define ontologies and knowledge graphs for many years. Because those standards have been defined for many years, they already exist in more than 50% of web pages. Whether other tools call what they're doing semantic layers, ontologies or knowledge graphs, if they don't follow these standards, they don't gain the advantages of the tools that do.

If you're the only person in your town who speaks English while everyone else speaks Mandarin, you won't be heard as well as the people who share the same language. We're all big fans of following the W3C standards of the semantic web: OWL for ontologies, SKOS for taxonomies and RDF for knowledge graphs. Following those standards gives us some distinct advantages.

Peter Crocker (45:07):
I'd simply add: what do those standards do? They force vendors like me to conform to an agreed set of standards. As a user of those products, you can walk into a project confident that the vendor's product has implemented the things you need for a knowledge graph. You can achieve a knowledge graph with other technologies - Jessica, for example, named labelled property graphs as one way of creating graphs - but because they don't necessarily conform to those standards, you may have to invent or reinvent a lot of the technology yourself. That's where these standards are useful.

They protect you as a customer because vendors implement things that will be useful to you, and they help avoid vendor lock-in, which most of us want to avoid.

Charles Ivie (46:24):
I wondered if you'd mention that.

Jessica Talisman (46:27):
Yes, and interoperability. That's one of the core tenets of systems, particularly as things like the EU AI Act and other requirements that rely on memory come into play. Interoperability is absolutely instrumental. Data sovereignty - making sure people can own their data - is also important, conceptually and otherwise. The fact that you're not locked into a vendor platform and can support complete interoperability becomes a core advantage if you work in a regulated space.

Controlled Vocabularies and Semantic Layers (47:07-52:27)

Pete Youngs (47:07):
Yep. Okay, Peter, back on leveling up. So, controlled vocabularies, but also we need to talk about semantic layers as well. So, maybe controlled vocabularies and then we'll do a bit of a broader view of semantic layers if that's okay.

Peter Crocker (47:25):
Sure. I'll keep it concise. A controlled vocabulary is about getting agreement within your organization - and I'll preface that by saying one organization's controlled vocabulary even though they exist in the same space could be very different to another. So it's about getting an agreed language for the business where you agree a set of terms and meanings that when different systems, people or AI agents refer to something they can be confident that they mean the same thing. Yeah, that's the short version. Can give you a longer one if you want.

Pete Youngs (48:09):
Well, then semantic layers because I think this gets misused. We've seen Databricks' Genie ontology come out. I don't believe that's a real ontology. I may be wrong. We hear semantic layers in Power BI. Anyone want to just tackle that one head-on?

Charles Ivie (48:23):
What is a true semantic layer? I'll give it a shot and then let the others do the same. I'll keep it as brief as possible. Lots of people are building semantic layers. They're essentially trying to do something we've been doing for a long time, although some organizations are realizing it in their own image. Microsoft has done something - I can't remember all the names now - but what they're really doing is defining an ontology, their view of the nature of being, and finding a way to bind it to existing data to create a knowledge graph. Even if people want to adopt some of those approaches, I would encourage them to understand the fundamentals first: designing ontologies and knowledge graphs using RDF and OWL.

That's the most practised and well-understood way of designing semantic layers. In my opinion, semantic layers are different attempts to implement the same solution: an abstracted ontological model that describes the nature of what an organization cares about, then links the data into something like a knowledge graph. We've been doing that for a while using those standardized technologies.

Jessica Talisman (49:58):
One interesting point is that semantic layers were branded in the late '90s by BusinessObjects. Historically, that was a concept for BI and analytics, but the definition has changed and morphed since then and seems to shape-shift with whatever is hot in the industry. Now we're seeing a convergence between the ontology and semantic-web world, where semantic layers have always been a core architectural tenet, and the analytics-world version of semantic layers. A semantic layer has to be more than a label and a definition that appears on a dashboard. If you think that is your context, that's a little concerning. But a semantic layer doesn't have to be heavy.

It could be as simple as RDF triples, such as Dublin Core, which is a standard for resources and documentation that exists widely on the internet. As Charles said, that sort of data exists across more than half of the web. It doesn't have to be a very complex architecture. The idea is to extend outside your dashboards and not be tool-bound: something you can extract and make interoperable outside your BI implementations and dashboards.

Pete Youngs (51:35):
Okay. Thank you. Peter, anything to add?

Peter Crocker (51:37):
For me quite simply it's a useful concept for explaining what you're doing. Below it sits data; above it sits knowledge or you know the transformation of that data into something that now has meaning within your organization. And therefore it's the point at which you want to be layering on agents on top because they're getting all of that work that you've put into to giving that data meaning. They also get the logic that your business needs. Yeah, they get all that work out of the semantic layer. They don't have to reinvent it every time you're running up your token count within the context of this conversation.

Pete Youngs (52:22):
Okay. In a truly machine-readable form, I think is what we're saying as well. Yeah.

Executable Governance (52:27-55:09)

Pete Youngs (52:27):
Okay. Right. Well, I thought we might run out of time today. There's a lot to get through. So I'm going to blast through the last section before we go to questions and this is really around governance. So we talked about the ontology as a model. We talked about the graph is the data, the semantics, the vocabularies. Governance feels like a really critical part of this. But governance is just traditional. It's paper-based. It's people talking about stuff, isn't it? So I don't know who wants to grab this one, but can we make governance more executable? Go Jessica.

Jessica Talisman (52:58):
Yes. I have a discipline around this derived from library science: the metadata application profile. I mentioned Dublin Core, which started this practice and codified it as the Singapore Framework. The idea is to structure functional requirements first. When you build governance, you should have functional requirements that look at how it works for users, machines and the organization. The most beautiful governed structures can reconcile and allow for a distributed controlled vocabulary system. You have reconciliation across the system, but everyone can define their own terms and carry their own definitions. That's RDF and SKOS, building governance around meaning first and foremost.

With ontologies and semantic systems, it's a layered approach, but the idea is agreement. That's how knowledge graphs and ontologies work: by agreement. Things are transparent within a system, you have feedback loops, and you can incorporate them. It's part of the neurosymbolic ethos of having humans in the loop and augmentation before automation. Governance is dialogue-based. It relies on feedback and on strategically architecting points of feedback into your system.

Pete Youngs (54:39):
I guess especially in agentic AI those checkpoints where humans can step in.

Jessica Talisman (54:44):
Yes. Not blasting straight to automation, but like realizing that a system can actually learn while building - that's reinforcement learning - but having a human in the loop is really important. But points like having checkpoints with augmentation where you're actually able to record people's feedback and incorporate it in real time to turn it back into something actionable.

Q&A: Cost and the Operating Model (55:09-60:28)

Pete Youngs (55:09):
Yeah. Cool. Thank you. Right, we've got four minutes left. We've got to do a quick key takeaway from each of you, then wrap up and there's too many questions to get through. One that stands out and we haven't really talked about this. Let's dive into this question. This is from Alex. What is the biggest cost of implementing an enterprise memory initiative from scratch? Anyone want to try and tackle that? Does it come back to starting small?

Charles Ivie (55:36):
I would go back to what Peter and Jessica were saying: don't try to boil the ocean. Start with something small. We run workshops over two to five days to prove out an initial use case or competency question that has real value. Someone asked in the chat whether we really need an enterprise-wide model. No. You can start with something small that shows value for one piece of the enterprise. It can be tiny, as long as it shows enough value to get buy-in. Then you can expand from there, sharing the knowledge and the ontology for the next use case.

Pete Youngs (56:17):
And tooling or compute costs - have you seen any significant costs there, or in those first initial pieces?

Charles Ivie (56:23):
Not really. Not really. There's very little cost involved in those early stages. In fact, the W3C standards we've been talking about are all completely free and open source and actually don't technically require anything apart from a whiteboard, pen and paper to get started. That's how we often start our workshops. I mean, we have our preferred tooling. I have Graph.build, which I was involved in starting which I like using, of course, but you don't actually need any of it.

Pete Youngs (56:52):
Yeah. And surely if this becomes a large enterprise system there might naturally be a large cost but that comes down to choices in the systems thinking and design of the solutions that you're rolling out.

Charles Ivie (57:03):
Prove the value and then it isn't expensive; it's cheap by comparison with what you're getting. It's actually incredibly good value.

Peter Crocker (57:13):
I'd just add that a well-organized system that encapsulates everything we're talking about - the semantic layer or knowledge graph - gets to the point with the answers you need. The savings are orders of magnitude when you bring in an LLM and its token costs, so getting this stuff right and, as Charles said, the technology does not come with vast costs. It's going to save you significantly when it comes to token costs.

Pete Youngs (57:58):
Yeah. Okay.

Jessica Talisman (58:00):
Don't waste time or money trying to cram it back into a relational database system. That's my one piece of parting advice.

Pete Youngs (58:08):
Just because that's what you know. Yeah. Yeah. Well, executive decision: we're going to run over by a couple of minutes. So I hope people stay on, but there's a really interesting question that we haven't touched on. It's about the team and organizational model. What do we think here? Is this a dedicated new team of specialized hires or is this upskilling of our existing business analysts and so on presumably to learn how to build an ontology? What are your thoughts on that?

Peter Crocker (58:38):
Yeah, I'd say bring in expertise because you know Jessica and Charles, they've been there, they've learned the lessons the hard way. But ultimately this is going to be fundamental to your business and you want with their support to be in a place where you can own this. And truly make it your own. And then dip into that expertise, you know, when you're kicking off the next project or building it. So that's what I'd advise.

Jessica Talisman (59:14):
I'm a big proponent of education as well. So yes, bring in the experts 100% and then embed that expertise. I think upskilling is one of the most compassionate things leaders can do these days, especially with layoffs and shifting skill-set needs within organizations. There are enough people who are interested but need the opportunity. This is an opportunity, and every opportunity has a slight cost, but the investment is worth it because there will be a return.

Peter Crocker (59:50):
And the other thing that I'd say is you know to get most use out of this technology this isn't just an IT team; it's an organization-wide opportunity you need expertise from across your business. We are trying to represent the meaning and logic of your business. So you need to bring expertise from across the organization and bring them on the journey because ultimately, they're the people you're going to make more productive. Bringing them on the journey gives the project a higher chance of success.

Executive Takeaways and Closing (60:28-63:28)

Pete Youngs (60:28):
Yeah, agreed. Thank you. Okay. There are too many questions to answer. So right let's move to wrapping up. So to each of you in one sentence, what's the question every executive should ask before approving the next wave of agents? And obviously we're endorsing knowledge architecture and knowledge management and enterprise memory here. So Jessica, starting with you. What's the one question executives should be asking before they move into this?

Jessica Talisman (60:56):
Are we building meaning into our systems? It's that simple. We started with repeatable patterns, so do we have sustained and persistent representation?

Pete Youngs (61:12):
And therefore, I guess, that real relevance to that organization rather than generic solutions?

Jessica Talisman (61:17):
Not generic. It's: how can we build this into the future and forever.

Pete Youngs (61:22):
Thank you. Peter?

Peter Crocker (61:25):
If I was looking at a project, I'd ask: before going down yet another agent project and perhaps just throwing RAG at the problem, have we given it the knowledge and the rules; have we modelled our organization and its meaning in a way that gives the system everything it needs to make decisions we can trust and explain?

Pete Youngs (61:53):
Okay. And Charles.

Charles Ivie (61:55):
Yeah. Show me how I can understand it and trust it.

Pete Youngs (62:00):
Okay. As simple as that. I like these key takeaways. Right. We are essentially done. So, thank you very much, Jessica, Peter, and Charles. I hope you've enjoyed this today. I've learned a lot. I knew I was coming into this not knowing as much as my esteemed guests. So, thank you. It's good to hear from you. For a key takeaway, I'm drawn to the standards. There's too many key takeaways. I've tried to call them out as we went through, but I'm drawn to that standards point. Like, don't reinvent the wheel. The standards are there. They've been mentioned today. So, yeah, follow that path and make sure that's part of where you go next if you're moving into this world.

We touched on some technical aspects, vector and so on. So, they need to be understood. I think this comes back to your point, Peter, around bringing the right skills to educate and build your internal capability to then upskill your team. And if you want to go in this direction and obviously we endorse that. So yeah, a really interesting conversation. I feel like we should be doing a follow-up and diving into some deeper aspects of this. So let's think about that. But yeah, thank you for your time. Apologies we've gone over. And yeah, Jessica, Peter, Charles, thank you very much indeed. And connect with us on LinkedIn. We'd love that. So yeah, thanks everyone.

Pete Youngs and panel (63:25):
Thank you, everyone. Goodbye. Bye. Cheers.