Unlock AI Value Without Rebuilding Your Stack – Ken Stott

Episode Overview

 Ken Stott is the Field CTO at Hasura, a company redefining how organizations connect and derive insights from data. With a rich background in financial services and data infrastructure, Ken helps businesses adapt to decentralization, regulatory complexity, and the rising demands of AI.

At Hasura, Ken oversees solutions like the Universal Data Access Layer and PromptQL, ensuring enterprises can gain real-time insights without centralizing all data. He’s a champion of semantics-driven architecture, operational transparency, and evolutionary not revolutionary data modernization.
Ken believes the real power lies in building systems that don’t just move data, but truly understand it.

Episode Transcript

Ken Stott: But the regulators are really asking you to provide good semantics around your data. Explain it. Tell me what it is. Explain how it flows through your system. If you can build infrastructure that can operate against those semantics. Now when you have problems, the answer is to improve those semantics that improves the way your organization operates because it understands how your data works better. It improves how artificial intelligence operates.

 Kevin Rosenquist: Hey there. Welcome to Pay Pod, where we bring you conversations with the trailblazers shaping the future of payments and fintech. My name is Kevin Rosenquist. Thanks for listening. Trust. It’s one of the most used and least understood words in the world of financial data. In this episode, I sit down with Ken Stott Field, CTO at Hasura, to unpack what trust really looks like in a modern data stack. We explore why so many financial institutions are still struggling with decentralized systems, how intelligent data agents are changing the game, and why the last mile of data delivery is the most consequential part of your architecture. Ken also breaks down how semantics, context aware systems, and universal data access layers are helping organizations get value from their data without needing to rip and replace everything. So without further ado, please welcome Ken Stott. So why is it so hard for financial institutions to balance broad data access with strong governance?

Ken Stott: Well, that’s a good question. And it’s one that,  I think most institutions ask themselves on a regular basis. There’s a couple of things that are going on. One is that the history of data management is really a history of data consolidation. And so a lot of the tooling that we see is all about how to improve our ability to consolidate data. All of that’s there to provide some form of user experience, right? That’s why they’re consolidating it.  a lot of that is based on some expectations around the technology that’s available and their organizational needs. But what’s really happening is none of those organizations are centralized. They’re very, very decentralized. And until we sort of acknowledge that and build solutions that really work with decentralized data management, data governance is always going to be kind of a problem.

 Kevin Rosenquist: When it comes to trust. From a technical perspective, what does that actually look like in a data stack? Because we hear the word trust all the time. It’s sort of just thrown around. You know, it’s not getting past the buzzword. What does that look like in the technology stack?

Ken Stott: Well, there are so many dimensions to trust that first, that’s a very hard question to answer, but I’m going to do my best at doing it.

 Kevin Rosenquist: Sorry too, general, I guess.

Ken Stott: It’s a lot. There’s a lot of things in a modern data stack that help engender trust. One of them is modern. Observability brings an incredible dimension to understanding the operations of a data stack in the moment, and your ability to assess whether it’s functioning correctly. And I think that’s an element of trust. The other element which you start, which you’re starting to see, is more inline data quality, both from a passive and an active perspective. So from a passive perspective there are different products that do this today. But they have inline anomaly detection. So they’re able to identify something that within some context looks unusual. And they’re able to either stop it or at least report it. And then the other is active validation where someone asks for data. And they also say I want this data and I’d like it to follow these rules, and please give me the data and let me know that it actually is what I’m expecting. Those are probably three elements of trust that I think that are often integrated into a modern data stack.

 Kevin Rosenquist: Okay. All right. Well, that was a good answer. I mean, you said it was a little too broad, but I thought you got there pretty good.

Ken Stott: Well, I could have gone into a few other things, but I was trying to narrow it down. But those three things, if you have those three things, you’ve got a lot of capability to really make sure that the information at the last mile is the information that you’re expecting to be delivered. And that, to me, is the essence of trust at the end of the day. Did it deliver the data? I was expecting to be delivered, particularly in the last mile. The last mile, uh, which never gets enough focus is this is where executives, business managers, regulators finally get the information that is actually used to, uh, to make key decisions for an organization. It is the most consequential aspect of your data stack. And that’s really what trust is all about, is making sure that when a person looks at that number, they can believe it.

 Kevin Rosenquist: Mhm. You know, I was thinking about something you mentioned before on the first question about how everything is decentralized and a lot of these businesses, is it just because they’ve gone in so many different directions and never figured out a way to kind of make it all. Is it just fragmented because of too many people or. What do you think the reason is for that?

Ken Stott: Well, they’re optimized for the businesses that they’re operating. So it’s natural. It’s organic. It is the way it ought to be. That’s how they can operate best. Maximize value for the customer is to operate in a decentralized way. It’s never going to change. That’s how that’s how the world works. Mhm. And until our data systems and our data ecosystems can match that. You’re always going to have this sort of cognitive dissonance around how your data ecosystem works versus how your organization works.

 Kevin Rosenquist: Okay. Okay. I want to talk about the term intelligent data agent.  sounds very futuristic.Can you kind of describe what an intelligent data agent is and why they’re such a game changer for financial services?

Ken Stott: Well, first of all, there is a lot of mundane work in financial services. And, uh, and because of the nature of our data ecosystems and the way they operate, you just have a lot of people checking things, checking boxes, making sure things are functioning the way they’re expected, etc.. Sure. An intelligent data agent, particularly if you’re optimized for and have some sort of decentralized data management in place, can actually identify and do those mundane tasks for you. So that’s more of an operational efficiency approach. But you can apply that to other things like marketing. You cannot get a broad understanding of a marketing strategy without correlating it with so many aspects of your business. Right. You cannot make certain critical business decisions about resourcing or risk without correlating it across many, many, many different data sources. And it’s extremely difficult to do manually an intelligent data agent if it has the semantics, if it has the ability to operate with that data, it can derive new algorithms that, uh, that would be very, very difficult for you to do manually. Mostly what these people would be doing is setting aside the operational efficiency. But when you’re thinking about the strategic piece and you’re thinking about things like marketing, etc., a lot of it is done very, very intuitively. And data agents actually allow you to get a deeper understanding of all of the data that could influence that decision and improve the way you model that decision. Is that does that help? Kevin.

 Kevin Rosenquist: Yeah, yeah, I think that that makes a lot of sense. And I also wanted to ask you about something that I saw with your company, Hasura. Context aware data is context becoming, not just access but context. Is it becoming a priority for modern data architecture and fintech?

Ken Stott: I’m not sure you picked up that term or where were you really?

 Kevin Rosenquist: I thought I saw it. I could have sworn context aware, like I thought I saw that on your website.

Ken Stott: You know, you’re probably right. Well, let me take a guess of what I think that means. Okay,  I can’t. So, Hasura as a product, uh, has both intelligent data agent projects, and it has a data delivery network. And that data delivery network is a part of a solution to creating a decentralized data management ecosystem.

 Kevin Rosenquist: Okay.

Ken Stott: Now what that data delivery network actually produces. Uh, as you connect additional data sources to it, is it builds a semantic layer that describes all of that data and its relationships, so that when our intelligent data agents actually are developing algorithms looking for data to solve a certain, uh, question that someone’s asking is they have available to it all of those semantics so they, they can understand that a piece of data isn’t just isn’t,  in some sort of isolated form, but it understands its relationships to many, many other parts of your organization. So it has a deeper understanding of the meaning of that data. And I think that’s maybe context-aware data.

 Kevin Rosenquist: I think so too. Yeah, that sounds right. That sounds like it makes sense to me. So and I you know, it makes sense to me. It’ll make sense to anyone. That’s why I always say, let’s talk about AI.  Obviously there’s a lot of AI going on with you guys as well. We talked about that a little bit before we hit record. You know, a lot of times, like even even, you know, I’ve talked to other people, uh, on this show before. And a common problem seems to be a lot of companies wanting to just sort of bolt AI on top of existing infrastructure. That might not be the best. That’s not a great approach, is what I’m kind of gathering so far. Can you kind of talk about why that’s a bad approach and what the right approach is?

Ken Stott: Well, first, I’m not sure it’s completely a bad approach, okay. But I think if it’s done in the right way,  let’s just back up for a second. I think the key is you want to leverage AI, get business value from it, and you want to do it soon. Right? And if the answer to that is that I’ve got to prepare, you know, all the data in all of these disparate systems in order to feed some AI agent. And that’s going to take me three years to do it. That’s not a great result, right? So how do I accelerate that process? And I think. So this is sort of my answer to all of that is building a data access layer that allows you to connect to disparate data systems, and then allows you to lay semantics on top of that data. Right. So that data agents can work with it and get reliable results. And I think that you can kind of bolt it on there’s a lot of good technical metadata in those data sources. So my answer to most people is build a data access layer connecting what you got right. Harvest that data. Add your data agent, start seeing if you can get value from it. And if you can’t, But the solution is to improve the semantics in that data access layer. That’s a very low cost kind of flywheel you can build to start. Start getting to value quickly.

 Kevin Rosenquist: Okay.

Ken Stott: That makes sense.

 Kevin Rosenquist: That makes sense. That makes sense. And back to centralization. Regulated industries seem to have kind of clung on to centralization. Are AP for API first data ecosystems becoming. Is that going to become just the norm?

Ken Stott: Yeah, I think so. I mean, when with the advent of Kubernetes and the cloud,  it really makes building microservices very, very straightforward. and they have incredible abilities for horizontal scale out. All those sorts of things. There are a lot of other problems associated with connecting those to data sources. Yeah. The data sources themselves can become sort of the problem. You can’t just layer a microservice on top of it.  but, and I think it is more or less the norm, and that is how people are trying to, in some ways, manage decentralization. The problem with microservices and API first approaches, you still need an organizing layer on top of it to understand how to orchestrate across all of those APIs to actually produce something of value. Again, most microservices are written in a way that they handle very small, sort of isolated ideas. They may have some idea of how they might orchestrate with something else, but it’s but it’s pretty hard to sort out what what we’re really missing is some sort of higher level orchestration capabilities. So you can derive value from it.

 Kevin Rosenquist: Okay. Let’s pivot to solutions. So Hasura can you talk a little bit about how Hasora fits into the modern data mesh conversation or the real world stacks?

Ken Stott: Sure. And,  I like the reference to data mesh. I think data mesh is very fascinating. Mhm. Uh, it’s gotten a little bit of a mixed review as it’s, as people have attempted to implement it, I think to an extent it is inspired by data mesh a little bit. It takes some of its inspiration from data mesh.  I think Zhamak Dehghani who popularized data mesh, the main issue there was sort of two main issues. I’m going off topic.

 Kevin Rosenquist: Just go. No, go for it, I love it.

Ken Stott:  The first was it was sort of represented as sort of this revolutionary idea. And I think as people attempted to implement it, they thought of it as a big idea. And big ideas often don’t go over that well in organizations, right? People have to think through, how do I do this in an evolutionary way? The other issue with, uh, with the original data mesh articles was there’s absolutely no implementation guidelines whatsoever, and there were no solutions that really did it. And then you had vendors who sort of misapplied the term and almost sort of in a way misconstrued it and, and sort of misapplied the whole term. And it created a lot of confusion. What I think Hasura does is it adds a kind of extra piece that makes the data mesh functional. It doesn’t solve all the solutions of data mesh, but it adds a very particular piece that is extremely useful. It is a universal data access layer. So Hasura has two products. Or data delivery network, which is a universal data access layer. I’m going to explain that in a moment. And PromptQL, which is an intelligent data agent that is incredibly reliable in the way it operates, which is also quite useful for regulatory or regulated industries. Okay. So a universal data access layer in my mind has a couple of requirements. It needs to be able to integrate with almost any data source. So we mentioned microservices earlier. So some of those things are exposed through SAS or other things. Can I connect to Salesforce? Can I connect to Jira? Can I connect to Bloomberg? Right. Can I connect to my own internal data sources, my analytical data source.

Ken Stott: Right. Can I connect to Databrick’s snowflake?  Can I connect to operational data stores, Oracle, MySQL, etc.? And then on the outbound side, you’ve got a lot of different interaction patterns that people have a preference for. Some people want to use SQL on the outbound side. Some people want to use GraphQL if they’re building, you know, web APIs, things like that. Some people want conversation, right? Ask me a question in English. Give me an answer. So a universal data access layer does all of those things. And so as you connect all of these data sources, it gives you an opportunity to build a universal data access layer with a universal semantics to support it.  and then PromptQL is able to connect to that, access all of that data and provide very, very reliable results by building data agents based on a prompt that you give it the main. And I’ve probably gone on a little bit too long here, but the main thing that Promal does that’s very, very different is it separates planning and execution, which is why it’s so reliable. It asks the LLM to plan how to answer a question. Then it executes it internally within your security context, so that no private data is escaping to the LM. Oh, wow. And that’s incredibly useful for a regulated company. You put all of that together. And what that means is you can really lay in this data access layer, right? Very in a very evolutionary way, just connecting a couple of relevant data sources. Add in your data agent and start creating business value from that.

 Kevin Rosenquist: That’s really cool.

Ken Stott: I think it is. I mean, I joined this company six months ago because I loved the story and I thought they were going to be successful.

 Kevin Rosenquist: So yeah.

Ken Stott: Why I’m here.

 Kevin Rosenquist: How long has this been around?

Ken Stott: They’ve been around for eight years. Okay. They originally were a product led growth company with an open source product called Hasura GraphQL server, I think.

 Kevin Rosenquist: Yeah, I saw something about that. The GraphQL server. Yeah.

Ken Stott: Yeah. That still exists in open source form. They still sell. That is their big scaled out universal data access layer, which is really phenomenal for larger organizations. Very enterprise class solution. And now their latest product is PromptQL.

 Kevin Rosenquist: Cool. That’s awesome. That’s really cool. In a larger sense, you know, you’ve been around data strategy. What’s a constant that you’ve seen in data over the years? And what’s one thing that’s completely changed?

Ken Stott: Well, from a financial services perspective, I mean, the regulations over the last ten years, mostly responding to the 2008 crisis, are just so intense that they’ve just taken over kind of everything from a from a data perspective. Right. How do I how do I respond to these regulations? Right. Given the technology landscape that I have in front of me. And the answer typically has been to to create these chief data officer organizations very, very focused on responding to regulators. And, uh, and it’s what’s also really fascinating about this is that it’s also manual issues come in the door, and it’s about spinning up like a 5060 person team and pulling in Deloitte and every other, you know, top, top tier consultant you can find to answer that one question. Right. So the cost of that is just just phenomenal. The a couple other big things. Of course, I is obvious over the last five years.  what’s fascinating with AI is that all these things the regulators are asking you to do are actually good practices, but people were approaching it as a check the box exercise, not as a value adding exercise. Now you add AI into it.

Ken Stott: All those things the regulators are asking you to do, it’s exactly what I needs to to work with your data. So now, now there’s a sort of convergence of this idea of actually getting control of your data, actually understanding it and doing it in an operational way so that you can use it. What I think is so incredible about this is that if you’re to sort of boil it all into one big, you know, answer as what the regulators are really asking you to do is to provide good semantics around your data. Explain it. Tell me what it is. Explain how it flows through your system. If you can build infrastructure that can operate against those semantics. Now, when you have problems, the answer is to improve those semantics. That improves the way your organization operates because it understands how your data works better.  it improves how artificial Official intelligence operates. And again, which I mentioned earlier in our show, is it? It sort of helps build this flywheel around continuous improvement of the way you explain your data. And now with artificial intelligence, there’s just incredible, phenomenal reasons to really put effort into doing that.

 Kevin Rosenquist: Is there anything that has largely stayed the same over the years, or is everything pretty much as tech has changed?

Ken Stott: I mean, SQL is a constant. Everyone wants SQL. Sql is not like the greatest language in the world, but it’s what we have and everyone wants it.

 Kevin Rosenquist: But it’s what we have. Yeah.

Ken Stott: And so that’s always sort of a funny, uh, outcome. Relational databases are never going to die. They’re just a model that people seem really content with. I think the rise of, um. Which I guess wasn’t your question, but the rise of PromptQL. Mongo DB is just, you know, a monster. Uh, and uh, obviously is creating a lot of, uh, uh, interesting value in the data space by, by allowing you to, to really persist things in more complex forms in MongoDB and then graph, I think graph is interesting. Graph had this big like trajectory for a few years, and then it kind of leveled off.  But it’s still got a really fascinating space. And it also really helps with data semantics and other things. And I really think graphs will be around for a long, long time. It may not be the answer to everything, but it is something that’s definitely here to stay.

 Kevin Rosenquist: Is there anything on your radar that you think people should be paying more attention to in the data world?

Ken Stott: I think I’m very concerned about lock in to large vendors who are promising. You know, the world. And so I’m very, very suspicious of vendors who say, bring me your data and I will solve all your problems.

 Kevin Rosenquist: It’s a pretty broad statement.

Ken Stott:  And so I think you want to think about how to not move data, right? How do I not move data, keep it where it is and bring value to the data? Don’t bring your data to a platform because it’s promising value. Find vendors who can bring value to your data. To me,  that’s the big differentiator in thinking around how to, uh, around how to improve your data ecosystem.

 Kevin Rosenquist: That’s great advice for sure. All right. Well, the company is Hasura. Ken, thanks so much for your time. I really appreciate you being here.

Ken Stott: Kevin, thank you for your time and appreciate it. And good luck to you.

 Kevin Rosenquist: Thanks.