Rise of the AEAs - the autonomous economic agent (AEA) framework explained

David Minarsch · 14th April 2021

Intro

The Autonomous Economic Agent (AEA) Framework is a concept for a software toolkit that allows developers and researchers to create agents from components. Its initial implementation has recently reached v1.

A software agent is a computer programme that acts on behalf of a human or an organization and pursues a goal or optimizes an internal utility function.

To do so, an agent usually needs to connect to and communicate with many other services and other agents.

An AEA is an agent that has capabilities to autonomously transact and engage in alternative forms of economic exchange with other AEAs, humans and organizations. The primary settlement and commitment (or smart contracting) layer is facilitated by Distributed Ledger Technologies (DLT).

In programming terms, AEAs are defined by the software components they consist of, the data they are initialized with as well as the wallet they control. Their wallet contains cryptographic key-pairs which are used to sign transactions and messages.

The AEA framework is not the first agent framework. In fact, there have been many frameworks proposed in the literature and multiple implementations exist, most prominently the Java-based Jade, as well as several Python-based frameworks (e.g. 1, 2, 3). What sets the AEA framework apart is that it has been built for a truly decentralized multi-stakeholder environment with native support for DLT and that it is intended for both developers and users of agents.

In the following sections I discuss the framework, its motivation and application in more detail.

Why we created a framework

The AEA framework evolved from work my team did at Fetch.ai on our trading agent competition (TAC) in 2019. At the time, there was no agent framework and most development focus at Fetch.ai was on the ledger and several agent libraries. However, when working on the TAC we noticed that a library-based approach does not lend itself well to building agents in a structured and reusable manner. Hence, we started looking into the idea of a framework which would allow us to build entire agents quickly through re-use of code and encapsulation of functionalities.

Based on my own experience in working with web frameworks like Django and Ruby on Rails I was keen to replicate a similar experience for agent development. However, it was also clear, that unlike web development, agent development would be more challenging - the developer is not just building for the user, they are building software to represent the user - and that as a result it would be useful if developers could re-use not just framework-specific plugins but entire business logic components or agents.

Besides enabling Fetch.ai's vision of a DLT enabled multi-stakeholder multi-agent system I was personally also inspired by the challenge of creating a framework which allowed any user to run software under their full control, without reliance on a third party, and have that software work for them.

Fortunately, at Fetch.ai my colleagues Ali Hosseini and Marco Favorito were equally excited and committed to developing a framework and provided the necessary background from multi-agent systems (MAS) and (symbolic) artificial intelligence (AI). Senior management at Fetch.ai also backed the idea and provided the necessary support for its development.

Framework design

The framework is based around the concept of asynchronous message passing and uses an actor-like design paradigm. Messages are the primary means of communication between framework components as well as agents. That is, messages - unlike events - are directed towards a recipient and that recipient can be external or internal to the agent.

The framework aims to allow for modularity and reuse. As such it defines four core components which make up an agent:

• Skills: are the core focus of the framework's extensibility as they implement business logic to deliver economic value for the AEA and its owner. Skills are treated like black boxes by the framework and can contain simple conditional logic or advanced reinforcement learning algorithms, for instance.
• Connections: wrap an SDK or API and provide an interface to network, ledgers and other services. Where necessary, a connection is responsible for translating between the framework specific protocols and the external service or third-party protocol (e.g. HTTP).
• Protocols: define agent-to-agent as well as component-to-component interactions within agents. As such, they include messages, which define the representation, serialization logic, which define how a message is encoded for transport; and, dialogues, which define rules over message sequences for a given protocol.
• Contracts: wrap (access to) smart contracts for Fetch.ai and third-party decentralized ledgers. In particular, they provide wrappers around the API or ABI of a smart contract and its byte code.

The developer develops some packages or reuses those packages developed by others and then places them in context to each other in an AEA. The framework then calls the code in the packages. Unlike in libraries, it is the framework that runs and calls the code by making use of inversion of control.

Currently, the framework is implemented in the Python programming language. However, implementation in other languages is feasible too and importantly, it is fully interoperable with any language stack provided the protocols are implemented correctly. A demonstration of such interoperability with a simple agent implemented in Golang is provided here.

Together, these four components can be utilized to establish interaction protocols between entities.

The framework also offers auxiliary tools and services, including a command line interface (CLI), a protocol generator to generate protocols' code from their specifications, test tools, a registry for framework packages, and a desktop app to run finished agents.

In its design, the framework makes no assumptions about the type of agents implemented with it. As discussed below, it can be used in a wide range of application areas.

Research

Agent frameworks and multi-agent systems (MAS) have only found limited real-world applications despite being developed in the research community for multiple decades (1, 2). We hope that the AEA framework will see adoption in and contributions from the wider MAS community.

We have written a number of research papers to present our work to the wider MAS community. Furthermore, we were also fortunate to gain the advice from eminent researchers in the space including Michael Wooldridge and Anisoara Calinescu at Oxford University.

We welcome the AI research community to contribute to the framework's further development and help us improve the role for machine learning, reinforcement learning and other AI approaches in the framework. We hope the MAS research community will help us improve the agent interactions (protocols, skills) and other framework primitives. Economists can help us implement additional mechanisms for multi-stakeholder agent economies. Developers of web3 tools like Brownie and Vyper for instance, might help us integrate them with the framework. We invite everyone to contribute where they can do so!

Examples of interactions

As mentioned above, AEAs can interact with various external entities:

• AEA <-> AEA

  AEAs use the public internet for message transport. The agent communication network allows AEAs to communicate knowing their cryptographic addresses alone. The ACN is a multi-tier messaging system with a peer-to-peer overlay network at its core. The peers maintain a distributed hash table that maps addresses to network addresses.

  The messages are part of a protocol for agent communication. The AEA framework allows developers to use existing protocols, create new protocols and share them with other developers via the AEA registry.

  There is no limit to the type of interactions AEAs can engage in. A common example is two AEAs engaging in negotiation which results in a transaction on a ledger.

• AEA <-> Server

  AEAs are not limited to communicate with other AEAs only. AEAs might connect to servers as clients, requesting whatever services the server provides.

  A common example is AEAs querying public APIs for information, e.g. public transport information.

• AEA <-> Client

  AEAs can also maintain servers to serve requests to other clients. For instance, an AEA might run a server to allow its owner to connect to it via a web client.

• AEA <-> Blockchain node

  In the context of DLT AEAs act as off-chain elements. They can query ledger state, submit transactions and make smart contract calls. This allows AEAs to utilize the properties of blockchains, like public code execution and censorship resistant exchange.

Application Areas

By now, multiple application areas should come to mind. Some concrete themes are introduced here, but this should not be taken as an exhaustive list. The general theme spanning all these application areas is that of codifying interactions between different economic entities.

1. Automate user interactions with blockchains

   AEAs can be used to automate interactions of a user with a blockchain. The benefit is that the AEA can perform the interactions reliably and efficiently. A good example is the Autonomous Hegician which uses an AEA to automate option management.

2. Enhance user interactions with blockchains

   Users are heavily constrained when using blockchains by the web clients they have access to and their own abilities. An AEA can interact with a blockchain much faster, more securely and with more (on-chain) protocols than a human ever could.

   Also imagine in the future wallet just detects on which network you have funds, you send, all the gas/tx fee management happens under the hood

   — stani.eth 👻 =(⬤_⬤)= 👻 (@StaniKulechov) March 2, 2021

3. Abstract ledger specifics for developers

   For developers the framework abstracts away many ledger specifics. It allows developers to reuse plugins for specific ledgers which provide a common interface, thereby making it straight forward to write cross-ledger applications.

4. Supply off-chain data to blockchains

   Transaction based blockchain systems rely on constant external input to progress. As a result oracles take an important role for many on-chain applications. AEAs can be used to operate oracles. Since AEAs can utilize off-chain protocols they are the ideal framework to develop resilient oracles.

5. Bridge different ecosystems

   An AEA can bridge disconnected ecosystems. For instance, it can wrap a public API to serve data to other agents in agent native protocols, or expose its information via a server.

6. Enable agent to agent interactions

   AEAs shine when they are used to building multi-stakeholder agent-based solutions. Some examples we and other teams worked on include supply chain, mobility and decentralized manufacturing marketplaces.

   AEAs can also be connected to Layer 2 solutions like state channels (e.g. Perun, State Channels) and rollups (e.g. Optimism, ZkSync) to enable faster and cheaper transactions.

   Remember when the idea of an autonomous vehicle ($TSLA) using crypto to negotiate for road space, fuel, WiFi, etc. was Sci-Fi? Will be here before you know it.https://t.co/7KCwayRIlE pic.twitter.com/RVeogDcPso

   — Cameron Winklevoss (@cameron) February 10, 2021

7. Simplify protocol development

   A side effect of the AEA's protocol generator is that it allows developers to easily define new interaction protocols. In fact, with some extra effort this tool could be made available to everyone, providing one answer to this question:

   How can we make protocol development as easy as web development?

   — balajis.com (@balajis) August 22, 2020

8. Simulate multi-stakeholder economies

   Although the framework was not developed for simulations and agent-based modelling, it does lend itself under certain scenarios for this purpose. In particular, when no synchronization between agents is required and the simulation is meant to be as-close-to-reality-as-possible then the AEA framework can be used for this purpose. The multi-agent manager lets developers spin up many agents in a programmatic and dynamic way.

As evident from the above list, the framework is a product for both developers and end users of agents.

What's in it for me?

• As a smart contract developer you can use the AEA to automate contract calls and contract deployment. Much like Keeper, but not tied to a specific token or use-cases.

• As an agents-oriented developer you can use the AEA framework to combine machine learning code, agent-to-agent communication, DLT facilitated exchange mechanisms and search and discovery in one code-base.

• More generally, any developer can leverage the framework infrastructure (AEA registry) and tools for code distribution, reuse existing components (for decentralized apps but also legacy ones) and develop reusable new components.

• As a researcher, you can contribute to the evolution of the framework. We just painted the rough strokes, there are many gaps to fill!

We hope you too will be part of a community of researchers and engineers working on the bleeding edge of technology in the fields of machine learning, MAS and DLTs.

Now, why not get started and build your first AEA using our extensive documentation? And reach out to us on Twitter, GitHub - aea, GitHub - aea.dev and IRL.