Skip to content
Melo Podcasts Home
CategoriesLanguagesFollowing

Episode notes

**(Note: Spotify listeners can also watch the screen sharing video accompanying the audio. Other podcast platforms offer the audio-only version.)** In this episode of MongoDB Podcast Live, host Shane McAllister is joined by Sachin Hejip from Dataworkz. Sachin will showcase “Dataworkz Agent Builder” which is built with MongoDB Atlas Vector Search, and demonstrate how it can use Natural Language to create Agents and in turn, automate and simplify the creation of Agentic RAG applications. Sachin will demo the MongoDB Leafy Portal Chatbot Agent, which combines operational data with unstructured…

Transcript

Read the transcript · about 13,730 words, follows along as you listen

And then welcome to Mongo DB TV Podcast Live. It's great to have you with us. I'm your host, Shane McAllister, and I'm on the developer relations team here at Mongo DB. Today we've got a fantastic show as ever lined up for you. So joining me is Sachin Egypt from Data Works, and he's here to show us something really exciting, the Data Works Agent Builder, a product build with Mongo DB, Atlas, vector search at its core. Sachin, you're very welcome to the podcast live. How are you?

Very good. Thank you, Shane. Thank you so much for having me. It's an honor and pleasure to be here. Not at all. It's great to have you on board. I'm very much looking forward to the content of this show. Umm, I know Data Works have been on before some of your colleagues, so it's lovely to get you back. Each time we have Data Works back on the podcast, there's something new and I'm very much looking forward to what we're going to go through a little bit later. As ever, Sachin, I do want for the benefit of our audience to delve a little bit deeper into you and your career path to date and how you got here and how you got the data work. So tell our audience a little bit about the pathway that you have to where you are now as Chief Architect for data. Works.

Sure, certainly. Um, so I've been around in the industry for 25 years. That's a long time been through a bunch of transformations in the, in the in the process, but where we are now, I think it's it's just amazing and a magical time and a professional timeline to be able to experience all the transformation that's going on. So how did I get here? So I was in a corporate job running engineering team about 10 years ago when the first AI wave hit, you know, not the Gen.

AI one, but the one with the AI ML stuff. And we were doing, yeah, we're doing a bunch of AI acquisitions and things like that and just didn't feel like we were tapping enough of the AI potential. So I quit to Co found a startup in the observability space where we were applying AI models for very large scale anomaly detection of infrastructure and business metrics. And we deployed that solution and for a number of high growth unicorns. And that was a phenomenal experience in terms of how to how to enable practical adoption of AI for enterprises AM AIM.

And then when the Gen. AI revolution took off, I wanted to be a part of it. Data Works was doing some fantastic work. Again, the thing that I liked about it was the way Data Works was approaching it was about very practical adoption of enterprises. So that appealed to me. And then the other big advantage I saw Data Works having was that they were building it on top of a very robust data platform. So I have been focusing on RAG and RAG pipelines at Data Works, figuring out how to make it easy for enterprises to adopt it. And then last six months, my focus has been entirely on enterprise agents.

How do we bring the same ease of use that we brought to RAG? How do we bring that to enterprise agents? How do we make the adoption of enterprise agents practical? And you know, for enterprises that want to take that transition and, you know, this opportunity to showcase what we've done, I really appreciate it. I'm really excited about where we are, where data works is, and where this technology trend itself is going. OK, OK. I love that. And look, as I alluded to the prior episodes, they with data works, you know, very practical application.

We're all used to AI and the cool demos that we see from the key companies in the AI space. But they're just that, they're demos, they're very cool, they're very interesting, but they're not, in my mind, very practical. And I love the fact that Data Works brings that. For those unfamiliar with Data Works section, before we get into the meat of today's conversation, could you give us the elevator pitch for Data Works? What problems are you solving for your customers?

Oh, sure. Absolutely. Um, so Databox is a platform for building Genea applications. So we want it's a full service platform in the sense that we are involved from the inception, the prototyping, the experimentation, the creation of it and then taking it to production, governing it, operationalizing it, all of it. And so our goal is to make it simple and timely to adopt these technologies. We want enterprises to be able to take advantage of it without having to really invest in expert AI resources or having to throw a lot of build new teams for it, just make it a lot more practical.

The ease of use is very important to us and so is bringing economies of scale development. So that's, that's fundamentally whatever we've done in the past with respect to RAG, a RAG builder, a point and click solution to build and deploy RAG pipelines and what we're doing now, that's been our driving principle. OK, OK. And I know we're going to get into it in the in the demo later on. I had a sneak preview when we were prepping for our live stream. So I appreciate that.

First of all, a quick shout out to those that are joining us in the comments, Rio and Kenneth and Gustavo and Carolina and Bill, etcetera. That's brilliant. Do keep that up. Let us know where you're tuning in and joining from. And as we go through our conversation today with Sachin, if you have any pertinent questions for what you're seeing on the screen or what we're talking about, please throw them into the comments and we'll try and take care of them either at that time or wrap them up towards the end of the show. You mentioned kindly on the way you know, what appealed data works, appeal to you, etcetera, what they were doing and be very pragmatic, but also the the database that they had chosen. So, you know, let's not make this it's all about Mongo DB. Obviously it is that it's our live stream. But at the same time talk to us a little bit because you were data works was essentially one of the really early adopters of our Atlas vector search product like pre public. You were in the preview beforehand. And why was that the right choice for yourselves or what pushed you towards choosing

Mongo for that, you know, early adopters, you're taking a leap of faith, right, with the product and you guys were on board very early before we came out with it publicly. Yep. Oh, yeah, absolutely. So that's actually an easy question to answer because there are so many dimensions on which that's really worked out for us. So all through this journey, Mongo DB and Data Works have been great partners. We were one of the earliest startups in the AI Innovators program.

From a technical dimension, I think Mongo DB is great on multiple fronts. 1 is Data Works in Mongo DB are very complementary. So Mongo provides fantastic infrastructure on which we can build the platform to actually help enterprises build any applications and take advantage of that. The fact that Mongo can be the operational database and also provide the vector database in the same instance or the same deployment massively simplifies the architecture for everybody. That's, that's a big, big plus.

And then we've had a number of mutual customers who've deployed MongoDB and data works together to build some very interesting business solutions on another dimension. We've had great collaboration with various teams. Christian, you've mentioned we've been on your show a few Times Now. So that's been fantastic for us. A big thank you to the Mongo DB Partners team for enabling us with Atlas credits that powers our free tier on dataworks.com and Mongo DB is our default vector database for powering RAG applications. And we have fantastic collaboration with the industry solutions team.

I personally have been working with Prashanth and Angie from the retail solutions vertical. And in fact what I'm going to show today is, is a built in partnership with all of us together over the past few months. So it's it's overall been fantastic. The choice of Mongol DB's worked out for us from a technical perspective, from a customer perspective, which has been fantastic. Excellent. We'll look very much Thank you for those kind words. And yes, a big shout out to the the partner team and industry team too, because I think they're, you know, they, they love to get deep down involved with our clients and our customers and our startups to to make it a success.

You know, this whole build together notion and really is part of what those teams do because it's you know, but they want they want it to be a success. They want, you know, to make sure that we create the easiest path for that success as well too. So that's it's thank you for shouting out to those teams. I'm sure Prashant and the others would be very keen to hear that as well. I appreciate that. We're going to dig the title today, obviously was build agents with natural language and we're going to dig deep into that now. And I know you've got some slides really as by way of reference architecture to share, but just before and for our audience who you know, they're familiar maybe if they've tuned into a couple of these episodes.

We have done a lot of rag retrieval augmented generation episodes. But agentic rag Sachin, what's meant by that and why is it important in in the world of AI applications today? Oh yeah. I think the evolution of Rag to Agentic is a fantastic story that talks about how this technology is progressing and how as as it starts to solve problems, it sparks imagination and people start to push it, push its boundaries. And then the next set of evolution in the technology starts to come in and it's it's a great example of that.

Shane, if you're OK, I do have a couple of slides that leads up to this. Sure. So we could switch to the slides right now and I could walk through that and. That makes sense. Picture paints 1000 words as they say, Sachin. So let's get that up on the screen because I think again, for our audience who may or may not be familiar with this space, I think it's, you know, we know we've got a technical audience, a developer focused audience. So if we can share that the slides and and kind of go through some of the architectures before we head towards our our demo that we're going to see you later as well. All right, so I just shared my screen, Shane, I think that's looking all right to me.

Can you that's. Good. Yeah, if you want to go into the slideshow mode, it should be fine. Yeah, zoom wise it seems good. Should anybody in the of our viewers have any issues, do shout out in the comments, but I think that's legible and pretty easy to read right away. OK. That's, that's great. So, so Shane, you mentioned RAG or retrieval admin generation. I thought we could start with level setting and just talking about RAG and then build up from there to identity RAG. So it will augmented generation has been like the go to technique for enterprises to leverage the power of LLMS over proprietary and private data.

It's a, it's a pretty simple effective architecture and it's, it's been transformational in terms of information retrieval for both users and employees. The picture on the left here on the slide actually is a typical implementation or architecture for what I'm going to call conventional RAG. And it is characterized by a sequence of steps that are executed. And so when a user asks a question, a process of vectorization, the question is performed as one step. And then you fetch relevant chunks of data from like a vector database, like a Mongo Atlas vector search. And then you put that into a prompt for an LLM to answer. But the constraint the LLM has is that the user's question can only be answered from the context that's in the prompt. So, so that works well actually for a lot of situations where you are dealing with relatively static data or data that doesn't change very frequently.

It's largely text or images or, you know, PowerPoints or web pages. That kind of stuff works really well. But where it starts to struggle is when users questions require accessing multiple data sources or accessing dynamic data, or when the user asks a more complex or compound question. That's when conventional rag really starts to struggle. So let's take a look at the example on the screen here on the left. So the user asks the question, cancel the order with White Sox.

Now that's a very specific question about a specific order in a conventional RAG system that has access to perhaps only the policy document in it. The best that a conventional RAG system can do is to answer the question by saying, hey, here's the cancellation policy. And then now it's up to the user to kind of apply it to their situation. You can't really get a situation aware answer from the LLM because the system doesn't actually have access to the order to be able to apply the the rules onto the order.

So so how do we fix that so agentic track can help us with this? So if we in we add agent, sorry for that. If we add an agent to a RAG architecture, what does that give us? Firstly, we are not going to trans, we are not changing RAG. It's still the same concept as before. We are still going to populate a context that can leverage to answer the question. But the the quality of a RAGS response depends very heavily on the the completeness and the accuracy of the context that is provided to them.

So what an agent gives us is that it can iteratively build out the context. It can have access to data sources apart from what is typically provided to a conventional Rack system. So an agent can have access to databases, it can have access to web services and many other data sources. So when a user asks a question, an agent can basically understand the users intent and decompose that question into sub queries and then tap into the various data sources to populate the context.

So that gives you a context that's significantly richer than what you would get with conventional Rack. So now and again, do a much better answer, provide a much better answer, much more complete answer than it could before. So let's apply it back to the previous example, right? So the user asks the same question, cancel the order with white socks. But let's say now we have an agent system and the agent has access to the same policy document as before, but it also has access to say the operational orders collection.

It says it's in Mongo DB, right? And we have access to, let's say we have access to the real time status of the order that comes from REST service. When the agent looks at the query, it basically gets the cancellation policy like the conventional track system. But it also realizes that it would help to add the order information into the context as well as add the real time status information into the context. Now the LLM has a lot more information and it can provide a much more situationally aware answer where it can say, yes, this order can, can be cancelled or no, this order cannot be cancelled because it's already been shipped.

So this allows us to create a significantly better, you know, RAG systems. And what Agentic basically allows us to do is to create transformational experiences by extending RAG to be personalized to the user and to be situationally aware because it has access to operational data. Which is incredibly valuable both on both sides of the table here. So you know, obviously for the company involved, having access to the operational data as well as the, you know, the unstructured data, the policies, etcetera is is really key because you know that does that make sure you have everything to hand to involve, to be involved in that decision making process as to whether in this example the order can be cancelled. But obviously it's incredibly valuable as a customer. We've all been there, Sachin, right? We're trying to do these types of things and the level of frustration that you have when you you go down a dead end maybe with some of the chat bots that are taking you somewhere. And then you get the human and the humans asking you to Add all the information you just gave the chat bot and you know, and then the human says I'll be back

to you, etcetera. So it's an incredibly valuable process that we're automating for the, in my perspective, the good of both sides of the table, the customer and also the business, right? Oh, absolutely. So we have an. I can give you an example from the customer who we are helping with this. It's it's a customer in the mobility space. And one of the things that they wanted to do was, you know, improve the meantime to resolution. When one of the customers calls into the customer service agent, right? And they, they provide troubleshooting, they'll get like some error code and they can basically ask, you know, can you help me fix this, resolve this problem. And the, the customer service agent has a RAG application now that allows them to basically ask the exact same question that the customer's asking into it and then get a response, you know, from all their internal documentation and all the troubleshooting guides, it can pull exactly what the customer wants.

The only caveat is that you have to 1st know what product the customer has already ordered from you. So that's an additional step that needs to happen because the conventional RAG system cannot cannot connect to that. But the moment you plug in an agentic rack system, what that can do is fetch the exact products that a customer has ordered, then ask a question for those specific troubleshooting requests and provide a response back. If the the result is that you need to order a replacement part, even the part numbers can be fetched based on what you've already gotten. So the meantime to the resolve the customer satisfaction, you know to your example Shane it just it's the number of things they can achieve with this is significant. Yeah, it's great, right?

And I know we're going to go into more. I just want to bring some of the comments on screen. So Kenneth came to the right live stream at the right times. He says it fits right in with the class he's taking right now. Database integrations with other systems. And so you know where MongoDB sits here is the operation of the transactional database, which is which is superb. Nathan is coming to the realization that many customer service bots aren't agentic rag, just conventional rag perhaps for most. So which leads me really to the next next step. So this obviously makes sense.

If you put this flow chart in front of any potential customer, Sachin, they will go, yeah, this is going to help my business. This is going to help my customers. But the developers in that company are going to go, what's this mean to me? Well, how much work is involved here? So talk to us a little bit about how we've ended up here with, you know, essentially data work day to Grag as a service that we're going to be showing. Yeah, absolutely. So 2025 is supposed to be the the year for AI agents and we think it's going to be the year for agentic rag as well. So every time we talk to customers, agentics parts their imagination.

You know, we've had a couple of very interesting comments already when they saw the the flow chart. A lot of the enterprises or the, the organizations, they, they start with a DIY approach. This they would like to start the DIY approach. And that's, that's fine because you need to build up some experience. But the, we quickly realized that this is the complexity of doing this and the iterative nature of it makes it expensive and time consuming. And the issue with the time it takes to put together a solution like this is that you dilute your competitive edge because it's a very transformative technology and the story you have to adopt it the further behind you go. And we've been in the business of trying to make adoption of Gen.

AI applications significantly simpler, make it make it timely to adopt. And our goal has been like I said earlier has been to kind of enable the adoption of these technologies with ease of use and economies of skill in mind. So we would like enterprises to be able to do this without having to invest in expert AI resources or build large teams to do this. We would we have We were invited to an RFP actually, and one of the. The key points there the the company that invited us was making was that the question was, you know, do you have, do you want technical resources or not technical resources to access to build engineer applications.

The key aspect of the answer was that the closer we can get to the business users building this, the the better it would be because that would be the fast. I can't see that. I mean, it's sometimes we've all been there, you know, that, that maybe perhaps the business use case isn't translated, you know, completely or complexity enough down for developers and and kind of there's always a disconnect in the middle there somewhere. So I can see that, that if if the business use case and those folks putting that together can actually use or manipulate the system. That makes a ton of sense, right? Right.

And, and with the, the existing customers we have, we've, uh, we've seen their existing technical resources dive into this because they understand it so much better. And they can, they can create transformative experiences and workflows without having to actually go and learn a ton of stuff. They already know their domain, they know their business and they can leverage that. So to enable this, we'll have an identical service offering, which is based on three pillars. Now I'm going to provide an overview because I think showing this would make a lot more sense. So I'm not going to go too deep into each of these, but I'll talk about them so we have an idea and then I can refer to this when I'm actually showing it to you. Brilliant.

So, yeah, so the first part is the agent hub, which is all things agents in data works. So that's where you have, that's where you build agents and that's where you build these sophisticated experiences and then you can take them to production and you can operationalize them. So is there a playground there, Sachin? Is there some way you can load sample data etcetera and kind of get your proof of concept up and running before you take it further? Definitely, yes, absolutely.

So Data Works itself is built on a data studio that allows you to connect to a real number of data sources, ingest data, transform it, and it's optimized for AI pipelines. And when you connect to these data sources, you can make them available to agents. Now the way you do that is you kind of interface the system you're connecting through something called a tool. So the agent can talk to that system via this tool interface. And if you, if you, if you think about this, we're talking about creating these workflows that span the enterprise. So we are pulling in data where these tools from like different departments and different teams and kind of bring it all together in an agent.

So having a centralized management capability where you discover these tools and you create them and you manage them and you audit them would make sense. So that's, that's what we call the tools repository. And then finally in ease of use is our goal. We've kind of built this agent builder, which we kind of spoke about very briefly in the introduction and I'll, I'll spend a lot more time on, which is our no code solution for building. Not only is it no code, we've kind of gone down the part where you can instruct it in just plain English and I'll show examples of that.

And finally, the third part of this solution is our conventional rag builder. It's a no code system again, where you point and click. And we showed the rag builder on your show, I think last year, Shane. Yes, indeed. Remember that one? Yeah, yeah. So so the the Rack Builder allows you to build high quality rack pipelines with just a few clicks. We've had customers build these things and deploy them in a matter of hours. No need for any expert resources, no need for any additional teams. And what this enables is that as a tool, you can plug this into an agent and that gives you access to unstructured data, whether that's you know from a PowerPoint or APDF or images or you know, web pages or whatever.

And they can be on SharePoint on your wiki, they can be on Google Drive, and they can all be pulled into this. OK, excellent. Sorry. As a service offering. Yeah. So all the tools at the disposal of the developers, depending on how they want to use it on leverage, ETC, as well too. And you're consistently trying to make it easier. So as you said, it's, it's now not just no code, it's now natural language. So talk to us a little bit about that. Maybe it's part of the demo, right? So talk to us a little bit about how, you know, kind of that's going to help developers, how easy it is to create those agents with natural language.

Sure. I would, I would love to do that. So before I talk about the agent builder, I just want to spend a slide and then and then we'll we'll start showing stuff and talk the demo and the agent builder. I wanted to speak about how we are approaching the whole problem with enterprise agents. And so that's going to eventually build into you know how we are putting it all together using the agent builder. So since we are building enterprise agents, we aren't targeting general purpose conversational agents. And the difference is fundamentally that enterprise agents are purpose built for a specific set of tasks. You want users to be able to achieve something, but also equally importantly, you want the agent to be able to identify when a user is asking you to do something that it is not meant to do.

Because you don't want an enterprise agent to go off the rails or be completely uncontrolled. So it's very, very important that you know you have necessary guard rails. The other issue that we should be very aware of is that the, the tools repository has, you know, has access to sensitive data all across the. So if an agent has access to all of this, then the attack vector and agent becomes very broad. So you want to contain that to the extent that it makes sense. So, so any agent tech architecture needs to kind of handle these.

There are other aspects to it, but these are some very interesting issues that are worth fixing. So, so we've, we've approached this problem in a particular way. The the way we've thought of this is that an agent solves a particular problem space and we we partition the problem space into non overlapping segments that we call scenarios. OK when a user asks a question. Umm, based on the user's intent in the question, the agent classifieds that into one of those scenarios and answers them from within that scenario. I'll try and.

And so if it doesn't actually get classified into any of those scenarios, then the users asking us something that the agent is not meant to do, and then we can just and respond. So let me illustrate that with an example. Let's say we have an agent that enables a customer to do a bunch of things. And one set of those things is to be able to query their profile and to update some parts of their profile. Maybe they can update their own shipping address, maybe they can update their preferred payment methods. And so anything related to profile updates can go into a scenario called profile.

And then if agent also allows you to provide feedback to, you know, past orders and all that, then that can be in in a separate scenario called feedback. So now the agent can route the user's questions to the right scenario. And anytime the user asks a question that does not fall into one of these, we can have the agent do something specific. OK, OK. That makes sense. Yeah, Yeah. Because, yeah, you're still trying to have that good customer experience, but you need to make sure you've got the right guardrails in place. You're dealing with a lot of customer and sensitive data. So yeah, it's a complete, it's a complete system you've thought of.

You've thought of most of the pitfalls anyway. Right. And, and the thing that we do is we, we classify the intent, not the actual text. So, so even if the users like typed a follow up piece of text that's, you know, that could be in isolation be assigned to any scenario or none at all in the context of the conversation, the agent would classify it to the right scenario. So you, so you don't, you don't have a rigid conversation that you're having. You can still have a very normal conversational flow in the in the in the agent, but it can still go to the right scenario. The other thing that scenarios get us is that if you, if we have a profile scenario, it just needs access to a couple of tools that help it fetch profiles and update profile feeds.

We really don't need access to, you know, orders order history, order status or feedback or anything else. So, and a scenario for us can be a curated subset of tools from the tools repository. So that gives us a very diminished cast radius for when a scenario has been assigned for a user's question, even if the agent is getting confused, you're limited to the number of tools that are within the within the scenario. OK, the yeah. And there's a lot of research that you know, that shows that the lesser number of tools you have that an agent needs to create a plan with, the better the OR more reliable the plan is. So we're trying to optimize the ability for an agent to reason well as well.

There are a few more aspects to enterprise security access that make this a little bit more interesting, but I think there are some of the higher level concepts that that we will build on when we when we do the demo. Perfect, perfect. No, that's that's very clear. And again, should anyone have any questions who's joining us on YouTube or LinkedIn to throw them into the comments and we'll try and take care of them as we have done already and that will be great.

Thanks, Sachin. OK, so I think Shane, now's a good time to probably jump into the demo. Definitely. We know our audience love the demo. We've got the slides, we have the background there. We can see that, you know, the architecture and the use case is very clear, but there's really nothing like seen it in action, Sachin. So I'm very much looking forward to this. And I'm, I'm very excited to show this, this, this is, this is the part I was waiting for as well.

So, so we've built, like I mentioned earlier, we've, we've built this in collaboration with the, the Mongo DB retail solutions team. And all of our work is available as blogs and videos and and it'll also become available in Mongo DB's fantastic solutions library resource. That's that's on it's way. But the blog and the video is already out and we can share the links for all of that. There is also a GitHub, a GitHub repo that has very detailed instructions on for for anybody who wants to try to do it by themselves. In fact, I would urge you to write it out for yourself and in case you get any issues, reach out to us on Slack or on GitHub itself.

So let me talk to you about what we are going to build. So I'm going to build this agent from scratch, all of it on the call here. This is going to be the back end of the agent. This actually does that agentic workflow using Agentic Rack. So the MongoDB Detail Solutions team has a showcase MongoDB ecommerce site called that highlights the application of MongoDB technology to that specific domain. It's fantastic actually. And then there was this idea to showcase a customer support chat bot on that ecommerce store. So, so the typical how can I help you bought on the bottom right corner.

So that lets you talk to it and this bot can do two things for you. One is users can ask it questions about store policies, you know, very, very similar to what you could do with a rag application. Basically, you ask things like, you know, how long the shipping take, what kind of products cannot be returned, that kind of stuff. So we can do that. And the other thing that we can do is we can or users can do is that they can ask specific questions about their orders, You know, things like what is the status of my order?

Can I cancel it, that kind of stuff. All right, so, so let's let's assume that I am the I am the person who's being tasked with building the back end of this agent in data works. And I have a product manager who comes to me and says, hey, here's the business brief about what we're going to build. It's it's text from the product manager that says, writes the agent and it says that it's going to be a customer support agent. You know, it helps the portal customers.

There's some text about, you know, what kind of behaviour you want there. There's specific instructions here about what users can do with the agent. And then there's some text care about what the agent should do if the users, you know, asking stuff that the agent can't do right. So that's good. And then the PM tells me that we have access to two things. One is APDF, that is the policies document that we share with everybody on, on our web on our portal.

And that's you want to answer questions from there. So everything is consistent that that's fine. And then I have access to the the operational database for orders, which is a Mongo collection, MongoDB collection. And that will allow us to basically understand when a user asks about a specific order, we can fetch that from there. All right, so with this background, let's let's build this from scratch. All of it. And I have a working version in the next 10 or 15.

Minutes and using that exact brief there, Sachin, that you've just gone. That exact brief, perfect, perfect. We'll build exactly what the the product manager wanted. That usually doesn't always happen, but I'm looking forward to seeing it in this case. For those tuning in, I've shared the blog links and also the video links in the comments as well too on YouTube and LinkedIn, so you can check those out and hopefully maybe not. Now for watching the other video, stay tuned to the live stream, but but afterwards, please, please check that out.

I'll put the GitHub repo up shortly as well too. Thank you. So, so I urge everyone to come to Airworks and sign up for a free account and give this all a spin and you can basically just try it for free. I already have an account, so I'm just going to log in and I let's just confirm that the Zoom level's good as soon as we get in here, that that looks OK, right? That looks good to me. Yeah, it's coming through. It's very light. No problem. Perfect. OK so so here's here's what we're gonna do. We have two data sources.

So we want our agent to connect to a RAG application so users questions can be answered. So that's one. And then we want to connect it to Mongo, so that's the other one. So the way I figure we've got to create 2 tools and one of those tools needs to be connected to Mongo and one of those tools needs a RAG application. So let's start with the RAG application first, because that's that'll take us a minute or so and then we can build the other one. So that's the policies etcetera that you want that's. The policies 1.

Exactly. Yeah, that's the policies 1. All right, so, OK and all right, so this is this is Dataworks. This is where you can build, this is where you can launch the the Rag builder. There's one piece of prep I have done here for the Rag builder, which is that I have plugged in Dataworks is open AIAPI key and configure a couple of LLMS already. So if you are doing this, you would bring your own and you would you would put that in. So let's. Do you support a broad range of LLMS in dataworks selection? Yes, we do.

We support Bedrock, we support Open AI and a bunch of others. So yeah, so you could, you could bring your own from any number of them. Perfect. Yeah. And, and I have, I don't have anything in this account, so everything's going to be pretty much empty. But if you had tag applications, you'd see a list of them here. But now that we don't have any, we fix that. We create the first one. So let's say if this is B fee total policy, which is and seems like a reasonable name for it, and let's pick GPD 4.

We could pick any, any one of these. I'm going to pick that one. So like I was mentioning in the slide, data works is built on the foundation of a data studio that allows you to bring data from many different sources, many different formats into the product and transform it into all kinds of things in so So if I did that, I could use data set that's already been transformed, but I'm not going to do that. I'm just going to pick up the PDF from my local disk and this is the no code rack builder. I'm pretty much just going to pick the defaults. Shane, I'm just going to walk through all the screens and just except for providing the PDF file, everything's just going to be default because that's going to be just fine for us. But I will point out a couple of interesting things as we go through it.

So, you know, we realize what is possible. So let's continue here. I know it's APDF. I'm just going to pick it up from my computer here. Sachin, you might go one zoom level more on the on the platform again if you can. On the on the browser. Yes, yeah, yeah. OK, I'll do that as soon as get there. Perfect. Yeah. Once you're back in, it's. Yeah, some of the screens a little bit. You're squinting to read some of it. And I know our audience will. Yeah.

This one, this one's the. This one's always. Windows 12 Choose, there's no problem. Yeah, yeah. I can't. I can't help that so, but this one I can. That's perfect, perfect. Excellent product. Thank you. All right, so I got the PDF, let me upload that and that's done. So let's save it. So it's it's chosen a default location to upload that it's in S33 account data works, gets some S3 space allocated to it automatically. That's perfectly, perfectly fine. I don't need to change that.

So we'll just move forward. And when we move forward, you will see an additional choice here. I'm not going to change anything. I'm just going to go next, but I'll just talk about what this is. This allows us to plug in custom data flows for ingestion, like, you know, chunking and vectorization. And then where do you want to store it? So you could pick your own embedding model, for example. There are a number of different options for strategies and various parameters and how you control that. Ultimately this is.

But in the default case, like I said earlier, it is going to go into Mongo, which is just fine. So no changes here, we just use this go forward to. Pick the table. But people have the choice to choose their own depending on their particular application and what embedding models suit that application more right? So. Right. Yeah. So if you have a embedding model that is particularly tuned for a domain like, you know, financial services, you could use that.

We have a general purpose document, so a general purpose embedding models, it's just fine. Perfect. This is where you configure your retrieval. The conventional drag sequential pipeline that I talked about in the first slide. Of course, this is a little bit more complex because there are additional best practices that have been put into this and there are more things you could do with it. I'm not going to change it, but in the default you get a hybrid retriever, which basically means that it will hit both a lexical index as well as a semantic index.

The semantic index is Mongo with cosine similarity with .55 as the threshold, and these are all good defaults, so we just let this finish. So that's. I'm a big fan of defaults, but I like the. I like the fact that you can change them there if you wanted to. So yeah, that's perfect. Yeah, yeah, make the default easy, but make the hard possible, right? Yes, exactly. Exactly. Yeah. So, so this is, this is, this has gotten started. It's going to pull in the data, it's going to do its thing.

It's going to provision a RAG application when it's done. So that's great. While it's gonna take a minute or so. So first, these things. Do let's just. Do the next step which is connecting to creating a tool to connect with mongo, right? So if I go here to configuration, I get the option to connect to a number of different systems. There's a pretty long list here. I have a option to connect to Mongo and I have already configured it in the. If you go to the GitHub the GitHub report you'll see that Dataworks is hosted A publicly accessible read only mongo DB instance. Perfect or get.

That to make the whole demo easier. Yeah, yeah, OK yeah, perfect. Thank you. So you can just use that, but there are also instructions on how to bring your own Mongo DB if you would prefer to do that. So you could go either way. I'm just using the one that Dataworks is hosted. I'm just going to kind of so it's fine, we'll configure it. OK, All right, so now I have a connection to a Mongo database. I'm just going to copy the ID here. Now the next thing I need to do is basically I want the agent to be able to send an order ID and then get an order object back with all the details in it from the operational DB. So I'm going to create a tool that does exactly that. So this is this is the agent hub. This is this is where we launched the agent builder and also the tools repository.

And Shane, I want to. I'm going to take this opportunity while I'm here with you on your show to announce that we are launching Agent Hub, the Agent Builder in preview and we would love for the audience to give it a try and give us feedback. Thank you. We've done something fantastic here and we're really excited about and we hope that everybody will find it interesting. It is in preview, so you might have some issues. Reach out to us. We have a stack community.

We are actively building a new version or the next version of it that's going to come out in the next couple of weeks. But you can already do a lot with what is there, and I'll show you exactly what is possible. Perfect. Listen, that's I'm thrilled you announced it here and that's great. I hope hopefully you get some users to try it out and get some valuable feedback as well too. That's brilliant. That would be perfect. All right, so I don't have anything right now here, but on the left is where I would see my agents, any agents I've created, and on the right is where I would see any tools that I created.

Let's start with creating 1. So like I was mentioning earlier, tools are the mechanism by which we plug in external data sources or make external data sources available to an agent. And that could be, it could be databases, it could be REST API web services, it could be rag applications, or it could just be utilities and all kinds of things that you can plug in. We are shipping with a bunch of pre canned integrations and there's a bunch more that are going to come out in just like a week or so.

So, but in this case, yeah. So in this case, we are connecting to Mongo. So let's let's start with that. And the way you deal with a tool is it's like, Shane, if I were to explain to you how you, how you should use something, right? So I would give it a name and then I would, I would describe it to you. If I give you a toolbox with a bunch of tools you aren't familiar with, I would tell you, I would point out a tool and say, hey, this is this is this tool and it does this, right? So that's exactly the thing that we need to do with an agent. We need to give it, give the tool a name, a name that kind of indicates what it does because it interprets that. So in this case, this is a good name because we are getting an order object from the Leafy.

For the Leafy portal, we need to give it a description so the agent understands what this tool does, and then we need to kind of tell it what inputs it takes. In our case, it takes an order ID, it's of a type string, and we give it a description. We say that it is the order ID of the user wants to get that. Sure. Enough. Right. And what this does is that if we if we throw a bunch of tools at the the agent, it can basically understand how to chain them together, how to use one's output into the next input in order to create a solve a particular problem. That's that's the goal here.

OK. OK. So and others would, would, would this be fair to say kind of others would call these kind of reasoning engine type logic etcetera as well too, right. It's understanding which is the right tool for the for the job with the details those extra details parameters that you're giving it. Exactly. And yeah, that's the reasoning part where it understands this and then puts a plan together to execute the to solve the problem. That's exactly. That's exactly right.

That's the reasoning part. So every, every tool is gonna have a similar concept where you describe it this way and we've not got the input, we need to give the output. Now the output in this case is a little a little bit more elaborate because we are going to plug in the output from the operational database as it is to the agent. No changes, no transformations, no simplification. We are just going to point it to the orders database and we are going to tell it that this is what the order object looks like. And then the agent just going to figure it out from there. So, so I'm basically describing it in it's, it's like any object.

You basically say this is the name of the object. It has these fields, fields have these types. And then again, there's a description. If you have more complex fields, for instance, this is a list of status history. You know, as the order went through delivery states, new items got added here every time the status changed. So this has a status and timestamp and so on and so forth. And this describes the output. So now given this, our agent knows that this is what it's called, this is what's meant for, this is what I should pass it, and this is what I will get back from it. OK, right, very clear.

And the only thing that's left at this point is actually tying it to a physical data source. So we connect it to the Mongo connection that we had made earlier. This is the same ID under add copy. And then we got to specify what database you want to connect it to. This is the name of the database, what collection we want to connect it to. This is the name of the collection orders. And then because the thing that we're doing here is we are saying given an order Idi want an order object back, we need a query predicate for Mongo. This is the the language in which Mongo understands a query predicate.

So we plug that in. The only interesting thing here is that this is a placeholder for what the agent will eventually pass in as the order ID. So if we get an order ID 123 when we actually make the query, we will replace this with 123. Perfect. Very clear. OK, OK all. Right. So let's let's say this and we actually we've done creating our first tool for Mongo. We need to create one more which is the one for the application. But so let's go and check on what happened there.

We gave it enough time so it is done. Job It has it. Is done, so let's take it for a spin. We'll ask it a couple of questions and see whether it's working fine. So this is the interface within data works to try and use your AG applications. There is an API could integrate this into like a search widget or whatever you want, wherever you want it within it makes sense. But let's ask a simple question so we don't have to read through a lot of text. All right, so that's start and suite. It says yes, you can cancel an order and then it points us to the relevant section in the document from where it. The reference is there, the reference tracker if you need it anymore.

Exactly perfect. And let's try another one that's also that also should be a short answer. All right, so that's great. So it looks like it's working fine. The one thing that I wanted to show here is that we have this probe that allows you to get visibility into what's actually happening when a conventional rack system executes. Yeah, right. Nice. That's great visibility into it. Perfect. Yes. So every step of what it did, and there are a few more steps than my slide because you know, we do a few more optimizations on it. But at a high level, this is the vectorization of the question. This is the the query to the lexical search. This is the query to Mongo.

So you see the results of the Mongo, the results from the Mongo database for the vector search. And then finally the context is populated into a into a prompt for the LLM and we get a response from the LLMS and this is the response from the LLM. Very nice. The level of I would imagine with your clients when you're showcasing this such and it gives a level of of of confidence and comfort in what's being built in the back end. If if they're going to, you know, leverage agents as they should do to do, you know, these tasks and certain amount of reasoning inside of these tasks. They want to be able to have, as you call it there, the probe to see under the hood exactly that's what's going on, right? Exactly, right.

So you're absolutely right. So the same visibility that we are providing to RAG applications is will be available in agents so that you can see exactly what the agents doing, what is the reasoning or tools are provided to it. So what was the plan it created? What what was the, what were the steps of execution went through, what did the tool return all of that. So you know you know how to tweak. It's full transparency, right? So that kind of, you know, I think one of the concerns, I mean, I do some of these shows and particularly we've done a couple of agentic ones is like, you know, am I letting this system off to do its own thing? Where am I safe?

Guards for the guard rails? How do I know? You know? As I said, the reasoning behind this. But this is superbly transparent here, Sachin, so that's great. Yes. And you made an excellent point again, Shane, which was that the other big reason to do this is for audit purposes, especially in regulated industries. So this is saved for every interaction, every question that's asked. So users can always go back to historical questions and see what happened, what happened there.

And you can also use this for analytics. You can see, you know how long something is taking, how large some context is, and then make some choices in terms of optimizing costs for by using the right LLM. And there's a bunch of things that you can do with it. OK. Is there in this rag portion here? Is there is there an element of memory inside and data works for this? If you're asking the the same sort of questions, does it build up that over time in terms of quicker responses or is it that not the case? There are there are abilities to plug in caching, so you could save on the cost of the prompts and all that provided your data itself is not updating.

Good. All right, so we built the Rag application, right? So Shane, the next step we had was to actually expose it as a tool so our agent can use it. So let's go back here and create tool. It's an AI app, so we picked that. Let's let's give it a name. I think I already have a decent one here, which is get leafy portal policy details. That's that's basically. What we're doing makes sense. And that's right, a description to it. The description is basically going to say that get answers to questions around store policies like shipping, returns, cancellations, and that should give it a general idea about what it can do. So we just have one application.

So let's pick the one that we just created and we use this. So this this interface is already populated because we know we're going to ask question and then you're going to get response. So that's already in there. Let's just give it a couple of examples. So the agent kind of knows what, what this tool can do. And those are the questions we asked earlier. So we can use that and, and, and that's it. Otherwise it's the same, same concept. It, it gets a description and gets a tool name.

So let's save it. And now we have two of our tools. That's, that's what we wanted to do. Now comes the interesting and exciting part of creating the agent and making this all come together. So we, we click create agent to launch our agent builder. And the first thing it asks is what do you want the agent to do? Right. And you know, I actually know exactly what I want my agent to do because my product manager told me what he wants it to do. You had the brief perfect.

I'm just going to go here and I'm going to paste the brief right in here. You're going to put all of that brief in there, Sachin, just like that. I'm. Just going to dump it. Yeah, absolutely. I'm just going to put it in there and I'm going to create. And what it's going to do is it's going to understand what's provided and it's going to, it understands data works agents. So it's going to assign parts of the brief to the right parts of the agent. It is going to understand scenarios.

It will break it down into scenarios. It will also hopefully suggest some tools to us so that we can use the scenario. And so it kick starts your agent development in a big way. In fact, it might, it might take us a very long distance here. And then you have access to doing whatever you want to do after that. So for instance, so here, here's a brief I gave and here's the response from the agent builder saying that it's created an agent. And let's just quickly take a look at what's happened here, right?

So the agent in Dataworks is actually a declarative specification. So it's basically defined by this Jason file and you don't actually need to do any programming or like or connect to any library or anything that you basically instruct the framework what you want and that prevents the agent for you creates the right prompts, the right reasoning, all of that. And the way we've put it together is that, you know, I was talking about this in an earlier slide, you compose a, an agent with a bunch of scenarios and, and the scenarios with tools, right?

So, So what we have here is a visual representational same Jason. And if you remember the brief, we have a persona for the agent that's been extracted from the brief that it says you're a helpful and professional assistant representing BFE portal e-commerce. So this came to brief. And then the other thing that came from the brief was, you know, if a user asked the question that the agent doesn't understand, then it should basically say this. And that's what it's extracted and populated that. And it also identified that there were two scenarios that the manager had in his brief.

One was to ask FAQs and the other was like to operate on orders, right? So let's, let's expand this, let's expand this and see what we got. It's a scenario to handle FAQs, greater store policies. We may have to expand that a little bit that might not that maybe that's fine. We'll see. We'll try, we'll test it out and we'll see if we need to change that. It picked up examples from the brief. We could ask it to create additional examples if you wanted it to do that.

And here it says that hey, I think this is a good tool to add to this scenario. OK. So it's suggesting the tool for that Perfect so. Now we had only tools, 2 tools, but it did exactly. But as you said earlier, like if somebody's using data works across the organization, there's going to be plenty of pre populated tools there. So exactly, yes, in this instance we only had two. It's going to pick from the 2. But as you say, you know, we're not reinventing the wheel here in terms of tools. So if the organizations need these tools and, you know, they're, they're applying them to customer service, then they're applying them to shipping, then they're applying them to, you know, maybe HR right or something. Yeah, I get it.

Exactly. Yeah. Exactly. And so and even between the two tools that we had, it did identify that the the Rag 1 is the right one to be added here. So so let's add that now. So that's that's fine. And then this one says to manage operation specific order. And again, I think that's a little brief, maybe we can expand that, but let's let's go and see what's going on. And here it says the Mongo get portal or a Leafy portal order is a good tool. That's that's true. I like that recommendation.

It's not sufficient though. So I'm going to go pick the other one as well because I want it to be in the context of the policy documents. So we add that as well. And you know, at this point we are actually done with what the PM wanted for the most part. We might have to tweak it a little bit because I think some of these descriptions may be a little short, but let's give it a shot. Let's see what it does. So let's let's use that and say, let's ask a question that actually it it doesn't know about. We haven't asked this before.

We didn't ask the dagger. We didn't put it in the examples of the tool. It isn't in these examples either. So it's, it's just a completely brand new question. And let's see if that works. It doesn't work. We might have to change the description so at this point the. Upper live demo. Exactly. So at this point, it worked just fine. Yeah. So the agent understood the intent, mapped it to the scenario and then executed this tool with that question and then provide us an answer back.

So that worked just fine. That's perfect. Yeah. And let's try and see if we can get it to do something for the second scenario, right? So I know that this order exists, so I'm just going to ask this question. Sure. And this one I suspect we might have to go to. No, I didn't have to. This one worked fine as well. So that's great. So we have a, this came from Mongo, right? And it's it's great because it got us the order. I find that, you know, LLMS are remarkable pieces of tech. I mean, without me having to tell it, it's actually figured out that the the final order status is delivered, which is great.

Yes, I don't want to rely on that every single time. So, and I also find this a little hard to read. So let's let's try and give it an instruction to maybe format this output a little bit more legibly, OK, and be a little bit more consistent about it. So. Fine tuning the output really now a little bit. Exactly. And and we're just going to instruct it. We don't need to do anything more than say that if the user requests the full order details, then you must use this format. But for everything else you can just respond briefly. OK, right, so nice.

So let's ask the same question again and we'll get a completely differently formatted answer. Actually, it follows this format. And in this case we've actually told it that for status, you must show the most recent status from status history. So there is no, no, we aren't relying on the, the LLM doing the right thing. We're instructing it that this is the right thing to do. So that's, that's one way of doing that. Now, now I want to talk about, you know, we talked about the agent builder, right? And this is the agent builder.

I mean, you can just give it a brief and it'll kick start a agent for you. If you want to add new scenarios, again, you can just type it in English and it'll create a new scenario and do this the same thing, you know, propose tasks and all of that. But you can also interact with it with this conversational agent. So for example, if I wanted to say let's do this. So for the for the queue scenario and the what's the other one called Order Order of scenario of scenario update the instructions to be. When a users question cannot be answered, respond with with and then please append the scenario selection failure message. So we are just going to instruct it to do something just just plain text.

You're just talking to the agent builder and you're saying, hey, this is what I want, right? And hopefully what it'll do is it'll update the scenarios for us through a conversational capital. OK, OK. It's incredibly impressive, very powerful, and you know, to be able to interact at such a, you know, as you said, you took the brief and you just cut and pasted the full brief into the beginning and then it's gone off on this. But I love the safeguards that you have, the ability to go expand out each of the sections, see what it's present to do, and go back in and modify those. It's a incredibly comprehensive Sachin. It's very, very clear to follow.

Thank you. I I really appreciate that feedback. And there's one one key thing on this saying that I didn't stress because I wanted to talk about it separately. The thing about the agent builder and the reason why we are so excited about this is because this this interface on the left you have this more traditional UI based interface and or a form based interface. On the right you have this conversational thing that you can interact with. All of this is powered by an agent that is written in the exact same database agent framework, the same framework that we are giving out to our customers with no additional capabilities.

So anybody could build a sophisticated UI with capabilities like this using our agentic framework. And right from the, the time we started down this thing, you know, Sachin Smothra, who's the, the CEO of Dataworks and I, you know, we, we wanted to create a conversational UI that demonstrates the capabilities. It also pushes the boundaries of what our own framework is able to do. And we wanted our own stuff in production before any customer actually had to do it. So we rely on it ourselves, and we have. You're, you're using, you know you're, you're using the tool to build the tool, right?

So. Exactly, exactly. And, and not just that, I mean, we have a Jason that describes our agent builder quite like this one, except that it's a lot more, it's larger and more complex, but it's still exactly the same concept. And the fact that we can build this on our agent framework, which means that, you know, we understand much better now what's what's easy, what's hard, what's possible, and. Yeah, so, so this is our our take on, you know, building agents using natural language.

We took inspiration from the the revolution in coding agents, for example, Although in that case, you know, like Cursor and you know, Aider and a bunch of those guys or copilot for that matter. But in those cases you do end up going back to code and working on that. That's something we wanted to avoid here. So we went down a declarative path. So you basically build out the Jason and then you have you have a conventional UI and a conversational UI that allows you to do that.

It's, it's incredibly powerful. I can only imagine the, the things that people get to build in here too. The one concern I have is we've all met the product manager, Sachin. So he goes, here's my brief, turn around 30 minutes later and give him backup product. He's just going to give you more and more briefs. But you know, this is the way the world has changed, right? So no more. Here's the functional specifications and we'll see you in eight weeks.

And can you conduct 4 sprints, you know? Exactly, exactly. And, and it's, it's amazing you bring this up, Shane, because we have this customer who, who, who had this, who has this problem into tracking processing of a customer's order within the enterprise, a large enterprise. And the processing goes through very many stages. And I think they've probably built it up organically, acquisitions, whatever. So it's a little hard for them to kind of bring it all together.

So they had a traditional project they put together, you know, get the teams on boarded, get, get all the, everything set up. That takes time. Then you put a solution together that takes time. And here's Nikhil, who's the CTO of Databerks walking into a demo and building these things in the, in the demo and showing a prototype for in like half an hour. So it's, it's, it's transformative. And like you said, I'm really excited about where people will take this. It's incredibly impressive.

And look, as I said, I've done, this is probably my third show with Dataworks. I see what your team builds so, but this has been the most impressive demo today because I just love how it all. It builds on everything that I've seen Dataworks do before, but now it's such a compelling solution. I think it's amazing and it seems so slick and effortless. Sachin, were there any kind any unexpected challenges or roadblocks putting this together that you you hadn't expected and how did you overcome them if there? Were no, there were.

There were a bunch of things. Because so much of this is new, we started fiddling around with agents, experimenting with them sometime last year. Our first implementation was React, and React was great, but we struggled with certain aspects of React. We just felt a little uncontrolled, I don't know maybe if it was our implementation or or reacts gotten improved since then, have no idea. But we kind of moved away from React and picked another framework to implement called LM compiler that's served as well.

But that was one of our first was to kind of choose a foundational agent implementation that would that would be good. The other thing was coming up with, you know, coming up with what would be easy to use to build agents, because that was our promise. We did that for RAG. We want to do that for agents. And we were so early with it. It's it's a little hard to imagine whether it'll all work out. So that was that was challenging. Originally they thought this would be a proof of concept, but the proof of concept kind of convinced us that we could actually put it in the product. The third, I think challenge is, is just the user experience, right?

This is, this is new even for our, our, our UX person. She's, she's also coming to terms with, you know, what are the interaction models? How, how do you present this to not how do you, how do you present this and how do you present this to the development team that needs to build it? How do you capture all the interactions? So that's, that's been interesting there. There's so many new areas here that we are all learning together. I think it's just something a fun journey. Yeah, well, look it, it certainly looks superb. I know we're over time.

I appreciate everybody still joining us etcetera as well too. Throughout I put up some of this that you had shared with me, Sachin. So if anybody wants to go back, if they're looking at the recording, you can dig down through the comments and you will find a link to the blog posts, the video, the GitHub repo for this, and also a link to sign up for for data works and try this yourselves. So and and that's sign up for free and, and get in there and start playing around Sachin, right?

Yeah, absolutely. Yeah. This is the this is the read me that has very detailed steps for everything we saw today. So you can, you can do this. You can sign up for free. And you know, like I said, there's a hosted Mongo DB that you can use. So yeah, absolutely. The only thing you would need to bring is your LLM key. Yes, you saw that on the way in as well too. Well, look, I mean, I think it was stunning in terms of, yeah, you started the demo, there wasn't anything in there. OK, You had, you had added the LLMS and you had your connections etcetera set up as well too. But other than that, you sent it off, it created the embeddings, it built that agent, it then went off and you added the other agent and then you drop the brief in and it just worked, which is incredible.

So I think, you know, sometimes we see, as I said at the intro, we see a lot of really cool AI demos and but they're, I don't mean to say that they're smoke and mirrors, but as you said at the beginning, they're not very practical. This was incredibly practical. This you could easily see how you could apply something like this to most businesses, most industries. So I appreciate how swift and how easy you made it all look, Sachin, and and as you said, you're everyone else can go and check it out as as well too.

To wrap up this, which has been a great conversation. Where's next for data work? So where do you see this type of technology going? Because we really are, you know, the, the Gen. AI space 2 and a bit years maybe there. So, um, you know, LMS and foundation models, et cetera, et cetera. But the agentic space is superbly new. So what's next? Yeah. Yeah. And I'll keep this brief because we are we got gone over time. Um, so we talked about conventional drag already and you know that powered, um, information bots or search widgets and stuff for that agentic rag. It's just been amazing.

I mean, in all my 25 years of experience, I haven't seen people react to conversations about agentic Rag or demos or presentations the way they react to it. The moment we talk about it, there are folks on the call that have ideas whether it's, you know, automation or some operational efficiency or just something transformation that instantly clicks for them. So I think we are at the doorway of a vast sea of opportunities with Integrat. So we are trying to solidify the offering.

We we have a number of ongoing Pocs and conversations around agentic lag. So that gives us a lot of insight into what people won't build and that'll go into the product. Of course, there's a lot of work already happening there. We are integrating it where it's required, like, you know, Slag, Zendesk, Salesforce, wherever a conversational agent could be required that is driven by this. And then as, as, as it gets used and deployed and confidence builds the next step, and we're already having conversations around this next step is going to be, you know, making actions from it doing, you know, doing small things, maybe update tickets, close tickets, but then eventually we start doing actions on behalf of the user, you know, maybe updating Salesforce. So then we get into actionable rack and we have a couple of customers who are already making these plans for, you know, how they can automate some of their workflows by triggering them, triggering the agent from human triggers, the agent with some inputs.

But that once they start to see enough confidence in the reasoning and the planning and you know, it does the right thing. And we have the supporting tooling around that that's going to move into triggered by an event or triggered by, you know, schedule triggering whatever. And that's going to be autonomous again. So there is there's a whole journey here as the confidence and experience with it increases over time within the enterprise, we'll see various aspects of it. And it's not going to be, it's probably all going to live together, probably have some autonomous agents and some action about diagonal of that.

And you know, it's, it's super exciting where we're going with this. It's it's incredibly exciting and it's it's also nearly overwhelming how quick things are progressing as well too. You know, if I think back, you know, when we started to see some of this and then, you know, even back to when we started to see rag being built, it's like, wow, we've moved on now we've got that. That's it. You know, if you if you were to do a yeah, rag demo still exists, but like, you know, the agentic piece layered on top, the reasoning behind, you know, how it knows where to go for answers, how it knows how to choose. It's brilliant.

And and you know, then, if you take what data works have done, which is as and kudos to your UI designer. I think she she did an amazing job. And then obviously the developers and implementing that super easy to follow. So I very much look forward to getting you back for one of these purple or green boxes when we get to the actionable and the autonomous, right so. That would be wonderful, yes. Get you back on the show. But for today, this has been superb and really powerful.

Clear demo that I think everybody will agree it's been great to get the comments in. Sorry we didn't get to go through a lot of them, but I think it's great. But as you, as I said, if you want to learn more, there's the blog, there's a video and most importantly, there's the repo, but also the link there to Dataworks where you can create an accountant and see it for yourself. So umm yeah, Sachin, chief architect of Dataworks, this has been a superb stream. Thank you so much for your time.

Thank you. Very much Shane, it's a privilege to be here and show all this to you and the audience. Thank you so much for the opportunity. Well, listen, it's a it's my privilege to host you. Thank you so much for your time and how clear and straightforward you made this all good luck. And I know tons of work behind the scenes to build products like this. But the proof is very straightforward in that you know, you, you set the scene and you did the demo from scratch and it just worked. And I, I think that's great.

So, umm, certainly we'll get you back as data works, move forward into that journey further, have new products to show. Delighted to have you or any of your colleagues back on the show, Sachin, Thank. You really appreciate that. Thank you. Excellent. And look for me and all of the other folks here in MongoDB. Thank you all for tuning into these live streams. As I said at the intro, keep an eye on our YouTube channel and LinkedIn for other streams coming your way that are exactly like this. We do appreciate everybody joining in and viewing and adding the comments.

So until next time from me, Shane McAllister, and from amazing guest Sachin. Thank you so much for joining us everybody. We will see you on another podcast live, hopefully shortly. Take care. Goodbye.

Transcript supplied by the publisher with the episode.

The MongoDB Podcast

by MongoDB · English · Tech & Science

Whether you're building your first app or scaling to millions of users, The MongoDB Podcast brings you the conversations worth having. Developers, founders, and technical leaders share how they architect systems, navigate hard decisions, and build with AI.

More from The MongoDB Podcast

  1. S1 · E266 · 22 May 2025 · 43 min

    EP. 266 How MongoDB Scales Atlas & Reduces Cost

    🔴 LIVE: How MongoDB Atlas Is Redefining Elasticity for Cost-Optimized PerformanceWelcome to this special episode where we explore the cutting-edge elasticity features in MongoDB Atlas—designed to help organizations optimize costs without sacrificing performance.Whether you're a software engineer, DevOps lead, or IT decision-maker, this conversation will show you how to scale smarter, faster, and more reliably.

  2. S1 · E265 · 16 May 2025 · 1 hr 17 min

    EP. 265 AI for Happier Teams: L10's Real-Time Feedback Revolution

    Is waiting months for employee feedback a thing of the past? Dive into the future of work with Shane McAllister and L10 founders, Zyrian Chung and Keith Chan . Discover how their AI-powered platform collects daily insights to transform workplace culture, empower managers, and address issues like silent quitting before they escalate. Learn how real-time feedback and AI can create more engaged and productive teams, and get a peek into the tech (including MongoDB) that makes it possible. Stop guessing, start understanding your team today! TAGs: #EmployeeEngagement, #AIinHR, #WorkplaceCulture,…

  3. S1 · E259 · 1 May 2025 · 59 min

    EP. 264 Beyond the Database: Mastering Multi-Cloud Data, AI Automation & Integration (feat. Peter Ngai, SnapLogic)

    ✨ Heads up! This episode features a demonstration of the SnapLogic UI and its AI Agent Creator towards the end. For the full visual experience, check out the video version on the Spotify app! ✨ (Episode Summary) Tired of tangled data spread across multiple clouds, on-premise systems, and the edge? In this episode, MongoDB's Shane McAllister sits down with Peter Ngai, Principal Architect at SnapLogic, to explore the future of data integration and management in today's complex tech landscape. Dive into the challenges and solutions surrounding modern data architecture , including: Navigating…

  4. S1 · E262 · 16 Apr 2025 · 57 min

    EP. 262 Solving Unstructured Data Challenges with AI & Vector Search

    **(Note: Spotify listeners can also watch the screen sharing video accompanying the audio. Other podcast platforms offer the audio-only version.)** Struggling with millions of unstructured documents, legacy records, or scattered data formats? Discover how AI, Large Language Models (LLMs), and MongoDB are revolutionizing data management in this episode of the MongoDB Podcast.Join host Shane McAllister and the team as they delve into tackling complex data challenges using cutting-edge technology. Learn how MongoDB Atlas Vector Search enables powerful semantic search and Retrieval Augmented…

  5. S1 · E261 · 1 Apr 2025 · 1 hr

    EP.261 Building Next-Gen AI E-Commerce with Storecraft & MongoDB | Live Code Demo

    MongoDB staff developer advocate Jesse Hall teams up with Storecraft creator Tomer Shalev to dissect how this open-source commerce platform leverages MongoDB for scalable, AI-driven workflows. Watch them live-code integrations (vector search, dynamic pricing, email automation) and explore real-world use cases—from custom discount logic to OpenAI-powered product recommendations. Perfect for developers building modular, future-proof commerce solutions.

  6. S1 · E260 · 26 Mar 2025 · 58 min

    EP.260 Vector Search Secrets Revealed! - AI-Powered Image Search with MongoDB - Live Demo

    Ever wondered how companies like Amazon or Pinterest deliver lightning-fast image search? Dive into this episode of MongoDB Podcast Live with Shane McAllister and Nenad , a MongoDB Champion, as they unravel the magic of semantic image search powered by MongoDB Atlas Vector Search ! 🔍 What You’ll Learn : Why semantic search is a game-changer for AI-driven applications (spoiler: it’s all about meaning , not just keywords!). How to transform images into vectors (embeddings) and store them alongside your data —no clunky ETL pipelines required! A live demo showcasing real-time image search on a…

  7. S2 · E8 · 5 Jun 2026 · 56 min

    Modern AIOps:
What It Takes to Build Reliable AI Products

    Watch this episode as a video on Spotify! In this episode of the MongoDB Podcast, host Jesse Hall sits down with Karthik Kalyanamaran, Co-Founder and CTO of Langtrace AI, to discuss how engineering teams are building reliable AI products. Moving from traditional, deterministic software engineering to the non-deterministic world of Large Language Models requires an entirely new approach to debugging, testing, and monitoring. Karthik shares his journey from scaling observability infrastructure at Coinbase to creating Langtrace AI, an open-source LLM application observability platform built on…

  8. S2 · E7 · 28 Apr 2026 · 15 min

    How Rox Is Rebuilding the CRM for the AI Era on MongoDB

    Watch this episode in Video Format on Spotify . Are autonomous agents about to replace your traditional CRM? In this episode, Anaiya Raisinghani (Sr. Tech. Evangelist, AI Startups & Ventures at MongoDB) sits down with Ishan Mukherjee, Co-Founder and CEO of ROX. They dive under the hood of ROX, the world’s largest-scale revenue agent company that is building AI to handle the end-to-end revenue cycle autonomously.Ishan breaks down his founder journey—from Amazon Robotics to Apple's Knowledge Graph—and opens up about the technical realities of building AI agents today.What you’ll learn in this…

  9. S2 · E6 · 21 Apr 2026 · 45 min

    Capgemini’s GenPAL: Payments Data Monetization in Action with MongoDB

    Watch this episode as a video on Spotify ! In this episode, Luis Pazmino, Industry Principal for Financial Services at MongoDB, sits down with Saurabh Khandelwal from Capgemini to explore how financial institutions can transform payments data into a strategic revenue engine. The conversation dives into GenPAL , Capgemini’s solution powered by MongoDB’s modern data platform, and how it enables organizations to move beyond data storage toward real-time intelligence, AI-driven insights, and data monetisation . In this episode, we discuss: • Evolving Payments Landscape: Key shifts shaping data…

  10. S2 · E5 · 15 Apr 2026 · 47 min

    Why Python Devs Are Ditching Raw Drivers for Beanie

    Watch this episode in video format on Spotify! If you're building Python applications on MongoDB and still writing raw queries by hand, you're leaving a lot of developer productivity on the table. Beanie, the async-first ODM built on Pydantic, was created to fix exactly that — and this episode goes deep on how and why it works. You'll learn how Beanie maps Python objects to MongoDB documents without sacrificing atomicity or performance, why async-first design matters for modern Python stacks, how schema migrations actually work in a document database, and what the deprecation of Motor means…

Every episode of The MongoDB Podcast →

Take it with you

The Melo app keeps playing with the screen off, works in the car and on your watch, wakes you to your station, and browses the whole catalogue offline. Free, no ads, no account.

Get it on Google Play