System Architecture Overview

The architecture for an Execution-Cognition Machine (ECM) is modeled after understanding the necessary theory to implement it. This documentation aims to detail the system's general architecture by revisiting the formal definition of an ECM. The ECM implementation requires two algorithms that meet specific criteria to effectively translate a user's problem into executable actions using the knowledge integrated into a Large Language Model (LLM).

Thus, as the formal conclusion of the theoretical approximation stated, we are seaching for two algorithms that satisfy:

Algorithm_1(p | C') = λ | λ ⊂ A' ∧ Algorithm_2(λ) = s

In this way, the ECM architecture contains:

Cognition Algorithm (A1): This algorithm translates a problem ( p ) using the knowledge from an LLM ( C' ) into a subset of actions ( A' ) within a defined action set ( A' ). It reflects the ECM's "cognition" aspect.
Execution Algorithm (A2): This algorithm takes the subset of actions ( A' ) and the problem ( p ) to produce a solution ( s' ). Since ( C' ) does not directly influence ( s' ), this algorithm can be simplified to ( A_2(p | A') = s' ). This reflects the "execution" aspect of the ECM.

Architecture Components

The ECM is designed to interconnect three key modules: "Cognition", "Execution", and "Action Space". The following diagram illustrates the proposed architecture and the interconnections between these modules:

Detailed Architecture Explanation

MCA (Main Core Agent): This class is responsible for maintaining an event loop connecting all the main modules in the ECM. It is built with the rest of the modules with the CELB.
Action Space (B'): This is where all possible actions that the system can perform are defined. It serves as the foundational layer from which the Cognition Algorithm selects a subset of actions ( A' ).
Cognition Space(A_1): This module processes the user-defined problem ( p ) using the integrated knowledge ( C' ) from the LLM (taking advantage of AutoGPT capabilities) to determine the appropriate actions ( A' ) from the Action Space. The output is a refined set of actions tailored to solve the problem expressed in an Exelent File. Note that all the system should be agnostic to the changes into the cognitive agent thanks to the AgentProtocol (acting as a mediator).
Execution Space(A_2): Once the subset of actions ( A' ) is identified, this module takes over to execute these actions to achieve the desired outcome ( s' ). It operates independently of the integrated knowledge ( C' ), focusing solely on action implementation. As the moment of writing this, the responsible class for doing this is ROSA, however the implementation should be easily changed by using the mediator.
Interpreter: As a middleware betwwwn A_1 and A_2, the interpreter is the class responsible for translating the specifications written in the Exelent file from the Cognitive Module into a set of objects/commands. If the Exelent file contains a set of plugins, this should be handled too by the interpreter, returning some actions to be resolved to the MCA.

ECMv2 Architecture Expansion

In the realm of artificial intelligence, the trend towards multi-agent systems reflects a move towards more distributed and specialized processing. Expert Agents are specialized entities designed to handle specific tasks or domains, such as gaming or data analysis, with greater efficiency and expertise than a general agent could. This specialization allows for a more scalable system that can adapt and respond more dynamically to complex environments or specific user requirements.

For this reason, the version V2 of the ECM aims to expand the action space ( A' ) without the need of more pre-composition or programming of each action. This concept stems from the current trend towards multi-agent architectures, where the main agent delegates the cognitive burden to specialized agents referred to as Expert Agents.

In this context, the Exelent language will now need to incorporate new statements that define a set of new requests from the cognition space. These requests will be forwarded by the Main Core Agent (MCA) to the appropriate Expert Agents. For instance, if the task involves playing a video game, instead of burdening the cognition space with this task, it could redirect the request to an agent specialized in gaming.

Notably, through the use of the AgentProtocol, we can employ the same interface as a mediator to maintain system stability and prevent modifications that could negatively impact the performance or functionality of the architecture. This ensures that any integration of new agents or capabilities remains plug and play, adhering to the established system architecture without disruptive changes.

With this, ECMv2's design philosophy enhances the system's adaptability and scalability by leveraging specialized expertise and maintaining a modular, plug-and-play approach through standardized protocols. This ensures that as the demands of tasks evolve, the architecture can easily integrate new capabilities without losing efficiency or operability.