on Nov 1, 2024
by Gnosis
in Developers
Gnosis Labs: Developing an autonomous agent
Introduction
This is the second post by the Gnosis Labs team - if you haven’t yet, take a look at the inaugural post by the team, where we introduce our work.
In this article, we aim to shed some light into one of the agents we are building, the General Agent (link to repo), which can autonomously read information on-chain (e.g. balances, positions) as well as interact with protocols (e.g. place bets and redeem winnings on Omen, a prediction market running on the Gnosis chain).
The Concept of the General Agent
The idea behind the General Agent (as the name says) was to make it as general as possible, i.e. we wanted to answer the question, “Is it possible to have an agent that behaves like a living organism on-chain, which tries to survive, evolve and reproduce”?
The question above can be controversial (see a great video on this topic), but we focus here on the technical side of it - if we were to have such an agent, what kinds of tools would we have to provide to it so that it can fulfill its goals?
The first goal (”survive”) is closely related to earning money, because if it has a zero balance, then the agent will lose its ability to execute any reasonable actions on the blockchain due to its inability to pay fees.
The initial way we envision the agent to make money (among an ocean of other possible ways) is to bet on prediction markets, more specifically on Omen. If the agent has a reasonable accuracy, then it’s expected that it will earn a positive amount of money over time, hence it will be able to survive.
We note that the major source of costs for the agent is related to API calls to LLM providers, specially OpenAI (roughly $0.25 per run). For further explanation in this blog post, we neglect these AI inference costs.
Blazing fast introduction to Prediction Markets
Prediction markets (link) are markets where people can speculate on top of future events. They are very similar to future contracts, however the event they are tracking does not need to be a price of a financial asset.
Prediction markets have several use-cases: they can be used for futarchy (link) to guide government decisions; they can be used for speculating on top of sport events, and several others.
For our ensuing agents discussion, we will restrict our analysis to prediction markets that follow the Constant Product Market Maker (CPMM) mechanism (link), which in turn closely resembles the mechanism of Automated Market Makers (AMM).
Without entering the nitty gritty math details, the basic idea is the following:
The funder creates a market (i.e. poses a question such as “Will Apple launch Iphone 16 by March 2nd, 2024?”) and adds some liquidity to it.
Traders (market participants) can trade in the newly created market, either betting on YES (buying YES outcome tokens) or on NO (buying NO outcome tokens)
Note that here is the biggest similarity with AMMs, namely that the price of YES and NO tokens follow the x*y=k bonding curve (being x and y the number of tokens)
Market participants can also add liquidity to the market and be entitled (as is the case of the funder) to fees that are accrued when traders trade against the market.
At resolution, the market is resolved (by an external oracle) and people holding outcome tokens corresponding to the correct answer have access to the liquidity available for the market.
Finally, winning betters can redeem their positions and rewards.
Prediction market example. Taken from presagio.pages.dev.
Coming back to the AI agents, the ways they are interacting with prediction markets is twofold:
We have funder agents that create markets
We have trader agents whose aim is to place correct bets on markets
Additional information on the theory on prediction markets can be found in the following tutorials:
Capabilities of the General Agent
Until now, the Gnosis Labs team implemented a bunch of functions for the agent, such as placing bets on binary markets on Omen; redeeming positions and selling outcome tokens. You can see that on our dashboard for the autonomous agent.
https://autonomous-trader-agent.ai.gnosisdev.com/
We highlight one of the functions - BuyYes. The way one goes about creating a function and providing it to the agent always follows the pattern below (we use the microchain package as agent framework):
1 - Create a new class that implements the Function class from microchain
# https://github.com/gnosis/prediction-market-agent/blob/main/prediction_market_agent/agents/microchain_agent/market_functions.py#L274
# imports
# MarketFunction implements microchain.Function
class GetBalance(MarketFunction):
@property
def description(self) -> str:
return (
f"Use this function to fetch your balance, given in {self.currency} units."
)
@property
def example_args(self) -> list[str]:
return []
def __call__(self) -> float:
return get_balance(market_type=self.market_type).amount
2 - Register the function on the agent’s engine
# https://github.com/galatolofederico/microchain?tab=readme-ov-file#define-a-llm-agent
# imports
engine = Engine()
engine.register(GetBalance())
and that’s it!
Another factor that plays a role in the performance of the agent is of course its prompt. We are currently experimenting with 2 different prompts:
Trading focused prompt - The agent is prompted to be a trader on prediction markets, with a brief explanation of what it should be doing (link to prompt)
General prompt - Agent is prompted to learn, survive and evolve. Everything else is up to it to figure out from the available functions. (link to prompt)
We are tracking the performance of both agents in our Dune dashboard (link) and it remains to be seen which one performs best, especially as the number of tools available to the agents increases.
We also highlight that the autonomous trader is able to update its own prompt and its goals, hence we expect it to be more powerful in the long term due to its extra flexibility.
Both prompting options are available on this dashboard for experimentation.
https://autonomous-trader-agent.ai.gnosisdev.com/?free_access_code=x
Challenges and Triumphs
As discussed in the paragraph above, the “General prompt” option is quite general in the sense that it states no goals to the agent, just “learn, survive and evolve”, and exposes it to a set of functions.
By exploring and experimenting with the engine toolkit, it’s remarkable that it’s able to place a bet within 10 iterations (please give it a spin using our autonomous-trader dashboard).
One last challenge we faced is keeping the “memory” of the general agent. There are several ways to do that (CrewAI has a nice overview), the easiest way being a technique called Conversation Buffer (link).
The general agent employs this technique (in fact, it’s available by default in the microchain package). In addition, we also allow the agent to restore a previous prompt, so that it can run further iterations even after it was interrupted. This is especially relevant in the “general agent” case, where the prompt is updatable by the agent.
From the autonomous trader dashboard. See bottom toggle for loading historical prompt.
Next steps
We have a few ideas for the next steps for the general agent. Among other topics, we plan to explore the following:
Dynamic creation of tools - instead of writing all the tools ourselves, we plan to include tools created by third-parties (specially by the community) to make the general agent even more resourceful.
Within this topic, one avenue we are exploring is leveraging the Olas protocol (link), specifically their mechs, for serving transaction parameters to the agent which then signs and executes the transaction. This would allow the agent to execute many different kinds of transactions, without having knowledge of the inner workings of a specific contract with which it wants to interact.
Dynamic creation of tools from smart contracts - this would involve auto-generating the function calls from the smart contract dynamically, similar to what Typechain does when generating Typescript classes/functions.
Unfortunately we can’t use Typechain directly because the agent can only execute Python functions. However, there are other promising packages we can explore.
We note that the agent would be responsible for calling a function (for example,
GenerateFunctionsForProtocolXYZ), which would then trigger the logic for auto-generating the function calls given a smart contract previously deployed on-chain.
We are also very interested in the input/feedback of the community regarding the next developments. Feel free to contact us on Twitter (link) or Discord (link), channel gnosis-ai.
Links
Dune - https://dune.com/hdser/omen-ai-agents
Github repos
PMAT - https://github.com/gnosis/prediction-market-agent-tooling/tree/main
More articles
