Atlas no firma el capstone hasta que tu sistema demuestra todas las habilidades del track integradas:
| Unidad | Cómo aparece en este capstone |
|---|---|
| A · Sistema vs prompt | Decidiste que esto vale como sistema (router + chains), no como un prompt monolítico |
| B · Diseño de cadenas | Cada flow tiene 2-4 steps focales, con estado pasado explícitamente entre pasos. Pensá caching donde el mismo input se repita. |
| C · Routing dinámico | router con 4 rutas + fallback seguro escalate_to_human. Decidí: ¿router por reglas o por LLM? ¿Clasificador barato adelante? |
| D · Agentes con presupuestos | incident_report puede entrar en loop. Definí presupuesto (max steps / max tokens) y política de retries por tipo de error. Pensá degradación graceful si un sub-paso falla. |
| E · RAG honesto | shift_info integra retrieval para preguntas procedimentales |
| F · Observabilidad + evals | Sección final con eval categories + judge. Declará qué trazás (spans por step, costo, redacción de PII). |
[mensaje del comms]
↓
[ROUTER] → 4 rutas + fallback
↙ ↓ ↓ ↘
incident shift lookup escalate
chain (RAG) chain chain
↓
[agent_loop opcional con stops]
↓
[resultado al log del turno]
↓
[EVALS: control + edge + adversarial, juzgado por LLM]No te pedimos los prompts completos de cada step. el judge va a evaluar la estructura y la composición, no las palabras exactas de cada prompt. Lo que tiene que estar:
incident_report incluye agent_loop con stops.shift_info integra RAG (al menos en parte).escalate_to_human es conservador.evals declarando qué se mide.Atlas firma cuando ve el sistema entero funcionando como pieza única. No le importa que tu YAML sea perfecto en cada bullet. le importa que las piezas estén ahí, conectadas, y que el sistema sea diseñable, evaluable y mantenible.
El sistema lo registra como Track 4 completado. Pasás de "alumno con onboarding" a ingeniero de sistemas con LLMs. La crew te puede asignar problemas reales. no a resolverlos, a diseñar la arquitectura para resolverlos.
Suerte en el turno.