Lead-first
El equipo se forma después de comprender el proyecto, no desde una plantilla rígida.
LABORATORIO ABIERTO · FLAGSHIP
Mi proyecto flagship open source investiga una pregunta concreta: cuándo un equipo de agentes de software mejora el resultado y cuándo solo añade coordinación, coste y nuevas formas de fallar.
Construir. Verificar. Entregar.
01 · DISEÑO
02 · CONSTRUCCIÓN
03 · VERIFICACIÓN
Datos de ejemplo
Un Lead entiende el objetivo, forma el equipo que el riesgo justifica y conserva issues, runs, costes, revisiones y bloqueos en SQLite. Los hard gates y la evidencia deciden si el trabajo se acepta, se reabre o se bloquea. Hoy el repositorio es público, la instalación está verificada en Windows y todavía no existe una release estable.
El equipo se forma después de comprender el proyecto, no desde una plantilla rígida.
Engineer, Reviewer, QA u otros perfiles aparecen solo cuando el trabajo y el riesgo los justifican.
Issues, runs, wakeups, interacciones, costes y evidencia sobreviven en SQLite y pueden recuperarse.
Runtime, autenticación, salud, autoridad y coste permanecen explícitos para cada agente.
Un agente directo se compara con solo_lead, lead_quorum y full_team bajo el mismo caso.
Las pruebas inconclusas y los casos donde más agentes no ayudan forman parte de la evidencia.
El Lead traduce el proyecto a issues, dependencias, criterios y condición de salida.
→Contrata la mínima estructura que puede asumir el trabajo y sus revisiones.
→Heartbeats, runs y presupuestos mantienen actividad y coste observables.
→Pruebas deterministas, revisión y evidencia permiten aceptar, reabrir o bloquear.
CÓDIGO + EVIDENCIA PÚBLICA
AI Teams 0.1.0 está publicado bajo Apache-2.0 y tiene una aceptación clean-room de Windows reproducible. Linux y macOS siguen sin verificar y no se promete autonomía total, ahorro garantizado ni que un equipo completo sea superior. RogueBall continúa como un caso independiente de ejecución Godot auditada.
Convertir una oportunidad priorizada en un sistema propio, medible y transferible.
Explorar esta ruta↗Dar al equipo criterio y autonomía para operar, evaluar y ampliar lo construido.
Explorar esta ruta↗Puedes inspeccionar y experimentar con el repositorio, pero todavía es desarrollo activo sin release estable ni soporte multiplataforma verificado.
No necesariamente. Esa es precisamente una de las hipótesis que el benchmark compara contra un agente directo.
Trabajo, dependencias, runs, wakeups, interacciones, costes, revisiones y evidencia de cierre en un estado durable.
No. Sigue publicado como caso auditado de compilación, ejecución y verificación en Godot, con límites de procedencia explícitos.
NEXT STEP
La página flagship muestra arquitectura, evaluación, código y límites. Si tu problema requiere una orquestación similar, podemos empezar por sus criterios de cierre.
Esta solicitud no está abierta durante el lanzamiento. La información permanece pública para ayudarte a preparar el proyecto; si necesitas consultoría o formación empresarial, puedes solicitar una conversación de encaje.