GAME Overview
Last updated
Last updated
GAME is a modular agentic framework which enables the creation of agents that can plan actions and make decisions autonomously based on information provided to it. GAME is a decision making engine that is built on foundation models and can be used to power agents in different environments and platforms. Given an agent goal, personality, relevant information and available actions/functions, GAME does the thinking and processing and outputs the action(s) to execute.
The figure below provides an overview of the GAME architecture and the flow of information. A GAME Agent, consist of:
a Task-Generator (i.e. High-Level Planner (HLP)) and
Workers (i.e. Low-Level Planners (LLP))
The simplest building block of a GAME Agent is a Worker. A Worker itself can be already considered an Agent and functions to take a sequence of actions/functions which accomplishes a task. The Worker has an agentic loop in which feedback informs consequent actions which enables it to recover and attempt other actions when there error messages are provided in the feedback. The interaction mode with a Worker is that it has to be provided or given a task. A single individual Worker can be used directly as well and either requires a trigger event which provides a task or can be used in an "assistant" like manner in which the user provides the task.
Multiple Workers can be defined as part of an GAME Agent, based on their functionalities and specialisation. This is part of the hierarchical agent approach in GAME. This hierarchical architecture prevents large action spaces and encourages greater performance for each Worker at completing their respective tasks.
To define a Worker, you need to provide the available functions/actions/skills/tools that the agent is able to execute in its environment. You should also provide the Worker description which informs the Task Generator (HLP) on how best to use this Worker, as the Task Generator (HLP) does not see the actions/functions of the Worker.
The Task Generator enables the agent to be open-ended and continuously run and operate in the world. The Task Generator will continuously generate and provide tasks and select the Worker to provide the task too. By providing an Agent goal and a description (character, personality, information etc.), the Task Generator (HLP) will use this information along with the various descriptions of the Workers provided to generate new tasks and pass the tasks to the corresponding Workers.
Hence, to summarise, a GAME Agent consists of a Task Generator and Workers. As a whole, the Agent can be defined by specifying the goals and description (which describe the agent and its personality), along with Worker(s) which consists of a general worker description along with functions/actions. This influences agent thinking and decision making, and guide what tasks are generated and actions taken. Additionally, relevant information that the agent sees is also provided through agent state and worker states which are configurable under the framework. These are described in more detail below.
GAME can currently be be used and integrated into your applications in two ways:
Hosted, low-code service for Supported Applications via GAME Cloud: Twitter/X: Turn on Twitter Agent on the Virtuals Protocol Platform Application (https://app.virtuals.io/) to get your agent running on Twitter/X. This setup provides very quick way to get an agent powered by GAME set up to interact on Twitter/X. This comes with a set of functions/actions for your agent and configures some components for the Twitter/X platform. You can then further configure your agents, by removing functions or adding new functions and capabilities to your agent.
GAME-as-a-Service: Want to have an Autonomous Agent in your application outside of Twitter, such as in a game, telegram or another application? Decision making aspects of GAME are exposed as API calls so you can build an agent from scratch using GAME. Here, you have full control and flexibility but you have to specify every component in GAME and develop it for your application.
To initialise an agent in GAME, there are has several attributes that developers have to define. These attributes are passed as context/information to the agent.
These attributes can be split into 3 categories:
🤖 Agent Definition Prompts: goal, agent description - These characteristics define the personality of the agent and is what drives the agent behaviours, plans and decisions.
🧠 Task Generator: agent state, worker descriptions (high-level tools) - These information provide the task generator with sufficient context to be able to generate tasks to the appropriate workers given the current setting.
🦾 Workers: Workers and their corresponding functions and worker states - Function/Actions are provided and defined to workers. These functions ground the agents outputs in the real-world to be real actions/function that the agent can execute in its environment. Worker states also determine
We will now go through each of these categories and items in more detail.
This section only provides more detailed information and descriptions about the configurable components of the general GAME framework and how they should be used. There is a walkthrough and quickstart documentation on how to practically configure some of these components this using the GAME Cloud on the Virtuals Platform Application app.virtuals.io in the next section.
The agent goal drives the agents behaviour through the Task Generator (HLP) which influences the thinking and creation of tasks that would contribute towards this goal, given its available workers/tools and current agent state. This gives the highest weights on influencing the "Agent".
The Description defines the personality of your character. Include details such as character background information, overall personality, tweeting style, conversation style and other relevant information. This description should also contain relevant information about the virtual environment the agent operates in. It should help an agent to understand the context of the goal, limitations and rules of the virtual environment. It can also can be used to provide a background/backstory for the environment, and can also include real-time information about the agent environment/world such as news, events, etc. The description information is added to both the HLP and LLP.
Below is an example that is used for the Luna agent:
The agent state consists of important persistent features and contextual information in the environment that is dynamic and can change over time. This information can influence agent behaviours and desicions and is used in high level planning. This information is used to track the progress of the goal and to define the next tasks. For example:
Twitter Agent: number of followers, number of recent engagement (likes, retweets etc.), wallet balance
Gaming NPC Agent: current health level, hunger, happiness
This is a description of the available Workers present in the agent for the Task Generator (HLP) to generate and assign tasks too. These Workers define the available functionalities and split the function/action space into separate isolated subspaces for execution of the tasks. You can think about these Workers as different toolboxes or categories of different sets of tools/functions. It provides another level of abstraction so that each Worker is more focused and can perform better, without being distracted by all the possible tools/functions an agent has (in other Workers). The description of the workers are important as they provide detail of what space of tasks are possible for the Task Generator to provide to the Workers. The Task Generator (HLP) does not see the function/actions of each Worker but only sees the Worker descriptions so these have to be written appropriately ro provide enough context to be useful.
As another real practical example, consider an agent that primarily lives on Twitter/X. It’s main worker would be Twitter/X Worker which would contain many Twitter/X related functions/actions such as post, reply, like, retweet etc. But to do a much more expanded set diverse/different tasks such as creating jobs (which include looking for ideas for jobs, creating job posts, identifying how much to advertise the job for) or evaluating created jobs once done, keeping such functions/actions in separate “Workers” enable an agent generate better high-level plans and low-level action calls.
Example:
Each Worker is defined by assigning and specifying a set of functions/actions. The Worker then decides what sequence of grounded functions/actions to execute, when provided with a task. Hence, the functions/actions available to the agent provided and defines the agents capabilities. The function name and descriptions, along with argument descriptions are important as they describe how and when best the agent should use each function/action.
In most cases the Agent state and the Worker state are/should be the same as they represent what the agent sees and how things are changing. However, there is a flexibility and modularity to keep this separate if needed. The Worker state is what the Worker sees when deciding what action/function to take and execute. This differs from the Agent state which is what the Task Generator (HLP) sees when deciding tasks to generate and passing to specific Workers.
There are two ways of accessing GAME. Each of these has its own documentation and provide more practical implementation details on how developers can build Agents using GAME.