An Edge AI agent service provider and consumer built on top of the Areg SDK for distributed and event driven systems.
Important
This repository is under active construction and may not be fully functional yet. Follow the repository to receive updates as development progresses.
Areg SDK is a framework with tools for building distributed applications where communication, concurrency, and service lifecycle are first class concepts. It is designed for systems that require predictability, clear ownership, and strong runtime observability.
This repository demonstrates how Edge AI agents can be modeled as Areg services. Each agent acts as a service provider or a consumer, communicating through well defined interfaces instead of ad hoc message passing. Areg manages discovery, message routing, threading, and fault isolation, allowing AI logic to remain focused, testable, and reusable.
A key strength of this approach is observability. Areg provides structured logging that captures service interactions, message flow, and per method performance metrics. These logs can be inspected in real time or offline using Lusan, the official UI toolset for debugging and monitoring Areg based systems.
In practice, this means Edge AI systems built on Areg are transparent, traceable, and ready for production from the start.
The projects in this repository are built using the Areg framework and Qt libraries for UI development. CMake is used as the primary build system.
It is recommended to build the projects using Qt Creator. Alternatively, the projects can be built from the command line, provided that the required Qt packages are installed on the system.
The Areg framework is automatically downloaded and built as part of the project build process.
For Edge AI functionality, the project plans to integrate llama.cpp as the AI engine. Additional AI engines or agent types may be introduced in the future.
- C++17 compatible compiler
GCC, Clang, MSVC, or MinGW - CMake 3.20 or newer
- Java 17 or newer
Required for code generation tools - Qt 5.12 or newer
Required for UI based projects
- Operating systems
Linux and Windows - Hardware architectures
x86_64 for Edge AI engines
x86, x86_64, ARM, and AArch64 for simulated Edge AI clients
The following use cases illustrate how Areg can be applied to Edge AI systems. These cases represent the intended direction of the project.
This use case is part of the current implementation.
A single AI agent receives text processing requests from multiple clients. Clients may appear or disappear on the local network at any time. When the agent is online, clients can submit requests and receive responses. Requests are queued on the agent side, and each response is delivered to the correct client without mixing results.
Key features to demonstrate:
- No startup order is required. The AI Service Provider and the Service Consumers can join or leave the network at any moment without destabilizing the system.
- Requests are queued on the AI Service Provider side. Each reply is delivered to the correct client.
- Automatic service discovery. When the AI Service Provider becomes available on the network, all Service Consumers receive a service available notification and can start communicating.
A central service provider receives requests from many clients. For each request, the provider starts a dedicated thread or process hosting an AI engine instance. Processing runs in parallel and results are returned to the provider, which forwards them to the originating clients.
Key features to demonstrate:
- No startup order is required. Service Provider and Service Consumers join or leave the network freely.
- Requests are not queued. Each request immediately triggers a new thread or process with its own AI engine instance. When processing is complete, the central provider sends the response to the requester.
- Automatic service discovery with the same behavior as in Case 1.
- The system can instantiate many independent AI engine instances.
Each small Edge AI agent service represents a specific skill:
- One skill rewrites text.
- Another compresses it.
- Another expands it.
- Another evaluates or rates it.
Clients publish a goal such as generating a short description with a score above a given threshold. Any available skill that matches the requirement may claim the task. The system behaves like a decentralized marketplace of capabilities.
Key features to demonstrate:
- Auto-discovery of services with specific capabilities.
- Decentralized task assignment with no single point of failure.
- Multi-role behavior: any node may be both consumer and provider.
- Runtime expansion: new skills can appear and work instantly.
A virtual story world is created where each agent represents a character with a defined personality. A central controller introduces scenarios such as investigating a mystery, planning a project, or debating a topic. Agents exchange messages according to predefined rules and react to each other’s outputs.
Key features to demonstrate:
- Many independent agents interacting in a shared context.
- State synchronization through AREG events.
- Multi-room or multi-scenario orchestration.
- Dynamic participation: new characters can join or leave at any time.
A quality evaluation pipeline is composed of multiple evaluator agents:
- One evaluates clarity.
- Another evaluates style.
- Another checks consistency.
- Another evaluates creativity.
A coordinator aggregates the individual scores and produces a final rating.
Key features to demonstrate:
- Many small services contributing to a single final result.
- Parallel evaluations.
- Redundant evaluators: start three clarity evaluators and one is chosen automatically.
- Service discovery and role specialization.
A central register application monitors and coordinates multiple agent applications. Each agent hosts its own AI engine and has a unique name. Agents and the register may run on the same machine or on different machines.
The register can create discussion rooms by selecting multiple agents and providing a topic. Each agent generates an initial response. All participants receive the initial texts and continue a shared discussion. Multiple discussion rooms may exist at the same time, and agents may participate in more than one room concurrently.
Key features to demonstrate:
- Many AI agent services can run in the network at the same time.
- Every agent can act as both service provider and service consumer.
- Mesh style communication. Even if the register application shuts down, existing discussion rooms continue to function. Texts do not leak between rooms and each topic remains isolated.
- Fault tolerance. Any agent or the register can disconnect and reconnect without interrupting ongoing communication among other agents.
- Horizontal and vertical use. Agents can consume each other’s services or provide services to each other without restrictions.
Note
These use cases are planned and may change over time. Some may be combined, refined, or replaced as development progresses. Feedback and feature requests are welcome.
This project is at an early stage and actively looking for contributors.
If you are interested in Edge AI, distributed systems, service oriented architecture, or C and C++ development, consider joining the effort. Contributions are welcome in code, testing, documentation, integration, or design discussions.
This project is licensed under the MIT License. See the LICENSE file for details.