Ruflo Analysis → Mejoras Aplicables

Comparativa: Nosotros vs Ruflo

Capacidad	Nuestro stack	Ruflo	Veredicto
Bots en producción	✔ 3 bots, usuarios reales	✘ 0 — es infra/tool	Nosotros
Routing por costo	✘ Todo Opus	✔ 3-tier WASM→Haiku→Opus	Adoptar
Coordinación inter-bot	✘ Silos aislados	✔ Swarm + message bus	No aplica
Memoria persistente	◐ Markdown (basic-memory)	✔ Vector HNSW + SQLite	Adoptar lite
Background learning	◐ Instincts (básico)	✔ SONA + 12 workers	Adoptar
Skills/Agent defs	✔ 24 skills funcionales	◐ 120+ markdown prompts	Nosotros
Task ownership	◐ Manual (Roberto)	✔ Claims protocol	No aplica
MCP tools	✔ Per-bot, scoped	✔ 314 centralizados	Nosotros
Consensus protocols	✘ No tiene	✔ Raft, BFT, Paxos, Gossip	Overkill
Domain plugins	✔ YouTube, business, LPDI	◐ Healthcare, finance (generic)	Nosotros

Arquitectura actual vs con mejoras

HOY — Todo Opus, silos

Miles (Slack) → Opus siempre

PMO (Slack) → Opus siempre

Alexa (TG) → Opus siempre

Sin feedback loop

Memory = archivos planos

→

DESPUÉS — Routing + Learning

Miles → Router → Haiku/Sonnet/Opus

PMO → Router → Haiku/Sonnet/Opus

Alexa → Router → Haiku/Sonnet/Opus

Weekly digest → auto-ajuste skills

Memory + embeddings semánticos

Conclusión rápida

Ruflo tiene 31K stars y 314 tools, pero cero bots en producción. Nosotros tenemos 3 bots sirviendo usuarios reales con workflows de negocio. De sus 15+ subsistemas, solo 3 ideas son aplicables a nuestro stack actual — el resto es over-engineering para un equipo de 3 bots aislados. Las 3 mejoras viables se enfocan en reducir costos (routing), aprender de errores (feedback loop), y mejorar búsqueda (embeddings lite).

Mejoras a adoptar — ordenadas por impacto/esfuerzo

Routing por costo de modelo

HIGH impact Talla S

▼

Problema

Hoy cada request de cada bot va a Opus (~$15/MTok input, ~$75/MTok output). Pero el 60-70% de las tareas son rutinarias: formatear mensajes Slack, lookups en Supabase, parsear JSON, generar respuestas FAQ. Estamos pagando precio premium por trabajo que Haiku hace igual de bien.

Qué toma de Ruflo

Su 3-tier routing: WASM (regex) → Haiku (routine) → Opus (complex). Nosotros no necesitamos el tier WASM, pero el concepto de clasificar y rutear sí.

Implementación

Un módulo model_router.py en ~/shared/ que cada bot importa
Clasifica por heurísticas simples: longitud del prompt, presencia de keywords (debug, architecture, design → Opus), tipo de handler
3 tiers: Haiku (formateo, lookups, FAQ) → Sonnet (generación, análisis) → Opus (arquitectura, debugging, decisiones)
Fallback a Opus si la clasificación falla o el response quality es bajo
Logging de modelo usado por request para tracking

Pseudo-implementación

# ~/shared/model_router.py
class ModelRouter:
    def classify(self, prompt, handler_type, context):
        # Tier 1: Haiku — simple, repetitivo
        if handler_type in ("format", "lookup", "parse"):
            return "claude-haiku-4-5-20251001"
        # Tier 2: Sonnet — generación moderada
        if handler_type in ("generate", "summarize", "analyze"):
            return "claude-sonnet-4-6"
        # Tier 3: Opus — decisiones, debugging, architecture
        return "claude-opus-4-6"
              

Archivos a tocar

~/shared/model_router.py — crear
~/shared/cost_aware_llm.py — integrar router
~/agents-claude/pool.py — usar router en AgentPool
~/agents-pmo/pool.py — ídem
~/agents-growth/pool.py — ídem

Ahorro estimado

30-50% en costos de API. Haiku es ~60x más barato que Opus en output. Si 60% de requests van a Haiku y 25% a Sonnet, el costo baja dramáticamente. Ver pestaña "Calculadora" para simular.

Instincts feedback loop semanal

MED impact Talla M

▼

Problema

Miles tiene un sistema de "instincts" que aprende post-respuesta, pero es reactivo e individual. No hay análisis agregado de qué skills fallan, qué patrones se repiten, ni cómo mejorar semana a semana. Los bots cometen los mismos errores periódicamente.

Qué toma de Ruflo

SONA (Self-Optimizing Neural Adaptation) — el concepto de background workers que analizan patrones y auto-ajustan. No necesitamos 9 algoritmos RL, pero sí el loop de feedback agregado.

Implementación

Cada bot loguea: skill usado, modelo, tokens, éxito/fallo, correcciones de Roberto
Cron semanal (domingo, junto con maintenance) que agrega los logs
Genera un weekly digest en playground con: top skills, failure rate, correcciones frecuentes
Auto-flag: skill con >3 fallos/semana se marca para review
Feed los insights de vuelta a basic-memory para que los bots mejoren

Pseudo-implementación

# ~/shared/feedback_tracker.py
class FeedbackTracker:
    def log_interaction(self, bot, skill, model, tokens, success, correction=None):
        # Append to ~/playgrounds/api/feedback-log.jsonl
        ...

# ~/bin/weekly-feedback-digest.py (cron domingo 7:30am)
def generate_digest():
    logs = load_week_logs()
    failures = [l for l in logs if not l["success"]]
    corrections = [l for l in logs if l["correction"]]
    # Flag skills with >3 failures
    # Generate HTML digest → playgrounds/feedback-digest.html
    # Update basic-memory with new learnings
              

Archivos a tocar

~/shared/feedback_tracker.py — crear
~/bin/weekly-feedback-digest.py — crear (cron)
~/agents-claude/handlers/*.py — integrar logging
~/agents-pmo/handlers/*.py — integrar logging
~/agents-growth/handlers/*.py — integrar logging

Valor

Los bots dejan de repetir errores. Roberto deja de corregir lo mismo dos veces. Los skills mejoran orgánicamente. El digest semanal da visibilidad de qué tan bien funcionan los bots sin tener que revisar logs manualmente.

Memory embeddings lite

MED impact Talla S

▼

Problema

basic-memory tiene ~50+ archivos markdown. El hook SessionStart inyecta contexto basado en cwd (hardcodeado). Cuando el contexto relevante no está en la carpeta del cwd, se pierde. La búsqueda es por nombre de archivo, no por contenido semántico.

Qué toma de Ruflo

Su AgentDB con HNSW vector search. No necesitamos SQLite + HNSW completo, pero sí embeddings sobre los markdowns para búsqueda semántica básica.

Implementación

Modelo all-MiniLM-L6-v2 via sentence-transformers (~50MB, corre en CPU)
Script que indexa todos los .md de basic-memory → genera embeddings → guarda en un .npy o .json
El hook SessionStart busca por similitud semántica al contexto de la conversación
Inyecta los top-3 docs más relevantes, no solo el que matchea por cwd
Re-indexa semanalmente (cron) o cuando un doc cambia

Pseudo-implementación

# ~/bin/index-basic-memory.py
from sentence_transformers import SentenceTransformer
model = SentenceTransformer("all-MiniLM-L6-v2")

docs = load_all_md("~/.basic-memory/convergence-hub/")
embeddings = model.encode([d.content for d in docs])
save_index(docs, embeddings, "~/.basic-memory/index.npz")

# En el hook SessionStart:
query_emb = model.encode([f"working in {cwd}"])
top3 = cosine_similarity_top_k(query_emb, index, k=3)
              

Trade-off

Agrega ~50MB de modelo + ~200ms al hook SessionStart. Si el hook actual funciona bien para el uso del día a día, esto puede esperar. Pero a medida que basic-memory crece, se vuelve más necesario.

Qué NO copiar de Ruflo — y por qué

Ruflo tiene 15+ subsistemas. La mayoría son over-engineering para nuestro caso de 3 bots aislados con scopes definidos.

Bus de comunicación inter-bot

Miles, PMO y Alexa están aislados por diseño con scope boundaries explícitos en código. PMO solo trabaja con Frank/LPDI. Miles solo con Roberto. Alexa solo growth. No hay caso de uso real para que se comuniquen.

Ruflo: Swarm message bus + pub/sub + queen coordinator

Claims / Task ownership protocol

Con 3 bots en gateways distintos (2 Slack, 1 Telegram) y scopes fijos, Roberto naturalmente sabe a quién hablarle. Un dispatcher automático agregaría complejidad sin valor — no hay ambigüedad sobre quién maneja qué.

Ruflo: Claims protocol con human-agent coordination

Consensus protocols (Raft, BFT, Paxos)

Diseñados para clusters de 50-300 nodos donde hay desacuerdo y particiones de red. Con 3 bots que nunca hablan entre sí, es como poner un semáforo en una calle sin tráfico.

Ruflo: 4 implementaciones completas de consenso distribuido

314 MCP tools centralizados

Nuestro approach per-bot con MCP scoped es más seguro y mantenible. PMO no debería poder acceder a tools de Miles. Un MCP centralizado rompe el aislamiento que es una feature, no un bug.

Ruflo: 314 tools en 31 módulos centralizados

Federation cross-swarm

No tenemos múltiples swarms. Tenemos 3 bots independientes. Federation resuelve un problema que no tenemos — ni tendremos a menos que escalemos a 10+ bots con overlapping scopes.

Ruflo: Federation hub (28KB) para coordinación distribuida

Principio aplicado

Ruflo construye para un futuro genérico con N agentes. Nosotros construimos para 3 bots específicos con problemas de negocio reales. La complejidad de Ruflo es su feature (developer tool que escala a cualquier caso). Nuestra simplicidad es la nuestra (bots que funcionan 24/7 sin fallar). Adoptar solo lo que reduce costos o mejora calidad sin agregar superficie de fallo.

Calculadora de ahorro: Routing por costo

Simula cuánto ahorrarías redirigiendo requests a modelos más baratos según complejidad.

Parámetros

Requests/día (total 3 bots) 150

Tokens promedio/request 2000

% requests → Haiku 60%

% requests → Sonnet 25%

% requests → Opus 15%

Resultado mensual

Costo actual (100% Opus)

$—

Costo con routing

$—

Ahorro —%

BREAKDOWN POR MODELO

Haiku (— req/día) $—

Sonnet (— req/día) $—

Opus (— req/día) $—

Precios: Opus $15/$75 MTok — Sonnet $3/$15 MTok — Haiku $0.80/$4 MTok (input/output, ratio 1:1 asumido)

Roadmap de implementación

3 mejoras, ejecutables secuencialmente. Sin dependencias entre sí — se pueden hacer en cualquier orden.

Semana 1 — Quick Win

01 · Routing por costo de modelo

Crear model_router.py en shared, integrar con cost_aware_llm.py, actualizar AgentPool de los 3 bots. Test A/B una semana comparando costos antes/después.

Talla S Sin dependencias ~2-3h implementación

Semana 2-3 — Foundation

02 · Instincts feedback loop

Crear feedback_tracker.py, instrumentar handlers de los 3 bots, cron semanal para digest. Primera iteración solo logging — el auto-ajuste viene después de 2-3 semanas de data.

Talla M Sin dependencias ~4-6h implementación 2-3 semanas de data antes de ajustar

Semana 4+ — Cuando basic-memory crezca

03 · Memory embeddings lite

Instalar sentence-transformers, indexar basic-memory, modificar hook SessionStart para búsqueda semántica. Puede esperar — el hook actual funciona bien con ~50 docs.

Talla S Sin dependencias ~2h implementación +50MB modelo en VPS

Esfuerzo total estimado: Talla M

Las 3 mejoras juntas son ~8-11h de implementación. El routing por costo es el quick win más claro: talla S, impacto inmediato en costos, cero riesgo. Recomendación: empezar por ahí, medir una semana, y luego decidir si vale la pena invertir en las otras dos.

Ruflo → Mejoras Aplicables

Comparativa: Nosotros vs Ruflo

Arquitectura actual vs con mejoras

HOY — Todo Opus, silos

DESPUÉS — Routing + Learning

Conclusión rápida

Mejoras a adoptar — ordenadas por impacto/esfuerzo

Qué NO copiar de Ruflo — y por qué

Bus de comunicación inter-bot

Claims / Task ownership protocol

Consensus protocols (Raft, BFT, Paxos)

314 MCP tools centralizados

Federation cross-swarm

Principio aplicado

Calculadora de ahorro: Routing por costo

Parámetros

Resultado mensual

Roadmap de implementación

01 · Routing por costo de modelo

02 · Instincts feedback loop

03 · Memory embeddings lite

Esfuerzo total estimado: Talla M