theCUBE + NYSE Wired: Data + AI: Turning Data Into Knowledge for Autonomous Systems | James Kaplan, McKinsey | theCUBE + NYSE Wired: AI Luminaries with Neo4j

Clips
More from theCUBE + NYSE Wired: Data + AI: Turning Data Into Knowledge for Autonomous Systems

James Kaplan

Distinguished Partner

McKinsey & Company

play_circle_outline AI-Powered Business Transformation with Programmatic Rules and Graphs to Reduce Entropy

play_circle_outline Graphs as context providers for large language models

play_circle_outline Federated Graphs for Unstructured Data: EcliptOS Lessons, Node-Level Encryption, Provenance, B2B CX Productivity

play_circle_outline Knowledge Graphs and Hybrid Infrastructure Powering Agent Fleets for Governed, Secure, Cost‑Efficient Enterprise AI

play_circle_outline Citizen developers and risks of low-code 'vibe coding'

play_circle_outline Importance of understanding model and system internals

play_circle_outline Context engineering (vs. prompt engineering) for model inputs

Info

James Kaplan, McKinsey | theCUBE + NYSE Wired: AI Luminaries with Neo4j

James Kaplan

Distinguished Partner McKinsey & Company

search

(INTRO)

John Furrier

>> I'm John Furrier, host of theCUBE, here at theCUBE's NYSE studio. Of course, we have our Palo Alto studio connecting Silicon Valley to Wall Street as the AI conversation continues. We're going to do more and more content exploring the leaders. This is our Neo4j Luminary series. We feature the leaders who are doing the most progressive work on the frontier of AI around data, databases, knowledge graphs. As we move into a world of intelligence, the role of data and how it's structured will be a big thing. James Kaplan, distinguished partner at McKinsey, is here with me. James, great to have you on theCUBE. Pleasure to be here. Many, many years at McKinsey, you've seen many waves of innovation. Yes. You've probably worked on many transformation projects. as McKinsey does. I terrify McKinsey associates by telling them I remember the days of fax machines and dial -up modems. and they ask me, what's a fax machine? What's a fax machine? I can't even. How do you describe it? Yeah, exactly. we've seen a lot of waves. we were just talking before we came on camera. IT transformation has been a big thing. Yep. New business model changes. McKinsey's been involved, advised many companies. But we are kind of living in both a technology and business model transformation. And AI is at the center of it. And you're starting to see, the old school network storage and compute, to add another pillar to that, data, databases. Yes. So you start to see the computer industry start to normalize around new forms of data organization, the knowledge graph. Neo4j obviously makes a graph database, but more platform -oriented, you start to see the architecture shift. What's your view on this? Because we're in a massive transformation. It's got revenue associated with it. AI is now seeing revenue visibility. Yep. Whole new ballgame.

James Kaplan

>> Let me explain why I think this time is a little bit different. Because, as I said, I've seen multiple waves of innovation. They're all great and they're all important. But I think it's easy to, I've seen also multiple generations of people getting caught up in the hype. And you say, gee, it's not that different. Here's why I think this is different. So, you mentioned network and storage and what have you. Over the past 25 years, 30 years, we've seen a massive increase in the productivity of and a reduction in the unit cost of infrastructure. It used to be we ran applications on $50 ,000 servers. Now the same application would be running just on a slice of a $5,000 server or on a cloud server someplace at much lower cost. We have not seen a commensurate decrease in the unit cost of IT functionality, application functionality. And for many institutions, that's a brake. Not on their technology strategy, but on their business strategy and their business model. You could only do so much, you could only automate so much, you could only analyze so much because of the cost of implementation. implementation.

John Furrier

>> And if you look at the agent role, when you start to see economics, where you say one user could have a fleet of agents or productivity gains coming out. it's like AI is a whole other user experience. I remember when virtual desktops came out, no one was crying a river when they went home. I missed my virtual desktop. virtualization was a very important trend. But AI, people want it so bad. They're using it. It's kind of impacting them.

James Kaplan

>> Here's what's different, or here's what I think of the core of what's different. And it's not even the fact that something's an agent. I joke probably somewhat oversimply that the cruise control in your car is an agent. What's different is for the first time, we can programmatically reduce what I sometimes call business entropy or what you might call complexity. Now, I've been deep up to my neck in complicated IT transformations and systems projects for 25 years. Why are they always frustrating? Why are they always expensive? And why do they often create unsatisfying user experiences? Well, they have incredibly messy, opaque, ambiguous, uncorrelated, unstructured data that you have to sort through. If you want to analyze data, you need to structure it or correlate it across multiple data sets. And then second, you have all these messy, complicated, interconnected business rules. Now, to address either of those things, you needed to have a business analyst or a software engineer or a data scientist or data engineer go through them by hand historically. That was time consuming, expensive, and imperfect. Now, for the first time, we have the ability to interrogate complicated processes and create deterministic business rules programmatically. and we have the capability to interrogate messy, uncorrelated, unstructured data and turn it into structured data, often storing it in a graph. And that opens up whole new frontiers. That means you can do things with systems that would have been very hard or very expensive even a couple of years ago.

John Furrier

>> Let's double -click on that because I think this is the Luminaries series' whole goal is that the graph database, which is not that complicated to understand what a graph database is. But what it does in that architecture, because you're starting to see, obviously we've seen this in the cloud. it's not the one database rules the world, like the Oracle. You saw DynamoDB emerge in the cloud. Now you have time series. There's a zillion different databases for the right thing. But the graph lays down an interesting construct. Why is it so popular with the top practitioners now? Because we're seeing evidence that when they plug this in, problems get solved. I saw a practitioner, he's like, man, I put this in and solved all my problems. I was banging my head for three weeks on this problem. What's the main reason? Why is it working so well in the AI era? Let me maybe say a couple of things.

James Kaplan

>> The first of which, here's how I explain it to people. Sometimes people ask why you talk about graphs, right?

John Furrier

>> Okay, explain that to me like I'm five.

James Kaplan

>> Yeah, I say two things. First of which is you're a graph user. If you're using LinkedIn, if you're using Wikipedia, if you're using any social media, that's a graph, right? So I would say many of the social media companies have arrived at this and the power of this technology before the enterprise did. Second, I'd say for most business users or most executives, if you ask them to draw a data model on a whiteboard, they would draw a graph. They would say, oh, here's a circle with customers. Here's a circle with products. And customers buy products. And it's literally they're drawing a graph on the page. So it's much more intuitive than a relational database. So that's the first thing I say. The second thing I point out is, okay, we're all used to massive relational databases, which are wonderful if you're processing transactional data and are much less good at ambiguous or complicated data. The third thing I tend to say is, okay, how would you describe James Kaplan? You would say he lives in New York. He works at McKinsey. He's married to Amy. He is interested in knowledge graphs. None of those things are intrinsic. They're all relationships. So just as you want to describe a customer or a product in the context of, or just as you're describing me in the context of relationships I have with other people or other things. It's incredibly insightful to describe a customer or a product or a process or a step in the process in the context of its relationship to other things. That's incredibly powerful, which brings us to the fourth thing. Graphs are wonderful food for large language models and wonderful ways to store the output of large language models. large language models.

John Furrier

>> Are magic.Explain that because this is where I think the computer science intersects with the graphs because they recurse through they have tensor they have reasoning multiple steps. Yeah, they can. Okay, so a couple.

James Kaplan

>> Of things here.First of which is a large language model, but it's not a person. It's a machine right? It's a statistical model. It takes input. It gives you output. Like any model the better the input you give it the better the output you get. And the nice thing about a graph is it provides structure which forces the model to infer less which reduces token costs. It changes it changes the pre -fill and decode significantly exactly so and increases the reliability of your analysis in many cases the flexibility of your analysis and then it's a fantastic way of storing the results in a very structured way so you can then turn around and enter it into the next stage in your.

John Furrier

>> So you agree it's very compatible with the AI infrastructure?

James Kaplan

>> I would say it's not AI. It's knowledge graphs plus AI. I think the world has started to realize. You hear about context engineering and graph engineering and what have you. What you put into the model is existential. substantial, right? And that is the source of, and what you store from the model is the source of differentiation. Everybody has access to the same frontier models. What matters is how you structure what you put into.

John Furrier

>> The models.As I say, feed the beast. And then let's get into that context because this is where I think graphs shine. So, okay, you have relations, but I would also say that we've heard on these interviews and it's pretty obvious in the graph world that you can put unstructured data in there, too, like Slack messages, like emails that have more context.Well.

James Kaplan

>> Let me push that a little bit. Okay, so you have a bunch of Slack messages, emails, and this is just a mess. Yeah, yeah, yeah. Right? And to use the technical term. Yeah, yeah. What I would suggest is you can interrogate that information to put it into a graph. I said this to you about that topic. Yes. and what I said is a proposition that somebody else disagreed with. And I know that that person disagreed with it. My God, now we have a graph. Yes. And that's a really interesting graph and we can do a much better job of reasoning over that graph than just reasoning over projects.

John Furrier

>> Let's take that one step further. You mentioned earlier your name. You work at McKinsey. You live in New York. You're working on these four projects. You're having these email conversations, these Slack messages about this project, that project, and that project. that all goes into the graph. That is now available for the reasoning and the intelligence of the model. That's what you're saying.

James Kaplan

>> It's available for the reasoning and intelligence of the model. You can interrogate provenance. You can enforce what the model has access to under some circumstances versus not. In some cases, what project I'm working on may be very secret. So you can say, okay, gee, this, we can add metadata to it. But for some graphs, you can encrypt individually. You can do node-level encryption. Say, okay, gee, only for these use cases is this information available. To the model.

John Furrier

>> Yeah, and that's why the social media comment you made earlier is a very important one. LinkedIn, everyone uses it. It's a network effect. You have a set of followers. You're a node, you're in the graph, and you can have graphs of graphs. But you can have your followers, and you can even dissect that further. How many people are technical?Well, yeah.

James Kaplan

>> And it's compounding because it's not that I know a ton about neuroscience, but the more interconnections, you build neurons that interconnect things, right? And so the richer the interconnections among nodes, the more intelligence you have in the graph and the more things you can determine. So, for example, I built a model that interrogates a set of business domains for the level of entropy to figure out, OK, gee, how tractable would this be for AI enabled productivity improvement? It puts all the results in a graph and sort of does some analysis to figure out, OK, where's the higher productivity versus lower productivity? What's the levers? What have you? When a client asks me, it's like, okay, that's really interesting, James. But what I really care about is improving the customer experience. So customer experience is more important to me than productivity. What does that tell me? I'm like, oh, but I had stored all every, you know, sort of piece of friction related with entropy in the graph, linked to every subdomain, linked to every productively enabling AI improvement, then I can say, all right, it was very easy to create a prompt to say, all right, what if I pointed these AI improvements at customer experience rather than productivity? What does that tell me? I was able to get a fairly credible answer. That's like left brain, right brain kind of thing. You just switched your orientation to use the brain metaphor. Yeah. Yeah. And the dense connections among nodes and the fact that not everything was it, but many things were connected to other things that provided context around each node that made for more sophisticated, allowed more sophisticated analysis.

John Furrier

>> Basic data structures in computer science curriculum is nodes and arcs. Yeah. They can measure those as weights. it's very important to have these connections. All right. Let's take it to reality now. As you look at things you worked on personally, as well as the market, your customers that you advise, how are people deploying this? Because most people that I talk to get confused. Oh, GraphData, I don't want to replace this other thing. They think it's replacing that other thing. So pre-existing data sets, data lakes. I might have a bunch of Databricks. I might have a bunch of Snowflake. I got my Oracle over there. I got my IBM mainframe doing the banking transactions. What do I do with a graph? Where does it plug in?

James Kaplan

>> So it's interesting. I was involved, very deeply involved with the conception of EcliptOS, which is McKinsey's next generation agentic and knowledge graph platform, among other things. And originally we thought okay we're going to take all the data. We're going to throw it in the graph and the answer is going. To be in there somewhere. And that turned out to be not right for a number of reasons. A was incredibly expensive. And B, you created issues where you had multiple sources of data that you had to reconcile. And there were concerns about okay gee you may not want to put everything into the graph. So what we in effect created was a graph of databases. And one of the nice things about graphs is they have more flexible data schemas than, for example, relational databases. So it's easier to create a virtual graph that connects many databases. And that to me is one of, it's an incredibly powerful. So not a lot of data movement going on. It depends. Unless it needs to. Yeah, it depends. I would certainly say one use case has been, a virtual graph which connects many databases of many different types.

John Furrier

>> Do you see that virtual graph having more impact down the road? Because, virtualizing data, it's not really the right word, but what's the right word for that?

James Kaplan

>> I mean, it's, I would call it federating. More like, listen, every big institution has 30 years worth of data, some of which is structured, some of which is unstructured, or more years of data. in name your legacy databases and all of them have different schema and what have you. And the data lakes data warehouses data lake houses what have you key value pairs whatever. And no one wants to. No I would never suggest that we do the data migration effort. And all data migration everyone runs for the hills. Yeah, yes. It's like, come on! No way! But it's sort of interesting. A couple of things are true now. One, AI gives us the ability to interrogate and correlate data much more easily than we could previously. It used to be if you want to correlate different data sets, it was sort of peering at the field names and then doing a download and actually looking at the individual data. Having a data scientist look at individual records, which is a mess. Now we can start to use gen AI to correlate different data sets and figure out how to bring those things together. But bringing those things together does not mean dumping them all into a single database. We can use a graph as a translation.

John Furrier

>> one of the themes coming out of these conversations is that there's practitioners that have a breakthrough with graphs. Then something happens, like magic, like they get promoted or they bring it to, look what I just did. I just solved this problem we've been trying to crack the code on for a long time. what experiences have you seen that have jumped out at you? That's jumped off the page like oh my god i didn't think we'd be able to do that. What are some areas that people should poke around in? I guess what i'm trying to get to is where do you see the action? Howdo someone get some magic going pretty quickly?

James Kaplan

>> I think about the world i would say the world of domains is a continuum of problems you might address with technology is a continuum. At one end, you have fairly structured transactional problems. Now, I would use consumer credit card origination as a problem, as an example. Excuse me. And I would say most people log on to a credit card company's website, and two days later or three days later, the credit card arrives in the mail. Why is this? Because with, I don't know, 20 data points, you can figure out what credit card you want. There's two or three card holders in your household. Transactions are atomic right? It is transactional data. I'm sure someone's gonna point out there's 50 things i'm not describing about credit. But at the high level it's a relatively understandable domain. And I personally know of fewer consumer credit card systems projects that have blown up in recent years. At the other end, you have anything that's B2B where, in effect, your customer base is a graph, right? Because if someone's buying databases, advertising services, anything, right? There's going to be a range of people involved in the decision at a client or customer, a range of people involved in the relationship. In many cases, your product stack is much more complicated than service offering number two from the credit card company. And all of those, I would say, are phenomenal use cases for AI because you can handle the quote unquote business entropy and phenomenal use cases for graphs because it can store that ambiguous relationship intensive data. And yes, there's a certain irony that the graphs are better than relational databases at managing certain types of relationships among data elements.

John Furrier

>> The platform era has been on us for a while. We saw the cloud. What's the biggest change with AI in the enterprise? Because you're starting to see the rise of the neoclouds as service layers are emerging. I can have on-premise, a small rack, big rack. I don't have to have the millions of dollars of NVIDIA NVL72s unless I need it. So you have this hybrid computing environment and all this data. Agents are hot. A lot of security challenges. Graphs seem to be a great solution in making the enterprise more successful with AI. Also with AI security, I would note. How does an organization inject intelligence? And how do graphs help that effort?

James Kaplan

>> Well, a couple of thoughts. One, I see relatively few organizations building out their own model infrastructure because they've got a lot to figure out now at the agent layer and at the data layer rather than at the inferencing model layer. So, you want to husband your technology resources. here's the way I see organizations at least starting to act, which is, one, figure out what I might call the upper ontology. What's sort of the set of primitives that you need to think about: customers, products, processes that work across many domains, right? Second, figure out a few domains where you can transform the domain. I'm intentionally saying domain rather than use case because you worry about sub-optimizing if you just focus on a narrow use case. You want to rethink a domain. You think about, okay, what's the ontology for that specific domain that connects to your upper ontology? You figure out how to hydrate that into a graph, and you figure out what the agents are that will interact with that graph. And then finally, in most cases, and I think this is quite an encouraging thing, I see people building platforms because they realize that without an AI platform, they will not get the security, the transparency, the resilience, and the cost efficiency they need as they start to deploy agents or AI at scale in the enterprise.

John Furrier

>> And that makes sense. Security built in, governance, very important features. Yeah. I wish we had more time to go into it, but we talked about context. Graphs are great. Context brings up another issue that's coming out of the graph discussion, because it's not really graphs, but it's where the graphs are playing. They're playing in AI infrastructure. They're sitting on top of all the horsepower coming out. The word sovereignty has been kicked around. I'm smiling because it's been bastardized 10 ways from Sunday, because sovereignty used to be GDPR. This country keeps their data in there. Now you've got sovereignty around AI revenue. Oh, I'm in France. I'll keep my GPUs in France, clusters in France. Okay, we'll keep everything there. It's got boundaries. But now enterprises are starting to use the word sovereignty for their business. Yes. So you brought up domains. Yes. How do you view sovereignty? Because I would imagine graphs would probably be a great feature because you have such context. You can say this context belongs there. Yeah. So sovereignty is an infrastructure challenge right now.

James Kaplan

>> Yeah. Yeah, sometimes the expression I use with people is your business is a graph. It's customers, it's products, it's process steps, it's locations, it's jurisdictions. Jurisdictions have regulations, what have you. So, if you do that, then you can start to create, again, connections, edges between elements in your graph and relevant, for example, regulations to sort of allow you to figure out which data has to stay where. And that might be a question of which country, but also might be a question of what's inside versus outside the four walls of the institution. Because obviously everyone's spending a lot of time thinking about which data do we need to own and control and which data is less important to own and control. The control piece is huge.

John Furrier

>> For sovereignty.All right, what's the coolest thing you've seen with graphs? Let me throw it out there. Could be what you've done, McKinsey's done, you've seen in the industry. I would say the coolest thing.

James Kaplan

>> Yeah, the thing is it's easier to do things yourself than would have been the case a year ago. So the shadow AI. I prefer to say citizen developers. And this, by the way. The two things I'll note there is platforms. Once you start to think about citizen developers, platforms become existential. Consistential now the tough thing is I really don't like the term vibe coding because it is really easy to hurt yourself. Yeah. Yeah, right And how do you create the understanding of computer science principles and data models among your citizen developers? So if they do more than oh, let me throw up a report. Yeah, they won't create, you knowthe right value.

John Furrier

>> Yeah. They could mis-, they might misunderstand exactly. Well it's very easy to create something thatmisinterprets data for example.

James Kaplan

>> Or creates a lot of complexity in data that makes it you know that adds to the you know adds to you could say technical debt. Or you could just say crud. Yeah. In the organization there's two things I've worked on personally that I'm really excited about, one bigger, one more amusing. The first is the model I was describing to you, where I take a business domain map, model it as a graph, and use that to interrogate which subdomains are higher and lower entropy, and therefore more versus less tractable, to AI-based digitization and AI-based analytics, and to identify a fairly tangible set of micro-level things you could do that you can aggregate up into initiatives. So that's very exciting. Maybe the more amusing example is every six months I get together about 50, 60 senior technology executives from big institutions. And traditionally, managing the administration of that was about the world's biggest pain in the neck. Yeah, it's like coaching Little League or managing some meet-up group. The invites and the list and what have you. Cut and paste, swivel chair. One of the worst gigs at McKinsey was owning the TLF spreadsheet. And there was always some poor associate who got dragooned into owning the spreadsheet. Which was, I think, negative third normal form. It had 20 tabs and was negative third normal form. Apologies for the geeky database joke. But I took the spreadsheet. I sucked it all into a graph. so now every member is in the graph every invitee is in the graph every McKinsey person who's the point of contact for a member is in the graph so it's now much easier to track who's coming who's not coming send all the invites right personalize the invites and this is one of the exciting things is although it sounds somewhat prosaic that I track all the sessions all the rooms and all the time slots so we could generate this complicated agenda with one command. And because I believe in composable documents, it now creates the entire Facebook.

John Furrier

>> Plenary session, keynotes.

James Kaplan

>> Exactly. He worked his butt off on this one. Well, it's funny. I was having lunch with one of the associates who'd gone on to the wealth management industry, but who was responsible for building, It's called the grid, which is the agenda. And I mentioned I had automated the grid. And the look of just terror remembering his building of the grid was very amusing to me. So I just wanted to emphasize when you put AI and graphs together, the ability to take unpleasant toil and scut work out of a process is probably an underappreciated thing.

John Furrier

>> And there was probably an unwritten rule in McKinsey, too. I can imagine the people who did that job, however long the duration, they would get a pat on the back, grinding it out. But, okay, let's talk about the reality of the new normal. Okay, that job is going to be automated away. What is that next grind? Because a lot of people's careers, they learn a lot. They learn a lot from those experiences of grinding. What's the new version of that associate work? Is it prompting? Is it like curating data sets, managing fleets of agents?

James Kaplan

>> Here's my view on that. I actually think we're romanticizing scut work, right? I don't know how much I appreciated the fact that the associates helped me manage this crazy spreadsheet. I'm not sure how much they learned doing it. It was really pretty mechanical. So now the associates working with me on this thing, they're working with me on, okay, let's think about what sessions we want to have and what should be the content of each session. Let's think about who are the people we didn't invite and what would be the ways to invite them.

John Furrier

>> So you're saying it's a get-off-my-lawn kind of moment, because most people that talk about it have already been successful. I used to walk to school barefoot in the snow. that's what you're kind of getting at here. It's kind of overblown a little bit.

James Kaplan

>> Yeah, well, I don't think it's. I would put it this. I put it two ways. One is there's a tremendous opportunity for early tenure people to learn more because there's less of the scut work they need to do. That's the first thing. Now, there's things that aren't scut work, which is really understanding the model and really understanding the analysis. And it's very easy to say, oh, I type, here's what the model told me. but I think it places a degree of onus on early tenured people to ask the other question and say, okay, how do I really sanity check the output that I'm getting?

John Furrier

>> Yeah, James, that's a great insight. I want to just double amplify that because here's what I see. Because I think in all these transitions, whether it's PC revolution, the rise of client-server, or SaaS, the people that were successful understood the internals of things. Absolutely. Absolutely. Absolutely. I remember I was a young kid working at Hewlett-Packard. It's like, oh, my God, John, you're like a young kid. We need someone to do the DOS internals. I'm like, what's DOS internals? Okay. I'll do it.

James Kaplan

>> And lots of people made careers out of understanding what was going on, whether it was understanding how to do a CONFIG.SYS and an AUTOEXEC.BAT. Yeah.

John Furrier

>> AUTOEXEC.BAT, right? Right.

James Kaplan

>> Or what the mechanics of that stuff is valuable. Pushing, pushing a box around a slide, not valuable, but understanding the mechanics of an analysis, no matter where it happens to be, is both instrumentally valuable and pedagogically valuable.

John Furrier

>> And I think that's advice I've given to my own kids and others that were young, because if you look at AI infrastructure, the data graphs, we're talking about robotics agents. If you know how the models work at a root level, if you know the internals of whatever system you're interfaced with, whether it's models or NVIDIA's KV cache and how networking works or robotics embedded systems, you'll do well. Yes. There's plenty of growth. Absolutely. This isn't just leaning on AI for the answers.

James Kaplan

>> Yeah. Now, I will say abstraction isn't bad, and we've been going through generations of abstraction. I'm old enough to remember the huge argument they had over Lotus 1-2-3 3.0 because that was the first version they wrote in C rather than Assembler. And, BYTE Magazine had debates back and forth around. Oh, gee, would it even work? Or, who are these young kids using C when they should be using Assembler?

John Furrier

>> Yeah, it was a religious debate.

James Kaplan

>> debate we've had generations of abstraction. Yeah right as we advance technology. The thing I like to use is okay. A lot of us went to see The Odyssey this summer right? I certainly did. You remember to my understanding that when they first wrote the Iliad and The Odyssey the Aegean world, or when the Iliad and the Odyssey first emerged, the Aegean world had lost written language, right? So you had, Bards had to, memorize. So when people say, oh, gee, AI is going to mean, nobody's going to understand anything anymore. I'm imagining some Bards, oh, gee, this writing thing, people aren't going to have to memorize every last word of the Iliad or The Odyssey. Remember we've gone through many many generations of advances in information technology. Going back yeah to the adoption of ofwritten language.

John Furrier

>> Yeah and the Rosetta Stone of this the new era. If you look at specialized intelligence which we're seeing a lot of in the enterprise. General intelligence okay AGIs, they crawl the internet they know general things but when you get into specialism, that has become very interesting because you can have very tight models, you have a lot of context, the data isn't unlocked, it's locked down, it's gotta come out and get value.Well, I think.

James Kaplan

>> The point about context is a really good one. And often I find the places where the models aren't quite, or the output of models aren't quite right is we haven't given it all the context and we have nothing that will suck up everything that's happening nor would you want it just now right so a lot of thought needs to go into okay gee what are the things we need to tell you know if you're using a um there was um there's a great book by Hal Brands about AI and geopolitics talking about yeah um and there was one chapter talking about how strategists sort of strategists working in the military or the diplomatic community might use AI -based models to model negotiations and what have you. But imagine how much thought needs to get put into the model in order to get a good result. That's a new engineering task.

John Furrier

>> You said it earlier, feeding the beast, feeding the AI. Exactly so. That's the context.

James Kaplan

>> And you think about any business problem. Any important business has organizational aspects, operational aspects, economic aspects, cultural aspects. How do you think through all the things? And that's what we need early career people to get on the path of learning to do.

John Furrier

>> It changes the prompt engineer kind of thing into just context engineering. Which is just how do you create a data environment to get the right data at the right time? Exactly. That's feeding the math. Exactly so.

James Kaplan

>> And you think about, you know, I mean, and I'm very much of the opinion that, an agent is just a piece of software. It's not a person. But there are some echoes of interpersonal relationships. If you think about managing any early tenure person, a lot of success is figuring out what to explain to that person. Because you can't explain everything. That would take a year. And the person can't retain everything. but there's some set of things that anyone needs to know in order to do a good job on the analysis. I think Alan Kay said something along the lines of context is worth 20IQ points or 50 IQ points. And that's exactly it's true with a person.

John Furrier

>> And it's true with an agent. Well James thanks for being part of the luminary series. You are a luminary of course with all your experience, but also now that experience just becomes input into the new opportunities. Absolutely. Can I make a plug for one thing?

James Kaplan

>> Sure, absolutely. I write a blog on Substack called Prosaic Times every Sunday, except Labor Day weekend, where I talk a lot about the stuff I've been talking about here.

John Furrier

>> All right. Check out that Substack. Say it again one more time. Prosaic Times. All right. Prosaic Times.

James Kaplan

>> And the topic is? It's everything we've been discussing. AI, graphs, business strategy, technology strategy, and driving change within a big, messy organization.

John Furrier

>> I'll promote my Substack, John Furrier at Substack. Of course, SiliconANGLE.com, theCUBE.net, theCUBE Research.com. We'll endorse each other. I promise you. There we go.

James Kaplan

>> I promise you this afternoon I will put your Substack on my recommended list.

John Furrier

>> It's great to have a distinguished partner from McKinsey here. You guys do a lot of great work. I like to joke. I was angling for the title irreverent partner, but they told me that wasn't on offer. It's not on the list yet. We're working on that. I'm working on it. All right. I'm patient. This is the Luminary Series, Neo4j's Luminary Series. We explore with leaders, how they think about how they're framing their view of the innovation for the future, how data and the data structures, how it's going to evolve. Again, to maximize productivity, cost, societal benefit, all happening as we speak. We're doing our part here on theCUBE. Thanks for watching. Thank you.

James Kaplan, McKinsey | theCUBE + NYSE Wired: AI Luminaries with Neo4j

search

(INTRO)

John Furrier

>> I'm John Furrier, host of theCUBE, here at theCUBE's NYSE studio. Of course, we have our Palo Alto studio connecting Silicon Valley to Wall Street as the AI conversation continues. We're going to do more and more content exploring the leaders. This is our Neo4j Luminary series. We feature the leaders who are doing the most progressive work on the frontier of AI around data, databases, knowledge graphs. As we move into a world of intelligence, the role of data and how it's structured will be a big thing. James Kaplan, distinguished partner at McKinsey, is here with me. James, great to have you on theCUBE. Pleasure to be here. Many, many years at McKinsey, you've seen many waves of innovation. Yes. You've probably worked on many transformation projects. as McKinsey does. I terrify McKinsey associates by telling them I remember the days of fax machines and dial -up modems. and they ask me, what's a fax machine? What's a fax machine? I can't even. How do you describe it? Yeah, exactly. we've seen a lot of waves. we were just talking before we came on camera. IT transformation has been a big thing. Yep. New business model changes. McKinsey's been involved, advised many companies. But we are kind of living in both a technology and business model transformation. And AI is at the center of it. And you're starting to see, the old school network storage and compute, to add another pillar to that, data, databases. Yes. So you start to see the computer industry start to normalize around new forms of data organization, the knowledge graph. Neo4j obviously makes a graph database, but more platform -oriented, you start to see the architecture shift. What's your view on this? Because we're in a massive transformation. It's got revenue associated with it. AI is now seeing revenue visibility. Yep. Whole new ballgame.

James Kaplan

>> Let me explain why I think this time is a little bit different. Because, as I said, I've seen multiple waves of innovation. They're all great and they're all important. But I think it's easy to, I've seen also multiple generations of people getting caught up in the hype. And you say, gee, it's not that different. Here's why I think this is different. So, you mentioned network and storage and what have you. Over the past 25 years, 30 years, we've seen a massive increase in the productivity of and a reduction in the unit cost of infrastructure. It used to be we ran applications on $50 ,000 servers. Now the same application would be running just on a slice of a $5,000 server or on a cloud server someplace at much lower cost. We have not seen a commensurate decrease in the unit cost of IT functionality, application functionality. And for many institutions, that's a brake. Not on their technology strategy, but on their business strategy and their business model. You could only do so much, you could only automate so much, you could only analyze so much because of the cost of implementation. implementation.

John Furrier

>> And if you look at the agent role, when you start to see economics, where you say one user could have a fleet of agents or productivity gains coming out. it's like AI is a whole other user experience. I remember when virtual desktops came out, no one was crying a river when they went home. I missed my virtual desktop. virtualization was a very important trend. But AI, people want it so bad. They're using it. It's kind of impacting them.

James Kaplan

>> Here's what's different, or here's what I think of the core of what's different. And it's not even the fact that something's an agent. I joke probably somewhat oversimply that the cruise control in your car is an agent. What's different is for the first time, we can programmatically reduce what I sometimes call business entropy or what you might call complexity. Now, I've been deep up to my neck in complicated IT transformations and systems projects for 25 years. Why are they always frustrating? Why are they always expensive? And why do they often create unsatisfying user experiences? Well, they have incredibly messy, opaque, ambiguous, uncorrelated, unstructured data that you have to sort through. If you want to analyze data, you need to structure it or correlate it across multiple data sets. And then second, you have all these messy, complicated, interconnected business rules. Now, to address either of those things, you needed to have a business analyst or a software engineer or a data scientist or data engineer go through them by hand historically. That was time consuming, expensive, and imperfect. Now, for the first time, we have the ability to interrogate complicated processes and create deterministic business rules programmatically. and we have the capability to interrogate messy, uncorrelated, unstructured data and turn it into structured data, often storing it in a graph. And that opens up whole new frontiers. That means you can do things with systems that would have been very hard or very expensive even a couple of years ago.

John Furrier

>> Let's double -click on that because I think this is the Luminaries series' whole goal is that the graph database, which is not that complicated to understand what a graph database is. But what it does in that architecture, because you're starting to see, obviously we've seen this in the cloud. it's not the one database rules the world, like the Oracle. You saw DynamoDB emerge in the cloud. Now you have time series. There's a zillion different databases for the right thing. But the graph lays down an interesting construct. Why is it so popular with the top practitioners now? Because we're seeing evidence that when they plug this in, problems get solved. I saw a practitioner, he's like, man, I put this in and solved all my problems. I was banging my head for three weeks on this problem. What's the main reason? Why is it working so well in the AI era? Let me maybe say a couple of things.

James Kaplan

>> The first of which, here's how I explain it to people. Sometimes people ask why you talk about graphs, right?

John Furrier

>> Okay, explain that to me like I'm five.

James Kaplan

>> Yeah, I say two things. First of which is you're a graph user. If you're using LinkedIn, if you're using Wikipedia, if you're using any social media, that's a graph, right? So I would say many of the social media companies have arrived at this and the power of this technology before the enterprise did. Second, I'd say for most business users or most executives, if you ask them to draw a data model on a whiteboard, they would draw a graph. They would say, oh, here's a circle with customers. Here's a circle with products. And customers buy products. And it's literally they're drawing a graph on the page. So it's much more intuitive than a relational database. So that's the first thing I say. The second thing I point out is, okay, we're all used to massive relational databases, which are wonderful if you're processing transactional data and are much less good at ambiguous or complicated data. The third thing I tend to say is, okay, how would you describe James Kaplan? You would say he lives in New York. He works at McKinsey. He's married to Amy. He is interested in knowledge graphs. None of those things are intrinsic. They're all relationships. So just as you want to describe a customer or a product in the context of, or just as you're describing me in the context of relationships I have with other people or other things. It's incredibly insightful to describe a customer or a product or a process or a step in the process in the context of its relationship to other things. That's incredibly powerful, which brings us to the fourth thing. Graphs are wonderful food for large language models and wonderful ways to store the output of large language models. large language models.

John Furrier

>> Are magic.Explain that because this is where I think the computer science intersects with the graphs because they recurse through they have tensor they have reasoning multiple steps. Yeah, they can. Okay, so a couple.

James Kaplan

>> Of things here.First of which is a large language model, but it's not a person. It's a machine right? It's a statistical model. It takes input. It gives you output. Like any model the better the input you give it the better the output you get. And the nice thing about a graph is it provides structure which forces the model to infer less which reduces token costs. It changes it changes the pre -fill and decode significantly exactly so and increases the reliability of your analysis in many cases the flexibility of your analysis and then it's a fantastic way of storing the results in a very structured way so you can then turn around and enter it into the next stage in your.

John Furrier

>> So you agree it's very compatible with the AI infrastructure?

James Kaplan

>> I would say it's not AI. It's knowledge graphs plus AI. I think the world has started to realize. You hear about context engineering and graph engineering and what have you. What you put into the model is existential. substantial, right? And that is the source of, and what you store from the model is the source of differentiation. Everybody has access to the same frontier models. What matters is how you structure what you put into.

John Furrier

>> The models.As I say, feed the beast. And then let's get into that context because this is where I think graphs shine. So, okay, you have relations, but I would also say that we've heard on these interviews and it's pretty obvious in the graph world that you can put unstructured data in there, too, like Slack messages, like emails that have more context.Well.

James Kaplan

>> Let me push that a little bit. Okay, so you have a bunch of Slack messages, emails, and this is just a mess. Yeah, yeah, yeah. Right? And to use the technical term. Yeah, yeah. What I would suggest is you can interrogate that information to put it into a graph. I said this to you about that topic. Yes. and what I said is a proposition that somebody else disagreed with. And I know that that person disagreed with it. My God, now we have a graph. Yes. And that's a really interesting graph and we can do a much better job of reasoning over that graph than just reasoning over projects.

John Furrier

>> Let's take that one step further. You mentioned earlier your name. You work at McKinsey. You live in New York. You're working on these four projects. You're having these email conversations, these Slack messages about this project, that project, and that project. that all goes into the graph. That is now available for the reasoning and the intelligence of the model. That's what you're saying.

James Kaplan

>> It's available for the reasoning and intelligence of the model. You can interrogate provenance. You can enforce what the model has access to under some circumstances versus not. In some cases, what project I'm working on may be very secret. So you can say, okay, gee, this, we can add metadata to it. But for some graphs, you can encrypt individually. You can do node-level encryption. Say, okay, gee, only for these use cases is this information available. To the model.

John Furrier

>> Yeah, and that's why the social media comment you made earlier is a very important one. LinkedIn, everyone uses it. It's a network effect. You have a set of followers. You're a node, you're in the graph, and you can have graphs of graphs. But you can have your followers, and you can even dissect that further. How many people are technical?Well, yeah.

James Kaplan

>> And it's compounding because it's not that I know a ton about neuroscience, but the more interconnections, you build neurons that interconnect things, right? And so the richer the interconnections among nodes, the more intelligence you have in the graph and the more things you can determine. So, for example, I built a model that interrogates a set of business domains for the level of entropy to figure out, OK, gee, how tractable would this be for AI enabled productivity improvement? It puts all the results in a graph and sort of does some analysis to figure out, OK, where's the higher productivity versus lower productivity? What's the levers? What have you? When a client asks me, it's like, okay, that's really interesting, James. But what I really care about is improving the customer experience. So customer experience is more important to me than productivity. What does that tell me? I'm like, oh, but I had stored all every, you know, sort of piece of friction related with entropy in the graph, linked to every subdomain, linked to every productively enabling AI improvement, then I can say, all right, it was very easy to create a prompt to say, all right, what if I pointed these AI improvements at customer experience rather than productivity? What does that tell me? I was able to get a fairly credible answer. That's like left brain, right brain kind of thing. You just switched your orientation to use the brain metaphor. Yeah. Yeah. And the dense connections among nodes and the fact that not everything was it, but many things were connected to other things that provided context around each node that made for more sophisticated, allowed more sophisticated analysis.

John Furrier

>> Basic data structures in computer science curriculum is nodes and arcs. Yeah. They can measure those as weights. it's very important to have these connections. All right. Let's take it to reality now. As you look at things you worked on personally, as well as the market, your customers that you advise, how are people deploying this? Because most people that I talk to get confused. Oh, GraphData, I don't want to replace this other thing. They think it's replacing that other thing. So pre-existing data sets, data lakes. I might have a bunch of Databricks. I might have a bunch of Snowflake. I got my Oracle over there. I got my IBM mainframe doing the banking transactions. What do I do with a graph? Where does it plug in?

James Kaplan

>> So it's interesting. I was involved, very deeply involved with the conception of EcliptOS, which is McKinsey's next generation agentic and knowledge graph platform, among other things. And originally we thought okay we're going to take all the data. We're going to throw it in the graph and the answer is going. To be in there somewhere. And that turned out to be not right for a number of reasons. A was incredibly expensive. And B, you created issues where you had multiple sources of data that you had to reconcile. And there were concerns about okay gee you may not want to put everything into the graph. So what we in effect created was a graph of databases. And one of the nice things about graphs is they have more flexible data schemas than, for example, relational databases. So it's easier to create a virtual graph that connects many databases. And that to me is one of, it's an incredibly powerful. So not a lot of data movement going on. It depends. Unless it needs to. Yeah, it depends. I would certainly say one use case has been, a virtual graph which connects many databases of many different types.

John Furrier

>> Do you see that virtual graph having more impact down the road? Because, virtualizing data, it's not really the right word, but what's the right word for that?

James Kaplan

>> I mean, it's, I would call it federating. More like, listen, every big institution has 30 years worth of data, some of which is structured, some of which is unstructured, or more years of data. in name your legacy databases and all of them have different schema and what have you. And the data lakes data warehouses data lake houses what have you key value pairs whatever. And no one wants to. No I would never suggest that we do the data migration effort. And all data migration everyone runs for the hills. Yeah, yes. It's like, come on! No way! But it's sort of interesting. A couple of things are true now. One, AI gives us the ability to interrogate and correlate data much more easily than we could previously. It used to be if you want to correlate different data sets, it was sort of peering at the field names and then doing a download and actually looking at the individual data. Having a data scientist look at individual records, which is a mess. Now we can start to use gen AI to correlate different data sets and figure out how to bring those things together. But bringing those things together does not mean dumping them all into a single database. We can use a graph as a translation.

John Furrier

>> one of the themes coming out of these conversations is that there's practitioners that have a breakthrough with graphs. Then something happens, like magic, like they get promoted or they bring it to, look what I just did. I just solved this problem we've been trying to crack the code on for a long time. what experiences have you seen that have jumped out at you? That's jumped off the page like oh my god i didn't think we'd be able to do that. What are some areas that people should poke around in? I guess what i'm trying to get to is where do you see the action? Howdo someone get some magic going pretty quickly?

James Kaplan

>> I think about the world i would say the world of domains is a continuum of problems you might address with technology is a continuum. At one end, you have fairly structured transactional problems. Now, I would use consumer credit card origination as a problem, as an example. Excuse me. And I would say most people log on to a credit card company's website, and two days later or three days later, the credit card arrives in the mail. Why is this? Because with, I don't know, 20 data points, you can figure out what credit card you want. There's two or three card holders in your household. Transactions are atomic right? It is transactional data. I'm sure someone's gonna point out there's 50 things i'm not describing about credit. But at the high level it's a relatively understandable domain. And I personally know of fewer consumer credit card systems projects that have blown up in recent years. At the other end, you have anything that's B2B where, in effect, your customer base is a graph, right? Because if someone's buying databases, advertising services, anything, right? There's going to be a range of people involved in the decision at a client or customer, a range of people involved in the relationship. In many cases, your product stack is much more complicated than service offering number two from the credit card company. And all of those, I would say, are phenomenal use cases for AI because you can handle the quote unquote business entropy and phenomenal use cases for graphs because it can store that ambiguous relationship intensive data. And yes, there's a certain irony that the graphs are better than relational databases at managing certain types of relationships among data elements.

John Furrier

>> The platform era has been on us for a while. We saw the cloud. What's the biggest change with AI in the enterprise? Because you're starting to see the rise of the neoclouds as service layers are emerging. I can have on-premise, a small rack, big rack. I don't have to have the millions of dollars of NVIDIA NVL72s unless I need it. So you have this hybrid computing environment and all this data. Agents are hot. A lot of security challenges. Graphs seem to be a great solution in making the enterprise more successful with AI. Also with AI security, I would note. How does an organization inject intelligence? And how do graphs help that effort?

James Kaplan

>> Well, a couple of thoughts. One, I see relatively few organizations building out their own model infrastructure because they've got a lot to figure out now at the agent layer and at the data layer rather than at the inferencing model layer. So, you want to husband your technology resources. here's the way I see organizations at least starting to act, which is, one, figure out what I might call the upper ontology. What's sort of the set of primitives that you need to think about: customers, products, processes that work across many domains, right? Second, figure out a few domains where you can transform the domain. I'm intentionally saying domain rather than use case because you worry about sub-optimizing if you just focus on a narrow use case. You want to rethink a domain. You think about, okay, what's the ontology for that specific domain that connects to your upper ontology? You figure out how to hydrate that into a graph, and you figure out what the agents are that will interact with that graph. And then finally, in most cases, and I think this is quite an encouraging thing, I see people building platforms because they realize that without an AI platform, they will not get the security, the transparency, the resilience, and the cost efficiency they need as they start to deploy agents or AI at scale in the enterprise.

John Furrier

>> And that makes sense. Security built in, governance, very important features. Yeah. I wish we had more time to go into it, but we talked about context. Graphs are great. Context brings up another issue that's coming out of the graph discussion, because it's not really graphs, but it's where the graphs are playing. They're playing in AI infrastructure. They're sitting on top of all the horsepower coming out. The word sovereignty has been kicked around. I'm smiling because it's been bastardized 10 ways from Sunday, because sovereignty used to be GDPR. This country keeps their data in there. Now you've got sovereignty around AI revenue. Oh, I'm in France. I'll keep my GPUs in France, clusters in France. Okay, we'll keep everything there. It's got boundaries. But now enterprises are starting to use the word sovereignty for their business. Yes. So you brought up domains. Yes. How do you view sovereignty? Because I would imagine graphs would probably be a great feature because you have such context. You can say this context belongs there. Yeah. So sovereignty is an infrastructure challenge right now.

James Kaplan

>> Yeah. Yeah, sometimes the expression I use with people is your business is a graph. It's customers, it's products, it's process steps, it's locations, it's jurisdictions. Jurisdictions have regulations, what have you. So, if you do that, then you can start to create, again, connections, edges between elements in your graph and relevant, for example, regulations to sort of allow you to figure out which data has to stay where. And that might be a question of which country, but also might be a question of what's inside versus outside the four walls of the institution. Because obviously everyone's spending a lot of time thinking about which data do we need to own and control and which data is less important to own and control. The control piece is huge.

John Furrier

>> For sovereignty.All right, what's the coolest thing you've seen with graphs? Let me throw it out there. Could be what you've done, McKinsey's done, you've seen in the industry. I would say the coolest thing.

James Kaplan

>> Yeah, the thing is it's easier to do things yourself than would have been the case a year ago. So the shadow AI. I prefer to say citizen developers. And this, by the way. The two things I'll note there is platforms. Once you start to think about citizen developers, platforms become existential. Consistential now the tough thing is I really don't like the term vibe coding because it is really easy to hurt yourself. Yeah. Yeah, right And how do you create the understanding of computer science principles and data models among your citizen developers? So if they do more than oh, let me throw up a report. Yeah, they won't create, you knowthe right value.

John Furrier

>> Yeah. They could mis-, they might misunderstand exactly. Well it's very easy to create something thatmisinterprets data for example.

James Kaplan

>> Or creates a lot of complexity in data that makes it you know that adds to the you know adds to you could say technical debt. Or you could just say crud. Yeah. In the organization there's two things I've worked on personally that I'm really excited about, one bigger, one more amusing. The first is the model I was describing to you, where I take a business domain map, model it as a graph, and use that to interrogate which subdomains are higher and lower entropy, and therefore more versus less tractable, to AI-based digitization and AI-based analytics, and to identify a fairly tangible set of micro-level things you could do that you can aggregate up into initiatives. So that's very exciting. Maybe the more amusing example is every six months I get together about 50, 60 senior technology executives from big institutions. And traditionally, managing the administration of that was about the world's biggest pain in the neck. Yeah, it's like coaching Little League or managing some meet-up group. The invites and the list and what have you. Cut and paste, swivel chair. One of the worst gigs at McKinsey was owning the TLF spreadsheet. And there was always some poor associate who got dragooned into owning the spreadsheet. Which was, I think, negative third normal form. It had 20 tabs and was negative third normal form. Apologies for the geeky database joke. But I took the spreadsheet. I sucked it all into a graph. so now every member is in the graph every invitee is in the graph every McKinsey person who's the point of contact for a member is in the graph so it's now much easier to track who's coming who's not coming send all the invites right personalize the invites and this is one of the exciting things is although it sounds somewhat prosaic that I track all the sessions all the rooms and all the time slots so we could generate this complicated agenda with one command. And because I believe in composable documents, it now creates the entire Facebook.

John Furrier

>> Plenary session, keynotes.

James Kaplan

>> Exactly. He worked his butt off on this one. Well, it's funny. I was having lunch with one of the associates who'd gone on to the wealth management industry, but who was responsible for building, It's called the grid, which is the agenda. And I mentioned I had automated the grid. And the look of just terror remembering his building of the grid was very amusing to me. So I just wanted to emphasize when you put AI and graphs together, the ability to take unpleasant toil and scut work out of a process is probably an underappreciated thing.

John Furrier

>> And there was probably an unwritten rule in McKinsey, too. I can imagine the people who did that job, however long the duration, they would get a pat on the back, grinding it out. But, okay, let's talk about the reality of the new normal. Okay, that job is going to be automated away. What is that next grind? Because a lot of people's careers, they learn a lot. They learn a lot from those experiences of grinding. What's the new version of that associate work? Is it prompting? Is it like curating data sets, managing fleets of agents?

James Kaplan

>> Here's my view on that. I actually think we're romanticizing scut work, right? I don't know how much I appreciated the fact that the associates helped me manage this crazy spreadsheet. I'm not sure how much they learned doing it. It was really pretty mechanical. So now the associates working with me on this thing, they're working with me on, okay, let's think about what sessions we want to have and what should be the content of each session. Let's think about who are the people we didn't invite and what would be the ways to invite them.

John Furrier

>> So you're saying it's a get-off-my-lawn kind of moment, because most people that talk about it have already been successful. I used to walk to school barefoot in the snow. that's what you're kind of getting at here. It's kind of overblown a little bit.

James Kaplan

>> Yeah, well, I don't think it's. I would put it this. I put it two ways. One is there's a tremendous opportunity for early tenure people to learn more because there's less of the scut work they need to do. That's the first thing. Now, there's things that aren't scut work, which is really understanding the model and really understanding the analysis. And it's very easy to say, oh, I type, here's what the model told me. but I think it places a degree of onus on early tenured people to ask the other question and say, okay, how do I really sanity check the output that I'm getting?

John Furrier

>> Yeah, James, that's a great insight. I want to just double amplify that because here's what I see. Because I think in all these transitions, whether it's PC revolution, the rise of client-server, or SaaS, the people that were successful understood the internals of things. Absolutely. Absolutely. Absolutely. I remember I was a young kid working at Hewlett-Packard. It's like, oh, my God, John, you're like a young kid. We need someone to do the DOS internals. I'm like, what's DOS internals? Okay. I'll do it.

James Kaplan

>> And lots of people made careers out of understanding what was going on, whether it was understanding how to do a CONFIG.SYS and an AUTOEXEC.BAT. Yeah.

John Furrier

>> AUTOEXEC.BAT, right? Right.

James Kaplan

>> Or what the mechanics of that stuff is valuable. Pushing, pushing a box around a slide, not valuable, but understanding the mechanics of an analysis, no matter where it happens to be, is both instrumentally valuable and pedagogically valuable.

John Furrier

>> And I think that's advice I've given to my own kids and others that were young, because if you look at AI infrastructure, the data graphs, we're talking about robotics agents. If you know how the models work at a root level, if you know the internals of whatever system you're interfaced with, whether it's models or NVIDIA's KV cache and how networking works or robotics embedded systems, you'll do well. Yes. There's plenty of growth. Absolutely. This isn't just leaning on AI for the answers.

James Kaplan

>> Yeah. Now, I will say abstraction isn't bad, and we've been going through generations of abstraction. I'm old enough to remember the huge argument they had over Lotus 1-2-3 3.0 because that was the first version they wrote in C rather than Assembler. And, BYTE Magazine had debates back and forth around. Oh, gee, would it even work? Or, who are these young kids using C when they should be using Assembler?

John Furrier

>> Yeah, it was a religious debate.

James Kaplan

>> debate we've had generations of abstraction. Yeah right as we advance technology. The thing I like to use is okay. A lot of us went to see The Odyssey this summer right? I certainly did. You remember to my understanding that when they first wrote the Iliad and The Odyssey the Aegean world, or when the Iliad and the Odyssey first emerged, the Aegean world had lost written language, right? So you had, Bards had to, memorize. So when people say, oh, gee, AI is going to mean, nobody's going to understand anything anymore. I'm imagining some Bards, oh, gee, this writing thing, people aren't going to have to memorize every last word of the Iliad or The Odyssey. Remember we've gone through many many generations of advances in information technology. Going back yeah to the adoption of ofwritten language.

John Furrier

>> Yeah and the Rosetta Stone of this the new era. If you look at specialized intelligence which we're seeing a lot of in the enterprise. General intelligence okay AGIs, they crawl the internet they know general things but when you get into specialism, that has become very interesting because you can have very tight models, you have a lot of context, the data isn't unlocked, it's locked down, it's gotta come out and get value.Well, I think.

James Kaplan

>> The point about context is a really good one. And often I find the places where the models aren't quite, or the output of models aren't quite right is we haven't given it all the context and we have nothing that will suck up everything that's happening nor would you want it just now right so a lot of thought needs to go into okay gee what are the things we need to tell you know if you're using a um there was um there's a great book by Hal Brands about AI and geopolitics talking about yeah um and there was one chapter talking about how strategists sort of strategists working in the military or the diplomatic community might use AI -based models to model negotiations and what have you. But imagine how much thought needs to get put into the model in order to get a good result. That's a new engineering task.

John Furrier

>> You said it earlier, feeding the beast, feeding the AI. Exactly so. That's the context.

James Kaplan

>> And you think about any business problem. Any important business has organizational aspects, operational aspects, economic aspects, cultural aspects. How do you think through all the things? And that's what we need early career people to get on the path of learning to do.

John Furrier

>> It changes the prompt engineer kind of thing into just context engineering. Which is just how do you create a data environment to get the right data at the right time? Exactly. That's feeding the math. Exactly so.

James Kaplan

>> And you think about, you know, I mean, and I'm very much of the opinion that, an agent is just a piece of software. It's not a person. But there are some echoes of interpersonal relationships. If you think about managing any early tenure person, a lot of success is figuring out what to explain to that person. Because you can't explain everything. That would take a year. And the person can't retain everything. but there's some set of things that anyone needs to know in order to do a good job on the analysis. I think Alan Kay said something along the lines of context is worth 20IQ points or 50 IQ points. And that's exactly it's true with a person.

John Furrier

>> And it's true with an agent. Well James thanks for being part of the luminary series. You are a luminary of course with all your experience, but also now that experience just becomes input into the new opportunities. Absolutely. Can I make a plug for one thing?

James Kaplan

>> Sure, absolutely. I write a blog on Substack called Prosaic Times every Sunday, except Labor Day weekend, where I talk a lot about the stuff I've been talking about here.

John Furrier

>> All right. Check out that Substack. Say it again one more time. Prosaic Times. All right. Prosaic Times.

James Kaplan

>> And the topic is? It's everything we've been discussing. AI, graphs, business strategy, technology strategy, and driving change within a big, messy organization.

John Furrier

>> I'll promote my Substack, John Furrier at Substack. Of course, SiliconANGLE.com, theCUBE.net, theCUBE Research.com. We'll endorse each other. I promise you. There we go.

James Kaplan

>> I promise you this afternoon I will put your Substack on my recommended list.

John Furrier

>> It's great to have a distinguished partner from McKinsey here. You guys do a lot of great work. I like to joke. I was angling for the title irreverent partner, but they told me that wasn't on offer. It's not on the list yet. We're working on that. I'm working on it. All right. I'm patient. This is the Luminary Series, Neo4j's Luminary Series. We explore with leaders, how they think about how they're framing their view of the innovation for the future, how data and the data structures, how it's going to evolve. Again, to maximize productivity, cost, societal benefit, all happening as we speak. We're doing our part here on theCUBE. Thanks for watching. Thank you.