[0:00]Hi everyone. Welcome to this episode of hands on with AI agents. Now in this episode we have an interesting topic for you. It's how to build a full-blown data science agent.
[0:14]Let's hear more from Mel. Hi Mel. Hi, thank you so much and hi everyone. I'm very happy to be here and very happy to be able to work with through the data science multi agent system that we built as mentioned on our open source Google SDK. So Yes, let's jump right in. Yeah, what do you have for us? I came prepared so we're doing a lot of technical hands on stuff, but before we dive into the front part, I wanted to briefly touch up again on the intro, like what are agents, where did we come from and where are we now? agents. A very brief refresh on the agent development kit as well. Then I'm going to work through the architecture of the data science agent and after we're going to see the front part with the technical data. Okay, I can't wait. Let's get started. So as for the introduction, I just want to very quickly iterate on where we came from with and where we are now. So when we started in the early days, there was mostly just and. You may remember these days, right? And then there was the hot topic of rock pipelines being the next big thing. So everyone was building their rock pipelines to connect to external sources so that the is a bit more useful. What came out Afterwards is then adding function calling and tools to the LLM. So we had done now which is in the model the LLM we had the right pipeline and then we had the tools that we essentially hard coded to the system for it to do stuff on our behalf. The next evolution and this is where we then come to the agents that's the container that you see in the slide deck is essentially having these components the same components the LLM the pipeline, the tools. But now we have a bit more sophistication behind it because now the LLM agent is doing the reasoning and planning. It knows when to execute the tools and it's also handling the session and the orchestration. And the last thing that you see here is moving from a single agent to a multi agent system. So now you also have to orchestrate not just one single agent and it's but also the communication between the different agents. So to summarize again what is an AI agent? An AI agent helps you plan reason and execute to do certain tasks on your behalf. So as I mentioned for the container that you remember from the previous slide. It comes with orchestration as well. So it has memory, it handles the session for you. It has the reasoning and planning capabilities as well so that it really knows when to how to execute a plan and when to use the tools did you provide to it? And now in the multi agent system went to route and went to call other agents as well. In the second part I want to give an overview again very on the agent development kit. We have another video series just on the agent development kit and also building your Hello World agent on top of it. So if you haven't seen it, I highly recommend that you take your time and watch it because here I'm just very briefly walking through the stuff as a reference and we will focus mostly on the data science agent. So just as a refresher to the AIK is a client side code framework and SDK to build sophisticated multi agent solutions. So it helps you by providing all of the necessary things you need to build multi agent systems. It handles a session for you, it makes it very easy for you to set up your agents and to set up agent tools and multi agent systems as well. So it's a very very helpful research to get started with multi-age systems. The tools that come out of the box with the AK or function codes, you can also install your audio tools, like for example for your files, or VRX search or VRX. And the very need thing here is as well that you can create based on custom tools by extending the base tool class. All right, before we dive into the core base. Let me walk you first through the architecture and let me briefly walk you through each of these agents and what they do. So starting from the middle with the database agent, as you can guess, the database agent is there to handle the network. Meaning it translates the user query into the proper sequence to cure the database. It's also the one agent that has the tool connected to our set to the sequel and to retrieve the data for us and it comes with a sequel and fix as well to make it a bit more robust.
[5:08]What we've integrated in the code base are two methods to build the sequel. The one is by scratch using. This is what I'm going to show in a bit more detail. The other thing that you can also play around with is Chase sequel. So Chase sequel was a paper from Claudia Research that was published a while ago and they really came up with a method to properly and robously build sequel from natural language queries. And this was also the method that is on the higher ranks on the bird bird from our own research organization. So code is there, you can play around with it, but we won't be going too much into detail in this session. The other agents are the data science that you see at the top. The data science as the name suggests does the to. So it's there you do analysis, um it can generate plots. It can essentially just execute Python code to help with everything on top of an oscilloscope. This works with the code interpreter extension, we'll also see this in a bit. Then we have to be sure ML agent that they're very bottom. So ML agent is there to support with a bit more sophisticated data science workflows. Everything that you can do on ML, you can do with a ML agent. It's really there to give kind of support, it can write the BML sequel statements. So you can really use it to train models using for inferrence and do other sorts of analysis. And everything comes together with what we see on the left hand side with our top level data agent, that's our route agent which is coordinating the complete flow. It's also the one communicating with the user. The route agent is task with orchestrating the query to the different data sets. sorry to the different agents. Meaning that um if it says I need to write this to the database agent then it does so. We're providing here as you can see the top two agents, so data science agent and the database agent as tools and the B chemical agent as sub agent.
[7:44]This is a great walkthrough, I'm like saying all of these components together in in architecture really simplifies things. And I have the same question too. Why do we have agents stores and sub agents, but I'll hold on to that until we get to the next section. Now, I have another follow up . Uh, can you help us with a sample prompt that you would give to the parent agent that maybe uses one or more of these agents just to tie things up together. Of course, we'll see a lot of this in action at the demo section but um essentially how all this works is that the level agent is the one that's being exposed to the user, so it handles the user communication. And the level agent then routes to the other agents whenever needed. So let's go with example, let's say you just want to explore your database. So you ask something like how many rows are in my train table for example. When you ask this what the root agent does is, it's passing the query to the database agent. The database agent then generates the SQL query. It executes it against query, it fetches the data and then brings it back to the root level agent. And the root level agent can then generate an answer and provide it back to the user. Also in here it's the level agent that's assessing in this case for example the data science agent was not needed to answer a question. So it knows I don't need to invoke it. But if the user ask questions like can you generate a plot of total sales per country for example, it also executes the data science agent, meaning it goes the same floor again the database agent, but then also is able to consolidate and fetch the data pass it to the data science agent to generate the code and execute it. And then bring everything back to the user to show the plot and provide an answer back. Wonderful. And now for the most exciting part of the video, can we jump into the code? Of course, more than happy to do so. So let's dive right in with the technical deep dive.
[9:48]All right, and with this we are finally at the fun part looking at the code base. So what you see here now is my VS code environment and I want to walk you through how things are set up and how things are working. So if you want to do this and test it yourself, we're going to show you later on where you can find a repository and we have a very detailed read me for the data science agent setup. So just follow the read me, set everything up and then you should be at the same stage that I am to be able to play with the data science agent. Before we go into the demo and say see everything in action, I want to work through the core back end and how everything how everything works and how everything comes together. So the starting point in the repository for us is inside the agent directory in data science. What do you see in the data science directory is another directory called data science. This is where the magic happens. So this is where the agent code resides. And if you inspect this directory, you'll see that we have agent.pi, instructions of pi and tools of pi directly in the data science directory. So this is what we need for the root agent. And I'm going to walk you through each of these files in detail.
[11:09]All right, I would now start with the agent 5 first because this is where we're using the 80k to really define and the root agent. This is happening by importing from agents, the class agent. And you'll see that it is very easy to get going and set up your agent class in here.
[11:34]So we have the root agent. We institute the agent class. And then we just simply need to pass a few configuration parameters. which are the model that we're using for this agent. So in this case we chose Gemini 2.1 2.0 flash. Then we have the agent name for our root that's the DDS multi agent. We have the instruction. O took them out from the instruction. The reason why we outsourced the instructions and the prompts in here simply for you have to make things a bit more easy. Because you are going to iterate on the prompts, you don't you're going to do the prompts tuning as well. So it's easier to keep track of the changes we are outsourced. But you see the setup of the file also in a bit. Then we have the global instruction. So difference in here you may wonder between global instruction is simply that instruction is specific to this root agent. So no other sub agent is going to see this specific instruction. Global instruction on the other hand are kind of like a global context. So each of the sub agents is also going to have this information. Hence why we kept it very limited in our case because we have very explicit instructions for each agent and we're passing the date of today because you want all of our agents to be aware of today's state. All right. Next up we have the sub agents and the tools. So if you remember the architecture, this is what I mentioned, we have the BQL agent provided as a sub agent. But we also have the DB agent and the S agent. but those who are providing us tool. I'll come to load out effects in a minute because that's not an agent. But just also for the reason why we chose to set up. The difference between sub agents and agents as tools as we provide them here is in how the orchestration is being handled. Meaning if the root agent is our main point of contact, what happens when we provide agent tools is that the root agent is invoking these tool agents passing the task to them. They're doing the thing and they always get back to the wood agent. So it's kind of outsourcing the task to the agent tools. And then you as the user continue to have the session with the tool, sorry with the root agent. Whereas with a sub agent, that's kind of more wiring the conversation. So in our case, why we chose to do this was because usually you do your analysis, your data exploration and then at some point in time you want to move over to more sophisticated data science workloads. And if you to pause the big again as a tool, that will mean that we would always need to switch back and forth, back and forth between the root agent and the big again. Whereas if we pause it as sub agents, what happens is that the root agent is giving over the conversation fully to the BML agent and I as a user am now correcting with the BML agent. We can always revert back as well, like have to become agent transfer back to the root agent if it identify that we again grew to an alt sequel type of questions. But it stays with the BGM agent for everything that is BGM related. Let me pause here and ask you as well if this has been clear or if there are still any questions on this.
[15:21]So you mentioned um about the load artifacts. Can you briefly talk about that a little bit more. Yes, I can. So why didn't go into detail was because the lot effects is as I mentioned, it's not an agent. The lot effects is a python function that we provide to the root agent as a tool and you'll see that in a bit it's helping us with managing the art effects that generated in the complete multi agent flow. So meaning let's say for example, you're curing the data science agent or rather the analitix agent which is the n to pi agent tool that we provided in here. And this one is generating a plot. We now need to somehow handle this artifact, the plot in our session as well and we want to make sure that we are probably highlighting it back to the user. That's what a lot of artifacts tool is doing. So instead of, you know, having an external service where you could actually store these artifacts, you'd have to run your write your own custom code. You're saying this is a prebuilt tool that we can leverage to just store artifacts and then use them in the way we want. It's right. Yes, so the K comes with simplifiy mechanisms to handle the artifact effects that are generated when you're using the agent. That is correct. Okay. Another very cool feature that we have in the 80K is the before agent call back. It is as you can see in here. So this is the find in here as well. So we have set up before agent call and if we go a bit up in here what we see is a few lines of quote setting up the agent. Let's inspect what's happening here. So essentially what we do is we are invoking this code before we are invoking the agent. So this is something that you can set up as control mechanisms as well as a developer. So we have both the set up before agent call and set up after agent call which essentially enables you to do some stuff first before the agent is being called. And likewise handle the output with a more descriptive color is more. So let's say you also want to make sure that certain things are filtered in the agent response. You can do that by invoking the agent call method in the in this scenario. We're not doing that we're just doing the set up for agent call. And what's happening in here is as you can see already with this one, we are providing the bubble scheme and DDL details up front to the agent. So we're essentially making it a bit more data aware by really telling it the root agent. This is the data set in the database we have access to and this are these are the tables, these are the columns and the data set. With this we also want to ensure that it's a bit more efficient because for kind of schema related questions we also don't want to always invoke the database agent and always generate a sequel and then always execute it. That way the root agent also has this information and can just provide answers for schema related questions. So we're doing this in here by setting these relevant details in our context. So we have the call back context where we are storing the things in the DB settings. And specifically in use database we define that we are using in the scenario. We're providing the database settings with a tool that we're invoking from the B curie tools which which as the name suggests, retrieves the B curie database settings.
[19:10]And then we storing the BQ DL schema as well in the context state. And that afterwards helps the agent to be aware as I mentioned. Let me pause here again and see if there is anything unclear with the callback context. Yes, uh thank you. So we saying is we can also use this as a tool. Like I mean the agent can have a tool which can get the schematics and then feed it. But we are optimizing here is what we're saying like even before you make the call to the agent we're going to fetch all of the schema and all of the info and pass to the agent to optimize the workflow. So if the agent has all of the necessary info it can immediately ask answer the user's problem. Is it right? It is making things a bit more it's giving a bit more control even. because if you think about the tools and how they are executed, you're giving the control over to the agent. Why because the agent is reasoning about when to execute certain tools. With the um call back context and the set up for agent call that we're doing here, you all ensure that this is always happening. So it's not the agent that's invoking it, but every time that the agent is being called, you run these things first. So that's kind of a pre setup stage that's a bit more that we have a bit more control that we can implement in here. And the same thing goes for the agent call like after agent call set up that you can implement. Okay, this is clear. So it's to introduce a bit more control and determinism into the workflow. Sounds good. Absolutely. All right, so that's for the agent of that's the core logic where the agent. I touched on the instructions of as well. As you can see here and let me maybe close that one. We have the prompts and instructions of the wood agent outsourced. And you see the same pattern for the other agent tools and the sub agents as well.
[21:19]So why are we doing this is just to as I mentioned make a lives a bit easier because you can see here that I can just iterate on the prompts. I have earlier versions of the prompts as well. So there are still there I can still use the points I used back then, they're not gone, like I'm not all writing them. And what we then have here is the instruction specific to the route agent. So we are giving a few instructions and notes on what the agent should consider and we are giving the instructions on the tools along with it as well. So how the 8K works is it also knows about what how the tools work from the dog string. So if you have of course a clean uh set up of your functions with a proper dog string, you won't need to excessively prompt in here. In my case, what I'm doing is I'm just giving a quick overview of the workflow because I want to ensure that the DB agent is called first to achieve the data before the DS agent is being executed. So you can see that I am and let me move this out of the way as well. You can see that I am underfinning the work essentially first make sure that you understand the intent and that you come up with a plan and know what you need to do. Then retrieve the data with the call DB agent tool. If you need to, that's also one in here, so you may need not need to do it. It may be the case that you sort of we provided the schema as well to the wood agent. There may be questions that the root agent can answer directly, so there is no need to unnecessarily invoke another tool or another agent. Likewise the same thing for the DS agent. So we're saying first receive the data, then if you need to call the data science agent make sure that you do it after receiving the data and that you're passing all of this to the data science station as well. And aside from that, also make sure that you transfer to BML. Meaning that um you can see here if the user specifically asks for any QL related work loads, use this one. Make sure that we route to the sub agent with this. And then we have a few other key reminders. Um I don't want to go too much in the detail in here because we have other instructions as well to look out for. But make sure to play around with this and you can always optimize a prompt or edit like edit it to make sure that it works for your use case. The instructions. files are where you will find the points for each of these agents. Okay, then the last file as we call is the tool stop by that we also had in here. This is also related to the root agent which is living in the main data science directory. So let's move over to the tools stop file. quickly stopping in here. Do we have any questions? I think the instructions file is even more lentier than our agent.py file, like most of our agents. But how important is to write good instructions for an agent, and have you tested by passing different variations of these instructions with this agent? I have and it's the same as it has always been with LLM's. So you want to make sure that you invest in your prompts and that you do prompts tuning and prompt optimization as well because they're important. Like from our experience, what we saw, especially with the latest Gemini releases, 2.0 and 2.5, is that it's considerably more robust than it was before.
[25:11]But nevertheless, and this is true for no matter what LLM you're using. Make sure that you don't have any contradictions in your prompt. Make sure that what I always tend to say is make sure that your prompt is human readable. Because when you as a human read it and you don't understand what's going on, don't expect expect the LLM to understand what's going on. So make sure that it's um clearly formulated, everything is concise, no contradictions and then you should be good to go. All right, let's now look into the tools as well. So these are the tools for the root agent. If you recall, these were the agents tools for the database agent as well as the data science agent and the load artifacts tool. So we have the async call here to the DB agent where we are essentially doing a bit of pre-processing as well before we're invoking the agent tool. The main invocation happens here. As you can see, we're doing instantiation agent tool for the database agent and then we're doing the await run async method which essentially then runs this agent tool.
[26:20]And then we're providing this back to which happens automatically to the root agent. But we also make sure that we store the DB agent output in the tool context state that you may recall that we've seen for the schematics as well. This helps to make sure that it's also a bit more efficient. Like if you retrieve data already for answering a user question, the agent now doesn't need to do it again because we've start the data output and the sequel in the context state. So it makes things a bit more natural and a bit more efficient in conversion with the agent. All right.
[27:50]Then very similarly the same structure for the call the agent. As you can see, we have the icing function in here as well. We're providing a bit more detail in here compared to the DB agent because we're giving the question as well in the kind of instructions to the DS agent and that's a key difference. actual data to analyze from the previous question is in the input data. So this is where now we see the action with what I now answered for the tool context. We stored the previous response and the data executing the database agent in the tool context. And now we can retrieve this inside the data science, the DS agent to make sure that the DS agent has access to this context when it's creating its Python code and when it's running its analysis. So this is how everything comes together in here. And then similar structure, very instantiate the agent tool and then run the async call as well to the tool which then essentially invokes the tool. So this is where the run is being executed. And as you can see here, so we prepare the string with the input data and the question we can pass it in here for the request and we're also providing the tool context where we're stored the DB agent output and also the where we're storing the query result. Is there a question? Yes, is it fair to say the tool context is almost like a short-term persistent context that you can provide to each and every tool, like each and every tool has access to it by default. So if one tool stores uh an artifact or a key variable in the tool, every tool would have access to it. Yes, so um it is short term. I want to be cautious with persistent. It's persistent over the current session, but um then it's going to vanish, yeah. But it is essentially yes, uh short-term memory in a way for everything tool related. All right. Now this concludes for the root agent and how things are set up. So you get to just right we have the agent of Pi with the core 80K logic on setting up the agent and the configuration. We have the instructions of Pi we outsource the prompt.
[30:13]We have the tools of Pi where all of the tools are stored that the root agent is using. And you'll see once you go into the sub agents that these are following the same structure. So we have for example in the B query agent, the agent of Pi, instructions of Pi and tools of Pi. And the same thing for the BML agent. So the format is always the same, which also makes it easier when you're exploring the code to follow along and to modify the prompts because you'll always find them in the instructions of Pi. All right, let me take the rest of the time to quickly go through the other things that we're building in here and how these flows come together. So let's start with the B query agent. This is what I mentioned in the architecture if we have two methods of sequel generation. First one being native with Gemini, and the second one using J sequel from our research organization.
[31:16]So I'm not going to cover J sequel in detail, but I would recommend you to try it out. You can simply set the method of an sequel generation in the environments file. So just switch it on to chase, everything's documented in the read me and then feel free to play along with it and see if this is uh helping you with more complex sequel generation use cases as well because it performs better than just the standard native Gemini sequel that we've implemented. But in our scenario we have now the B query agent is tool that the root agent is using. And also very quickly in here, it's the same setup, right? So it's also very easy to set up the agent tools, the sub agents, they're all following the same pattern. We have the agent class that we're importing and then we just instantiate it with the config, model, name of the agent, the specific instructions just for this um agent, agent tool, sub agent, whatever it is. We have the tools again, we have the before agent call back again. So you can see that you can set up the tools, you can set up agent, like agent callbacks before and after for all of the agents you're defining. These are not limited to the root agent. These can be also used for the agent tools, what we see in here as well as the sub agents that we connect to the root. So as you can see, it's the same thing again and it's very easy to set up the agents, you can follow the same pattern to extend it as well. Like for example if you want to include another type of agent into this. One for question answering over PDF files for example. You can just follow the same format, set up another agent, be it as a tool or as a sub agent, depending on what is your need for your use case. And then just provide the agent of Pi with these lines of code, setting up a agent, the instructions as well as the tools that you need for your agent and you're good to go. Then the only thing that you need to do is for the root agent to go back and edit either as a tool or as a sub agent into the list and everything else will be handled automatically by the 8K. So it's also very easy to extend the agent workflow to with additional features and additional use cases as well. Okay, um I will now go into all of the prompts in here. So as I mentioned, feel free to check them out. They're always in the instructions. And they're all following the same pattern as well. All right, then with this, uh that concludes for the code base. What I now want to do is I want to show this agent in action. And to do it, we're spinning up our terminal here. We're making sure that we're navigating to the data science repository. So see the agents data science. And then and that's another very cool thing. The AIK comes with its own developer front end. So all we need to do once everything is set up, we just run the command 80k. And then you'll see that it's going to spin up an angular front and for me and I'll be able to interact with this complete multi-agent system. And the cool part is you didn't even have to write any streaming code to handle this or you didn't have to write any front end or client facing or anything. It's all built in within the SDK and we're just invoking it with this one command. That is true. You see all of that once I spin up the front end. And here we are. So this is the front end of the AIK.
[35:07]When you're running the AIK web in the terminal, this is what is being spin up. You can just uh go to your local host and you'll see it. And the first thing we're doing, so we're walking the AIK web command inside the data science directory. not the second one, the first one that the right top. And now we're being able to select the data science one where if you remember, the core complete agent backend logic resides. So we're just going to ahead and select this one. And then we are good to go. So when we now go ahead and chat with the system, what is being done is we are then interacting with the root agent. But before I do it, let me also walk you a bit through do you UI what do you see here. So you'll see all the events in here. Once we start conversion with the agent, you can also always inspect the sessions. install them so that you can get back to them. You will see artifact generated in here. I'll show you this one as well once we created a few of them. And there's another tab with the evaluation. Um I also recommend that you play around with this as well because if you have a session, what you can do is you can create an evaluation set. Automatically handle by the 8K and then you can use this evaluation set down the line again, spin it up to evaluate your system if you made any changes. So the other evaluation set, which is not referring to the 80K but more to the data science use case itself. is first for the to set one. For that we have as I mentioned the case set method of generating the set as well. That's the one from research and you'll see that it is currently inside the bird board top five. So you can check out um the birth board there and the bird set is essentially a test and evaluation set for performance. The other thing is for the data science evaluation. What we did as well and you can check this out in the specific highlight overview of the data science agent. um which we're also going to link in the resources. You see a video where we showcase essentially the full BML steps of training a model for a competition. And you'll be able to use the BQL model in here to very quickly get you going. set up in our case an model for forecasting in just a matter of a few minutes. And then you can use the model to influence and even submit to board. So we managed to get to the top 30% in about 30 minutes using just a B agent and honestly speaking, I'm an absolute noob when when it's really coming to because I haven't played with it before. So I was able to get this running in 30 minutes without any big amount of knowledge whatsoever. But that's for the evaluation and I will now show you our data science agent in action. So let's just start querying what data do you have.
[38:28]You'll notice that the first prompt that you're sending takes a bit longer than the rest simply because when you haven't set up the code in the project extension, it's spinning this up for you. In my case, it was working a bit faster because I already have the code in project extension set up. So what we see here is I have access to data about sticker sales, which is the data that we provided in BigQuery and then it's giving me information about tables which is set, test, train, and train full that are in my BigQuery and the information inside these tables being date, country, store, product, and number sold for each transaction. You'll see that it's that it retrieved this answer without invoking any of the agent tools or the sub agents. Because if you remember, we passed the DDL schema, like the complete table and column schema to the root agent as well. So it can answer these questions without adding latency on top of it. But let's go ahead and ask a question where we need to invoke the database agent. So let's say what countries exist in my train table.
[39:39]What what you see now happening is we see in the front end the full trace of what's happening inside the agent system. So the root agent has now invoked the call DB agent. Now it got the response back from the call DB agent tool and it's providing us with the response. What you can now also see in here, we have the events tracked as well. Inside the UI on the left hand side. We can also additionally inspect the traces in more detail. So we can see how the call DB agent to was invoked. We can inspect the JSON and see exactly what question the root agent passed to the database agent tool. saying, what are the, and what we then get from the tool execution is the response from the database agent where we then see the explanation of what it did. We get the SQL that's generated back from the model and we also get the data back.
[40:51]So these are the SQL resource that we get once we execute the generated SQL against BigQuery. And with this information, the uh root agent then comes up with the answer to the users.
[41:07]Okay. Then let's continue with another question. Let me close this one right here and maybe also close this one so we have a bit more space. Let's ask a question that needs to invoke the data science agent, like the DS agent tool because we have to complete data science agent in here. So to invoke the DS agent, let's just say I instructed to generate a plot of total sales per country. So let's say generate a plot per total sales. Oh sorry. with total sales per country.
[41:55]Again and this is the correct workflow it's first invoking the database agent because it needs to retrieve the data. It gets the data and the responses back and then it's invoking the analytics ds agent for the Python workload.
[42:14]And what the what this agent is doing is going to write the Python with the data. If you remember it that we passed in the tool context, we're we're stored the output from the DB agent. The ds agent has access to it now. the data and it's generating the for us. There we go. It's a bit small here, but what what you can do is you can open it and a new tab and inspect the in detail. And you see that I got the total states per country back in here. So we have the countries Canada, Italy, uh in Singapore and it plotted it for us. Let's move back. It's also giving the results in natural language again for us along with explanation. And if we now open the artifacts tab, you'll see that it's storing all of the generated artifacts in the session for us. So this is the lot artifact tool that's being embedded into the 8K. That's making it easier for you to handle all of that. So you don't have to think about all of these artifact handling and plotting. All right, then let's try one last query and let's try to invoke the BML agent. So if you Remember from the prompt, this is explicitly set to only be invoked and transferred to if the user says, we want to know where on BML. So let me say I want to train a forecasting model using BQL.
[43:53]And as you see, what the word agent does is it's transferring the complete session over to the BQL agent. So it's not the BQL agent that I the user am talking to. And what the BQL agent is doing, you can see it in the tools as well when it inspects the tools set that the BQL agent has access to. It is connected to the BQL reference guides and can do rock inoculation. So it's just doing a retrieval for generation to these reference guides for BQL so that it knows the proper BML syntax as well. And then it's directly suggesting us that the BML reference guide is saying okay. For forecasting, I would recommend the plus X-ray model in BML. It requires these kind of data and before creating the model, like before creating the code for you, let me check if there is any existing data models in my data set, which is good because I already have a few. So it's invoking the tool to check for existing BML models and it's giving getting the response back in here as well. So okay, there are already some models in a data set. And what we then get is the SQL for the BML execution for the model training.
[45:22]So how the BQL model works as well is it's always verifying first with me, the user, the syntax and the plan for execution. So it will not go ahead and execute any BML execution unless I say this code looks reasonable and please proceed with the training. And also one other note I want to make here when you're playing around with it, you'll notice that the BML agent also has the capability to refine itself. So if there's still any errors in here because it missed something from the reference guides, it will fetch the error message from BML and it will refine the plan automatically for me and then say okay, this is the error that I found, this is the fix that I made, this is the new execution plan, is this okay for you and then I can just either fix it or edit stuff or just proceed with it. All right, so that's the data science agent in action. That was so fun to watch, Mel. So, can you quickly summarize what we've seen in this video and give us like maybe four to five takeaways? Absolutely. So what you saw today what we walked through was we walked through hands on through how you can set up a multi-agent system, in our case of data science agent, using the AIK. So if you recall, we had our root agent with two agent tools with a sub agent. And we're very quick in setting things up, which also leads me to the recap here is the first one is you saw that it's very easy to get started with the AIK.
[47:03]So it is modular in nature and you can just very quickly set up your agents how you need them, following the pattern that we walk through in the code base. And the second thing in here is as well that you can also adjust this very easily to your use case. I mentioned this prior with how easy it is to extend it, but likewise, it's also very easy to just ingest certain modules for your use case. For example, let's say, for your use case, you only want to have the database agent with Chase SQL because you want to do data Q&A in your flow. You don't need to include all of the rest. You can just import the database agent, connect it to your own root agent, and you're good to go. And where can we find some resources on this? Maybe the sample agent we just built. Of course, I'm going to show them in here on the screen. So we'll provide you with the links for the GitHub repository of the Agent Development Kit. Another GitHub repository with all of the agent samples that we built, including this data science agent, but also other samples, so I really recommend that you check those out as well. And a few additional links for the evaluation that I mentioned for the Bird SQL EVAL using Chase SQL, as well as a short video showing how we used this exact data science agent to train a model using BQL to compete in the Kaggle competition. And yes, all these links are in the description below. Do check it out. And thank you everyone for tuning in. We hope you like this video. So we have many more sample agents and videos that's line up for you. Do check it out and let us know what you think. And thank you very much for this wonderful demo. Thank you, and thanks everyone for watching.
