Autonomous economic agents
This page presents a brief overview of the Open AEA framework. We refer the reader to the Open AEA documentation for the complete details.
An intelligent agent is a computer program that observes its environment, processes the perceived information, and executes actions in order to achieve some predefined goals. Intelligent agents can be designed to work autonomously by gathering data on a regular, pre-programmed schedule, or when a user prompts them in real time.
An autonomous economic agent (AEA) is a specific type of agent that is concerned with the generation of economic wealth on its owners' behalf in an autonomous way.
A multi-agent system (MAS), also known as a self-organized system, is a computer system composed of multiple, intelligent agents that coordinate to solve a problem. Such systems are inherently decentralized: each of the agents pursues its own objectives and as a result, conflicts of interest are expected to arise. Furthermore, agents operate asynchronously, and due to this decoupling and the absence of a central moderator the resulting system becomes fundamentally uncertain.
Every agent service built with the Open Autonomy framework is a MAS composed of several AEAs that interact between them to achieve the goals of the service.
How Agent Services Are Secured
So, how can we create a functional system in which agents can pursue their objectives without guarantees on how other agents might behave? The answer lies in minimizing the need to trust other agents in the system by not making assumptions on how, or even if, they will respond.
Instead of relying on the other agents to behave honestly or a third party to mediate transactions (e.g., via escrow), in a MAS there is a distributed shared state in which transactions are recorded. This shared state takes the form of a deterministic finite-state machine (FSM), which is replicated by all the agents so that each one has a copy of it. The mechanism that is in charge of managing the replication is called the state-minimized consensus gadget (SGC).
In order to make any changes to the shared state, the agents in the MAS need to reach consensus over the update. For example, let us consider the case where the shared state is the current exchange rate between two cryptocurrencies. When a majority of agents that comprise the agent service decides on a single state, the shared state is updated accordingly provided that consensus is achieved. More precisely, FSM replication with \(N = 3f + 1\) agents can tolerate up to \(f\) simultaneous failures, and hence consensus over the new state is reached when \(\geq\lceil(2N + 1) / 3\rceil\) of the agents agree on a particular state. Systems that possess this fault tolerance level are referred to as being Byzantine fault-tolerant. The result is what is called a trust-minimized system, which refers to a system in which the amount of trust required from any single agent is minimized. That is, "by not trusting any single authority, this system creates trust by default."
Main Components of an AEA
Every AEA is composed of a number of components that work together to achieve the pre-defined goals of the agent. The image below offers a high-level view of such internal components.
As it can be seen, there are quite a few elements that make up an AEA. We briefly review the most relevant ones that play a role in the creation of an agent service:
is the "economic brain" of the AEA, where the developers' or users' goals, preferences, message handling and wallet
control reside. It comprises:
Wallet, containing access to crypto addresses, public and private keys.
Cryptoobjects are used to load and encrypt private keys stored in an agent's local environment.
Resourcesobject, giving access to various
Registries, and allowing for the remote registration of various components such as
AgentContext, which allows access to various objects that are relevant to the agent's
Preferencesobject, used to check whether a proposed
Transactionsatisfies the AEA's goals. This is done through the computation of a marginal utility score based on the
Termsof the transaction and the AEA's current
Skills are the core focus of the Open AEA framework's extensibility, as they implement business logic to deliver economic value for the AEA. They represent the AEAs knowledge, that is, self-contained capabilities that AEAs can dynamically take on board, in order to expand their effectiveness in different situations. Skills exhibit both reactive and proactive actions as follows:
Handlersimplement AEAs' reactive behaviour. Each
Skillhas zero, one or more handler objects. There is a one-to-one correspondence between
Protocolsin an AEA (also known as registered protocols). If an AEA understands a
Protocolreferenced in a received
Envelope(i.e., the protocol is registered in this AEA), this envelope is sent to the corresponding
Handlerwhich executes the AEA's reaction to this
Behavioursencapsulate actions which further the AEAs goal and are initiated by internals of the AEA rather than external events.
Behavioursimplement AEAs' proactiveness. The Open AEA framework provides a number of abstract base classes implementing different types of simple and composite
Behaviours(e.g., cyclic, one-shot, finite-state-machine, etc), and these define how often and in what order a behaviour and its sub-behaviours must be executed.
Behavioursact as a user in a traditional blockchain.
Since there might exist a need to share a certain context which is relevant both to behaviours and handlers, this can be achieved via a
Skill has a
This object is shared by all
Model objects. The
SkillContext also has a link to the
AgentContext, which provides read access to AEA specific information like the public key and address of the AEA, its preferences and ownership state.
ErrorHandler(Handler) class, the code often grabs a reference to its context and by doing so can access initialised and running framework objects such as an
OutBox for putting messages into:
Moreover, the programmer can read/write to the agent context namespace by accessing the attribute SkillContext.namespace.
Importantly, however, a
Skill does not have access to the context of another skill or protected AEA components like the
Overview of AEA Skills Implementation
Skills are one of the parts where the developer will need to invest more time, as it is where the concrete business logic is developed. This will be also the case when developing agent
services, because a special type of
Skill is what will define the agent
service business logic.
Therefore, we briefly provide a general overview on how an AEA
Skill is implemented in the Open AEA framework. See also the Open AEA documentation for the complete details.
simply defines all the strictly necessary methods and properties required to
implement a concrete
AEA class inherits from the
Agent and extends it with
The abstract class
SkillComponentserves as the base class for the implementation of all the internal components of the AEA
Skills. Upon instantiation, it receives a
SkillContextobject, which provides access to the
Then, the classes
Behaviourimplement the class
SkillComponent. Note that the inherited abstract methods
teardown()force the developer to ensure these methods are implemented on any concrete subclass.
Also, note that the
Behaviourclass has access to two additional properties,
start_at, which allow that the
Behaviour, or more concretely, the
act()method, be invoked periodically, starting from the designated time. A simple concrete implementation of
Behaviour, one which we will return to in the next section, looks as follows:
ConcreteBehaviour, therefore must implement the corresponding methods to initialize, execute the action, and finalize the
AEAs interact with other agents, either within the same agent service, and/or with agents in the outside world, via interaction protocols. In order to locate other agents, they connect to the Agent Communication Network (ACN).
More specifically, AEAs communicate asynchronously with other agents by exchanging
Envelopes, each one
These messages adhere to specific messaging
In order to make the communication possible, each AEA needs to
set up a
is managed by the
Connection wraps an SDK or API and provides an interface to networks, ledgers or other services, in addition to make possible the communication between AEAs through the ACN.
For example, the logic related to the execution of a smart
requires a connection to provide the agent with the
necessary blockchain network access.
Connection is responsible for translating between the framework-specific
Envelope with its
Message and the external service or third-party protocol (e.g. HTTP).
provides access to any associated addresses and public keys.
A list with
allows agent-to-agent communication.