Tristan Baker of Salesforce joins host John Furrier on Neo4j GraphTalk for a conversation about knowledge graphs, artificial intelligence, referred to as AI, and enterprise data architecture.
Baker draws on experience in data modeling and platform architecture to trace the arc from Resource Description Framework, referred to as RDF, and Web Ontology Language, referred to as OWL, to modern graph approaches. They discuss GraphRAG, vector search and semantic search and explain how graph databases and graph context connect distributed data to support agentic conversational applications and retrieval-augmented generation.
Key takeaways emphasize the graph as an infrastructure backbone that enables relationship-aware retrieval and rapid conversational answers. Baker explains that robust systems combine diverse storage engines, a metadata and semantic layer and graph context to determine truth, routing and computation. They stress governance and master data management, referred to as MDM, as prerequisites for trustworthy agentic AI and note that strong governance supports reliable conversational agents and enterprise-scale AI deployments.
Forgot Password
Almost there!
We just sent you a verification email. Please verify your account to gain access to
theCUBE + NYSE Wired: Data + AI: Turning Data Into Knowledge for Autonomous Systems. If you don’t think you received an email check your
spam folder.
Sign in to theCUBE + NYSE Wired: Data + AI: Turning Data Into Knowledge for Autonomous Systems.
In order to sign in, enter the email address you used to registered for the event. Once completed, you will receive an email with a verification link. Open the link to automatically sign into the site.
Register for theCUBE + NYSE Wired: Data + AI: Turning Data Into Knowledge for Autonomous Systems
Please fill out the information below. You will receive an email with a verification link confirming your registration. Click the link to automatically sign into the site.
You’re almost there!
We just sent you a verification email. Please click the verification button in the email. Once your email address is verified, you will have full access to all event content for theCUBE + NYSE Wired: Data + AI: Turning Data Into Knowledge for Autonomous Systems.
Thanks for confirming your account. Now you can access theCUBE + NYSE Wired: Data + AI: Turning Data Into Knowledge for Autonomous Systems with this email address.
I want my badge and interests to be visible to all attendees.
Checking this box will display your presense on the attendees list, view your profile and allow other attendees to contact you via 1-1 chat. Read the Privacy Policy. At any time, you can choose to disable this preference.
Select your Interests!
add
Upload your photo
Uploading..
OR
Connect via Twitter
Connect via Linkedin
EDIT PASSWORD
Share
Forgot Password
Almost there!
We just sent you a verification email. Please verify your account to gain access to
theCUBE + NYSE Wired: Data + AI: Turning Data Into Knowledge for Autonomous Systems. If you don’t think you received an email check your
spam folder.
Sign in to theCUBE + NYSE Wired: Data + AI: Turning Data Into Knowledge for Autonomous Systems.
In order to sign in, enter the email address you used to registered for the event. Once completed, you will receive an email with a verification link. Open the link to automatically sign into the site.
Sign in to gain access to theCUBE + NYSE Wired: Data + AI: Turning Data Into Knowledge for Autonomous Systems
Please sign in with LinkedIn to continue to theCUBE + NYSE Wired: Data + AI: Turning Data Into Knowledge for Autonomous Systems. Signing in with LinkedIn ensures a professional environment.
Are you sure you want to remove access rights for this user?
Details
Manage Access
email address
Community Invitation
Tristan Baker, Salesforce
Tristan Baker of Salesforce joins host John Furrier on Neo4j GraphTalk for a conversation about knowledge graphs, artificial intelligence, referred to as AI, and enterprise data architecture.
Baker draws on experience in data modeling and platform architecture to trace the arc from Resource Description Framework, referred to as RDF, and Web Ontology Language, referred to as OWL, to modern graph approaches. They discuss GraphRAG, vector search and semantic search and explain how graph databases and graph context connect distributed data to support agentic conversational applications and retrieval-augmented generation.
Key takeaways emphasize the graph as an infrastructure backbone that enables relationship-aware retrieval and rapid conversational answers. Baker explains that robust systems combine diverse storage engines, a metadata and semantic layer and graph context to determine truth, routing and computation. They stress governance and master data management, referred to as MDM, as prerequisites for trustworthy agentic AI and note that strong governance supports reliable conversational agents and enterprise-scale AI deployments.
>> Welcome back to theCUBE. I'm John Furrier, your host in San Francisco for Neo4j's GraphTalk. Of course, there'll be a GraphTalk in New York City in September. I'll be there as well. This is where the practitioners and the leading technologists get together to talk about the future of the role of data and AI, specifically around graph databases, the role of knowledge graphs, ontologies. As the new data structures of AI emerge, a significant change is happening. We're doing our part to bring the experts to the table to discuss it. Tristan Baker here, senior director, head of data architects at Salesforce. Welcome to theCUBE. Maybe soon to be called Agentforce or AG&T. New ticker. I told Marc Benioff. Welcome to theCUBE.
Tristan Baker
>> Thank you very much. Happy to be here.
John Furrier
>> I told Marc Benioff and said, Dreamforce last year, they should change the ticker from CRM to AG&T.
Tristan Baker
>> Yeah, it might happen.
John Furrier
>> Might happen. I hear it's in the works. Salesforce obviously pro-agent. That's really the narrative for Salesforce. But in the technical community and the graph community, everyone kind of knows the benefits. And now IT went cloud native, cloud native's going AI native, starting to see a melting pot of large scale system architecture for business building out these AI visions. And you have the top-down management mandate, put AI in the business. And then you have the bottom up adoption on users, and you have the practitioners building the systems to stand up knowledge graphs and put AI workloads in production. That's kind of the big picture. But there's a lot going on. There's a lot of data. You got Oracle databases over there, you got a Databricks over there. I mean, there's tons of data. We talked to regulated industry and bio and pharma. They have tons of nuanced data. I mean, it's everywhere. But graphs are a nice solution. What's your take on the knowledge graph wave? Because it seems to offer up and illuminate new relationships and makes the recursion of computer science work really well.
Tristan Baker
>> So I've been thinking about this problem for a while and going back maybe 10 years or so before AI, as we know it today, was as popular as it is now. The tools that you had at your disposal that are similar to what we're dealing with now looked like RDF, OWL and inference engines built on top of this extremely structured ontological language. So the push, and in my opinion, it was still mostly academic at the time I was looking at it, was take all your data and you can get the inference out of it if you represent your data correctly using this kind of precise, cool representation language called RDFNL. And if you bring in these specialized interpretation engines, you can infer interesting new facts from the data that an enterprise might have at its disposal. And then AI comes along. And does it need highly structured information? No. You can just feed it a document and it'll kind of read English and tell you what it thinks. Do you need a hyper-specialized prologue-like theorem proving engine? No. You can kind of also give that to LLM and it'll reason through its neural network and come out with something else. So the new question I think is what is the right way to represent your data so that AI can make the most sense of it? In the old world, you needed highly structured data structures and super specialized databases and machines. Now those things aren't needed as much anymore, but nobody's getting away from the issue of accurately describing your context, accurately representing an enterprise's information in a way that something can make sense of it. And I think the question on everybody's mind is of the 700 different ways people are currently experimenting with ways to do this, you've got GraphRAG that came out a little while ago. LLM Wiki is a really interesting approach for representing knowledge. It has its limitations. Vector search or semantic search over vector databases. These are all kind of beating around the same question. But I do think that in some of my own usage of it and some of the other folks that I think you spoke with today, I used to work with them in prior lives. So I know the problems they're working on, but everybody seems to be converging around, "Hey, maybe a graph is the right way to represent the facts and terminology and nodes and relationships that maybe you used to have to do in maybe what you might now call archaic old languages. But now maybe there's a better way of doing it and maybe we can demonstrate that if you follow these kinds of approaches, you're keeping your token usage down and all kinds of other things."
John Furrier
>> I love that explanation because it frames where we came from and where we got here. It's funny, RDF had a little triggered flashback to the '90s on that one.
Tristan Baker
>> Yeah, it's about that old.
John Furrier
>> But that was a metadata reasoning issue. And metadata was really more about describing data of data. So okay, that's database stuff, but that's not reasoning the way AI does it. I was just yesterday live-streaming at the AMD advancing AI event. And one of the things that came out of that event was that inference and small compute pods could actually do a lot of good things. And context was a discussion in their world. So when you look at metadata around databases, that was just to make the database retrieval better. It wasn't getting reasoning in the best answer. I mean, search gets stuff fast, gets the first thing first and you get it. AI is not really a search paradigm, but you have to have a search discovery mindset. So how do you think about the architecture that when you look at the neural network, if you will, being graph-based? Because metadata in the graph is relationships. That has power. So there's a lot of benefits in computer science there now. So what about AI do you like about the graph? Because the community's raving about converging. "Wow, I got great search. Well, I'm done with that. What do I do next?" And so there seems to be a progression of advancement Where, "Oh my God, when does this stop getting better?" So how do you lay that out without getting over your skis on the architecture side? How do you zoom out and say, "Okay, I'm going to lay out super AI infrastructure." And I said yesterday that AI is now infrastructure. So you have AI infrastructure, NVIDIA, AMD, Intel, Cerebras, they're all pumping and clouds are getting faster. You got NeoCloud, Salesforce, the original cloud. So the infrastructure is getting better, but AI itself is infrastructure if you're think about it. So it's not metadata for the database.
Tristan Baker
>> No.
John Furrier
>> The graph is an infrastructure component.
Tristan Baker
>> It is. It's becoming that critical piece that helps tie the end agentic experience that you want to deliver. It's almost like the glue that stitches what the customer or the person is asking to the data in the context that is needed in order to answer that question. Maybe to better answer your question, I can do it through the example of a use case. And it's one that's top of my mind now, and it's probably similar to a lot of what people are thinking about, which is my company and all my peers working at all their companies, all the CEOs of all these companies just say, where's my chatbot? Where I can just ask a question and I get my QBR report kind of spat back at me. And then I can drill 17 layers deep on that and ask, "Why do I see customer drop off over here? Where's my churn happening over there? What is my financial outlook going to look like based on the issues that I'm seeing here? Where should I make the next product investments?" Those are the kinds of questions that are top of mind for any leader.
John Furrier
>> By the way, I want those answers in seconds.
Tristan Baker
>> Yeah, in seconds.
John Furrier
>> Milliseconds.
Tristan Baker
>> And they need to be right. So it's one thing to just spit out garbage. It's another thing to spit out something that I actually believe.
John Furrier
>> Yeah, they want to graph with that too, by the way.
Tristan Baker
>> Yeah. So don't just give me the number. Tell me how you figured it out and give me all the things it's connected to. So this is, I don't know, I think this is kind of like the penultimate epitome of where at least my colleagues and a lot of us are attempting to go. But the mechanism-
John Furrier
>> That's the user agency piece. That's been verified. People want that.
Tristan Baker
>> Oh, absolutely.
John Furrier
>> There's high demand for that use case.
Tristan Baker
>> And at least unless somebody's withholding information from me, I don't know anybody that's actually totally solved this one yet.
John Furrier
>> No one's got this, but now they get it to the data. So we're backing into that. Okay, what does it take to do that? Okay, you got access to the databases. Where's the data? Because you want the best reports, you want to have access to everything. And you got to get it retrieved, organized, reasoned in less than a second.
Tristan Baker
>> Yeah, exactly.
John Furrier
>> Or maybe a millisecond.
Tristan Baker
>> Conversational speed, which is seconds, not much longer than that. So if you unpack that problem a little bit, I like to think about it in a couple of different layers. Maybe we'll go bottom to top. At the bottom, bottom layer, it looks just like the database infrastructure that you're familiar with. I think that you're going to continue to need lakehouses or analytical data stores. I think you might continue to need, I think maybe what's colloquially referred to as customer profile stores. And I think you're going to continue to need your operational databases. So relational databases, NoSQL databases.
John Furrier
>> Time series databases.
Tristan Baker
>> Time series databases. These things exist because at the fundamental level, they implement different data structures that are optimized for different kinds of retrieval. You have an indexed-based data store, and those tend to be the things that power your front end applications because you've got one customer right now and they need to look up just their record. They don't care about all your other millions of customers. And then you have columnar-based file formats in lakehouses and they're organized that way and they don't have indexes because nobody wants one customer. People want the aggregate sum of something across all 10 billion customers. So as long as you're going to have different kinds of questions, you're going to have different kinds of retrieval data structures in the engines to power them. So that's always going to be varied. I don't think we're heading to a world yet where one database is going to do everything.
John Furrier
>> There's an old expression I always used to use when I do theCUBE interviews or I meet people. Well, I have to tap that section of my brain.
Tristan Baker
>> Yes.
John Furrier
>> In a way, you can look at a time series database and say that's a section of the brain. So if you're building-
Tristan Baker
>> It thinks in a different way than other sections of the brain.
John Furrier
>> Yeah. And if I'm a company and I had the tech team, I'd be like, "Okay, I want a brain for the company. And I want this brain to be powering everything." So if you could build your company brain, what would that look like?
Tristan Baker
>> Yeah, exactly.
John Furrier
>> It's a thought exercise. Okay, I want my time series over here. I want my art, some creative side here. I want my math side. So you can actually get it. And then, okay, how do I tap it?
Tristan Baker
>> Then how do you tap it piece is the next layer up, which is, okay, you've got essentially the same fact about a customer, maybe represented in six different databases, 60 different databases. So now immediately you have this problem of, "Well, where's the truth about my customer?" Because now I'm copying it 60 different times. So the next fact then becomes, or the next layer you might need on top of it then starts to look a little bit like this metadata layer that says, "Where are six different copies of this data maintained? What's the source of truth? What's the system of record? What's the eventual consistent copy? And when should I use what for what kind of question?" Those become interesting metadata descriptions that you need. Then you also probably need, what does it mean? Now you're starting to get to the point where you're going to map the way that a natural language thinking person mentions a metric, like a KPI like average order value or average contract value or annual recurring revenue for product X, Y, Z. That's how people talk about it, but that's not the name of the column in your database. So now you need something that maps your business terminology to where this stuff exists. You also need something that maybe keeps track of what kind of math is the person implying that I need to run right now? And if it's this kind of operation, now I'm getting specialized into this data store. If it's another operation, I'll go to this one. So now you're kind of packing in context and knowledge about what you would normally use a data engineering team for or a database design or an engineering team for. You have to kind of bake in that engineering context as well so that you can meet that requirement that you mentioned, which was, "Yes, I want an answer, but no, I don't want it a day from now. I want it in like five seconds."
John Furrier
>> And I need a graph to be the, I guess, spine or backbone or the connection where you can hang the relationships off.
Tristan Baker
>> Exactly.
John Furrier
>> You have customer wants, but it could be mentioned in a zillion places and that'll have that. Will that have the relationship graph of graphs? How should people think about the architecture?
Tristan Baker
>> Now I'm not pretending to say that I know exactly the right answer because if I did, then-
John Furrier
>> You wouldn't be here-
Tristan Baker
>> I wouldn't be here.
John Furrier
>> ... going public.
Tristan Baker
>> Yeah, I would've built it already. So now I'm talking speculative, maybe more.
John Furrier
>> Yeah, we're . We're ripped.
Tristan Baker
>> Then you go, "Okay, well, what is the role of that graph?" So in my architecture now, the role of this graph database is to manage the relationships and the context that are at more of that metadata level that say, where is the data? How should I query it? And how can I connect things together? Because potentially my user is not asking for a metric that's already calculated. They might be asking for a relationship or correlative. Maybe they're exploring a correlative causal hypothesis between two things. In which case I might need to, at the same time, fire a query over here. I need to fire one over here and bring the two results back together and then let the user determine if there's actually gold hints.
John Furrier
>> And by the way, the user's treating this as a generative query basically because you never know, you can't anticipate what the relationship ask is. I mean, that has to be done in the graph itself. What makes that happen? Is it the ability to recurse through that? Is it the science behind it? What makes it so good?
Tristan Baker
>> Yeah. So the power of the natural, sorry, the power of a graph database is in its ability. I mean, you have kind of a declarative language of saying, I think these two things are related. Find for me the connections that prove that that is the case. And now I can take advantage of those connections. So now we're getting into the mechanics of how a graph database works, which honestly, I'm not the right person to tell you exactly why it's better than a relational database.
John Furrier
>> But you lay out the big picture. I mean, it's like laying out a system architects for any system.
Tristan Baker
>> Yes.
John Furrier
>> I mean, data architecture now isn't database specific.
Tristan Baker
>> No.
John Furrier
>> You got to look holistically and say, "Okay, we're building a data system."
Tristan Baker
>> Exactly.
John Furrier
>> That's what the mindset I'm seeing people who are succeeding in production with AI because they have to handle scale, deterministic agency. Agents and robotics are really pointing to deterministic behavior because agents behave and they touch everything. Storage, memory, and microservices. If they go off the rails, they're only good as what you give them.
Tristan Baker
>> Yeah, exactly.
John Furrier
>> You train the agent and say, "Well, why?" It's new and slap it in line, bring it in line. So there's a lot of that going on.
Tristan Baker
>> Yeah. So like most things, many systems are garbage in, garbage out. So you can have the best technology in the world, but if you're not careful about the content you're exposing it to, then you're going to end up with nothing very useful.
John Furrier
>> What are some of the talks here at GraphTalk at Neo4j? Because New York's coming up in September. A lot of these conferences when they're small community events, all the leaders are here, they're the pioneers, the frontier leaders. What are some of the hot issues people are talking about? What is the top?
Tristan Baker
>> So the one that I can talk about, the one that I think is the least discussed, again, I'm just kind of doing a pulse check when I go around and talk to people about this stuff. I don't hear discussed very much the access control and governance aspects of how are you going to protect the data from misuse or inappropriate access in the architecture that I just described, for the use case that I just described. So again, we can go back to my example use case and let's say that you-
John Furrier
>> Well, if you're mapping data, you need to know certain things.
Tristan Baker
>> So if you have a CEO that's conversing with an agent, maybe you can make the argument that the CEO more or less has access to be able to see everything. But then the CEO has divided his suite suite or her suite suite up into, well, there's my marketing person and my legal compliance officer, my security officer, et cetera, et cetera. And then they have organizations and so on. And eventually you get to portions, you don't have to go very far before you get to portions of the organization were you go, "Well, maybe you don't need to and shouldn't see the same data sets that this portion of the organization."
John Furrier
>> You don't need to see payroll.
Tristan Baker
>> Sorry. Yeah. So a lot of people don't need to see payroll at that level of detail. So we talk a lot about, okay, maybe there's a semantic representation of all the data at the company. But again, maybe it lives in very low level, more specific databases. Traditionally, the access control is managed at those database levels. So I write a grant statement and that's what protects my rows and columns and things in my relational database. I set an S3 bucket policy, and that's what prevents people from accessing buckets of unstructured data. But if we're pushing all of the metadata up at a higher level to help tie that conversational analytic use case, then I guess in addition to needing a semantic description of the data, you start to also maybe need a semantic description of your access policy because your legal team is going to come to you and they're not going to say, "Here's how data should be protected in Postgres." They're going to say, "People like this should not be able to access data like that."
John Furrier
>> And they're going to speak in normal language.
Tristan Baker
>> They're going to speak in normal language.
John Furrier
>> This is language.
Tristan Baker
>> So at the same time, your CEO and C-suite and everybody is asking natural language questions of your data. Your legal and compliance team is reading a bunch of contracts and agreements that they've negotiated with their clients and they're saying, "Yeah, sure, but don't let them do this and you shouldn't be able to do this." And they're also describing it in a
John Furrier
>> You bring up the top conversation that I was talking to the Neo4j CTO about, which is Neo4j with the graph, that's a great solution. They're doing great with it. The timing's perfect with AI. But system of intelligence isn't just about graphs. It's an ecosystem. You mentioned different databases. You got Databricks and Snowflake. Snowflake dominated the data analytics business, but now they're trying to go in. Databricks come in and say, "No, no, we're the AI company. We open tables, take that Snowflake." And then so they're $188 billion company. They're $10 billion less than IBM. But then they're private company, they don't really trade, so it's really not a right market value. But think about Databricks is literally $10 billion less than IBM. So it shows you that the data lakes are a key piece, but pipelines come up a lot too. You got to have good data pipelines and you got to feed the agents. So this is not just about graphs. Graphs I like, I think from my standpoint, I look at it as very valuable for the neural network piece, but you have an ecosystem of data and you got to reign it in. How do you think about that? How are people thinking about it? Because then you start going outside the religion of graphs, which is, I love to talk about graphs, but I think it's super important. People will know more about it, but it's a bigger picture.
Tristan Baker
>> Oh, for sure. Yeah. The domain map, if you will, of everything having to do with managing data is much, much more broad than just the role that a graph database or even a semantic layer might play in it. So I think the problems themselves are no different than they have been over the last 10 or 20 or forever as far as I'm concerned. You've got your kind of governance compliance concerns about making sure data is appropriately used and that you're not leaking it or losing track of it. You've got your performance concerns. Am I spending more money than I need to for the amount of value that I'm getting out of this? I've been in many different projects called clean all this mess up because we're paying too much.
John Furrier
>> Exactly.
Tristan Baker
>> And those projects go really slow if you don't have great tracking of why this is here and what value it's providing. Plus, not to mention it's its own compliance risk to have things lying around. So there's those kinds of concerns, those aren't changing.
John Furrier
>> Harmonization layers are emerging.
Tristan Baker
>> Master data management still I think continues to be a critical piece of this because you will continue to have multiple sources of opinion about who this customer is. And this is definitely true as you're talking about your prospect to customer pipeline. Your prospects, you're always kind of sure who they are, but you're not 100% sure. And is this person the same person as the conference person I met over here? And are they related to the same leader at this organization? So you're always harmonizing and mastering records. And so some of these things, we talked about how ontology is maybe what's old is new again. I think master data management as well is gaining popularity or I don't know, mindset.
John Furrier
>> I think governance is the number one issue on agentic. MDM and governance go to hand to hand.
Tristan Baker
>> They do.
John Furrier
>> You get that right, good things happen. That seems to be the pattern.
Tristan Baker
>> Yeah. So really it's taking every one of these problems that, I don't know, anybody who spent any time in this space has probably spent a lot of time thinking about. And now you're thinking about, "Great, how do I identify it? How do I make sure-
John Furrier
>> It sounds so easy.
Tristan Baker
>> It does, doesn't it?
John Furrier
>> Well, I mean, Salesforce, we've been meeting a lot of your SVPs in the tech side over the past couple years, Dreamforce last year too. You have so much data. System of record dominates the system of record business. Engagement is evolving, but this holy grail is the system of intelligence because now that you have these AI infrastructure systems, AI is infrastructure. It's a perfect scenario to actually deploy a systems of intelligence. Everyone's trying to figure it out.
Tristan Baker
>> Yeah. So the investments that Salesforce has made over the years continue to be relevant. Obviously you have the core CRM product, the marketing products, Data Cloud now Data360 or maybe
John Furrier
>> AgentCore.
Tristan Baker
>> Yes. So there's AgentForce.
John Furrier
>> AgentForce.
Tristan Baker
>> Yep.
John Furrier
>> AgentCore, that's Amazon. I'm so confused.
Tristan Baker
>> Right. But this pattern that I had described earlier of you have your core product, in this case, a CRM product. Then you have your kind of activation layer, which is built on top of your customer profile store that's like Data Cloud. And those patterns aren't really changing. Those patterns I think are present not only at companies that I've worked for before, but it's also the core product that Salesforce sells. And now they're talking about, "Okay, congratulations. If you've been using Salesforce and using it properly and stuck with us over this period of time, this thing called AgentForce now gives you the opportunity to kind of agentify not only your workflows, but also get agentic based insights into your data."
John Furrier
>> I think that's easier. Playing with data as a value proposition is not what end users sign up to do.
Tristan Baker
>> Not usually.
John Furrier
>> So if you can eliminate the toil of data entry and eliminate the hassle of getting at the data and doing the reports, that's the holy grail. And I love the Slack integration into Salesforce.
Tristan Baker
>> Oh, it's amazing.
John Furrier
>> Another talk about neural network opportunity to build the company brain you could shatter.
Tristan Baker
>> Yeah. That's the layer of consumption or the layer of engagement is what Slack is described as. And we practice what we preach as well. Like I said, I've only been there for two months, but
John Furrier
>> Well, as senior director, head of data architecture, you are at the right place to get your hands on the keys to the kingdom.
Tristan Baker
>> Yeah, certainly.
John Furrier
>> I mean, there's so much to master. It's such a great domain of opportunity.
Tristan Baker
>> Yep. Absolutely.
John Furrier
>> Thanks for coming on theCUBE. Appreciate it.
Tristan Baker
>> Thank you very much, John.
John Furrier
>> What do you think about the event here so far?
Tristan Baker
>> Oh, it's been great. I was able to attend half of it. Unfortunately, not all of it, but I was in a panel just before this answering some of the same questions that you were asking me. So what you're asking me is certainly relevant-
John Furrier
>> Okay, good.
Tristan Baker
>> ... because there's 200 people out there that were asking versions of the same question.
John Furrier
>> The whole world wants to know. I mean, I think this is going to be very popular. I love the graphics. We have a real critical piece in the data stack with AI as well as the system intelligence system. That's the data operating system emerging. There's no doubt about it. And I hope to catch up with you at Dreamforce a couple of weeks.
Tristan Baker
>> Yeah, I'll be there.
John Furrier
>> So good to see you.
Tristan Baker
>> It's right down the street.
John Furrier
>> Yeah, course we'll be there. Thanks for coming on.
Tristan Baker
>> Thank you very much.
John Furrier
>> All right, cool. I'm John Furrier theCUBE. We are here at the Neo4j. This is GraphTalk. It's soon to be a podcast because it sounds like a great podcasting thing, but it's also an event here in San Francisco. The leaders get together, of course, in New York City in September. I'll be there as well with theCUBE. Thanks for watching.
>> Welcome back to theCUBE. I'm John Furrier, your host in San Francisco for Neo4j's GraphTalk. Of course, there'll be a GraphTalk in New York City in September. I'll be there as well. This is where the practitioners and the leading technologists get together to talk about the future of the role of data and AI, specifically around graph databases, the role of knowledge graphs, ontologies. As the new data structures of AI emerge, a significant change is happening. We're doing our part to bring the experts to the table to discuss it. Tristan Baker here, senior director, head of data architects at Salesforce. Welcome to theCUBE. Maybe soon to be called Agentforce or AG&T. New ticker. I told Marc Benioff. Welcome to theCUBE.
Tristan Baker
>> Thank you very much. Happy to be here.
John Furrier
>> I told Marc Benioff and said, Dreamforce last year, they should change the ticker from CRM to AG&T.
Tristan Baker
>> Yeah, it might happen.
John Furrier
>> Might happen. I hear it's in the works. Salesforce obviously pro-agent. That's really the narrative for Salesforce. But in the technical community and the graph community, everyone kind of knows the benefits. And now IT went cloud native, cloud native's going AI native, starting to see a melting pot of large scale system architecture for business building out these AI visions. And you have the top-down management mandate, put AI in the business. And then you have the bottom up adoption on users, and you have the practitioners building the systems to stand up knowledge graphs and put AI workloads in production. That's kind of the big picture. But there's a lot going on. There's a lot of data. You got Oracle databases over there, you got a Databricks over there. I mean, there's tons of data. We talked to regulated industry and bio and pharma. They have tons of nuanced data. I mean, it's everywhere. But graphs are a nice solution. What's your take on the knowledge graph wave? Because it seems to offer up and illuminate new relationships and makes the recursion of computer science work really well.
Tristan Baker
>> So I've been thinking about this problem for a while and going back maybe 10 years or so before AI, as we know it today, was as popular as it is now. The tools that you had at your disposal that are similar to what we're dealing with now looked like RDF, OWL and inference engines built on top of this extremely structured ontological language. So the push, and in my opinion, it was still mostly academic at the time I was looking at it, was take all your data and you can get the inference out of it if you represent your data correctly using this kind of precise, cool representation language called RDFNL. And if you bring in these specialized interpretation engines, you can infer interesting new facts from the data that an enterprise might have at its disposal. And then AI comes along. And does it need highly structured information? No. You can just feed it a document and it'll kind of read English and tell you what it thinks. Do you need a hyper-specialized prologue-like theorem proving engine? No. You can kind of also give that to LLM and it'll reason through its neural network and come out with something else. So the new question I think is what is the right way to represent your data so that AI can make the most sense of it? In the old world, you needed highly structured data structures and super specialized databases and machines. Now those things aren't needed as much anymore, but nobody's getting away from the issue of accurately describing your context, accurately representing an enterprise's information in a way that something can make sense of it. And I think the question on everybody's mind is of the 700 different ways people are currently experimenting with ways to do this, you've got GraphRAG that came out a little while ago. LLM Wiki is a really interesting approach for representing knowledge. It has its limitations. Vector search or semantic search over vector databases. These are all kind of beating around the same question. But I do think that in some of my own usage of it and some of the other folks that I think you spoke with today, I used to work with them in prior lives. So I know the problems they're working on, but everybody seems to be converging around, "Hey, maybe a graph is the right way to represent the facts and terminology and nodes and relationships that maybe you used to have to do in maybe what you might now call archaic old languages. But now maybe there's a better way of doing it and maybe we can demonstrate that if you follow these kinds of approaches, you're keeping your token usage down and all kinds of other things."
John Furrier
>> I love that explanation because it frames where we came from and where we got here. It's funny, RDF had a little triggered flashback to the '90s on that one.
Tristan Baker
>> Yeah, it's about that old.
John Furrier
>> But that was a metadata reasoning issue. And metadata was really more about describing data of data. So okay, that's database stuff, but that's not reasoning the way AI does it. I was just yesterday live-streaming at the AMD advancing AI event. And one of the things that came out of that event was that inference and small compute pods could actually do a lot of good things. And context was a discussion in their world. So when you look at metadata around databases, that was just to make the database retrieval better. It wasn't getting reasoning in the best answer. I mean, search gets stuff fast, gets the first thing first and you get it. AI is not really a search paradigm, but you have to have a search discovery mindset. So how do you think about the architecture that when you look at the neural network, if you will, being graph-based? Because metadata in the graph is relationships. That has power. So there's a lot of benefits in computer science there now. So what about AI do you like about the graph? Because the community's raving about converging. "Wow, I got great search. Well, I'm done with that. What do I do next?" And so there seems to be a progression of advancement Where, "Oh my God, when does this stop getting better?" So how do you lay that out without getting over your skis on the architecture side? How do you zoom out and say, "Okay, I'm going to lay out super AI infrastructure." And I said yesterday that AI is now infrastructure. So you have AI infrastructure, NVIDIA, AMD, Intel, Cerebras, they're all pumping and clouds are getting faster. You got NeoCloud, Salesforce, the original cloud. So the infrastructure is getting better, but AI itself is infrastructure if you're think about it. So it's not metadata for the database.
Tristan Baker
>> No.
John Furrier
>> The graph is an infrastructure component.
Tristan Baker
>> It is. It's becoming that critical piece that helps tie the end agentic experience that you want to deliver. It's almost like the glue that stitches what the customer or the person is asking to the data in the context that is needed in order to answer that question. Maybe to better answer your question, I can do it through the example of a use case. And it's one that's top of my mind now, and it's probably similar to a lot of what people are thinking about, which is my company and all my peers working at all their companies, all the CEOs of all these companies just say, where's my chatbot? Where I can just ask a question and I get my QBR report kind of spat back at me. And then I can drill 17 layers deep on that and ask, "Why do I see customer drop off over here? Where's my churn happening over there? What is my financial outlook going to look like based on the issues that I'm seeing here? Where should I make the next product investments?" Those are the kinds of questions that are top of mind for any leader.
John Furrier
>> By the way, I want those answers in seconds.
Tristan Baker
>> Yeah, in seconds.
John Furrier
>> Milliseconds.
Tristan Baker
>> And they need to be right. So it's one thing to just spit out garbage. It's another thing to spit out something that I actually believe.
John Furrier
>> Yeah, they want to graph with that too, by the way.
Tristan Baker
>> Yeah. So don't just give me the number. Tell me how you figured it out and give me all the things it's connected to. So this is, I don't know, I think this is kind of like the penultimate epitome of where at least my colleagues and a lot of us are attempting to go. But the mechanism-
John Furrier
>> That's the user agency piece. That's been verified. People want that.
Tristan Baker
>> Oh, absolutely.
John Furrier
>> There's high demand for that use case.
Tristan Baker
>> And at least unless somebody's withholding information from me, I don't know anybody that's actually totally solved this one yet.
John Furrier
>> No one's got this, but now they get it to the data. So we're backing into that. Okay, what does it take to do that? Okay, you got access to the databases. Where's the data? Because you want the best reports, you want to have access to everything. And you got to get it retrieved, organized, reasoned in less than a second.
Tristan Baker
>> Yeah, exactly.
John Furrier
>> Or maybe a millisecond.
Tristan Baker
>> Conversational speed, which is seconds, not much longer than that. So if you unpack that problem a little bit, I like to think about it in a couple of different layers. Maybe we'll go bottom to top. At the bottom, bottom layer, it looks just like the database infrastructure that you're familiar with. I think that you're going to continue to need lakehouses or analytical data stores. I think you might continue to need, I think maybe what's colloquially referred to as customer profile stores. And I think you're going to continue to need your operational databases. So relational databases, NoSQL databases.
John Furrier
>> Time series databases.
Tristan Baker
>> Time series databases. These things exist because at the fundamental level, they implement different data structures that are optimized for different kinds of retrieval. You have an indexed-based data store, and those tend to be the things that power your front end applications because you've got one customer right now and they need to look up just their record. They don't care about all your other millions of customers. And then you have columnar-based file formats in lakehouses and they're organized that way and they don't have indexes because nobody wants one customer. People want the aggregate sum of something across all 10 billion customers. So as long as you're going to have different kinds of questions, you're going to have different kinds of retrieval data structures in the engines to power them. So that's always going to be varied. I don't think we're heading to a world yet where one database is going to do everything.
John Furrier
>> There's an old expression I always used to use when I do theCUBE interviews or I meet people. Well, I have to tap that section of my brain.
Tristan Baker
>> Yes.
John Furrier
>> In a way, you can look at a time series database and say that's a section of the brain. So if you're building-
Tristan Baker
>> It thinks in a different way than other sections of the brain.
John Furrier
>> Yeah. And if I'm a company and I had the tech team, I'd be like, "Okay, I want a brain for the company. And I want this brain to be powering everything." So if you could build your company brain, what would that look like?
Tristan Baker
>> Yeah, exactly.
John Furrier
>> It's a thought exercise. Okay, I want my time series over here. I want my art, some creative side here. I want my math side. So you can actually get it. And then, okay, how do I tap it?
Tristan Baker
>> Then how do you tap it piece is the next layer up, which is, okay, you've got essentially the same fact about a customer, maybe represented in six different databases, 60 different databases. So now immediately you have this problem of, "Well, where's the truth about my customer?" Because now I'm copying it 60 different times. So the next fact then becomes, or the next layer you might need on top of it then starts to look a little bit like this metadata layer that says, "Where are six different copies of this data maintained? What's the source of truth? What's the system of record? What's the eventual consistent copy? And when should I use what for what kind of question?" Those become interesting metadata descriptions that you need. Then you also probably need, what does it mean? Now you're starting to get to the point where you're going to map the way that a natural language thinking person mentions a metric, like a KPI like average order value or average contract value or annual recurring revenue for product X, Y, Z. That's how people talk about it, but that's not the name of the column in your database. So now you need something that maps your business terminology to where this stuff exists. You also need something that maybe keeps track of what kind of math is the person implying that I need to run right now? And if it's this kind of operation, now I'm getting specialized into this data store. If it's another operation, I'll go to this one. So now you're kind of packing in context and knowledge about what you would normally use a data engineering team for or a database design or an engineering team for. You have to kind of bake in that engineering context as well so that you can meet that requirement that you mentioned, which was, "Yes, I want an answer, but no, I don't want it a day from now. I want it in like five seconds."
John Furrier
>> And I need a graph to be the, I guess, spine or backbone or the connection where you can hang the relationships off.
Tristan Baker
>> Exactly.
John Furrier
>> You have customer wants, but it could be mentioned in a zillion places and that'll have that. Will that have the relationship graph of graphs? How should people think about the architecture?
Tristan Baker
>> Now I'm not pretending to say that I know exactly the right answer because if I did, then-
John Furrier
>> You wouldn't be here-
Tristan Baker
>> I wouldn't be here.
John Furrier
>> ... going public.
Tristan Baker
>> Yeah, I would've built it already. So now I'm talking speculative, maybe more.
John Furrier
>> Yeah, we're . We're ripped.
Tristan Baker
>> Then you go, "Okay, well, what is the role of that graph?" So in my architecture now, the role of this graph database is to manage the relationships and the context that are at more of that metadata level that say, where is the data? How should I query it? And how can I connect things together? Because potentially my user is not asking for a metric that's already calculated. They might be asking for a relationship or correlative. Maybe they're exploring a correlative causal hypothesis between two things. In which case I might need to, at the same time, fire a query over here. I need to fire one over here and bring the two results back together and then let the user determine if there's actually gold hints.
John Furrier
>> And by the way, the user's treating this as a generative query basically because you never know, you can't anticipate what the relationship ask is. I mean, that has to be done in the graph itself. What makes that happen? Is it the ability to recurse through that? Is it the science behind it? What makes it so good?
Tristan Baker
>> Yeah. So the power of the natural, sorry, the power of a graph database is in its ability. I mean, you have kind of a declarative language of saying, I think these two things are related. Find for me the connections that prove that that is the case. And now I can take advantage of those connections. So now we're getting into the mechanics of how a graph database works, which honestly, I'm not the right person to tell you exactly why it's better than a relational database.
John Furrier
>> But you lay out the big picture. I mean, it's like laying out a system architects for any system.
Tristan Baker
>> Yes.
John Furrier
>> I mean, data architecture now isn't database specific.
Tristan Baker
>> No.
John Furrier
>> You got to look holistically and say, "Okay, we're building a data system."
Tristan Baker
>> Exactly.
John Furrier
>> That's what the mindset I'm seeing people who are succeeding in production with AI because they have to handle scale, deterministic agency. Agents and robotics are really pointing to deterministic behavior because agents behave and they touch everything. Storage, memory, and microservices. If they go off the rails, they're only good as what you give them.
Tristan Baker
>> Yeah, exactly.
John Furrier
>> You train the agent and say, "Well, why?" It's new and slap it in line, bring it in line. So there's a lot of that going on.
Tristan Baker
>> Yeah. So like most things, many systems are garbage in, garbage out. So you can have the best technology in the world, but if you're not careful about the content you're exposing it to, then you're going to end up with nothing very useful.
John Furrier
>> What are some of the talks here at GraphTalk at Neo4j? Because New York's coming up in September. A lot of these conferences when they're small community events, all the leaders are here, they're the pioneers, the frontier leaders. What are some of the hot issues people are talking about? What is the top?
Tristan Baker
>> So the one that I can talk about, the one that I think is the least discussed, again, I'm just kind of doing a pulse check when I go around and talk to people about this stuff. I don't hear discussed very much the access control and governance aspects of how are you going to protect the data from misuse or inappropriate access in the architecture that I just described, for the use case that I just described. So again, we can go back to my example use case and let's say that you-
John Furrier
>> Well, if you're mapping data, you need to know certain things.
Tristan Baker
>> So if you have a CEO that's conversing with an agent, maybe you can make the argument that the CEO more or less has access to be able to see everything. But then the CEO has divided his suite suite or her suite suite up into, well, there's my marketing person and my legal compliance officer, my security officer, et cetera, et cetera. And then they have organizations and so on. And eventually you get to portions, you don't have to go very far before you get to portions of the organization were you go, "Well, maybe you don't need to and shouldn't see the same data sets that this portion of the organization."
John Furrier
>> You don't need to see payroll.
Tristan Baker
>> Sorry. Yeah. So a lot of people don't need to see payroll at that level of detail. So we talk a lot about, okay, maybe there's a semantic representation of all the data at the company. But again, maybe it lives in very low level, more specific databases. Traditionally, the access control is managed at those database levels. So I write a grant statement and that's what protects my rows and columns and things in my relational database. I set an S3 bucket policy, and that's what prevents people from accessing buckets of unstructured data. But if we're pushing all of the metadata up at a higher level to help tie that conversational analytic use case, then I guess in addition to needing a semantic description of the data, you start to also maybe need a semantic description of your access policy because your legal team is going to come to you and they're not going to say, "Here's how data should be protected in Postgres." They're going to say, "People like this should not be able to access data like that."
John Furrier
>> And they're going to speak in normal language.
Tristan Baker
>> They're going to speak in normal language.
John Furrier
>> This is language.
Tristan Baker
>> So at the same time, your CEO and C-suite and everybody is asking natural language questions of your data. Your legal and compliance team is reading a bunch of contracts and agreements that they've negotiated with their clients and they're saying, "Yeah, sure, but don't let them do this and you shouldn't be able to do this." And they're also describing it in a
John Furrier
>> You bring up the top conversation that I was talking to the Neo4j CTO about, which is Neo4j with the graph, that's a great solution. They're doing great with it. The timing's perfect with AI. But system of intelligence isn't just about graphs. It's an ecosystem. You mentioned different databases. You got Databricks and Snowflake. Snowflake dominated the data analytics business, but now they're trying to go in. Databricks come in and say, "No, no, we're the AI company. We open tables, take that Snowflake." And then so they're $188 billion company. They're $10 billion less than IBM. But then they're private company, they don't really trade, so it's really not a right market value. But think about Databricks is literally $10 billion less than IBM. So it shows you that the data lakes are a key piece, but pipelines come up a lot too. You got to have good data pipelines and you got to feed the agents. So this is not just about graphs. Graphs I like, I think from my standpoint, I look at it as very valuable for the neural network piece, but you have an ecosystem of data and you got to reign it in. How do you think about that? How are people thinking about it? Because then you start going outside the religion of graphs, which is, I love to talk about graphs, but I think it's super important. People will know more about it, but it's a bigger picture.
Tristan Baker
>> Oh, for sure. Yeah. The domain map, if you will, of everything having to do with managing data is much, much more broad than just the role that a graph database or even a semantic layer might play in it. So I think the problems themselves are no different than they have been over the last 10 or 20 or forever as far as I'm concerned. You've got your kind of governance compliance concerns about making sure data is appropriately used and that you're not leaking it or losing track of it. You've got your performance concerns. Am I spending more money than I need to for the amount of value that I'm getting out of this? I've been in many different projects called clean all this mess up because we're paying too much.
John Furrier
>> Exactly.
Tristan Baker
>> And those projects go really slow if you don't have great tracking of why this is here and what value it's providing. Plus, not to mention it's its own compliance risk to have things lying around. So there's those kinds of concerns, those aren't changing.
John Furrier
>> Harmonization layers are emerging.
Tristan Baker
>> Master data management still I think continues to be a critical piece of this because you will continue to have multiple sources of opinion about who this customer is. And this is definitely true as you're talking about your prospect to customer pipeline. Your prospects, you're always kind of sure who they are, but you're not 100% sure. And is this person the same person as the conference person I met over here? And are they related to the same leader at this organization? So you're always harmonizing and mastering records. And so some of these things, we talked about how ontology is maybe what's old is new again. I think master data management as well is gaining popularity or I don't know, mindset.
John Furrier
>> I think governance is the number one issue on agentic. MDM and governance go to hand to hand.
Tristan Baker
>> They do.
John Furrier
>> You get that right, good things happen. That seems to be the pattern.
Tristan Baker
>> Yeah. So really it's taking every one of these problems that, I don't know, anybody who spent any time in this space has probably spent a lot of time thinking about. And now you're thinking about, "Great, how do I identify it? How do I make sure-
John Furrier
>> It sounds so easy.
Tristan Baker
>> It does, doesn't it?
John Furrier
>> Well, I mean, Salesforce, we've been meeting a lot of your SVPs in the tech side over the past couple years, Dreamforce last year too. You have so much data. System of record dominates the system of record business. Engagement is evolving, but this holy grail is the system of intelligence because now that you have these AI infrastructure systems, AI is infrastructure. It's a perfect scenario to actually deploy a systems of intelligence. Everyone's trying to figure it out.
Tristan Baker
>> Yeah. So the investments that Salesforce has made over the years continue to be relevant. Obviously you have the core CRM product, the marketing products, Data Cloud now Data360 or maybe
John Furrier
>> AgentCore.
Tristan Baker
>> Yes. So there's AgentForce.
John Furrier
>> AgentForce.
Tristan Baker
>> Yep.
John Furrier
>> AgentCore, that's Amazon. I'm so confused.
Tristan Baker
>> Right. But this pattern that I had described earlier of you have your core product, in this case, a CRM product. Then you have your kind of activation layer, which is built on top of your customer profile store that's like Data Cloud. And those patterns aren't really changing. Those patterns I think are present not only at companies that I've worked for before, but it's also the core product that Salesforce sells. And now they're talking about, "Okay, congratulations. If you've been using Salesforce and using it properly and stuck with us over this period of time, this thing called AgentForce now gives you the opportunity to kind of agentify not only your workflows, but also get agentic based insights into your data."
John Furrier
>> I think that's easier. Playing with data as a value proposition is not what end users sign up to do.
Tristan Baker
>> Not usually.
John Furrier
>> So if you can eliminate the toil of data entry and eliminate the hassle of getting at the data and doing the reports, that's the holy grail. And I love the Slack integration into Salesforce.
Tristan Baker
>> Oh, it's amazing.
John Furrier
>> Another talk about neural network opportunity to build the company brain you could shatter.
Tristan Baker
>> Yeah. That's the layer of consumption or the layer of engagement is what Slack is described as. And we practice what we preach as well. Like I said, I've only been there for two months, but
John Furrier
>> Well, as senior director, head of data architecture, you are at the right place to get your hands on the keys to the kingdom.
Tristan Baker
>> Yeah, certainly.
John Furrier
>> I mean, there's so much to master. It's such a great domain of opportunity.
Tristan Baker
>> Yep. Absolutely.
John Furrier
>> Thanks for coming on theCUBE. Appreciate it.
Tristan Baker
>> Thank you very much, John.
John Furrier
>> What do you think about the event here so far?
Tristan Baker
>> Oh, it's been great. I was able to attend half of it. Unfortunately, not all of it, but I was in a panel just before this answering some of the same questions that you were asking me. So what you're asking me is certainly relevant-
John Furrier
>> Okay, good.
Tristan Baker
>> ... because there's 200 people out there that were asking versions of the same question.
John Furrier
>> The whole world wants to know. I mean, I think this is going to be very popular. I love the graphics. We have a real critical piece in the data stack with AI as well as the system intelligence system. That's the data operating system emerging. There's no doubt about it. And I hope to catch up with you at Dreamforce a couple of weeks.
Tristan Baker
>> Yeah, I'll be there.
John Furrier
>> So good to see you.
Tristan Baker
>> It's right down the street.
John Furrier
>> Yeah, course we'll be there. Thanks for coming on.
Tristan Baker
>> Thank you very much.
John Furrier
>> All right, cool. I'm John Furrier theCUBE. We are here at the Neo4j. This is GraphTalk. It's soon to be a podcast because it sounds like a great podcasting thing, but it's also an event here in San Francisco. The leaders get together, of course, in New York City in September. I'll be there as well with theCUBE. Thanks for watching.
John Furrier
