The Astro Team Secretly Built the Best AI Agent Framework
BBetter Stack
Computing/SoftwareSmall Business/StartupsInternet Technology
Transcript
00:00:00This is Flu, an open source framework for building AI agents made by the team behind Astro,
00:00:04which basically takes what Cloud Code does as a harness and makes it 100% programmable.
00:00:09So things like skills, tools, sandboxes are supported out of the box,
00:00:13so you can create a fully featured agent harness and deploy it anywhere in just a few lines of TypeScript.
00:00:19But why would the Astro team decide to build an agent harness framework in the first place?
00:00:23And what's this cool trick you can do with sandboxes that allows you to run agents much cheaper?
00:00:28Hit subscribe and let's find out.
00:00:33Flu was built by the co-founder of Astro, and funnily enough,
00:00:36they didn't set out to build an agent harness framework.
00:00:39Fred and the team built Flu to run AI workflows inside of Astro's own GitHub repo.
00:00:44But when another engineer from Amplitude got their hands on it,
00:00:47the team realized that this is a tool that any agents would have access to,
00:00:51which actually makes sense if you think about it.
00:00:53I mean, let's take a look at Cloud Code, for example.
00:00:55Underneath the terminal or UI chat interface is a harness,
00:00:58so it supports custom tools from MCP servers, it reads Cloud MD files,
00:01:02it has sandbox support and support for reusable skills.
00:01:05This and much, much more enables the model to do real work,
00:01:08which Flu can give you in just a few lines of code.
00:01:11It does this by being built on top of Pi, which is a minimal agent harness itself,
00:01:16the same thing that OpenClaw is built on top of,
00:01:18and it wraps a real framework around Pi's agent core.
00:01:21Flu actually does something clever with sandboxes to help you run them a lot cheaper,
00:01:25which I'll talk about a bit later.
00:01:26But if you go back to the Cloud Code example,
00:01:28it assumes that there's a human behind the wheel driving the agent,
00:01:31which is usually the case.
00:01:33But Flu doesn't have that same limitation.
00:01:35With Flu, you can build agents like Cloud Code that require human input,
00:01:38but you can also build workflows that don't require a human at all,
00:01:42which is useful for agentic processes that are very specific
00:01:44and don't need to change that much.
00:01:46Now, you may be thinking,
00:01:47this sounds very similar to something like Mastra or the Vercel AI SDK,
00:01:52and I'll talk about the differences a bit later on.
00:01:54In fact, the differences will be much more clear if we go through a simple demo.
00:01:57So let's go ahead and do that.
00:01:58So to get started, you'll have to install the Flu runtime,
00:02:01which is what your agent imports and runs on,
00:02:04and then you'll have to install the Flu CLI,
00:02:06which compiles and serves your agent.
00:02:08You'll also have to set up an API key from one of the many providers' Pi supports.
00:02:13For this demo, though, I'm going to use Anthropic,
00:02:15and then you'll have to run flu init with the targets,
00:02:18which creates a flu config file so the CLI knows how to package your project.
00:02:22You can choose between Node or Cloudflare,
00:02:24and I'll talk about the differences in just a second.
00:02:26But I've already done these steps,
00:02:27and so let's have a look at what these files look like.
00:02:30So here are the typical files you get from a blank bun project,
00:02:33and some of these files aren't even used.
00:02:35If we have a look at index.ts, this isn't going to be used for anything.
00:02:38Neither is the readme file,
00:02:39but what's actually going to be used is this flu config.ts file,
00:02:42which uses V behind the scenes,
00:02:45the CI to use Node instead of Cloudflare.
00:02:47And the difference is Node uses a HTTP server on top of HONO,
00:02:51and Cloudflare will deploy your project to a worker
00:02:53with a durable object for persistence.
00:02:55Now, after you've done those steps,
00:02:56you'll have to create a new directory,
00:02:57either an agents one or a workflows one.
00:03:00We'll go through workflows a bit later,
00:03:01but for now, I started with a simple agent,
00:03:03which contains the code in the documentation.
00:03:05And this basically sets a model
00:03:06and adds some instructions,
00:03:08which appends to the system prompt.
00:03:09And that's it.
00:03:10That's all you need to create a basic flu agent.
00:03:13Let's see it in action.
00:03:14To run it, we can use flu connect,
00:03:15which builds and runs the agent.
00:03:17And we're matching the name of our TS file,
00:03:20which is hello world,
00:03:21before giving it an instance ID,
00:03:22which could be anything.
00:03:24So it could even be a local one, two, three.
00:03:25But this is useful if you have lots of agents running
00:03:27and each agent can have its own unique ID.
00:03:29This is also useful for deploying to Cloudflare
00:03:31because this ID maps onto its own durable object instance.
00:03:35So now if we hit enter,
00:03:36we can see it loads the config,
00:03:38reads the target and runs the agent it's found.
00:03:40Now we don't have an agent MD file,
00:03:42but if we did, it would use that.
00:03:43And now it's built the agents to this server.mjs file
00:03:46and it's given us the ability to enter a prompt.
00:03:48So I can say something like, give me a random joke.
00:03:50And here we can see the agent starts thinking,
00:03:52it responds, so streaming its lifecycle.
00:03:54Then it gives me a joke, asks me for another one.
00:03:57But then below here, it prints the final JSON,
00:03:59which comprises of the text,
00:04:00as well as some input and output tokens,
00:04:02the cost of the whole prompt
00:04:03and the model that was used.
00:04:05Of course, we could continue talking to this agent,
00:04:06but for now, I'm going to shut it down.
00:04:08And that is an example of building a basic agent with Flu.
00:04:11Let's do something a bit more complicated.
00:04:13Let's build a workflow to help generate some titles
00:04:15for this YouTube video.
00:04:16And to do that, again, we're creating an agent
00:04:18with some more complex instructions.
00:04:20And this time we actually have a skill.
00:04:23So the skill is imported here with a skill import attribute.
00:04:26And here, notice we're no longer exporting the agent itself,
00:04:29but this time we're exporting a function called run.
00:04:31And what this does is it initializes the agent
00:04:34for the workflow and then opens a session in the harness.
00:04:36Now, what happens next is quite interesting.
00:04:38So here, what's going on is we are getting the path
00:04:41from the payload, which was set here
00:04:43in this flux context type.
00:04:44So if we change the name here to file,
00:04:46we would get a type error.
00:04:47And here is getting the file,
00:04:49which I've called script,
00:04:50and passing that in as a prompt.
00:04:52So this will all make sense
00:04:53if we have a look at the instructions over here,
00:04:55which we're telling it to study the script
00:04:57and give me 10 clickbait YouTube titles
00:04:59using the title score skill to rank them.
00:05:01So let's see if this works.
00:05:02But before we do,
00:05:03I want to make it obvious that workflows
00:05:04are in the workflow directory
00:05:06and skills are in the skills directory
00:05:08from the project's root.
00:05:09And to run this workflow,
00:05:10we need to run flu run with the name of our workflow.
00:05:13In my case, it's YT titles,
00:05:14followed by the target and the JSON payload,
00:05:16which is the path for this script.
00:05:18So if we hit enter,
00:05:19we'll see we get a workflow ID.
00:05:21And here it's doing something a bit odd.
00:05:23It's actually looking around for the skill,
00:05:25even though I've specified it earlier.
00:05:27And now in this reasoning,
00:05:27it's telling me there aren't any files on the file system.
00:05:30Why is it doing that?
00:05:31So by default,
00:05:32flu runs agents in a sandbox using just bash.
00:05:35All it has access to is the skills description,
00:05:37which has been registered over here,
00:05:39but it doesn't have access to any of these files
00:05:42related to the skill.
00:05:43And the skill itself, if we have a look at it,
00:05:44it actually runs a Python script using bash
00:05:47in order to come up with an accurate vidIQ style score
00:05:50for a YouTube title.
00:05:51So to fix that,
00:05:52I'm going to import local from flu runtime node,
00:05:54which tells flu to run the agent on my local system
00:05:57so it has access to all my files
00:05:59and can run Python scripts.
00:06:01If you're security conscious,
00:06:02I'll explain how you can get around this
00:06:03later on in the video.
00:06:04But we're also going to change
00:06:05the current working directory to the skill
00:06:07inside the skills directory of this project.
00:06:10So that flu doesn't have to look around
00:06:11to find the exact files it needs.
00:06:13And now when I run this workflow,
00:06:15we can see flu immediately reads the skill MD file
00:06:17and is able to generate the 10 clickbait titles
00:06:20with a score for each of them.
00:06:21Now, if you don't want to give your agent
00:06:22a workflow access to your local system,
00:06:25what you could do instead
00:06:26is to create a custom tool from the Python file.
00:06:28So here I'm loading the Python file in the skill
00:06:30and creating a tool called score title,
00:06:33which uses value bots to verify the parameters
00:06:35and then runs the Python script.
00:06:37Then we can register this tool inside our agent
00:06:40and everything should work as expected.
00:06:42But now let's go back to the previous project
00:06:44and say we want to trigger it based on a HTTP post call.
00:06:47Well, there's just one thing we need to do to enable that.
00:06:50And that is simply to add the root middleware.
00:06:52Now, all we have to do is build the flu project,
00:06:54specify our target, an optional port,
00:06:56and then run our server file.
00:06:58And now it's listing on the port we specified.
00:07:00Note that the server.js file
00:07:01inlines any agents or workflows we have.
00:07:03So we just need this file
00:07:05if we wanted to deploy it anywhere that supports Node.js.
00:07:07Now I can run curl with the post method
00:07:09to the port that was specified,
00:07:11select a workflow and give it some data,
00:07:13which gives us a workflow ID.
00:07:14And then if we curl for workflows,
00:07:16specifying our specific workflow ID
00:07:18and piping to JQ just to make it easier to read,
00:07:21we can see information about our workflow
00:07:23and a summary of the results.
00:07:25Of course, Flu supports WebSockets instead of HTTP
00:07:27if you wanted to stream the workflow information.
00:07:29Now, as usual, there are so many features Flu has
00:07:31that I didn't get around to going through,
00:07:33like agent profiles for reusable agents,
00:07:35support for Daytona, Cloudflare sandboxes,
00:07:37or any other sandbox just by using a URL,
00:07:40adding custom routes for auth or health checks,
00:07:42and even support for sub-agents.
00:07:44But how does this compare
00:07:45to another open source AI agent framework like Mastra?
00:07:48Well, the last time I used Mastra
00:07:49was when I made this video,
00:07:50which you can pause this video and go and watch
00:07:52if you want a refresher on what it is.
00:07:54But when I did use it,
00:07:55you still had to manually set up the sessions,
00:07:58the memory, the sandbox, and tool loading yourself.
00:08:01It was much more of a granular step-by-step process,
00:08:03and I'm not sure if that has changed
00:08:05to become more simple,
00:08:06but I think the approach that Flu is taking
00:08:08is completely different.
00:08:10It's more of a harness-first approach
00:08:11and assumes that you're going to be using
00:08:13these features from the get-go.
00:08:14Speaking of sandboxes,
00:08:16Flu actually does something really clever with them.
00:08:18So each agent gets its own sandbox by default,
00:08:21which I explained earlier in the demo,
00:08:22but this sandbox is powered by Vercel's just Bash,
00:08:25which re-implements Bash in TypeScript.
00:08:27So it runs this sandbox in memory
00:08:29instead of a real container,
00:08:31meaning you get access to grep, glob, and read tools
00:08:34without paying for a container every time,
00:08:35which has to boot up a whole Linux machine
00:08:38just before you can do anything.
00:08:40Meaning Flu runs thousands of agents
00:08:41for next to nothing,
00:08:43and you can opt into a real container
00:08:44only when you need one.
Community Posts
No posts yet. Be the first to write about this video!
Write about this video