Una nota técnica sobre cómo adaptamos el patrón de Advisor de Claude Code en Kilo Code usando subagents read-only, benchmarks con GLM 5.2 Cloud y MiniMax M3, y una separación clara entre executor y advisor.
Una de las pruebas más útiles que hicimos con Kilo Code fue separar dos responsabilidades que muchas veces se mezclan demasiado: ejecutar y aconsejar.
La idea vino de mirar el patrón del Advisor Tool de Claude Code. No lo usamos directamente en esta máquina, ni Kilo lo soporta de forma nativa. Lo tomamos como referencia conceptual: un executor Claude puede apoyarse en un advisor server-side para revisar dirección y estrategia.
En Kilo lo emulamos con subagents read-only.
No todo trabajo necesita el mismo tipo de inteligencia.
Modificar archivos, producir un HTML, correr pasos o seguir instrucciones claras es trabajo de ejecución.
Detectar si el resultado va en la dirección correcta, si hay riesgo, si falta estructura o si conviene cambiar el enfoque es trabajo de advisor.
Si mezclás todo en un solo agente, pagás de más y además cuesta entender qué falló.
La primera configuración fue:
ollama/glm-5.2:cloudadvisor con minimax/MiniMax-M3Lo configuramos en ~/.config/kilo/config.json y agregamos una regla global en ~/.config/kilo/AGENTS.md: consultar al advisor casi siempre antes de writes no triviales.
La idea era que GLM hiciera el trabajo operativo y MiniMax actuara como capa de revisión estratégica.
Después dimos vuelta la arquitectura:
minimax/MiniMax-M3advisor-glm con ollama/glm-5.2:cloudEste setup era interesante porque iba contra la intuición inicial. En vez de poner a GLM como executor principal, lo dejamos como advisor. MiniMax quedó haciendo el trabajo pesado.
No queríamos medir solo “terminó o no terminó”.
Usamos benchmarks con screenshots de Playwright y QA visual con visión para mirar calidad real del output:
En esta segunda comparación ignoramos tokens. La pregunta era calidad + tiempo.
GLM_MAIN_M3_ADVISORollama/glm-5.2:cloudminimax/MiniMax-M3M3_MAIN_GLM_ADVISORminimax/MiniMax-M3ollama/glm-5.2:cloudEl ganador fue claro:
minimax/MiniMax-M3 como executor + ollama/glm-5.2:cloud como advisor.
La conclusión no fue “este modelo es mejor que este otro”.
La conclusión fue más útil:
El rol importa.
MiniMax M3 funcionó mejor como executor. Avanzó más rápido y produjo una salida más sólida.
GLM 5.2 Cloud funcionó mejor como advisor. Aportó dirección sin tocar archivos.
Separar esos roles hizo que el sistema fuera más fácil de operar.
El worker ejecuta.
El advisor corrige dirección.
El verifier mide.
El router decide cuándo escalar.
Copiar el patrón de Advisor de Claude no significó copiar una feature interna.
Significó adaptar una idea de arquitectura:
un agente trabaja, otro mira desde afuera.
Esa separación baja el costo de razonamiento innecesario, reduce desperdicio de contexto y mejora los modos de falla.
Si algo sale mal, podés distinguir mejor:
Eso es mucho más operable que un agente gigante haciendo todo.
Para mí, esta es la diferencia entre usar IA como demo y usar IA como infraestructura.
Una demo puede tener un modelo enorme resolviendo todo.
Un sistema real necesita roles, límites, validación y medición.
En nuestro caso, el mejor resultado no vino del setup obvio. Vino del reverse advisor:
MiniMax-M3 ejecutando.
GLM-5.2:cloud aconsejando.
Menos dogma, más benchmark.