Documentación técnica

Arquitectura Técnica

Desde el SovereignNode hasta la llamada LLM — así funciona AIMOS bajo el capó.

Diagrama de stack

Vista general del sistema

El flujo de datos completo desde el mensaje del usuario hasta la respuesta — todas las capas de un vistazo.

CANALES DE USUARIO Telegram E-Mail Voz (STT/TTS) Dashboard Shared Listener PostgreSQL (Message Relay) Orchestrator (VRAM Guard, Process Manager) Proceso del Agente (Memory + Skills + Prompt-Builder) LLM (Inferencia local) Ruta de respuesta Kernel Base de datos Orquestación Inferencia

Inferenz

Inferencia IA local

Inferencia local vía SGLang. Operación secuencial. Gestión inteligente de VRAM.

Qwen 3.5:27B (Q4, ~17 GB VRAM)

Modelo de 27 mil millones de parámetros con Tool-Calling nativo. Los modelos más pequeños (<20B) fallan en el control fiable de herramientas — un resultado crítico para producción de nuestra evaluación.

SGLang Runtime

Runtime LLM de alto rendimiento con endpoint API compatible con OpenAI. RadixAttention: el caché de prefijo se comparte entre agentes — sin recarga al cambiar de agente.

Operación secuencial

El VRAM Guard asegura que solo un agente accede al GPU a la vez. Las solicitudes se mantienen en la cola de la base de datos y se procesan secuencialmente — sin OOM, sin conflictos de VRAM.

Keep-Alive / RadixAttention

El modelo permanece 30 minutos en VRAM. Todos los agentes comparten el mismo modelo — sin descarga al cambiar de agente. El VRAM solo se libera después de 30 minutos de inactividad.

// Anatomía de una solicitud LLM
System Prompt + Contexto de Memoria Cognitive Balance Check LLM Inference SGLang API Tool Dispatch Ring-Check Audit Log + Response Token-Tracking

Gestión de contexto

Arquitectura de contexto

14.336 tokens de ventana de contexto. Cada agente utiliza 17–22% para su prompt — el resto queda para memoria, conversaciones y llamadas de herramientas.

// Composición de la ventana de contexto (14.336 Tokens)
Core Prompt ~2.000 Agent ~400-700 Tools ~400-600 Memories ~500-1.500 Calendario ~200 Chats ~300-600 Historial dynamisch Respuesta ~2.000 reserv. Fijo por agente (17-22%) Dinámico (Memoria + Conversación + Respuesta) ! Context Budget Guard Recorte automático: si el contexto supera el presupuesto, el historial de conversación se comprime antes de iniciar la llamada LLM. zZ Dreaming-Trigger Si el historial supera el umbral, el agente consolida conocimientos en la memoria a largo plazo (Dreaming) y vacía el historial.

Context Budget Guard

Antes de cada llamada LLM, se verifica la suma de tokens. Si supera el presupuesto, el historial de conversación se acorta automáticamente — los mensajes más antiguos primero. El prompt del agente y las definiciones de herramientas siempre se mantienen intactos.

Compresión dinámica

El presupuesto de contexto disponible se calcula dinámicamente: prompts de agente más cortos dejan más espacio para el historial y las Memories. Los agentes con conjuntos de herramientas extensos compensan con system prompts más cortos.

Agent-Splitting

En lugar de sobrecargar un agente con un prompt enorme, AIMOS distribuye el trabajo entre especialistas con prompts cortos y enfocados. Cada agente domina su área — menos prompt, más espacio para contexto.

Infraestructura

SovereignNode

Un único servidor. GPU local. Sin dependencia de la nube. El SovereignNode es el corazón de cada instalación de AIMOS — un servidor físico o virtual que alberga todos los componentes.

Todo funciona on-premise: la inferencia LLM, las bases de datos, los procesos de agentes y los canales de comunicación. Ningún byte sale de su red — a menos que usted lo configure explícitamente (ej. mensajes de Telegram).

Componente Minimum Recomendado
GPU NVIDIA RTX 3090 (24 GB VRAM) NVIDIA RTX 5090 (32 GB VRAM)
RAM 32 GB DDR4 64 GB DDR5
Almacenamiento 256 GB SSD 1 TB NVMe
CPU 8 núcleos 16+ núcleos
OS Ubuntu 24.04 LTS Ubuntu 26.04 LTS
SovereignNode GPU (NVIDIA CUDA / LLM Runtime) Qwen 3.5:27B (Q4, ~17 GB VRAM, native Tool-Calling) PostgreSQL SQLite (Memory) Orchestrator + VRAM Guard Agent A Agent B Agent C Shared Listener (Telegram, E-mail, Voz)

Dual-DB

Arquitectura Dual-DB

AIMOS utiliza dos sistemas de bases de datos con responsabilidades claramente separadas:

PostgreSQL (Base de datos Relay)

Retransmisión central de mensajes entre Shared Listener, Orquestador y agentes. Almacena mensajes entrantes, registros de auditoría, mappings PII-Vault y datos de sesión. Multi-proceso gracias al connection pooling.

SQLite (Memoria del Agente)

Cada agente tiene su propia base de datos SQLite con memoria semántica, episódica y procedimental. Búsqueda híbrida mediante FTS5 + embeddings vectoriales. Portable mediante simple copia del archivo.

PostgreSQL message_relay audit_log pii_vault sessions llm_usage SQLite (por agente) semantic_memory episodic_memory procedural_memory vector_embeddings dreaming_log Sync via Orchestrator

Interoperabilidad

Portabilidad de agentes

Los agentes AIMOS son portables, compatibles e interoperables gracias a estándares abiertos.

OAP Export/Import

El formato Open Agent Package permite la exportación completa de un agente incluyendo memoria, habilidades y configuración como archivo portable.

agent_export.oap
  config.yaml
  memory.sqlite
  skills/
  prompts/

MCP Bridge (39 herramientas)

El Model Context Protocol permite a LLMs externos (Claude, GPT, etc.) acceder a las habilidades AIMOS. 39 herramientas están disponibles como servidor MCP.

sql_query file_read rest_call memory_search +35 mehr

A2A Agent Cards

Cada agente publica una Agent Card (JSON-LD) según la especificación Google A2A. Los sistemas externos pueden consultar capacidades, formatos de entrada y nivel de confianza.

"name": "Agente de Construcción",
"skills": ["cad_read", "bom_gen"],
"trust_ring": 1
SovereignNode A Export: agent.oap Transfer OAP (Memory + Skills + Config) Import SovereignNode B Agente activo

Destacados técnicos

Lo que distingue a AIMOS

Native Tool-Calling

Sin hacks de texto ni análisis regex — AIMOS utiliza la API nativa de Tool-Calling del LLM. El agente controla sistemas directamente, en lugar de solo describir acciones.

Voz multilingüe

Reconocimiento de voz (Whisper STT) y síntesis de voz (Piper TTS) en todos los idiomas — los agentes entienden mensajes de voz y responden en el idioma materno del usuario.

Token-Tracking

Cada llamada LLM se registra: tokens de entrada/salida, latencia, utilización del contexto. Transparencia total de costes por agente, por conversación, por mes.

Conversation Threading

Cada agente sabe con quién habla en qué canal. Telegram, e-mail y mensajes internos se separan limpiamente — sin confusión entre interlocutores.