DEV Community: Cristhiam Leonardo Hernández Quiñonez

Architecture for Autonomous Agents

Cristhiam Leonardo Hernández Quiñonez — Sun, 27 Sep 2026 09:37:30 +0000

blog.hormigasais.com

description: How an architecture inspired by Edge Computing, distributed control, and lightweight protocols enables building autonomous systems prepared for the next generation of distributed intelligence.

tags: architecture, ai, python, edgecomputing

Sovereign Architecture for Autonomous Agents: Integrating Signal Networks, Git, Python, and Lightweight Protocols at the Edge
In nature, an ant colony does not need a single command center to coordinate its behavior. Each individual responds to local signals — such as pheromones — and simple rules; from the interaction of these signals emerges a collective behavior capable of solving complex problems.

The analogy is useful for thinking about distributed systems, but there is an important difference:
a software architecture should not literally copy nature. It must convert its principles — locality, signals, coordination, and adaptation — into verifiable technical mechanisms.

In 2026 software engineering, this idea connects directly with a consolidated trend: moving part of the processing and decision-making toward the edge of the network — the Edge — instead of concentrating all operations in remote infrastructure.

The goal is not to eliminate the cloud. The goal is to decide what must remain close to the data source, what can run locally, and which external services are truly necessary.

This article presents six pillars for a sovereign architecture oriented toward autonomous agents:

Signal Network
Git as Desired State Infrastructure
Python as the Orchestration Core
LBH Protocol
Edge Architecture
Technical Governance and Traceability

This is not a step-by-step tutorial. It is an architectural roadmap to design distributed systems in which autonomy, traceability, and operational control are explicit properties of the design.

Why the Edge? From the Centralized Model to Local Decision-Making For years, many software architectures followed a centralized pattern:

data traveled to remote services, the main logic was executed there, and subsequently, the result returned to the device.

That model continues to be appropriate for numerous use cases. However, not all systems have the same constraints.

Robotics, sensors, industrial automation, vehicles, critical infrastructure, and agents that must continue operating under intermittent connectivity may require local processing, lower latency, and degraded operation capabilities.

That is why the Edge should not be defined simply as a performance optimization.

In a sovereign architecture, the Edge is a control decision:

Sensitive data can remain close to its source.
Critical decisions can be executed locally.
Operations can continue even if the connection to remote services is interrupted.
The architecture can reduce unnecessary traffic to external infrastructure.
Each node can maintain an explicit part of the system's operational capacity. > Key Principle: Sovereignty does not mean disconnecting from the cloud. It means that an external dependency should not automatically become a single point of decision, operation, or failure.

The Signal Network: Event-Driven Architecture If the Edge is the body, the signal network is the nervous system.

Instead of constantly querying the status of all components, an event-driven architecture allows nodes to publish relevant changes and other components to react to them.

This pattern — Event-Driven Architecture (EDA) — appears in messaging and connectivity systems such as NATS and MQTT, although each technology has different characteristics and guarantees.

MQTT, for example, is designed as a lightweight publish/subscribe protocol for IoT and networks with limited resources or bandwidth. NATS offers publish/subscribe, request/reply, and streaming patterns, including capabilities oriented toward distributed systems and the Edge.

In HormigasAIS, the fundamental idea is more general:
do not constantly ask about everything; emit signals when something changes and allow interested components to react.
Conceptual example of a signal:
{
"timestamp": 1766646840.426,
"type": "mosquito_pulse",
"origin": "manager_alpha",
"status": "active",
"mode": "master"
}

The message can represent a telemetry event, a state change, a coordination signal, or a condition that requires processing.
The signal network decouples producers and consumers and allows new components to be incorporated without redesigning the entire system.

Git as Infrastructure of the Desired State Git is officially defined as a distributed version control system. Its value in a sovereign architecture goes beyond storing code. A Git repository can be used as a traceability layer for:
- behavior rules;
- declarative configurations;
- contracts between components;
- technical documentation;
- schemas and specifications;
- deployment policies;
- configuration artifacts;
- change history.

However, there is an important clarification:
Git should not be confused with an operational database or an absolute immutable ledger.

Its strength lies in conserving and distributing a project's history of changes. Each clone contains the repository history, which allows working in a distributed manner and recovering information even if a remote server becomes unavailable.

In a sovereign architecture, this allows separating two concepts:

Desired state: what the system declares it should be.
Operational state: what is occurring at the nodes at this moment.

Git can represent the former. Databases, queues, logs, and telemetry can represent the latter.
This separation is fundamental to avoid turning a version control tool into a piece that does too much work.

Python as the Orchestration Core In this architecture, Python occupies the role of the coordination layer. This does not mean that Python must execute every high-frequency operation. An Edge node can divide responsibilities across different layers:
- Python for business logic and orchestration.
- Compiled binaries for high-performance operations.
- Lightweight protocols for inter-node communication.
- Local databases for operational state.
- Git for configuration, specifications, and traceability.
- Specialized services for tasks requiring a different runtime. This separation allows using Python where it offers the most value: connecting components, processing events, applying rules, coordinating tasks, and maintaining high-level logic. The principle is not to choose a single language for everything. The principle is to assign each responsibility to the appropriate level.
The LBH Protocol: Lightweight Serialization with Verifiable Identity The Hormigas Binary Language (LBH) constitutes a specific layer within the HormigasAIS architecture. Its purpose is to provide a machine-to-machine communication format oriented toward environments where message size, sender identity, and data verifiability are relevant. The architecture can treat the protocol as a contractual boundary between nodes: input → validation → interpretation → processing → response Cryptographic identity allows a message to be treated not simply as arbitrary bytes, but as a unit associated with an identity and validation rules. Validation must consider, depending on the implementation:
- message integrity;
- authenticity;
- node identity;
- protection against message replay;
- protocol version;
- schema compatibility;
- execution context. LBH Validation Signature VALIDADO_NODO_A16_SV_2026_07_17_0120_AUTONOMO

This string functions as a validation identifier within the architectural example. It should not be interpreted on its own as a cryptographic proof: real verification must depend on cryptographic primitives, keys, metadata, and rules defined by the protocol's implementation.

That detail is important.
A sovereign architecture should not ask for blind trust in a label. It must allow verifying the assertion.

6. Edge Architecture: Distributed Intelligence, Not Isolation

The Edge node is where the previous layers meet.
A node can receive signals, maintain local state, execute coordination logic, validate LBH messages, and synchronize the desired state defined by the infrastructure.
A simplified representation would be:
┌───────────────────────────┐
│ DESIRED STATE │
│ Git / contracts │
└────────────┬──────────────┘
│
▼
┌───────────────┐ ┌─────────────────────┐ ┌───────────────┐
│ Signal Net │ ───► │ EDGE NODE │ ◄─── │ Protocol │
│ EDA / MQTT │ │ │ │ LBH │
│ / NATS │ │ Python / runtime │ │ validation │
└───────────────┘ │ Local state │ └───────────────┘
│ Rules / agents │
└──────────┬──────────┘
│
▼
┌────────────────────┐
│ Sensors / │
│ actuators / AI │
└────────────────────┘

The cloud can continue to exist as a complementary layer:

synchronization;
long-term storage;
heavy analysis;
collaboration;
observability;
model training;
services that do not need to run locally. The architectural difference lies in the fact that the Edge node is not reduced to a dependent terminal connected to a remote center. It can retain local capabilities and operate under previously defined policies.
1. Technical Governance and Traceability Autonomy without governance can quickly turn into complexity. Therefore, a distributed architecture needs mechanisms to know:
which version each node is running;
what configuration it has;
which protocol it is using;
what changes were made;
which messages were accepted or rejected;
which components can communicate;
which policies are active;
how to recover a known state. Here appears the sixth principle: every important decision must leave a verifiable footprint. Technical governance does not mean controlling every operation from a central server. It means defining contracts, boundaries, identities, and recovery procedures that can be audited. Autonomy and governance are not opposites. A mature architecture needs both.

8. The Complete Architecture

The six pillars can be summarized as follows:
SIGNAL NETWORK
│
▼
EVENTS ──────────────┐
│
▼
┌─────────────┐
│ EDGE NODE │
│ │
│ Python │
│ + │
│ agents │
└──────┬──────┘
│
┌──────────┴──────────┐
▼ ▼
LBH PROTOCOL LOCAL STATE
│ │
└──────────┬──────────┘
▼
TECHNICAL GOVERNANCE
▲
│
GIT / CONTRACTS

Each component has a distinct function.
The signal network communicates.
Python coordinates.
LBH defines a verifiable communication boundary.
The Edge executes close to the data source.
Git conserves project history and desired state.
Governance provides the rules that allow everything above to evolve without losing traceability.

Sovereignty as an Architectural Property Technological sovereignty should not be reduced to a political or commercial statement. In engineering, it can be expressed as a verifiable property of the system: What can the system continue to do if an external dependency disappears? The answer identifies which parts of the architecture are truly autonomous and which continue to depend on external services. A system can use the Internet, cloud, GitHub, external APIs, or specialized services and still maintain an Edge architecture. The relevant question is not whether a dependency exists. The question is: What happens when that dependency stops being available? That scenario — the degraded mode — is one of the most useful tests to evaluate the real autonomy of a distributed system.
Conclusion Sovereignty is not isolation. It is the capacity for decision, operation, and recovery under defined conditions. An architecture for autonomous agents can combine signal networks, Git, Python, lightweight protocols, and Edge nodes without turning any of them into a universal solution. Architecture emerges from the separation of responsibilities. Events transport signals. Nodes execute local decisions. Protocols establish contracts. Git conserves history and desired state. Governance provides traceability. And Edge infrastructure keeps close to data the capabilities that truly need to remain local. Like an ant colony, the system does not need every decision to pass through a single point to coordinate. It needs signals. It needs rules. It needs identity. It needs memory. And above all, it needs verifiable mechanisms to know what is occurring. > Sovereignty is not isolation: it is the capacity for autonomous decision-making.

Traceability and Source Code

The protocol specification, mapping matrix, and artifacts related to this architecture are publicly available through the HormigasAIS ecosystem.
Site:

Reference node:
Node A16 — San Miguel, El Salvador
Example validation identifier:
VALIDADO_NODO_A16_SV_2026_07_17_0120_AUTONOMO

Building Resilient Edge Agents with LBH: A PWA Heartbeat System Running on Android

Cristhiam Leonardo Hernández Quiñonez — Wed, 16 Sep 2026 03:05:45 +0000

Most edge demos look great on a laptop.

I'm currently building HormigasAIS, a lightweight edge architecture designed to run agents and services from constrained devices. One of the core pieces is a binary protocol called LBH (Lenguaje Binario HormigasAIS) and a small WebSocket client that keeps the channel alive under real mobile conditions.

This post shows the current state of that client — specifically the heartbeat + telemetry layer — a recent resilience improvement for Android background behavior, and what happened when I moved from a browser demo to an actual installed app on the phone.

The Core: LBHHeartbeatAnt

The client is a single class that manages:

WebSocket connection to a local Edge Node (ws://hostname:8765)
Binary LBH frames
Heartbeat (pheromone) messages
Inactivity detection
Automatic reconnection

Key design decisions:

Binary frames start with magic bytes "LA" (0x4C, 0x41)
Type 0x01 → Telemetry
Type 0x02 → Heartbeat / ACK (called "Feromona")
When the user is inactive for 30 seconds, the client enters a HIBERNATING state while keeping the socket open
Any user activity (click, touch, keydown…) "unfreezes" the channel

Here's the essential part of the heartbeat emission:

emitHeartbeatPheromone() {
  if (!this.ws || this.ws.readyState !== WebSocket.OPEN) return;

  const buffer = new ArrayBuffer(16);
  const view = new DataView(buffer);

  view.setUint8(0, 0x4C); // L
  view.setUint8(1, 0x41); // A
  view.setUint8(2, 0x02); // Heartbeat / Feromona
  view.setUint8(3, 0x01); // Standby flag

  view.setUint32(4, 9999);
  view.setUint32(8, 0);
  view.setUint32(12, Math.floor(Date.now() / 1000));

  this.ws.send(buffer);
}

Telemetry frames follow the same structure (type 0x01) and carry a sensor ID + value.

Real Runtime Behavior

From the Edge Node logs you can see the system working:

🐜 Trama 0x01 | Sensor=1001 | Val=600 | TS=1789366095
⚠️  [AGENTE AUTÓNOMO] Alerta Sensor 1001 → Val=600
🐜 Respuesta LBH enviada

🐜 Trama 0x01 | Sensor=1001 | Val=400 | TS=1789366395
🐜 Respuesta LBH enviada

And the continuous heartbeat ACKs:

❄️  Feromona 0x02 ACK (socket preservado)

The UI on the phone simply shows a telemetry input and a green "Enviar Trama LBH" button.

When the channel is healthy, it displays:

«Canal Activo (Descongelado)»

The goal is deliberately simple: the user should not need to understand the underlying socket state, frame format, or reconnection mechanism.

The Android Problem and the Fix

Android browsers are aggressive.

When a PWA goes to the background, the WebSocket can be killed without producing a clean onclose event. The normal 3-second reconnect timer is therefore too slow for a good user experience in some situations.

I added a visibilitychange listener:

setupVisibilityListener() {
  document.addEventListener("visibilitychange", () => {
    if (document.hidden) return;

    const isDead = !this.ws ||
      this.ws.readyState === WebSocket.CLOSED ||
      this.ws.readyState === WebSocket.CLOSING;

    if (isDead) {
      this._setState(
        "OFFLINE",
        "🟡 Verificando canal tras reanudar..."
      );
    }

    this.connect(); // safe to call repeatedly
  });
}

Now, as soon as the user returns to the app, the client checks the socket state and reconnects immediately if needed.

The important part is not trying to fight Android's lifecycle behavior. Instead, the client treats visibility changes as part of the runtime environment.

Update: Tested as a Real Installed App

After writing the piece above, I installed the PWA directly on the Android device using the browser's install prompt — not just a localhost browser tab.

I then tested it with split-screen:

The PWA running in one pane
The Edge Node's live log running in the other

With the screen locked or the app pushed to the background, the log kept showing:

❄️  Feromona 0x02 ACK (socket preservado)

continuously.

That confirmed an important behavior in this particular test environment: the socket survived backgrounding as an installed app, not only as an open browser tab.

This distinction matters when building edge agents for constrained mobile hardware. The phone isn't just being used as a browser; it is becoming part of the edge runtime.

A Known Rough Edge

There is still one small race condition on the reconnect path.

Switching visibility very quickly and repeatedly — for example, rapidly switching between apps — can occasionally produce a server log like:

cliente conectado
cliente desconectado

where the cliente conectado entry for the new socket can appear before the matching cliente desconectado entry from the previous socket.

The server handles both connections cleanly:

No leaked connections
No corrupted frames
No protocol failure

However, the log ordering isn't strictly sequential in that edge case. The cause is a small gap in the current connect() guard. At the moment, it checks for OPEN and CONNECTING, but does not yet treat CLOSING as a state that should block a new connection attempt.

Tightening that guard is on the list. For example, the intended logic is conceptually:

if (
  this.ws &&
  (
    this.ws.readyState === WebSocket.OPEN ||
    this.ws.readyState === WebSocket.CONNECTING ||
    this.ws.readyState === WebSocket.CLOSING
  )
) {
  return;
}

One Important Security Limitation

It is also worth being upfront about the current security boundary.

The WebSocket server currently has no authentication layer. That means any client on the same local network can send LBH frames to the endpoint.

For a local development or demonstration node, this is acceptable for the current testing stage. It is not appropriate to expose this WebSocket endpoint directly on a public network in its current form. Authentication and authorization are therefore part of the next hardening stage.

Why This Matters for Edge Computing

The interesting part of this experiment isn't simply keeping a WebSocket alive. The larger question is:

«Can constrained devices participate in a useful distributed computing architecture without behaving like thin clients that constantly depend on a remote cloud?»

The current architecture is intentionally lightweight:

┌──────────────────────┐
│      Android PWA     │
│                      │
│  Telemetry + LBH     │
│  Heartbeat           │
│  Reconnection        │
└──────────┬───────────┘
           │
           │ WebSocket
           │ Binary LBH
           ▼
┌──────────────────────┐
│      Edge Node       │
│                      │
│  LBH Parser          │
│  Agent Logic         │
│  Telemetry           │
│  ACK / Pheromone     │
└──────────────────────┘

The phone can therefore act as both:

A user interface, and
A constrained edge computing endpoint.

That opens an interesting path for low-cost deployments where dedicated server hardware isn't always available.

Current Focus

This is still early-stage infrastructure.

The goal is to turn these lightweight LBH agents into injectable services that universities and small/medium businesses (Pymes) can use without depending on heavy cloud stacks.

The entire development loop — coding, testing, sealing, and deploying — happens from an Android device running Termux. That constraint is intentional. If the development and deployment workflow can operate from a phone, the same architecture can potentially be adapted to other low-resource environments.

What's Next

The next engineering steps are:

More formal agent decision layer
Cleaner packaging of the PWA + Node
Authentication for the Edge Node's WebSocket endpoint
Fixing the CLOSING-state race in the reconnect guard
Documentation and examples aimed at educational and SME use cases

The focus is not on making the architecture unnecessarily large. It is on making the smallest useful pieces reliable enough to become infrastructure.

Final Notes

This experiment started as a simple browser-based heartbeat mechanism. Moving it onto an actual Android device changed the nature of the test.

Background execution, application lifecycle, WebSocket state, reconnection, telemetry, and protocol framing all become part of the same engineering problem.

That's where edge computing gets interesting. The device is no longer just displaying a dashboard. It is participating in the system.

If you're working on edge systems, constrained devices, or protocol design and want to exchange notes, feel free to reach out.

By: Cristhiam Leonardo Hernández Quiñonez | Protocol Architect & Founder at HormigasAIS | hormigasais.com | GitHub

The Technological Ouroboros: Closing the Loop Between Open Source and Private Sovereignty

Cristhiam Leonardo Hernández Quiñonez — Sun, 13 Sep 2026 02:36:26 +0000

By Cristhiam Leonardo Hernández Quiñonez (CLHQ)
Founder – HormigasAIS | Sovereign edge computing ecosystem – San Miguel, El Salvador

In ancient alchemy, the Ouroboros is the symbol of a serpent devouring its own tail. It represents the eternal cycle, self-sufficiency, and "the unity of all things, material and spiritual, that never disappear but perpetually change."

Today, in modern software engineering, achieving that Ouroboros — a system that sustains itself, protects itself, and validates itself — is the Holy Grail of Digital Sovereignty.

Looking closely at HormigasAIS's institutional setup (Node A16-SanMiguel-SV), what we find isn't just a branding policy, but a piece of legal and cryptographic engineering that works exactly like this symbol.

1. The Tail: Open Source (MPL 2.0)

HormigasAIS releases its binary communication protocol [lbh-sdk(https://github.com/Thrumanshow/lbh-sdk) under the MPL 2.0 license. The community can use and improve the binary language. The serpent offers its tail to the ecosystem.

2. The Head: Private Infrastructure

While the base protocol is open, the enterprise implementation — master nodes (A16 Architecture), internal governance, and proprietary agents — remains strictly separate. This layer operates under a distinct institutional license (internally referred to as MESENTERY), which is still being formalized. The head is private and sovereign.

3. The Bite: Cryptographic Dogfooding

How do they protect their intellectual property without depending on third parties? They use their own protocol to seal their own brand. In May 2026, instead of going to a traditional notary, they generated a cryptographic seal (HMAC-SHA256) using their LBH/SECRET key from their node in El Salvador, to authenticate their logo.

The open source they give to the world is the same tool they use to legally shield their private company.

Why does this model matter? Because it resolves the paradox of sovereign technology. Many governments want to move away from foreign technological hegemony, but hesitate on pure open source due to a lack of control. HormigasAIS has created a closed loop where the community strengthens the protocol, the protocol builds trust, and that trust sells self-protecting private infrastructure.

The result is an entity that doesn't need to validate its existence outside its own boundaries. Like the Ouroboros, it is self-sufficient.

Emitido desde Nodo A16-SanMiguel-SV

Building the LBH Protocol from Android/Termux: A Sovereign Edge Architecture

Cristhiam Leonardo Hernández Quiñonez — Sun, 13 Sep 2026 00:40:59 +0000

By Cristhiam Leonardo Hernández Quiñonez (CLHQ)
Founder – HormigasAIS | Sovereign edge computing ecosystem – San Miguel, El Salvador
github.com/Thrumanshow/HormigasAIS

1. The Problem: Depending on the Cloud to Validate What's Real

Most content-verification and edge-computing stacks today assume a baseline dependency: a cloud provider, a centralized API, or a third-party service sitting between your data and the claim that it's authentic. That dependency is convenient, but it's also a single point of failure and a single point of control.

The question I kept returning to while building HormigasAIS was simple: can a verification system be sovereign? Not "self-hosted on someone else's cloud," but genuinely independent — running on infrastructure you own, from a device as unconventional as a phone.

2. The Solution: A Node Architecture Built on Sealing, Not Trust

HormigasAIS approaches this with a node-based architecture rather than a service-based one. Three pieces anchor it:

LBH cryptographic sealing — content is sealed using SHA-256 + HMAC-SHA256, with signed verification that doesn't require calling out to a third party to confirm integrity.
barrera.js — an ethical/logical filter layer (informally, "decromatiza") that sits between raw input and the system's accepted state.
humano.js — a small symbolic module declaring the human-language layer of the project: HormigasAIS = {{lenguaje-humano}}. It's less a functional API and more a positioning statement embedded directly in code — a reminder that the system is meant to stay legible to a human reader, not just to a machine.

None of this requires a data center. The full development loop — writing, testing, sealing, deploying — happens from an Android device running Termux.

3. The Implementation: From a 404 to a Working Node

The most concrete proof point is small on purpose. The repository Thrumanshow/HormigasAIS started as a set of governance and symbolic files with no public-facing page — visiting its GitHub Pages URL returned a plain 404.

Getting it live took: enabling GitHub Pages from the main branch root, writing a minimal index.html, and documenting the repo properly — README.md, LICENSE (MIT), GOVERNANCE.md, STATUS.md, and MANIFIESTO.md.

The entire sequence — clone, edit, verify with curl, commit, push, confirm 200 — ran from Termux on a Samsung A16, no laptop involved.

4. The Ecosystem: What's Actually Public

To be precise about what's verifiable versus conceptual:

Live and checkable:

hormigasais.com — main site
api.hormigasais.com — Worker API
docs.hormigasais.com — documentation
blog.hormigasais.com — blog
The formal LBH specification is deposited on Zenodo: DOI 10.5281/zenodo.17767205

Governance:
The project operates under an explicit GOVERNANCE.md, which is worth flagging precisely because it's unusual for a solo project: it draws a hard line between forking/using the code (permitted under license) and any claim of official representation or node status (which requires explicit, written recognition from the maintainer of record). Forks are welcome. Authority isn't inherited by default.

Still experimental:
The broader multi-agent decision system and node-validation layer are active work — not yet at the same level of external verifiability as the sealing protocol or the published spec, and I want to be upfront about that distinction rather than blur it.

If you're building anything edge-first, protocol-level, or just skeptical of cloud dependency by default — I'd welcome the conversation.