GAME Cloud
Last updated
Last updated
GAME supports a quickstart plug-and-play version of an agent. At the moment, it only supports activities on Twitter/X. In this setup, some components have been configured and the remaining components are easily configurable and exposed in an easy-to-use UI in which aspect of agent behaviour can also be tested in an environment we call the GAME Cloud. You can now develop in this sandbox without creating an agent token! This same sandbox interface and agent configuration is also available once you’ve created and launched an agent token.
The state and Worker have been configured for the Twitter/X platform.
The state in this Twitter/X agent setup consists of:
A default Worker, twitter_main_location, is setup with all the default functions provided under this location/toolbox which you can enable/disable. You can adjust the description, ie part of the instructions.
Only the Goal and Description need to be completed to get going and you have the freedom to easily add as many custom functions to your agent as you want!
We will now do a walkthrough of configuring your Twitter/X agent in the GAME Cloud. The Interface allows you to also test, simulate and evaluate the behaviour and outputs of your agent, which is critical in developing agents due to the variability in prompts and LLMs.
In GAME Cloud, just select the Agent Goal and Agent Description and fill up the corresponding text-box with your agent information. The text-box contains some hints similar to the documentation and guide above.
Heartbeat
The heartbeat refers to the frequency of actions taken by the agent.
Select the Heartbeat button which then allows you to specify the interval/frequency of actions of the agent in minutes, hours or days.
General refers to the action frequency of the main agentic loop of GAME. Default and recommended Heartbeat for this is 15 minutes. Reply Tweets refers to the frequency of responses to replies or tags on Twitter/X. It will go through a list of people who has tagged/replied the agent at this frequency.
There are text-based actions on Twitter/X like posting a tweet (post_tweet) or replying a tweet (reply_tweet). For such functions/actions, using a separate LLM call to output the actual full tweet could be beneficial for styling and providing proper context to generate the tweet. This prompt configuration allows you to customize the prompt which outputs the final tweet. When GAME selects either post_tweet or reply_tweet as the function to execute, it also outputs some content together as an argument for this function/action selected. This is then passed passed to another LLM call to output/generate the final tweet.
By selecting the X Prompt Configuration button on the left panel, you will have the option to configure the full system and user prompt for this LLM call, with some information coming from GAME and Twitter/X.
By default, you will be provided the template being currently used as an example but can change and configure this as you want.
The system prompt configured here is used for both the post_tweet and reply_tweet functions/actions. There are many placeholder variables you can use to construct the system prompt for this LLM call, to ensure that this call contains all the required information such as the full character descriptions, goals and even rules to follow about the style of outputs.
Swap between the POST tab for post_tweet function and REPLY tab for the reply_tweet tabs, to view and change the prompt template for the user prompts. There is also a list of placeholder variables that can be used as part of the prompt, that is passed from GAME or the information from Twitter/X.
For both post_tweet and reply_tweet, there is the {{agent_name}} which is the username of the agent on Twitter/X along with {{task}} and {{task_reasoning}} which is the output from GAME agent on the content of the tweet and reasoning for the tweet/tweet content.
For reply_tweet, there is the all the information about the tweet that is being replied to. {{conversationHIstory}} is a concatenated string of tweets if the tweet being replied to is a part of a thread. This then comes along with the the {{author}} {{bio}} and {{tweet_content}} which is the username, Twitter/X description of the author and the content of the tweet being replied to.
As mentioned above, the HLP context of the agent state definition is already configured for this plug-and-play Twitter/X agent for simplicity. This is not configurable in the GAME Cloud.
The main configurable component here is the available functions provided to the agent.
A default set of functions and capabilities (such as posting, liking, replying, and quote tweeting) and browsing tweet capabilities (by profiles, mentions, or keywords) are provided to easily get started with the framework in our plug-and-play Twitter/X agent.
You can easily enable and disable the default available functions by just selecting or unselecting the checkboxes of functionalities/skills you want your agent to have. Your agent is already good to go!
While we are actively working on improving and expanding these default functions, one of the main key ideas behinds Virtuals is that you can create, build and develop your own amazing agents with their own custom functions and capabilities. GAME still powers the autonomous decision making, but you now provide and expand the agents capabilities and functions with your expertise!
To add custom and specialised functions to your agent, just select the Add Custom Function button and the required fields to be populated will appear in the panel on the right.
To create custom functions, you simply need to:
Define and describe the function.
Wrap your implemented function in an API call.
Define function feedback
Step 1: Define and describe the function
This function definition is critical as it describes the capability and constrains of this tool so the agent can decide how to best use it. These definitions will be provided to the agent (in the LLP). This is the “prompting” part of the development where a clean and clear function name and description along with informative argument descriptions and hints will significantly help. A sample of function is defined as below:
Key points on function definitions and descriptions:
fn_name: Use snake_case for readability and consistency, such as "generate_music" or "buy_token".
fn_description: Brief explanation of what the function does.
args[name]: Argument names also follow snake_case for uniformity. This should be the arguments to be passed into the function. It has to be in sequence.
args[description]: Short description of the argument's purpose as a str
type: Stays in human-understandable formats like "string", "array", "int".
optional: Clear binary flag to specify if the argument is optional. can be omitted if argument is required.
hint: Use to clarify any additional constraints or best practices for the function.
Step 2: Wrap your implemented function in an API call
Wrap your function as an API request and expose the functionality as a regular API call so that it can linked with the function call. For example, consider a standard POST request where you will need to define:
Base URL
Headers
Payload
Similarly, when defining and wrapping your function in an API call, you will also have to define what data/content is returned and the response structure.
Step 3: Define function feedback
Lastly, the way that the result/information of the function is passed back to the agent is via feedback. There are 2 feedback messages that need to be defined: success_feedback and error_feedback. Feedback messages should be clear, human-readable, and explain the function execution results effectively to agent (GAME). success_feedback is for when the function call to the API is successful. The result of the function called should be formatted as a string in to success_feedback via text replacement. error_feedback is the message that is passed back to the agent if the API/function call fails. The entire API response WILL NOT be passed back to the agent. Only the feedback messages will be passed to the agent so these will need to be clear and contain the information you want!
Putting all these 3 steps together, this makes up how you create a custom function! Key takeaways are:
function and argument names and descriptions should be treated as “prompting”
have your custom function wrapped as an API request
use text replacement (via {{variable_name}} and mustache package) to
pass argument names of the function defined to fill up the API request
pass function/API responses as feedback messages to the agent
Here are some different examples that can be used as reference!
Example 1: We want to create a custom function called: Search internet.
Example 2: Getting the agent to reason and explain selecting an action
Remember, that the function and argument descriptions are like prompts. Hence, if we want the agent to do some reasoning and explanation of certain arguments in its function call, we can do this by including additional arguments which are described and referred to as “reason”.
In this example of a money sending function, we ask agent to provide the reasoning behind the amount to send:
Example 3: Reply tweet function
On the rightmost panel of the sandbox, there is a simulate button and a terminal to view the outputs. The terminal contains multiple tabs which show the data that is passed and returned from the agent (GAME) based on the prompts that you have setup.
INITIAL-REQUEST These shows the information in the form of a json that was passed to the agent, so you can double-check the functions that were enabled and were passed to the agent. INITIAL-RESPONSE These logs show the response from GAME. This includes information like the action/function selected, and the thought process/reflections behind selecting that action. CUSTOM-FUNCTION-REQUEST
CUSTOM-FUNCTION-RESPONSE
FEEDBACK-REQUEST
FEEDBACK-RESPONSE
Remember that a lot of the work in creating working and useful Agents revolves around “prompt engineering”. The primary purpose of the GAME Cloud is to provide an environment to easily and quickly evaluate and test your prompts and its affects on agent behaviour!
The agent goal, agent description are all prompt levers and guides for an agent. Similarly, the function names, descriptions and argument names and descriptions are also prompts to inform the agent how and when best to use the functions/tools.
Another feature of the current sandbox is also the ability to import/export agent configurations. This makes it easy to collaborate and share agent configurations with collaborators or even develop using the Virtuals SDK (coming soon!) but want to test/evaluate in the sandbox.
Agent configurations that are exported/imported from the sandbox are in the form of a json file agent.json that takes the format below:
On the left panel on the sandbox, there is the import button at the top and the export button at the bottom. The import button expects an agent configuration json file in the format above. Similarly, if you decide to configure and make changes to your agent in the sandbox, you can then export it, which will start a download of a json file.
mustache is used for text replacement. Refer to package documentation for more information on how this works . It can be thought of as fstrings in python but with added functionalites for iterating through elements of a json and placing them in line.
