Autonomous economic agents
Note
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.
Important
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:
DecisionMaker
The DecisionMaker
is the "economic brain" of the AEA, where the developers' or users' goals, preferences, message handling and wallet
control reside. It comprises:
- The
Wallet
, containing access to crypto addresses, public and private keys.Crypto
objects are used to load and encrypt private keys stored in an agent's local environment. - A
Resources
object, giving access to variousRegistries
, and allowing for the remote registration of various components such asProtocols
,Skills
,Contracts
andConnections
. - The
AgentContext
, which allows access to various objects that are relevant to the agent'sSkills
. - A
Preferences
object, used to check whether a proposedTransaction
satisfies the AEA's goals. This is done through the computation of a marginal utility score based on theTerms
of the transaction and the AEA's currentOwnershipState
.
Skills
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:
-
Handlers
implement AEAs' reactive behaviour. EachSkill
has zero, one or more handler objects. There is a one-to-one correspondence betweenHandlers
andProtocols
in an AEA (also known as registered protocols). If an AEA understands aProtocol
referenced in a receivedEnvelope
(i.e., the protocol is registered in this AEA), this envelope is sent to the correspondingHandler
which executes the AEA's reaction to thisMessage
. -
Behaviours
encapsulate actions which further the AEAs goal and are initiated by internals of the AEA rather than external events.Behaviours
implement AEAs' proactiveness. The Open AEA framework provides a number of abstract base classes implementing different types of simple and compositeBehaviours
(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.Behaviours
act 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
Model
.
Every Skill
has a
SkillContext
.
This object is shared by all Handler
, Behaviour
, and 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.
Example
In the 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:
self.context.outbox.put_message(message=reply)
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 DecisionMaker
.
Overview of AEA Skills Implementation
Note that 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.
The AbstractAgent
class
simply defines all the strictly necessary methods and properties required to
implement a concrete Agent
.
The AEA
class inherits from the
Agent
and extends it with
additional functionality.
-
The abstract class
SkillComponent
serves as the base class for the implementation of all the internal components of the AEASkills
. Upon instantiation, it receives aSkillContext
object, which provides access to theshared_state
. -
Then, the classes
Model
,Handler
, andBehaviour
implement the classSkillComponent
. Note that the inherited abstract methodssetup()
andteardown()
force the developer to ensure these methods are implemented on any concrete subclass. -
Also, note that the
Behaviour
class has access to two additional properties,tick_interval
andstart_at
, which allow that theBehaviour
, or more concretely, theact()
method, be invoked periodically, starting from the designated time. A simple concrete implementation ofBehaviour
, one which we will return to in the next section, looks as follows: -
A
ConcreteBehaviour
, therefore must implement the corresponding methods to initialize, execute the action, and finalize theBehaviour
.
AEA Communication
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
containing a Message
.
These messages adhere to specific messaging
Protocols
.
In order to make the communication possible, each AEA needs to
set up a Connection
, which
is managed by the
Mutliplexer
.
A 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
Contract
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).
The AEAs Identity
provides access to any associated addresses and public keys.
A list with Connections
allows agent-to-agent communication.