Block demos an AI Agent built using Databricks

Key Takeaways

All right. Today I will be going over code name goose. How to install it, how to connect it with a datab bricks served model um and how to begin playing with it. So what is code name goose? code name goose is uh an on machine AI agent AI assistant that was built to really help as it says automate engineering tasks codeame goose was developed by block and released earlier this year a couple key features um of goose it's open source so lots of visibility like I said it does run locally and is very extensible um it's built on top of the model context Next protocol framework, which allows you to build your own um tools and extensions um or utilize tools and extensions um that have already been built uh connect those up to Goose and uh give it the ability to talk and interact with um a variety of different technologies or applications that you you that you use. So um supports a handful of different LLM providers. Uh in this demo we're going to be um connecting it up to a datab bricks served um claude model. So let's take a look at what that looks like. So inside data bricks uh under our model serving we can see we have a handful of foundational models ready to use. Um in this demo we're going to be using this claw claude 3.7 model. So you can see this is just the cloud model um being served up through a datab bricks endpoint right here. So, we're going to walk you through um how to download Goose and how to get it um connected with this endpoint and begin using it. So, first step, we actually want to install Goose. And now, Goose um can be used as both a CLI tool uh and a desktop application. For this demo, we're going to be going over uh the desktop app, but I would recommend um downloading both and and learning how to use both. So, I will install it using Buru. So, just running this um Buru install command. And you can see here I now have my Goose application in my applications folder. So if I open that up, you'll see right off the bat, uh, it prompts you to pick a provider. These are the LLM providers, um, that we discussed earlier, and we're going to go with, um, data bricks. So to set it up, we're going to have to give it a um datab bricks host. So I'm just going to copy that over here. I'll be using the demo field engineering workspace. Um and in order to connect to data bricks, um goose will use SSO. So you'll need to have that configured um in order to access the serving endpoints. Uh if you don't have SSO configured, you can use tokens. Um yeah, so we'll launch this here and this is what the chat interface looks like. Um let's configure this uh a little bit more. So going into advanced settings to actually connect to that model um that cloud model we're talking about we're going to add our model the provider data bricks and we'll take that model name copy that from up here this datab bricks claude 37 sonnet just add that model um and so now if we go back we can see that it is uh attached to that cloud model. Um if we go back to this chat interface, we can just ask what can it do. Um it'll SSO. It's on a different screen right now. Let me see if I can bring that down. There you go. Uh it SSOed in. Um and there you go. Just like that, we've connected it up. Um, it's accessing that cloud model. It's being served by data bricks. Um, and now let's configure it a little bit more and have it do some uh engineering tasks for us. Um, so if we go into our advanced settings here, talk about the extension. So the extensibility of goose. Um, you have some built-in extensions that you can toggle on or off here. I'm going to turn on the computer control. You can also, um, switch on memory, uh, Jet Brains IDE or add a custom extension. So, if you download an, you know, an MCP server or you create your own, you can add it, um, here. So, really flexible and extendable. Um, like I said, and just to give you an example of that, um, Goose comes with some extensions you can download. So, here's a fetch extension for web content fetching. Uh, we can just install that straight from Goose, the Goose website. And just like that, we have a new extension fetch. And we can toggle that on or off. Now, what we want to do in this demo is the goal at least. I have um some tables, some sample tables um in a catalog. And I want um the askers to take the sales uh transactions table and the sales franchise table, explore them a little bit and then create a script that will um combine the tables and look at a number of transactions per day for each franchise. um in order to get goose um interacting with data bricks, there is no official databicks mcp yet. So we're not going to use this extensions um here. But what we can utilize are what are known as goose hints. And so goose hints is just a text file that's used to provide additional context about your project to goose. And they come in two different flavors. You have your global hints file and your local hints file. The global hints file, the one that we'll be creating um will apply to all your sessions within goose and that's stored in our config um directory which I'll show you a little bit more about. But you can also have a little bit more specific local hints files that you store in root directories um of a project you're working on. So if you have project specific hints that you want to help guide goose um you can serve you can store those in the root directory of your project uh and that way you're not inundating your global um goose hints file with project specific hints. So this is the route we're going to go down to kind of help goose interact with um data bricks. So, in order to set up a goose hints file, we're going to need to create a goose hints file again in this config goose um repo. So, I will just create that file real quick using a touch command right there. If we come in and we look at our config folder, we can see we have this goose um folder created. We can see I just created this empty goose hints file. Um within this config folder, there's also a config yaml which will store some of your um information. So here that data bricks host that we just set up, that's the only thing in there right now. Um, let's go into our goose hints file and actually populate it. So, I have some hints um already pre-written for goose and these are specific to um really working with data bricks. So, it's a handful of uh hints that really guide goose on how to authenticate into um data bricks, how to use the data bricks cli tool, how to use the datab bricks connect tool um so it can do some local development for me and really creating these hints is um kind of it's just a learning process um learning how goose works adding hints when you start to see certain patterns um that goose decides to make. So, we've created that goose hints file. We've saved it. Um, and now we're go back. I'll create a new session just to make sure. Um, and then I'm going to prompt it with um, oh, before I move any further, uh, the last thing I want to mention is, um, Goose also comes with a couple, um, built-in guard rails here. So, it can act completely autonomous, meaning that it'll just um run all of its actions um on your computer without checking in. Um I prefer to use smart approval. So, you'll see it'll check in with me um before it makes certain actions. So, that's an extra guard rail there to make sure that Goose doesn't just run wild. Um but here's the uh prompt I gave it just I have a workspace. Um there are two tables. Can you write a script that will use these tables? Create a new table which shows the total amount of spend per day at each franchise. Um I'm telling it to explore the tables so you know what columns to use. um telling it where to save that file and that I want to be able to run it locally using datab bricks connect. So, we'll take a look at um what it does. Hopefully, uh it can get this right. Never know with the demos, but right off the bat, it's just going to uh authenticate into data bricks. And again, um it's going to be using the data bicks CLI tool and the databicks connect uh Python library. So, um, in order to do work like this, you're going to need to have one or both of those, um, set up just like you would if you were doing any sort of flow development. But here you can see it's running some shell commands, um, to explore the tables I talked about. Uh, you can explore the output of those commands. So, it's looking at the sales franchise, the sales transactions. Um and then it's going to create um this script. And so you see uh the script executed successfully and created the table. Um, now it's going to verify that the So, it verified that the uh table was created by running a CLI command um a data brick CLI command. Uh, it's attempting to run a SQL here, SQL query here using the CLI um tool which doesn't exist. So, it's going to see that error and uh try a different approach. Um, I don't need it to actually explore this table for me. So, I'm going to stop it for now. Um, but let's see if we look at this uh file. Um it should have created a table franchise daily sales um in our datab bricks environment. So let's take a look here. Um sure enough there's franchise daily sales here. We look at the sample data. Um we can see franchise date uh and the total amount. Um, so looks like it's working. And the last thing I'll ask it to do is just can you upload this file to my databicks workspace. Um, and now it should use the command line tool to take that file that it created locally and push it up into my datab bricks workspace. Um, I have a goose hint here that tells it um, you know, the home workspace is my email and you can get that using data bricks current user me. So that's why it's doing that. Um, I'll allow it to import the script. Um, you can see there it had the wrong syntax. It corrected itself. Again, those are things that you can begin to iron out with um, data bricks hints or if there was an MCP um, it probably would have oneshot that. But one thing I find incredibly interesting is how it can take the error output um and figure out the correct syntax to actually use. Um so it uploaded the file and then it ran a list command here to see that it actually exists and it gave a little summary of what it did. And so we can check its work. Um, go into my workspace. Uh, and there you go. Franchise daily sales.py at 10:55. I promise you it's 10:55 right now. Um, and there's the script. And now if we wanted to keep going, we could have it build a job or pipeline that runs this script. um deploy that job and pipeline etc. Um but I think that gives you a good rundown of how you download goose, how you connect it with a datab bricks um served endpoint and then really the power um of goose. All right, so the last thing I wanted to uh touch on today um was really just highlight some of the key features of data bricks model serving and AI gateway. So in the demo we just um went over we were using the foundational claude 37 model but you can also create your own serving endpoint and I did just that um so I could show off some of these feature that created a goose demo endpoint and if we look at what's going on under the hood all that's happening here is I'm serving up a data bricks model and I'm serving up that same claude 37 model that we were using um in the demo. I'm just wrapping it in another endpoint. But if I wanted to, I could come in here and I could add a second model. So let's say I wanted to add an open AI um model. I could add that as well and I could distribute the traffic between the two both on the same endpoint. So the user still hitting the same endpoint. goose is still hitting the same endpoint. Um, but the model under the hood might be different and the user would know no different. And then looking into uh some of the key features of AI Gateway, um some big things uh that AI gateway provides are really fine grained usage tracking. Um so we have tables that um track the metrics of each request. Uh you can set up an inference table and these inference tables will actually show you um all the requests and responses. Save them in a delta table. Uh and right now I'm saving that um in my uh uh ryworth catalog. You can add some uh guardrails to make sure that the model isn't um giving off information you don't want it to. You can also easily add rate limits to make sure that certain endpoints aren't being um abused. Uh could help keep costs down. And lastly, um if we did have multiple models at this endpoint, we could enable fallback. So if that first model uh was failing for whatever reason, it would um fall back to the second model and again the underlying user wouldn't see any difference any interruption. So let's take a closer look at those usage monitoring um endpoints. So if we look at this table, it's going to be in our system serving uh schema. And like I said, you can see exactly who requested um who made the request, some token information, and what model um the request was against. So if we wanted to take a look, for example, at uh what requests I've been making, um we can do that here. And I I really just want to highlight um how important this is being able to attribute um certain requests to specific users. You know, if you're um querying, you know, the open AI API uh and you all have the same um API key, it can be very difficult uh for an organization to attribute who is making which request. Um and this gives you a very fine grained look uh what requests were being made um some information and against which model. And then taking a look at this inference table that I set up for this endpoint uh we'll be able to see the exact request message that was being sent to the model and the response that the model gave back. And of course, you'll be able to see um who made that request. And so with these two tables, you can really get a fine grain look uh as to what's going on. Uh it really helps to enable um real time monitoring. You can build alerts off of these dashboards off of them. Um really a very powerful tool. And so with all that, um hopefully this is enough to get started. uh you can start to play around and um I encourage you to start building some cool things. Thank