meta-consilium-loop
Meta-Consilium Loop
Summary: Propuesta de diseño que aplica el patrón del karpathy-loop al diseño autónomo de equipos de Consilium — team-spec como superficie editable, eval harness determinista como métrica, ratchet loop como motor de mejora continua sin intervención humana.
Sources: Meta-Consilium loop para mejorar equipos sin interaccion humana.md
Last updated: 2026-04-18
Nota: Este es un documento de diseño interno, no investigación empírica verificada. Las fuentes académicas citadas (Karpathy, Reflexion, ToT, GoT) están verificadas en otras páginas. Las conclusiones operativas son hipótesis de diseño pendientes de validación experimental.
Hipótesis central
El karpathy-loop demostró que un agente puede mejorar código de entrenamiento autónomamente con tres condiciones: superficie editable única, métrica clara, presupuesto de tiempo fijo. La misma lógica aplica al diseño de equipos de consilium-arquitectura: si el team-spec es la superficie editable y el eval harness es la métrica, el loop puede optimizar equipos sin humano en el ciclo.
Los 7 componentes operativos
1. Superficie editable única por equipo (team-spec)
Un archivo por equipo — team-spec.md o team-config.yaml — que contiene:
- Roles activos y orden de participación
- Reglas de turnos
- Criterios de cierre del Conductor
- Prompt de cada rol
- Política de memoria y herramientas
Todo cambio versionado. Análogo a train.py en AutoResearch.
2. Evaluation Harness determinista
Cada corrida produce 4 scores reproducibles:
| Score | Qué mide |
|---|---|
score_principal |
Calidad de la decisión final |
guardrail_1 |
Contradicciones internas |
guardrail_2 |
Costo (tokens / latencia) |
guardrail_3 |
Trazabilidad (acuerdos, supuestos, riesgos, tareas) |
Sin harness determinista, no hay mejora confiable. Ver evals para diseño de métricas.
3. Banco de casos con holdout
Dataset por dominio con:
- Input inicial fijo
- Restricciones del problema
- Rúbrica de salida esperada
- Casos de holdout ocultos al optimizador — clave para detectar overfitting al benchmark
4. Oráculo de evaluación 100% automático
Combina tres capas:
- Validador por reglas (estructura, cobertura, consistencia)
- Jury de 2-3 jueces LLM con rúbrica fija
- Penalización por desacuerdo entre jueces
La combinación reduce el sesgo individual de LLM-as-judge. Ver evals — tipos de evaluación.
5. Loop ratchet (sin humano)
Ciclo autónomo:
- Proponer variante de
team-spec - Ejecutar suite completa de casos
- Comparar contra baseline
- Promover solo si mejora score Y respeta guardrails
- Si no mejora, descartar
Principio fundamental: nunca degradar baseline. Mismo principio que AutoResearch de Karpathy.
6. Protecciones anti-gaming
- Holdout oculto y rotativo — evita que el optimizador memorice los casos
- Pruebas adversariales
- Penalización por respuestas largas sin valor (verbosidad ≠ calidad)
- Regla de generalización: no promover cambios que mejoran en train pero empeoran en holdout
7. Despliegue autónomo seguro
- Canary automático
- Monitoreo continuo post-despliegue
- Auto-rollback por umbral
Meta-Consilium como fábrica de equipos
Pipeline para generar equipos nuevos para un cliente:
- Clasificar problema del cliente por dominio/vertical
- Generar 3-5 configuraciones candidatas de equipo
- Evaluar automáticamente sobre benchmark del vertical
- Seleccionar mejor variante por score compuesto
- Empaquetar
team-specreutilizable
Núcleo estable: 5 roles base (ver consilium-arquetipos).
Specialist: activar solo si dominio regulado o alto costo de error.
Conecta directamente con consilium-giro-estrategico: el giro a equipos personalizados entregados como packs se vuelve automatizable con Meta-Consilium.
Relación con scaffolding-engineering
Meta-Consilium es una instancia específica de Scaffolding Engineering aplicada a Consilium. Donde AutoAgent de ThirdLayer optimiza el harness de un agente genérico, Meta-Consilium optimiza la configuración de un equipo multi-agente estructurado con roles fijos.
Diferencia clave: Meta-Consilium tiene restricciones adicionales (roles no son arbitrarios — Critic, Architect, etc. tienen funciones cognitivas definidas). El optimizador ajusta prompts y parámetros dentro de esa estructura, no los roles mismos.
Preguntas de investigación abiertas
Estas preguntas no tienen respuesta en el documento fuente — son líneas de investigación pendientes:
- ¿Qué métricas predicen mejor valor real de negocio en equipos multi-agente?
- ¿Cómo detectar automáticamente sycophancy residual en equipos con Critic?
- ¿Qué configuración minimiza costo sin perder calidad por vertical?
- ¿Cómo diseñar evals robustos cuando no hay ground truth único?
- ¿Qué tan transferibles son mejoras entre dominios distintos?