RuFlo / Claude-Flow: cuando más no es mejor

Cada pocos meses sale un framework de agentes que parece redefinir el estado del arte. RuFlo — antes conocido como Claude-Flow — es uno de esos. Tiene 32 mil estrellas, un manifiesto técnico que no cabe en una sola lectura, y una ambición sincera de construir la orquestación de agentes más completa que existe sobre Claude. Lo evaluamos con calma, y la conclusión interna es matizada: es impresionante, y aun así no lo vamos a adoptar.

Este post es para colegas que están evaluando RuFlo sin querer instalarlo primero. No es una crítica destructiva. Es un intento honesto de explicar por qué algo que funciona para su autor y su comunidad puede no ser la herramienta correcta para un equipo que entrega software a clientes reales con plazos y presupuesto.

· ruvnet/ruflo · MIT · @ruvnet

Qué hace realmente

RuFlo es un orquestador de agentes para Claude con cuatro piezas centrales, y conviene nombrarlas sin envoltorio:

• Swarms multi-agente. Hasta 100+ agentes que se coordinan en seis topologías distintas (mesh, hierarchical, pipeline, ring, star, hybrid). En la práctica, una manera estructurada de que varios agentes dividan trabajo, se pasen contexto y consoliden resultados.
• 313 herramientas MCP. Model Context Protocol es el estándar que Anthropic impulsa para conectar modelos con herramientas externas. RuFlo trae trescientas trece de fábrica: desde acceso a shell y filesystem hasta helpers de swarm, memoria, búsqueda y telemetría.
• Agent Booster con WASM. Un componente nativo que corre transformaciones deterministas (formateos, refactors mecánicos, parsing) sin invocar al LLM. El claim es 352x más rápido para ese subconjunto de operaciones.
• RAG con RuVector. Búsqueda vectorial implementada directamente en PostgreSQL vía 77+ funciones SQL. No es un vector DB aparte: es el propio Postgres haciendo retrieval semántico.

Cada pieza, aislada, es defendible. El debate empieza cuando se combinan.

Cómo funciona por dentro

El workflow típico: levantas un swarm, eliges topología, asignas un objetivo, y los agentes se reparten subtareas mientras comparten memoria persistente. Las 313 herramientas MCP están disponibles para cualquiera de ellos. Agent Booster intercepta operaciones mecánicas para no gastar tokens. RuVector maneja el retrieval cuando el contexto no cabe.

Sobre el papel es elegante. En la práctica requiere que entiendas cuándo una topología mesh es mejor que hierarchical, qué subconjunto de las 313 tools necesita cada agente, y cómo el sistema decide cuándo delegar en WASM vs en el modelo. Ese conocimiento no es opcional: configurar mal cualquiera de esas decisiones degrada el rendimiento o dispara el costo.

El número 313 no es un ataque. Es un dato con consecuencias. Cada herramienta adicional es superficie de configuración, vector de fallo y línea extra de documentación. Más no es gratis.

Pros

Treinta y dos mil estrellas no se consiguen por marketing solamente. Hay cosas que RuFlo hace bien:

• Ambición real. Es de los pocos proyectos que intenta cerrar todo el loop — orquestación, memoria, retrieval, aceleración nativa — en un solo stack coherente.
• RuVector es técnicamente sólido. Hacer vector search dentro de PostgreSQL con funciones SQL bien pensadas evita sumar un Pinecone o un Weaviate al stack. Si alguien lo extrajera como librería independiente, la adoptaríamos mañana.
• Agent Booster tiene sentido. La idea de no gastar tokens en cosas que un parser determinista resuelve es correcta. Muchos frameworks ignoran esta optimización.
• Comunidad activa. Releases frecuentes, issues con movimiento, una base de usuarios dispuesta a experimentar. Eso importa.
• MIT. Sin trampas de licencia, sin gate empresarial. El código está ahí.

Contras

Aquí es donde nuestra recomendación interna se enfría:

• Bus factor de 1. Un único mantenedor — ruvnet — sostiene el proyecto. El autor es prolífico y capaz, pero un proyecto de esta superficie técnica con un solo owner es una dependencia que no queremos firmar por un cliente. Si mañana desaparece, nos quedamos con 313 tools que hay que mantener nosotros.
• Complejidad de adopción. El README supera los 290 mil caracteres. No es negligencia — es la consecuencia natural de tantas piezas. Pero significa que onboardear a alguien nuevo cuesta días, no horas.
• 313 tools es demasiado para la mayoría. Un equipo de cinco personas no va a usar ni el 10% de ese catálogo. Lo que sobra no desaparece: sigue en la superficie de ataque, sigue en los bundles, sigue en las decisiones del agente.
• Claims difíciles de verificar. 352x más rápido, 16,400 QPS, enterprise-grade. Los números pueden ser reales bajo ciertas condiciones, pero no vienen con el harness para reproducirlos. En nuestro criterio, una claim sin benchmark reproducible es una hipótesis.
• 408 issues abiertos, 71 PRs pendientes. Es lo que pasa cuando la superficie crece más rápido que la capacidad de un solo mantenedor.
• Node.js-céntrico. Añade una dependencia de runtime que no todos los equipos quieren cargar.

Cuándo sí, cuándo no

Quizá sí: si eres un laboratorio de IA con 15-20 desarrolladores cuyo trabajo es explorar el límite de lo que los agentes pueden hacer. Si tu día a día es experimentar con topologías de swarm, si tienes tiempo para leer 290 mil caracteres de documentación, y si el riesgo de depender de un solo mantenedor es aceptable porque si algo falla pueden fork y mantener. RuFlo es un playground excelente.

Probablemente no: si eres un equipo pequeño entregando software a cliente. Si tu métrica es cuántas features llegaron a producción este mes, no cuántos agentes orquestaste en paralelo. Si tu cliente te va a pedir mantenimiento por tres años. Si el costo de una dependencia que se vuelve abandonware supera el beneficio marginal de tener seis topologías disponibles cuando solo usas una.

En nuestro caso concreto — equipos de 3 a 7 personas, proyectos con SLA, clientes que no pagan para experimentar — la respuesta honesta es que no. No porque RuFlo sea malo, sino porque está optimizado para otro perfil de usuario.

Veredicto

RuFlo es un proyecto admirable técnicamente y arriesgado operativamente. El autor está empujando el estado del arte, y eso tiene valor incluso si no adoptamos el resultado. La innovación en RuVector, el razonamiento detrás de Agent Booster, y la sistematización de topologías de swarm son contribuciones reales al ecosistema.

Pero adoptar un framework es un matrimonio con su superficie. Y esta superficie es demasiado grande, demasiado concentrada en un solo mantenedor, y demasiado optimizada para exploración, no para entrega. Nuestra recomendación interna es no meterlo en proyectos de cliente. En un playground interno, con tiempo y curiosidad, tiene sentido. Para el resto, preferimos stacks más pequeños, más mantenidos, y con menos herramientas en el menú.

La pregunta no es si RuFlo funciona. Es si el costo total — onboarding, mantenimiento, bus factor, superficie — se justifica contra lo que realmente vamos a usar. Para nosotros, hoy, no. Si el proyecto gana más mantenedores y reduce su superficie por defecto, lo reevaluaremos.

TL;DR — RuFlo es impresionante, un solo mantenedor, 313 herramientas y una curva que no cabe en una tarde; técnicamente admirable, operativamente demasiado caro para equipos que entregan a cliente.