Orión: Una Filosofía de Tier-Routing para Orquestación Personal de IA
Este no es un artículo de "mi proyecto le gana a productos serios". Es un caso de estudio sobre una filosofía concreta — router barato, workers contextualizados, memoria duradera, nada bloqueante — comparada honestamente con dos proyectos maduros que cubren terreno solapado: Hermes de Nous Research y OpenClaw.
En las últimas semanas instalé Hermes, el agente open-source de Nous Research, y probé OpenClaw, un ecosistema MIT con tracción significativa en GitHub y enfoque en agentes personales 24/7 multi-canal. Ambos cubren parte del problema que ya tenía resuelto en casa con Orión, mi orquestador personal. Quería entender qué hacían mejor que yo, qué hacían distinto, y qué partes de mi diseño se sostenían bajo escrutinio.
Conclusión corta: Hermes es técnicamente impresionante en paralelismo y diversidad de sandbox. OpenClaw es brutal en cobertura de canales messaging y madurez de ecosistema (Foundation, marketplace de skills, companion apps). El diferencial real de Orión no es el feature-set bruto — es una filosofía concreta de routing por coste que ningún producto generalista implementa por defecto. Este artículo explica esa filosofía sin inflar la tabla comparativa.
El problema central: agentes mono-tier
La mayoría de orquestadores de agentes — Hermes y OpenClaw incluidos en su configuración por defecto — asumen que un único modelo gestiona todas las peticiones. OpenClaw soporta multi-provider con failover automático en rate-limit, pero la selección sigue siendo manual. Hermes deja configurar el modelo. Ninguno implementa tier-routing automático por coste.
Eso es caro por diseño. Una pregunta de enrutamiento cuesta lo mismo que una de razonamiento profundo. Un saludo cuesta lo mismo que un plan de migración. Y como todo pasa por el mismo canal, la latencia se acumula.
Los agentes mono-tier son tractores con una sola marcha. Funcionan, pero siempre pagas por la máxima potencia aunque vayas a paso de peatón.
La arquitectura de 3 niveles de Orión
Orión funciona con tres niveles de modelo, cada uno con un mandato específico:
4 keys round-robin
ack pregrabados + ambient + queue
Telegram listener (opt)
queue serial · cwd aislado
Bash/Read/Edit/Glob
planificación · arquitectura
(Anthropic 429 / quota)
+ gpt-image-2
markdown frontmatter
SQLite jobs
e5-small 384d
fusión RRF k=60
resume tras restart
/metrics /cost /errors
last_run · run_count
cloud free
no solapes
text + voz canal
imagen / pdf / código
Nivel 1 — Haiku: el router front-line
Cada mensaje llega aquí primero. Haiku es rápido (respuesta sub-segundo para consultas simples) y cuesta una fracción de Sonnet u Opus. El trabajo del router es un árbol de decisión, no razonamiento pesado:
- ¿Puedo responder esto directamente? (saludos, consultas factuales, comprobaciones de estado) → respondo inline.
- ¿Requiere acceso a ficheros, ejecución de código o trabajo específico de proyecto? → delego a un worker Sonnet, devuelvo confirmación inmediata.
- ¿Es arquitectónico, complejo o marcado explícitamente como "piensa a fondo"? → escalo a Opus, devuelvo confirmación, notifico cuando termina.
La clave: el router nunca bloquea. Si delega, el usuario recibe confirmación en milisegundos. El trabajo pesado ocurre en async.
Nivel 2 — Sonnet: workers por proyecto
Cada proyecto tiene su propia sesión worker Sonnet. Los workers son persistentes: una pregunta de seguimiento en el mismo proyecto reanuda la sesión existente en vez de empezar en frío. Pueden leer ficheros, ejecutar comandos shell, escribir código, correr linters, revisar logs — cualquier cosa acotada a su proyecto.
Múltiples workers corren en paralelo. Si necesitas trabajo en tres proyectos simultáneamente, tres sesiones Sonnet corren concurrentemente mientras el router Haiku queda libre para nuevos mensajes.
Nivel 3 — Opus: escalado para profundidad
Las sesiones Opus son ad-hoc y caras por diseño. Reservadas para decisiones que justifican el coste: arquitectura de sistemas, planificación de migraciones, debugging complejo, análisis de trade-offs técnicos. Opus se invoca en async: los resultados llegan como notificación, no como espera bloqueante.
Capacidades clave
Memoria RAG Persistente
Cada hecho relevante se almacena en una base de datos vectorial Qdrant. Preferencias, detalles de infraestructura, credenciales, decisiones pasadas — recuperadas automáticamente al inicio de conversación mediante similitud semántica.
Delegación Asíncrona
Los workers corren en background. El router confirma inmediatamente y sigue procesando nuevos mensajes. Una notificación push llega cuando el worker termina — sin polling, sin bloqueos.
Enrutamiento por Intención
El router decide el nivel de ejecución por intención, no por keywords rígidos. Las preguntas conceptuales se quedan locales. Las operaciones de ficheros y shell se delegan al worker del proyecto correcto. El análisis profundo se escala a Opus.
Coste Optimizado por Tier
Haiku gestiona la mayoría de interacciones. Sonnet corre solo cuando hay trabajo de proyecto. Opus se activa raramente, bajo demanda. Cada nivel paga solo por lo que realmente hace.
Aislamiento Multi-Proyecto
Un router, workers ilimitados. El mismo agente front-line gestiona trabajo en todos los proyectos — infraestructura de servidor, repositorios de código, documentación, pipelines de datos — sin contaminación de contexto entre ellos.
Notificaciones Push
Los eventos de finalización asíncrona van directamente a Discord (texto + voz en canal). El router decide si un resultado justifica notificación — las completaciones triviales se descartan silenciosamente, las importantes llegan al móvil.
✅ Canal de voz Discord duplex
Bridge Node.js (py-cord no soporta DAVE de Discord) con auto-join al canal del usuario, STT vía Groq cloud (whisper-large-v3-turbo, 4 keys en pool con round-robin), TTS Edge Neural (es-ES Alvaro), ack pregrabado contextual (delegando a Sonnet / escalando a Opus), ambient pad mientras Haiku procesa, cola de audio FIFO sin solapes. End-to-end voice round-trip ~3-8s.
✅ Generación de imágenes
Tool generate_image(prompt, size) conectado a gpt-image-2 vía AI Fabric (LiteLLM on-premise). PNG ~2MB se postea como adjunto Discord directamente. 60-180s latencia.
✅ Memoria híbrida vector+lexical
Qdrant para semántica + SQLite FTS5 para coincidencia exacta de tokens (puertos, IDs, comandos). Fusión RRF (k=60) combina rankings. Recupera "puerto 8765" exacto incluso si la similitud semántica es baja.
✅ Skills (atajos pregrabados)
Catálogo markdown en ~/.claude-orchestrator/skills/ con frontmatter YAML. Comandos shell parametrizados que ejecutan sin gastar Sonnet (ej. claude-quota, disk-usage, list-services). Tools find_skill + invoke_skill. Skill típica: <1s vs 5-30s de un worker Sonnet.
✅ Scheduler cron persistente
Tool schedule_recurring(prompt, cron_expr) registra job en SQLite + APScheduler. Dispara prompts a horas programadas, ejecuta como turno autónomo de Orion (o delega a project worker), notifica resultado vía notify_user. Sustituye workflows n8n para automatizaciones simples.
✅ Failover Anthropic → AI Fabric
Cuando Anthropic devuelve 429/5xx/quota, retry exponencial 3 veces. Si persiste, fallback automático a Claude vía LiteLLM AI Fabric on-premise (modo degradado texto-only, sin tools). Métrica de uso fallback expuesta.
✅ Métricas Discord-first
SQLite event log captura cada turn (modelo, duración, tokens, errores). Comandos Discord /metrics, /cost, /errors, /queue agregan en tiempo real. P50/P95 latencia por tier. Coste USD/día desglosado por modelo.
✅ Compartir archivos
Tool share_file(path, caption) sube cualquier fichero a Discord (≤24MB). Preview inline para imágenes/audio/PDF, descarga para otros.
Comparación honesta con Hermes y OpenClaw
Antes de la tabla, una caracterización justa de los dos proyectos. Leí su documentación pública y los probé brevemente; lo que sigue es lo que realmente hacen, no la versión de paja para hinchar mi proyecto.
Hermes — Nous Research
Agente único con subagentes aislados paralelos. Cada subagente tiene su propia conversación, terminal y scripts RPC Python.
- Memoria persistente local (
~/.hermes/) + FTS5 search + perfiles Honcho - Notificaciones nativas: Telegram, Discord, Slack, WhatsApp, Signal, Email, CLI
- Cron natural-language built-in ("every Monday 9am check X")
- Hibernación serverless: targets Daytona, Vercel (separados de los sandboxes de ejecución)
- 5 sandbox backends de ejecución: local, Docker, SSH, Singularity, Modal
- 200+ modelos vía OpenRouter, Nous Portal, NVIDIA NIM, vLLM local
- Auto-skills generadas: el agente aprende y guarda habilidades reutilizables
OpenClaw
Gateway local Node.js + companion app macOS/iOS. Multi-agent routing por canal/workspace con sesiones aisladas. Governance de non-profit Foundation, ecosistema activo con plugins comerciales.
- 20+ canales messaging nativos: WhatsApp, Telegram, Slack, Discord, Signal, iMessage, Teams, Matrix, Feishu, LINE, WeChat, QQ, Gmail, Twitch...
- Voz nativa vía ElevenLabs + companion macOS/iOS con push-to-talk overlay
- Memoria persistente: SQLite local + vector embeddings para semantic search
- 3 sandbox backends: host (sesión main), Docker (default no-main), SSH, OpenShell
- Multi-LLM con failover: Claude, OpenAI, DeepSeek, MiniMax, locales — selección manual + fallback en rate-limit
- ClawHub marketplace: registry centralizada de skills community-built (markdown
SKILL.mden~/.openclaw/workspace/skills/) - Ecosistema masivo: Claworc (orchestrator multi-instance), Mission Control (dashboard), CloudBot.ai (voice plugin), NVIDIA NemoClaw stack
Nota: OpenClaw ejecuta una task por sesión a la vez (serializada para evitar race conditions). El paralelismo viene de multiplicar instancias por canal/workspace, no de subagentes concurrentes dentro de una sesión como Hermes. Es un trade-off de diseño: simplicidad y previsibilidad sobre paralelismo bruto.
| Capacidad | Orión | Hermes | OpenClaw |
|---|---|---|---|
| Tier-routing por coste | Explícito (Haiku → Sonnet → Opus) | Configurable manual | Manual + failover automático |
| Async delegation | Nativo no-bloqueante | Cron NL + hibernación serverless | Persistente 24/7, 1 task/sesión serializada |
| Memoria duradera | RAG Qdrant cross-sesión | FTS5 local + perfiles Honcho | SQLite + vector embeddings local |
| Subagentes paralelos | Workers Sonnet 1:1 por proyecto | Subagentes RPC concurrentes | 1 task/sesión serializada |
| Sandbox backends | Solo local | 5 (local/Docker/SSH/Singularity/Modal) | 3 (host/Docker/SSH/OpenShell) |
| Canales messaging | Discord (bridge Node) + Telegram opcional | 6 nativos (TG/Discord/Slack/WA/Signal/Email) | 20+ nativos (incl. iMessage, Teams, Matrix, LINE, WeChat) |
| Voz nativa | Canal voz Discord duplex (STT Groq + TTS Edge + ambient + queue) | No nativo | ElevenLabs + companion macOS/iOS con push-to-talk |
| Cron natural-language | Sí (APScheduler + tool MCP) | Sí, built-in | Tool cron, NL no confirmado |
| Skills reutilizables | Catálogo markdown manual (v1) — auto-gen en roadmap | Auto-generadas por el agente | Manuales + ClawHub marketplace |
| Generación imágenes | gpt-image-2 (AI Fabric) → Discord directo | N/A | Vía plugin externo |
| Flexibilidad de modelo | Anthropic + failover a AI Fabric LiteLLM | 200+ modelos cualquier provider | Multi-provider + failover (Claude/GPT/DeepSeek/locales) |
| Madurez / ecosistema | Personal, no público | Research project, comunidad activa | 247K stars, Foundation, ecosistema con plugins comerciales |
| Licencia | Personal / no liberado | MIT | MIT (Foundation governance) |
| Coste mensual | Pago por uso, optimizado por tier | Self-hosted (infra + API only) | Self-hosted gratis (BYOK) o SaaS terceros (Clowdbot, etc.) |
Lectura honesta de la tabla:
- Orión gana en un solo eje claro: tier-routing automático por coste. Los otros dos lo soportan manualmente o no del todo.
- Hermes gana en paralelismo de subagentes + diversidad de sandbox (5 backends de ejecución + 2 targets hibernación serverless) + 200+ modelos + auto-skills generadas.
- OpenClaw gana en cobertura de canales (20+ messengers nativos) + voz + companion apps + ecosistema y madurez (Foundation, marketplace, miles de contribuidores).
- Orión pierde en breadth: solo Telegram, solo local, sin marketplace de skills, sin Foundation. Eso es deliberado — es un proyecto personal, no un producto.
Ejemplos de uso real
Ejemplo 1 — Respuesta directa (Haiku inline)
Usuario: "¿Qué proyectos están corriendo ahora mismo?"
Haiku llama list_projects(), formatea respuesta, responde en menos de un segundo. Sin worker, sin delegación. Coste: una inferencia Haiku.
Ejemplo 2 — Delegación async (worker Sonnet)
Usuario: "En el proyecto server, reinicia el stack de monitorización y revisa errores en las últimas 100 líneas de log."
Haiku identifica proyecto, llama delegate_to_project("server", prompt), devuelve confirmación inmediata. Worker Sonnet ejecuta shell, analiza logs, push notification Telegram con hallazgos. Usuario recibe ack en milisegundos y resultado un minuto después — sin esperar en terminal.
# Decisión del router (pseudocódigo)
intent = classify(user_message)
# → "project_action" en project="server"
delegate_to_project(
project="server",
prompt="Reinicia el stack de monitorización. Revisa últimas 100 líneas de log. Informa."
)
# retorna inmediatamente
ack_user("En ello — te aviso cuando termine.")
Ejemplo 3 — Escalado a Opus (arquitectura profunda)
Usuario: "Piensa a fondo en migrar nuestros workflows de n8n a una arquitectura de agentes nativa. Considera costes, mantenimiento y rollback."
"Piensa a fondo" + naturaleza estratégica dispara escalado. Haiku llama escalate_to_opus(prompt), devuelve confirmación, sigue gestionando otros mensajes. Cuando Opus termina (5–15 min), notify_user empuja resumen con análisis completo disponible bajo demanda.
Ejemplo 4 — Recuperación de memoria cross-sesión
Usuario: "¿Qué decidimos sobre el esquema de base de datos la semana pasada?"
Antes de responder, el sistema inyecta top-K memorias híbridas (Qdrant + FTS5 fusionados via RRF). La búsqueda exacta de "esquema de base de datos" + similitud semántica encuentra la decisión incluso si se guardó con palabras distintas: remember("DB schema: UUID como primary keys en vez de auto-increment por portabilidad cross-servicio", tags=["db", "schema"]).
Ejemplo 5 — Skill instantánea (sin Sonnet)
Usuario: "¿Cuánto me queda de cuota Anthropic?"
Haiku busca skill catalog → encuentra claude-quota → invoca invoke_skill("claude-quota", {}) → ejecuta script Python contra API Anthropic con OAuth Bearer → devuelve JSON con utilización 5h/7d. Latencia <1s. Cero coste Sonnet/Opus.
Ejemplo 6 — Generación de imagen on-demand
Usuario en canal de voz Discord: "Orion, genérame una imagen de un gato astronauta en Marte"
Haiku decide → generate_image("un gato astronauta en Marte", "1024x1024") → POST a AI Fabric gpt-image-2 → PNG 2MB → bridge sube como adjunto Discord directo. Latencia 60-180s, durante los cuales suena el ambient pad. Caption inline con el prompt.
Ejemplo 7 — Programación recurrente
Usuario: "Cada lunes a las 9 dime el estado de los servicios del server"
Haiku traduce a cron → schedule_recurring("invoca skill list-services y reporta", "0 9 * * 1", label="lunes-servicios"). APScheduler persiste el job. Cada lunes 9:00 dispara, ejecuta como turno autónomo de Orion, llama invoke_skill("list-services"), narra el resultado con notify_user directo a Discord.
Ejemplo 8 — Failover transparente
Anthropic devuelve 429 (límite Max alcanzado). Master Haiku reintenta 3 veces con backoff exponencial. Si persiste, fallback automático a AI Fabric LiteLLM (Claude mismo modelo, otro provider). Modo degradado: solo texto, sin tools. El user nota latencia ligeramente mayor pero NO interrumpción. Métrica orchestrator_turn_fallback registra el evento — visible vía /errors.
La aritmética de costes
Un día típico de interacciones, modelado frente a un setup OpenClaw self-hosted con BYOK Claude Sonnet (sin tier-routing):
Precios oficiales Anthropic mayo 2026 ($/M tokens):
| Modelo | Input | Output |
|---|---|---|
| Haiku 4.5 | $1.00 | $5.00 |
| Sonnet 4.6 | $3.00 | $15.00 |
| Opus 4.7 | $5.00 | $25.00 |
| gpt-image-2 (AI Fabric) | ~$0.07 / imagen 1024² | |
Nota: la generación 4.5/4.6/4.7 redujo Opus de $15/$75 (era Opus 4/4.1) a $5/$25 — un ajuste de un 67% que cambia la economía de los modelos premium.
Un día típico modelado (~200 turnos):
| Tipo de interacción | Coste Orión | Mono-tier Sonnet (sin routing) |
|---|---|---|
| ~150 consultas Haiku (routing, status, chitchat) | ~$0.13 | ~$1.50 |
| ~40 tareas worker Sonnet | ~$0.30 | ~$0.30 |
| 2 escalados Opus (planificación) | ~$0.27 | ~$0.20 (peor calidad) |
| Edge TTS + Groq STT (canal voz) | $0 (free tier) | $0 |
| Image gen (2 imágenes / día) | ~$0.14 | N/A |
| Total / día | ~$0.84 | ~$2.00 (peor en deep work, mismo TTS/STT) |
Sutileza: la mayor parte del ahorro viene de delegar el ~75% de turnos a Haiku que cuesta una fracción de Sonnet. Con los precios actuales de Opus (más asequible que la generación anterior), escalar a Opus para planificación profunda apenas mueve la aguja del coste. La ventaja Orión no es el precio bruto — es la automatización del tiering: lo hace por defecto, sin que pienses en ello. Y para análisis profundo, Opus aporta calidad que Sonnet no iguala — ahora a un coste muy razonable.
No pagas por capacidad en espera. Pagas por trabajo real hecho en el nivel que ese trabajo requiere.
Cómo Orión puede mejorar — lecciones de la competencia
Evaluar Hermes y OpenClaw en serio reveló áreas donde Orión queda corto y que entran en mi roadmap próximo. No las llamo "ventajas que Orión ya tiene". Las llamo "deuda técnica que reconozco".
Auto-skills generadas (Hermes)
Cuando un worker Sonnet resuelve una tarea repetitiva (p.ej. "revisa logs de nginx por errores 5xx"), guardarla como skill ejecutable parametrizada. Próxima ejecución: Haiku invoca skill directa, sin gastar Sonnet en re-razonar.
Hibernación serverless (Hermes)
Workers Sonnet idle → snapshot a disco, descomprimir on-demand. Hermes lo hace vía Daytona/Modal. Reduce coste de cache warm idle.
Multi-sandbox backends (Hermes + OpenClaw)
Hoy Orión corre workers solo en local. Añadir Docker (aislamiento), SSH (workers remotos), Modal (escalado on-demand). Misma API delegate_to_project, distinto destino físico.
Cron natural-language (Hermes)
"Cada lunes a las 9 revisa logs servidor" → schedule nativo sin pasar por n8n. Integrar parser NL → registra worker con trigger cron, ejecuta y notifica.
Multi-canal messaging (OpenClaw)
Orión hoy solo Telegram. OpenClaw cubre 20+ canales nativamente. Añadir adapter genérico de salida con plugins por canal (WhatsApp, Discord, Signal). Misma notify_user(msg) API, ruteo según preferencia del usuario.
Marketplace de skills (OpenClaw ClawHub)
Si llego a liberar Orión, copiar el modelo ClawHub: registry pública de skills markdown estandarizadas (SKILL.md + manifest). Comunidad aporta skills, Haiku descubre por similitud semántica.
Multi-provider failover (OpenClaw)
Cuando Anthropic devuelve rate-limit en Haiku/Sonnet, fallback automático a otro provider equivalente (GPT-4o-mini para Haiku, GPT-4o para Sonnet). Mantiene tier-routing pero gana resiliencia.
Companion app push-to-talk (OpenClaw)
OpenClaw tiene companion macOS/iOS con overlay push-to-talk siempre disponible. Orión hoy depende de Telegram. Considerar app nativa minimal que hable directo con Haiku via gRPC.
Memoria híbrida vector + lexical
RAG semántico (Qdrant) bueno para conceptos, malo para queries exactas. Añadir índice FTS5 paralelo (estilo Hermes + OpenClaw SQLite). Búsqueda híbrida lexical + semantic, fusionar resultados.
Roadmap Orión — estado actualizado
Update mayo 2026: la mayoría del roadmap Q2-Q3 cayó en un sprint intensivo. Lo que sigue refleja el estado real.
Memoria híbrida vector+lexical
Qdrant para semantic + SQLite FTS5 para coincidencia exacta. Fusión RRF (k=60). Recupera tokens específicos (puertos, IDs) que la similitud semántica perdía.
Failover Anthropic → AI Fabric on-premise
Retry exponencial 3 intentos en master Haiku. Si persiste error retryable (429/quota/5xx), fallback a Claude vía LiteLLM AI Fabric on-premise (modo texto-only, sin MCP tools). Mantenemos tiers Anthropic puros para flujo normal.
Cron natural-language nativo
APScheduler + tools MCP schedule_recurring, list_schedules, cancel_schedule. Haiku traduce "cada lunes 9am" a cron expression. Jobs persisten en SQLite y reaparecen tras restart.
Adapter Discord nativo + canal voz duplex
Bridge Node.js dedicado (necesario porque py-cord aún no soporta DAVE de Discord). Auto-join al canal de voz del usuario, STT Groq (4 keys pool), TTS Edge Neural, acks pregrabados contextuales, ambient pad mientras procesa, cola FIFO de audio. Telegram queda opcional.
Skills v1 (manual-curated)
Catálogo markdown con frontmatter YAML en ~/.claude-orchestrator/skills/. Tools MCP find_skill, list_skills, invoke_skill. Auto-extraction (Hermes-style) sigue en roadmap.
Métricas + observability Discord-first
SQLite event log con hooks en cada turn. Comandos Discord /metrics, /cost, /errors, /queue. P50/P95 latencia + coste USD/día desglosado por modelo.
Generación de imágenes
Tool generate_image(prompt, size) → gpt-image-2 vía AI Fabric LiteLLM on-premise → adjunto Discord directo.
Auto-skills generadas
Detector que analiza turnos worker recientes en RAG, identifica patrones repetitivos exitosos, propone guardar como skill markdown. Confirmación user antes de activar.
Multi-sandbox backends
Refactor de delegate_to_project para soportar backends pluggable. Implementaciones: local (actual), Docker (aislamiento), SSH (workers remotos). Cada proyecto declara su backend preferido en orion.yaml.
Hibernación de workers idle
Workers Sonnet sin actividad >10 min → snapshot a disco. Descompresión on-demand sub-2s cuando llega nuevo mensaje al proyecto. Reduce coste cache warm de workers raramente usados.
Tier 0 local — modelo on-prem para queries triviales
Probar Llama 3.3 8B o Qwen 2.5 vía vLLM como filtro pre-Haiku para queries ultra-simples (saludos, dates, list_projects). Coste marginal cero. Reservar Haiku para enrutamiento real que requiera contexto.
Open-source de Orión core (evaluando)
Una vez estabilizado, considerar liberar el core como librería pip + adapter MIT. La parte personalizable (memoria, voz, AI Fabric integration) queda como capa de usuario.
Qué no reemplaza Orión
OpenClaw es claramente la mejor opción si tu prioridad es cobertura de canales (quieres hablar con tu agente desde WhatsApp, iMessage, Signal y Telegram según el momento), ecosistema maduro con plugins comerciales (CloudBot.ai voice, Claworc multi-instance), companion apps nativas macOS/iOS, o si necesitas un proyecto MIT con Foundation governance para uso profesional sostenible.
Hermes es excelente si necesitas paralelismo real de subagentes con sandboxes diversos (Docker/SSH/Modal/Daytona), 200+ modelos multi-proveedor en el mismo pipeline, auto-skills generadas por el agente, o hibernación serverless out-of-the-box.
Orión encaja en un perfil distinto: operador técnico que ya gestiona su propia infra, quiere control total sobre coste por interacción (de ahí el tier-routing), prefiere stack Anthropic puro con failover opcional, y está dispuesto a invertir días de setup para tener un orquestador moldeado a su flujo personal, no a un caso de uso genérico. Si esos perfiles no encajan, OpenClaw o Hermes son mejores opciones, y eso está bien.
Reflexión final
Este artículo no pretende sustituir ni mejorar a Hermes, ni a OpenClaw, ni a ningún producto serio del ecosistema. Hermes es técnicamente excelente. OpenClaw es un referente de madurez. Cualquiera de los dos puede ser la mejor elección para mucha gente, y no aspiro a competir con ellos en breadth, ecosistema, o tracción comunitaria.
Lo que sí pretende este artículo es defender una idea sencilla: cualquiera con interés y tiempo puede construirse su propio agente personal. No hace falta esperar a que un producto generalista cubra exactamente tu caso de uso. No hace falta delegar todas tus decisiones a código ajeno cuya implementación no entiendes. Puedes elegir tu stack, tus modelos, tus canales, tu memoria, tu tono — y modificarlo cuando algo te chirríe.
La filosofía de routing por coste es un ejemplo concreto. Tener tu propia memoria RAG con la semántica que tú quieras priorizar es otro. Decidir qué canal de mensajería usas, qué voz responde, qué ack pregrabado oyes mientras espera el modelo — son decenas de detalles pequeños que ningún producto generalista va a clavar a tu gusto. Construirlo tú significa que cada decisión es consciente, y cuando algo se rompe sabes exactamente dónde mirar.
Hay un coste: tiempo de setup, mantenimiento, deuda técnica acumulada. Yo asumo ese coste porque me interesa entender qué hay debajo de cada capa de mi software. No es para todo el mundo, y está bien. Pero si alguna vez te has preguntado qué exactamente hace ese SaaS cuando aprietas un botón, esa curiosidad ya es suficiente para empezar a construir.
Construir tu propio orquestador no es competir con productos serios. Es ejercer control consciente sobre la herramienta que más usas cada día — y descubrir, de paso, cuánto puedes hacer tú mismo.
Volver a artículos