Sam, Julian, welcome to the podcast. How are you both doing?
Pretty good. Great, busy, but good times.
Fantastic, well, it's great to have you both back with us. Today we're talking about what it means to become an AI native company. What does that look like and how do our chief data officers and analytics officers of today need to essentially embrace that transition that organizations are going through or risk getting moved out of the way in their own organizations or also seeing other competitors in their space encroach on their value offering?
We're here working, we're telling it, AI native organization. What else, let's restart with some of the learnings that we've seen over the past six, 12, 18 months and how we've transitioned into that space.
Yeah, I mean, maybe start with some of the use cases of where we're seeing this AI native stuff crop up in the organization.
Engineering is a great example. We have coding agents. I've spoke about these a lot of times. We've got developers essentially supercharged by coding agents. And that also translates to data engineering as well. So you call it code cursors, those AI native agents.
And so Ed, what people are just becoming more productive with their code, isn't there a risk that they're just producing spaghetti instead of like actually tangible evidence? How have you changed your, as an engineering leader, have you changed your mindset to essentially become what, a reviewer of other people's use of other areas of new genetic systems?
Yeah, I think, so software engineering, I suppose data engineering as well , like you tend to have practices in place for testing these things, like testing data quality in data engineering or software testing is like unit tests, integration tests. Those are what you can fall back on. You're not just generating lots of code, you're also generating lots of tests. You validate that the tests are actually testing the right functionality.
And then as we're seeing adoption in engineering here go massively , you've got some people who are now at least 10X productivity gains on previous, with output of coding, shipping more functionality. And then, yeah, obviously that leads to the need to review more code. But there's also now, there's a GenTK I reviewing code as well. So the first thing I'll always do in my workflow, write some code , the first thing I do is get Claude to review that code again. I give it a clean conversation, I say review this code. It comes back and I give it at least a few iterations myself before giving it to a human. But we are seeing definitely an increase in pull requests where we submit our code and put it up for review, a massive increase in the number of those being raised now.
Yeah, in the data analytics space, you get the same kind of productivity gains. And the speed allows you to be more curious and as you investigate hundreds more, rather than thinking, oh, I ought to check that, but it was gonna take me a day. It gets pushed to the back of the to-do list. But I could set a GenTK system off investigating something and get a report back just on a hunch and that's cost me 10 minutes. And that makes it more practical to run down things you wouldn't have had time for and bothered.
But both of you have already made that leap of early adoption of these GenTK systems and frameworks and also this GenTK way of thinking about how you solve those problems, how you review the code at scale and how you're happy with those outcomes. If we take it back a few months or years, perhaps to when we first started engaging with these AI native systems and frameworks, what was it for you, Sam, personally, that helped you make the leap of like, oh, this isn't just a chatbot, this is something else. And here's how I can think about using it at scale across the enterprise , because what you're describing there is a fully a GenTK driven development of a product , in this case, your use case here is the engineers that are building a platform using code under the hood, you're responsible for developing all of that. But to then have that vision of execution and delivery, can you pinpoint a moment where you're like, oh, now I can see the value of what this can offer and how I can cheat?
Yeah, so I'm a little bit biased and probably had a better start the most because I built Matillion's first co-pilot as we called it back then. So I've been working with this technology as it's got better, building stuff with it. So then essentially, it's kind of cheating really, isn't it? That then when these other tools come out that essentially do a similar thing in a different field, I just kind of get them and know how to prompt them.
But for me, it always started with chat GPT or whatever. That's what everyone, let's be honest, that's where everyone really started when AI or GenAI became mainstream. And I always use the example of like, can you give me a recipe for spaghetti bolognese or the simple stuff you used to ask where you needed a quick answer? And I still use it for those things today. And that was probably a couple of years ago. That was really all it was good at and text summarization and generation.
And then over time, I mean, it's not been that small of an increment , like, you know, Claude code, I talk about a lot because that's my favorite coding agent of choice. Really, I don't even think that's been around a year. And like even the jump from when they first released it to now has been so significant that they're just kind of wearing away at the barriers of like what it can do. And like, you just, you get blown away by the tasks that can complete that it previously wasn't easy to do.
I'd say biggest learning for me over the last few months of this change is equally how you feed them information beyond it just being talking to the chat bot. Is it the innate knowledge that the model has had at the time of training, which is the things like the GenAI's deep research or similar with the ability to search and look for information, collate information, operate at a scale in terms of research? Whether that's analysis, like, okay, we've heard about a competitor, a potential competitor product. Can we get a summary of them and how it compares to us? Well, that's a perfect task for a deep research bot to go off and Google that company, their product, it's what their specs and similar.
Or equally just learning to combine possible sources that maybe you wouldn't have time to read yourself, but like, I've got a bunch of docs from the company website, from the company's internal notes. I've got a Slack channel of conversation that was talking about something , collating all that up and just saying, all right, can you sort this out and give me your thoughts on this or give a summary of this view? Super quick and very effective. It's like having a team of assistants, capturing all of that pieces of information and summarizing that up. And what you're describing there is a great use case that now we're seeing some of these GenAI models come to fruition in terms of what they can start to offer us. We're seeing more of those productivity gains internally day to day.
But when you started shooting, you've been long in the game of AI as a concept. And then we've now got this new branch of generative AI that's opened up way more of those avenues for us. How did you make a leap from a chief data science officer making that bridge from, okay, this is non-deterministic, this is text generation, here's how my team can use this effectively in a way? What was that leap?
I think it's realising it's almost a bit like taking a people leader's view to it, which is you send somebody off, you send a bright member of your team off to do something, you probably still have some criteria. You've got to give them a decent brief and you've got to be clear of what you want. And you've got to have some criteria how am I going to judge whether they've done a good job or not, how am I going to evaluate what's coming back to me? So it still comes back to the basic principles of testing. Having some criteria for checking, rather than just blind acceptance of what comes back. Right. How can I validate it?
I think what helps you come from a data science background is why things are more probabilistic. You're getting used to things not being, I don't know, having 100% view of the picture of the truth. You're used to a dataset that's incomplete and scrappy and probably inconsistent. And if you wait for perfect data, you never do anything. So it gets you a mindset to say, okay, this is probably the best intelligence we can get at this point. And that's a real, that helps with the mindset of embracing the data. I say, well, it might not be perfect. It can't be 100% reliant, but it's probably a pretty good steer. We want to then combine it with other things we know to validate it. I think it's that how do you then join that to the pieces of knowledge you have already or the facts you have already?
So we've been talking a lot about how we've adopted it like personally and for the processes that we do sort of day to day. For me, I use a blend of that summarization use case , going and telling me everything about what's happened with this interaction in the past few weeks , or go and read through the cool history that I've had with this particular person and help me identify where there's opportunity. So it's helping with that summarization piece.
But when we take out that kind of the quick wins, that low hanging fruit that we have , what do you see as some of the biggest sort of like people upgrades that Agenta AI can offer our day to day leaders in organizations? Like you're speaking to chief data officers and analytics officers all the time about what an Agenta future looks like for them. What do they need to be concerned with now and how can they leverage generative AI to transform into an AI native business?
I suppose it depends what they want their business to be like. If you think at the end of the day, you know, Agenta AI now means that essentially one person can do the job of many people. So they will essentially have a powerhouse of additional work that they didn't. And what you always hear when I've ever spoke to someone, some of our customers that they always have a backlog of data engineering work bigger than they can ever get through and hopefully now with Agenta AI, you know, they can hire more people. So, and they can get given agents. And essentially that, you know, that person who has that backlog of work can now do five times the amount of work. That's a huge, huge, massive thing. And yes, that might require buying a certain agentic tool or technology that costs money, but that's likely to be more efficient and, you know, less than hiring another person, for example.
So. So stick with the team that you've already got, made them more productive. Yeah, keep using the knowledge. Capturing, capturing the knowledge that's within the organization, I think is a really rich area too. Cause you get that, if you can get that into an agentic framework, into a co-pilot system or similar, your coding standards or in a data space, kind of your known problems, your known issues, your known, you decal the data. That then empowers sharing of that knowledge with even a new team member or across the team. Right, so treating these agentic systems as almost humans, you've got to train them. You've got to share, okay. If you had a new member of your team, a person joining a data team, you're going to, you've got to show them which database to use, which connections to use. You probably want to give them the, get them to talk to the experts in the field who use the systems that can tell them all the kind of gotchas. The fact that, oh, how this particular sort of credit use was calculated, changed a year ago so that you've got to be aware that there's going to be then inconsistency in the table. That's something you share with a new data engineer or a new analyst. You want to share that with your agentic assistant and make sure that then anybody in the team using that is getting reminded of those little facts that, you know, allow decay over time.
That's why it's important, like, if you can think of most agents or you start a new conversation even in chat GPT, it's essentially a chat where the agent has amnesia, right? It doesn't remember anything. And some of this stuff Julian talks about is like, the best tools out there right now are the ones where the agent learns over time because you don't want it to have to look this information up every single time and build this context up. You want to have reasonable context and reusable memory so that these agents do learn, as Julian says, you know, you give them documentation on how your business works or your, you know, your data landscape or something like that. You don't want to tell it every time and have it go and figure that out every time. It should have that in its knowledge and its memory.
Likewise, where the agent is doing a technical or semi-technical task, you want it to start learning from that or you want something to be in the system to be collecting that information to save time the next time it attempts it. You'll often find that by that, letting the agents take notes in some form, it means they're not necessarily that they didn't sell the first time, but you're probably still a bit much faster the second time around because it doesn't get down blind alleys.
So then I guess what we're saying here is our visionary CDOs, the ones that are looking to build AI native companies or transform their existing organizations into AI first organizations are the ones that are going to be able to onboard these agentic systems with speed and keep that reinforced learning. Give them the right information, keep their enforcement learning going, but, you know, this is where they can innovate. You can innovate in this space without being competing with a great model builders. A lot of the innovation we've done is all about what information we give, in our case, Maya , time it executes or time to make a decision and how it gets to the right context, how it gets to the right notes, how you create what comes to it and the leave it as it has to pull. And that's what the owner of the system can innovate with. And that's where they can be a hero within their own organization, really drive things forward.
But we are seeing a shift now from people are, you know, our cloud code writes 80, 90% of my code now, but that means I can write more, but like I say, I write more, it writes more and I review it , but now there is like, there's a data literacy problem. So if you've not got good documentation, you know, and we've seen, we've spoke to a lot of customers, a lot of them don't have good data catalogs, for example , what is going to make your agent like in a data space much better is having a really good data catalog. So I think the work will shift from physically doing and building data pipelines or writing software code to actually curating and making sure that like the documentation, the best practices, everything you have, whether it's confluence or, you know, word docs is in a really good format accessible and then provided as context. But that has to be up to date , like, And that is, and that's where we see, you know, the opportunity to agents to collect and update their information automatically. Right, I think that's vitally important because that's, data catalog exercises are usually huge amounts of admin work. And of course, the second you stop it, the information starts to age. Okay. So we're, you know, we're looking for ways you can systematically collect that information.
So if you're a leader in your organization today and you're looking to build that agentic, or that AI native mindset of tomorrow , we need to onboard agentic tools into our ecosystem, train people on how to use them effectively and also train the models themselves or, Or extract the wrong models. Provide them with that context, real understanding of that business. Yeah, take advantage of their ability to document things well.
So how do we see those humans that were previously doing tasks in your world sound at coding and in our world of data science or data engineering, it would be like a human data engineer? How do we see their roles shifting left up that to providing models with those, like, for those contextual systems? Is that something that we'll see become a more important part?
I see the role of, you're on for a role as the curator or the librarian, that's a bit on managing the resources available , making sure they're well understood and documented and how it finds in the coding space, but.
Yeah, yeah, I mean, it's the same, like, to be honest, in software, it's quite unique. Like, the coding is really good at making changes in a single code base , but like this, you know, there's a lot more to software engineering. I mean, even in the past, people said that like, writing code was only 10% of software engineering or something, something crazy like that. There's all the stuff around operationalization, like monitoring, observability , then like releasing the code, deploying the code, and each one of those is like a complicated system. It might be that you write a Java app, and then you happen to deploy that into Kubernetes, and you happen to monitor that with Grafana and Prometheus stack, an observability tool. You're expecting the agent to have knowledge across all of those, have context and work across them all, maybe one day, but not at the moment. So the human essentially becomes the driver and the orchestrator of these agents. Like, I might use it to write some code, and I might switch to it to look at some logs or fix a bug that I've seen in some logs, and you become the orchestrator.
Where I can see it in the analytics, but it's in the genics, in the analytics places, it might be start with pieces of work where we do them with one-offs of research. Now it might become a repeatable scheduled task. So rather than do a deep dive in analysis of a document of our product, and what kind of persona is using what feature , that's something you might do once a month or once a quarter with a human analyst chasing it. I can see a world where that's a scheduled task that runs every week to say, "Okay, look at our usage data, see if there's any interesting trends, drill into them," and then flag up to people whether there are any things that's worth their notice, worth digging into, comes back to the human user.
Well, I mean, you're highlighting a really good use case for investing in that analytics organization already that most of our, or if you had all of our enterprise customers, have already invested heavily into creating advanced analytics and business insights. But there is a real risk here for these organizations that don't start identifying and being curious with their data, that they're gonna start to lose out to these native AI companies that are coming on. Organizations like Lovable and others in that space that we're seeing become the sort of go-to. We also talked to B2 release their, opening eyes, sorry, release their browser and prophecy went free with theirs this week as well.
Yeah, there's certainly also there's opportunities. I think there's a lot of opportunities for companies that want to get more AI native. Yeah. But it might have a lot in terms, particularly if you've got outsource or offshored resource doing particular tasks, especially in the analysis phase. There's a lot of overhead then just going back and forth between teams in like, "Okay, if I want this analysis task done, I've got to hand it off to my analytics team that might be in a different country, different time zone". This potential for us to be lost in translation, there's a potential for that. And then there's literally the physical hours of the day as things move back and forth when that task could go instead to an agent at your fingertips as a domain expert. Yeah. So you become more ranked.
So whilst we do run this podcast, we are also providers of an agent Maya that does do all of those things for data engineers and at an MCP server ready deployment. So without straying into the weeds on what Maya can offer, it's more focusing also on like how we can help educate on those leaders, those analytics leaders in those lines of business, how do they update their modal of thinking about these problems? Because it's a big shift, right?
Yeah, so I'm very bullish on this. Like at the end of the day, if there are businesses out there and they're not becoming AI native, they're not getting people, they're not encouraging every single person and they're not questioning why everyone in that organization isn't trying to use AI. They will lose to the company that does. And we're seeing like even internally for us with adoption, like there are people that need a nudge and it's and like actually measuring is quite hard. So, you do get metrics from some of the tools you use, like how many lines of code did God write or things like that. But that's not necessarily a great reflection of like, did that, has that person used it and did it actually solve? Yeah, solve the problem and add value.
But like, I think for us, it's been less about trying to measure it to be like, hey, you're not using AI, say fired. It's more about like, hey, why aren't you using it? What can we do to help you use it? Because we want you to be as productive as you can. We want you to look good with your peers. And I do think it falls down to individuals. If you've got one engineer or data engineer using it, they've become five, 10X more productive and you've got one that isn't, they're gonna get left behind and they're not gonna look as good when they go for their performance reviews and that sort of thing. Yeah, just a sheer amount you can get done. It's gotta be from the top that this is pushed down. Like our CTO, Ed Thompson in our engineering org, he set a small group of people up that we called like the AI Dev Tool Committee. And that committee evaluated some of the tools and is the first group that will take a new tool in and try and evaluate it. And then we essentially are the people that go out to the rest of engineering and advocate for it and be like, look, why aren't you using this? And slowly over time, you kind of, you go back to your teams and you start to see bits of it kind of growing out, almost like growing into teams and then you've got teams sharing this all. And like, I would encourage anyone, like if you're not pushing your teams to use it, you should be, because it's not going anywhere.
There's another factor in this that the principle we had found earlier on when we were developing was that, the "Cristin's Tech Techies" movie so fast, it was often worth parking something. If something half worked, you kind of park it for three months or six months and then try again as the newer models or newer tooling systems came out. And it may well also be the case, I think, for organizations looking at adopting it, that if some of the team have tried it and they've not been convinced , or they thought, okay, well, I could see it was sort of useful but it wasn't, you know, when you tried it last year, it wasn't quite precise enough. So you went, oh no, get out, it's not for me. I'd encourage them to like regularly retry. If you're of the mindset, say, I could see this for whether this might help, but I don't trust results right now. Keep coming back to it until it meets your standards. You know, you may have, people are gonna have different thresholds for what's good enough, but.
And I guess that's the biggest risk for organizations that have a build versus buy approach, right? Because if you're building all of this in-house, if you're there as a CDO today thinking, how do I build my own agenda platform for my data teams to take advantage of , then, you know, you're gonna run the risk then of having to essentially keep all of your models up to date and keep advancing and analyzing the technologies. Like talk us through, I mean, I've seen loads of customers that I was thinking to at the moment today raising really great questions on, oh yes, but how does mine handle this? Or how does mine handle that? And normally I'm listening to all of their concerns that they've raised with the systems that they've built internally when trying to tackle these agentic projects. In fact, 95% of agentic projects fail to get off the ground, primarily because they don't have the right data.
But how would we think about advising those build mindset organizations when it comes to things like keeping models updated and keeping a platform operationally sound under the hood? I know that I'm preaching to the converted here because we've built a platform that handles all of that and does all that for us, but you're outlining some of these real risks if you do go with the build approach, right? Stuff becomes outdated very quickly if you're not continuously updating it. If you're not monitoring its performance, looking at embracing the latest and available models, yeah, you're definitely gonna fall behind in comparison to somebody that's updating it for you and handling all of that, the mechanics first of all.
I think, yeah, there's basically a whole lot of work just to keep it stable and on top of what's the best performance that you can have. See, it isn't just as simple as building a wrapper around an open AI model or an anthropic model , there's so much more to context engineering and memory management and conversations and all of this stuff that people probably don't understand that goes into some of these because they log in to chat with you to have a message and get a magical response. Oh, hey, that's me. Yeah, I log in every day and I'm like, "Oh, mate, I wanna build this today". And it tells me, it comes back and says, "Yeah, sure, no worries". "Like, let's proceed". And then, you know, I've wasted three hours later and I've not got anywhere with it because I've not got the right-- Yeah, I mean, yeah, go ahead.
No, but it goes from like, the more philosophical things of like, do you have the team size to build and maintain this thing? Like, we're an entire engineering business and our entire directive is to build Maya. Like, if you're building a smaller version of that and a small little team, you're not gonna be able to maintain it, you're not gonna keep it up to date. And then, there's the other side of it, of actual technical limitations. Like, if you're a big vendor working on AWS or GCP, the likelihood is you get much higher rate limits than, you know, a smaller team. And a Gentak AI application is a very token heavy. And can be very spiky and can be subject to spikes from around them. Yeah, so you need core, like, you need good engineering practices to fail over resiliency. And by the time you start doing that, you realize it's, again, it's like a big software engineering problem and you can't just solve that with a small team.
The other fact, as we see, is obviously, is it something that's just sitting out there checking out spaghetti code or checking out generator? Or have you built the structures around it that actually capture it and make it explainable, make it understandable, maintainable effectively in terms of what's being generated? Because it's easy to create, it's harder to maintain, I think, if you're-- And then, probably the hardest thing, actually, and we know this firsthand, is actually evaluating and making sure the system is behaving. Like every change and every tweak you make, you're essentially having to validate and evaluate a non-deterministic, multi-step reasoning process. It just doesn't, like, it's incredibly difficult. And just building that out alone requires an entire team. As Julian, what was Julian?
Yeah, because you've built a gym recently, right? Well, we've got to stay, and not a normal gym, Julian. As you can tell by my perceive, it's not the normal gym. But-- You've been working with who?
Yeah, so the things we were exploring is, how do you test and evaluate, and how do you build scenarios, really, to set up how you can set up repeatable ways to evaluate performance , because it's non-deterministic. So it's no good running your regression testing pack once , because it's non-deterministic. All right, it worked once, but maybe it might be actually only working one in three times. So you need things that are repeatable, and be able to execute it multiple times, and then evaluate the results. You frequently end up with a system where you've got in, the way we're managing things, you have a large language model playing the role of the tester, walking Maya through the testing scenario, the scenario it's trying to do, and then a third large language model actually evaluating results, looking at the conversation and scoring it on certain criteria. And finally, the human analyst occasionally looks at the large language model as a judge's results, so do I agree with that? Just to sanity check what's going on. Once you've got that kind of framework in place, you can experiment more, you can try different variations. You can keep, you try different models, you try different prompts, you try ... There's a lot that lets you scale up the evaluation of what are the best combination of prompt model parameters and the rest.
I mean, that's such a complex framework of agent-dram training. Like, you know, that's incredible.
I'm going to ask a loaded question, which I don't know the answer to , but when you were designing that, Jim, in framework, were you thinking of when you're, you know, you're an incredibly intelligent data science leader, were you thinking of that organically, or were you ... Are you consulting with LLMs and with models to help kind of build some of these frameworks out in the kind of design approach?
A little chunk of talking to the models or evaluating ... They're very good for brainstorming and drawing through ideas, and that's part of it. Also for just condensing and churning through the latest academic papers and what's out there. So you're kind of looking at sources of information what's coming out to people's pressure, diseases and industry of techniques alongside of, you know, transcripts of YouTube courses , summarised versions of what's been published as papers, all to collate, keep on top of the volume of changes in the field.
I mean, it sounds like you're basically doing a master's every day in terms of the amount of content you can actually ... We want to try and automate that process rather than...
It's one of my favourite use cases of like, agenda KI now, is this way and like the way I do it. So there's a tool called Obsidian. It's like a markdown notes application, and you can build a knowledge graph in it, but that's not the key part. Like the fact that it's all your notes is marked down. Then essentially you can use a coding agent on top of that, such as Claude or cursor , and you essentially just vibe, document and chat and bullet point, and then over time you just start kicking out lots of documents about ideas and thoughts and, you know, and because it's just files on a machine, textual files on a machine, you can just keep iterating on that. And that's like, that is the way that I will now brainstorm or a new idea or some thoughts. I'll start with a few bullet points and then, you know, in 20 minutes or less, I've got five or six documents of different opinions and implementation strategies , all the way to the point where I might then condense that down into an implementation specification that I essentially go, OK, write that into a spec now and go and implement this. So not only are we probably doing that for things like the test frame, but we're actually doing that for like pretty much everything we build now. Wow. Which is definitely a crazy way of using AI that I think would be ... Sid, I mean, there are other experiments for exploring that. How do we get the AI to teach itself and practice? That's my next barrier that I'm working on. Oh, I see. That's kind of setting things up that it can do a bunch of exercises and take notes and then hopefully speed its operation in the future.
I'll throw it out there. So we've talked a little bit about the people changes in terms of the mindsets that AI leaders have in organizations, but also the humans inside of those organizations for how to adopt agentic AI into their sort of day to day. We've talked about sort of the processes that both of your teams have adopted to become an AI-native organization, how we think about driving innovation for our own customer base here, using AI-native's best practices and tips and processes. Let's talk about the third aspect of our products. When do we need to show the product that isn't behaving in an agentic manner? Have you had any of those recently? Are there ways in which you now are looking at existing technology stacks that are out there and just seeing, "That's not helping me or my organization become an AI-native space"? And how do you sort of go through that evaluation? And that's a bit of a big question.
Yeah, I mean, for us, obviously I said we, from an engineering org, have that committee. So that is a group that's essentially taking the strain off all the other teams and engineers , because essentially there is a new AI, we're in a bit of a bubble, let's not mistake that. But there is a new AI technology company coming out every day, a new startup , very unproven, but really cool ideas. And you kind of don't want everyone suddenly going, "Well, I want to use that. Oh, I want to use this. Oh, I want to use this". You want a committee or a group to evaluate those in a more systematic, measurable way. And I think that feeds into the question you asked around, that committee can also look to kind of shelve something. Like, in our org, we were using GitHub Co-Pilot for a long time , and now ClorCoder is our most used offering. But we still know that people have preferences , because ClorCoder is very different. We have some people using Cursor, we have some people using WINSurf. But, you know, effectively, as a business, we don't want licenses with everyone. We want one platform that we can trust and do everything we want to do with.
That takes some work I was going to put on this , which is working out kind of independent of the tools, how you're going to evaluate, how you're going to make a judgment call about what's good and what's bad. Because there's a lot of stuff out there that is a bit random and can't actually meet the needs. As you said, like, 95% of the projects fail, and I'm assuming that the tools will not. A lot of the tools you'll see won't be fixed purpose. But kind of thinking before you start, how am I going to judge whether this is actually helping me do my job? That's probably the ... Having a clear-cut definition. It's a bit of a scientific approach, really. It's like, "All right, how would I score this? How would I rate this"? And that can be partly subjective. It can be, "I'm just going to put it in front of five experienced people and have them vote yes or no, whether we should adopt it". But have some ... Build some framework for judging what's good and what's bad.
OK, so we've got a framework for judging. We've got a committee for sort of approving all of that through. But if you're a chief data officer of a product in your organisation or a product as that is in the space that you're offering, like, you know, it's really single swim time, right? Like, either it's transforming to that AI-native product offering and mindset , or we're going to start to see, as you just listed off, six huge productivity-gaining code generation engines that are out there for software engineers today. And we know, as the lead provider of data engineering and genetic teams with our genetic team, Maya, we know that there is other avenues of organisations, or be ours as in data engineering and beyond in that data analytics space. There are other aspects, like finance and operations, where we're going to start to see these AI-native tools and products pop up into those organisations.
What would your advice be to a people leader of, say, operations-focused, like a manufacturing, or like, you know, a more ... less technical, AI-focused?
I would say think about what happens. Let's say you change your process, you embrace and similar. Envisage what life looks like in six or 12 months. Envisage, think about, OK, well, how am I going to manage what I've got? How am I going to keep track of what I've built? How am I going to understand what's coming out? And what are the tools I'm adopting, ones that make it easy for me to keep on top of what they keep on top of all the productivity they're giving me? Or am I generating a whole lot of stuff that's actually just spiralling the work? And so I'm trading off productivity gains in creation for a massive maintenance overhead? Or am I doing something that's actually helping me maintain as well as generate? That would be my first piece.
I think the other one I could say is about thinking about how your team are going to learn. So think about how the team are learning and ensuring that the quality of the volition, how you can make time when it generates.
Yeah, we're finding the measuring bit, it's really difficult to get right , because at the end of the day, we're talking about measuring the current human process, right? And now all of that gets sped up. It becomes also about empowering those humans to use those agentic tools effectively , as we've seen, probably internally, but I've seen with some of our customers at the moment. It depends on who's using it, it depends on how fast you can get those results and those productivity gains. So then you need to provide those rigorous tests for those productivity gains.
Sam, any thoughts from yourself on the advice that you'd offer CDOs in terms of more operational focus as opposed to software business focus?
Yeah, I think they've got to analyse the places where the current AI tooling can actually help. For example, if you're heavy manufacturing , I'm sure there are already robots and stuff out there , but the robot scene probably isn't as popular as the back office scene where you've got a finance team, or you've got people in marketing or something like that, and there are tools coming out that can massively help with that. They can help you build your campaigns or they can help you process invoices and all sorts of things across the business. So the key is to find the places in the business that actually fit. And I'm sure, we as a company, we do this, I'm sure they're getting ads on things and they're getting salespeople calling them up about tools that are useful. Try them. Don't reject the phone call if something sounds really cool. Start a proof of concept, don't wait.
Fantastic. Sam, Julian, it's been a real pleasure talking to you today about how we've transformed Matillion into an AI native business and also how we're helping other organisations do that with our AgenteC team. I'm looking forward to us meeting again next time where we're going to be discussing some of our guesses for next year's 2026 predictions and wants to come in the AgenteC AI space. With that being said, thank you very much for listening and tune back in soon next time.