ATLAS: asistente local-first y multiplataforma para IA, sistema y productividad
ATLAS es un proyecto personal de fin de semana inspirado en la idea de un J.A.R.V.I.S. propio, construido desde cero para explorar un asistente local-first y multiplataforma con clasificación de intención, sesiones, orquestación de herramientas, telemetría y síntesis de voz. Su objetivo es mantener control real sobre el diseño y la evolución de la solución, sin depender de herramientas previamente construidas, y servir como base para crear agentes especializados para distintos workflows.
Hay proyectos que nacen de una necesidad inmediata y otros que nacen de una idea que simplemente no te deja en paz. ATLAS pertenece a la segunda categoría.
Nació como un proyecto personal de fin de semana, impulsado por la curiosidad de explorar hasta dónde se puede llegar sin depender de un único proveedor externo y poniendo en práctica conocimiento que he ido construyendo durante los últimos años. Parte de la inspiración inicial viene de la idea de tener un J.A.R.V.I.S. al estilo de Iron Man, pero construido desde una base propia, sin apalancarme en herramientas previamente hechas como OpenClaw, Hermes u otras similares.
La intención no era solo crear otro asistente con IA, sino diseñar una base flexible capaz de clasificar intenciones, coordinar sesiones, ejecutar herramientas locales y devolver respuestas útiles con una arquitectura clara y extensible. Con ello, mantengo control real sobre el diseño y el desarrollo de la solución, tanto en su alcance actual como en su escalabilidad futura, para que yo mismo o cualquier otra persona que le vea utilidad al repositorio pueda construir sus propios agentes especializados para los workflows que necesite.
El resultado es una POC funcional construida en Python, con un enfoque local-first, multiplataforma y orientado a crecer por módulos. ATLAS combina clasificación estructurada, orquestación con herramientas, persistencia de sesiones, telemetría y síntesis de voz, además de un proxy compatible con APIs OpenAI para desacoplar el backend de modelo del resto del sistema.
La idea detrás del proyecto
Más que partir de una necesidad urgente, ATLAS surge como una exploración técnica con intención práctica. Quería construir un sistema que me permitiera experimentar con:
- Clasificación de intención con salida estructurada.
- Enrutamiento a agentes especializados.
- Ejecución segura de acciones locales.
- Manejo de sesiones conversacionales.
- Síntesis de voz y salida multimodal.
- Observabilidad real desde el primer día.
La premisa fue simple: si el sistema puede entender lo que el usuario quiere, decidir cómo resolverlo y dejar trazas claras de todo el proceso, entonces la base ya es útil incluso antes de crecer a una suite más grande de agentes.
Una arquitectura modular y observable
ATLAS está organizado como una cadena de componentes bien separada, donde cada capa cumple una función específica:
Componentes que conforman la arquitectura
- Entrada y CLI: el punto de entrada principal permite ingerir texto, levantar el daemon local, listar voces TTS y probar síntesis.
- Ingesta y registro: cada transcripción se guarda en logs JSONL para trazabilidad y análisis posterior.
- Clasificador: interpreta la intención, el idioma, la ruta y el nivel de seguridad de cada solicitud.
- Gestión de sesiones: mantiene conversaciones activas, detecta continuaciones y gestiona expiración por inactividad.
- Orquestador: conversa con el modelo, procesa tool calls y coordina la ejecución de acciones.
- Herramientas: expone comandos locales y utilidades del sistema para agentes especializados.
- Telemetría: registra trazas con OpenTelemetry en consola y en disco.
- TTS: sintetiza voz con motores intercambiables.
- Proxy LLM: desacopla el consumo del modelo mediante una API compatible con OpenAI.
Flujo general
Usuario -> ingestión -> clasificación -> sesión -> orquestación -> herramientas/agente -> respuestaLa clave de esta estructura es que el clasificador no resuelve la tarea: solo decide. El resto del trabajo lo hace el orquestador con el contexto adecuado y el conjunto de herramientas correspondiente.
Del input a la respuesta
El recorrido de una solicitud dentro de ATLAS sigue una lógica bastante precisa.
1. Ingesta
La entrada llega por CLI o por el daemon local. En ambos casos, el texto se registra primero para conservar un historial mínimo de uso y facilitar la observabilidad.
2. Clasificación
El clasificador analiza el mensaje y devuelve una estructura con intención, ruta, seguridad, idioma, confianza y estado de sesión. Ese resultado permite tomar decisiones de manera consistente sin mezclar lógica de negocio con generación de texto libre.
3. Sesiones
Si el usuario continúa una conversación previa, ATLAS reutiliza la sesión activa. Si el tema es nuevo, crea una sesión nueva. Si es una interacción paralela, el sistema puede abrir un flujo adicional sin perder el contexto anterior.
4. Orquestación
El orquestador toma la sesión, construye el prompt del agente, añade la clasificación inicial y comienza el ciclo con herramientas. Cuando el modelo requiere ejecutar una acción, el sistema resuelve la tool call, inyecta el resultado de vuelta en la conversación y continúa hasta obtener una respuesta final.
5. Salida
La respuesta puede ir por terminal, notificación, portapapeles o voz. Esa flexibilidad hace que ATLAS funcione tanto como asistente de escritorio como base para automatización conversacional.
Un clasificador que enruta, no improvisa
Uno de los elementos más importantes del sistema es el clasificador. Su salida está estrictamente modelada, lo que evita respuestas ambiguas y facilita el control del flujo.
El clasificador determina cosas como:
session_action: si la solicitud abre, continúa o corre en paralelo.intent: qué tipo de tarea quiere el usuario.route: a qué agente debe ir.safety: si requiere confirmación.input.language: español, inglés o desconocido.
Esto permite que el sistema responda de forma distinta según el contexto, sin depender de reglas rígidas hardcodeadas para cada caso.
Agentes y especialización
ATLAS está pensado para crecer con agentes específicos. En el estado actual, ya existe un system_metrics_agent orientado a consultar información del sistema, con herramientas para CPU, memoria, procesos y datos del sistema operativo.
system_metrics_agent
Este agente está enfocado en consultas de diagnóstico y métricas del host. Su propósito es responder preguntas como el estado de CPU, RAM, procesos o información del sistema, con soporte para más de un idioma según el contexto del usuario.
Además del agente de métricas, la clasificación contempla rutas preparadas para otros perfiles, como:
launcher_agentbrowser_agentqa_agentsystem_agentwriter_agentdictation_agentfallback_agent
El objetivo es que cada uno tenga una responsabilidad clara y una superficie de herramientas limitada a lo necesario.
Tecnologías involucradas
ATLAS se apoya en un stack bastante pragmático:
- Python 3.11+ como lenguaje principal.
- FastAPI y Uvicorn para el proxy LLM.
- httpx para comunicación HTTP.
- Pydantic para modelado y validación.
- PyYAML para configuración declarativa.
- OpenTelemetry para trazabilidad.
- LiteLLM para abstraer proveedores de modelo.
- edge-tts y kokoro-onnx para síntesis de voz.
- soundfile y numpy para audio.
- vLLM como servidor compatible con APIs tipo OpenAI.
La arquitectura está diseñada para funcionar en entornos locales, pero sin cerrarse a una sola plataforma o proveedor. Esa flexibilidad es parte central del proyecto.
Observabilidad y trazabilidad
Una de las decisiones más útiles del diseño fue tratar la observabilidad como parte del producto, no como un agregado posterior.
ATLAS registra:
- Transcripciones en
jsonl. - Trazas estructuradas con OpenTelemetry.
- Eventos de clasificación.
- Ejecución de herramientas.
- Resultados de sesiones y respuestas.
Esto permite entender qué pasó en cada solicitud sin tener que adivinarlo a partir de logs sueltos o respuestas parciales.
Cierre
ATLAS es, en esencia, una base técnica para un asistente local-first que prioriza estructura, modularidad y control. Nació como un proyecto personal, pero está planteado con una mentalidad profesional: desacoplar componentes, mantener trazabilidad, evitar dependencias innecesarias y dejar espacio para que el sistema crezca con nuevos agentes y nuevos flujos.
Lo más interesante de este tipo de proyectos no es solo el resultado visible, sino la base que dejan lista para lo que viene después. En este caso, ATLAS no intenta ser una solución cerrada ni definitiva: busca ser un punto de partida sólido para experimentar, construir y extender. Y si en el camino también sirve como inspiración para que otras personas armen sus propios agentes o workflows, mejor todavía.
Más que una demo aislada, ATLAS busca ser una plataforma sobre la cual se puedan construir interacciones útiles, seguras y sostenibles en el tiempo.
Enlaces
- Repositorio del proyecto: Link al repositorio