Building AI Agents
Beam is launching a new type of agent framework that is stateful and has concurrency built-in.
Other agent frameworks can't...
• Multi-task
• Automatically synchronize state
• Run each task in an isolated environment
• Scale to 100s of GPUs
Beam gives you everything you need
• Sandboxed compute environments
• Concurrency
• Task management and queuing
• Edge deployment and autoscaling
• Authentication
• Lots of GPUs
Introduction
Today, most agent frameworks are based on graph DAGs. While useful for simple tasks, this limits you to performing one action at a time (i.e. using one tool at a time).
Beam uses a new agentic concurrency model, based on petri nets, which are capable of multi-tasking complex, multi-threaded workflows.
By combining this agent framework with Beam’s cloud compute, you can build powerful, parallelized applications.
Core Concepts
Our agent framework has three important components: locations, transitions, and markers.
For this example, suppose we’re modeling an eCommerce store.
- Locations — these are specific states or conditions that hold tokens. For example,
in_shopping_cart
orin_queue
. - Transitions — events or actions that cause state changes. For example
place_order
oraccept_payment
. Each transition has:- Inputs — the locations the data is consumed from.
- Outputs — the locations the data is sent.
- Markers — markers are data types. For example,
order_12345_red_shoes
.
Think of a Petri net as a factory assembly line, where parts (markers) move between workstations (locations), and tasks (transitions) are performed when all required parts are in place.
Initial Setup
Let’s setup a simple hello world
chatbot. This chatbot will respond to messages from a user. It will ask the user for their name, and attempt to update the status of their order.
Pre-requisites
- A free Beam account, and Beam installed on your computer
- An OpenAI API key
Hello World
We’ll start by creating a bot
, a transition
, and initial state markers
:
Managing State
Now we’ll add locations
and markers
, which represent state.
Adding Transitions
Let’s add our first transition. A transition is a state change. It takes our UserName
location and returns an OrderStatus
location.
Interacting with User Input
Let’s add basic logic in the transition. We’ll accept a username, and update a dict with the user’s order status.
Adding Prompts
We’ll introduce a new concept, called context
, which is a class that provides various convenience methods for your bot.
Human-in-the-loop
We can also add a confirmation prompt, so that user input is required before the bot can proceed to the next step.
Let’s add the confirm
flag to the transition:
The bot will only proceed if the user confirms the request.
Adding Transitions
Let’s add a second transition, which will issue a refund to the user after they cancel their order.
This transition will fire when an OrderStatus
marker is created.
You’ll notice that we’re not returning a marker, because this transition marks the end of our workflow. After this transition runs, there’s no state left to update.
Advanced Usage
Controlling Bot Awareness
Based on the system prompt, the bot automatically knows about all the locations and transitions defined in the network. This means that the bot will understand its role based on the data you add to your transitions.
However, you might not want the bot to know about certain transitions or locations!
If you want certain things hidden from the bot’s context, you can pass
expose=false
to locations and transitions.
Think of hidden transitions as ‘backstage actions’ — users can still interact with them, but the bot won’t take it into account in its reasoning.
Using Context Commands
We provide a number of helper commands using a class called context
.
Context variables can be used for prompting the user for input, creating blocking requests to the bot, and sending message to the user.
Available Commands
Method | Description |
---|---|
context.confirm() | Pause a transition until a user says yes or no. |
context.prompt() | Send a blocking or non-blocking request to the model (e.g., “summarize these reviews”). You can pass an optional wait_for_response=False boolean to make this non-blocking. |
context.remember() | Add an arbitrary JSON-serializable object to the conversation memory. |
context.say() | Output text to the user’s chat window. |
context.send_file() | Send a file to the user created during a transition. |
context.get_file() | Retrieve a file from the user during a transition. |
Development Workflow
Testing
We’ll start by running the bot from our shell, as a temporary development server.
This command will spin up a container in the cloud for the bot transition
, and create an interactive dialogue in your shell.
You can interact with your bot by typing into the shell. In your shell, you’ll see responses from the bot, as well as event logs from each transition that fires.
Deployment
You can login to the Beam Dashboard and use the web UI to chat with your bot, view the network graph, and view the event logs for each task.
Creating Public Chatbots
You can also create sharable pages for your chatbot by adding authorized=False
to your bot
:
When deployed, you can access a public URL for your bot, which looks like this:
Was this page helpful?