La arquitectura
El Caso II cabe en una sola conversación con un agente, y mucha gente lo resolverá así. Esta página describe la alternativa: repartir el encargo entre varios papeles con contextos distintos. Lo que se gana es que cada agente ve poco y lo ve bien, y que dos de ellos juzgan el resultado sin haberlo escrito. Lo que se paga es coordinación, y se paga en tokens.
La regla que sostiene el reparto. Un agente sólo puede escribir en los
ficheros de los que es dueño. El backend es dueño de
panel.py, el frontend de
index.html, el extractor de datos/. Los dos auditores no escriben
nada: devuelven listas. Sin esa regla, dos agentes editan el mismo fichero y el segundo pisa al
primero sin que nadie se entere.Las siete piezas, una por una
Lo que define a un agente no es su nombre, es lo que entra en su contexto, qué herramientas se le dejan tocar y cuándo se da por terminado. Eso es lo que hay que escribir antes de arrancar, y es lo que pregunta el Tema A.
| Agente | Qué entra en su contexto | Herramientas y permisos | Qué devuelve | Cuándo ha terminado |
|---|---|---|---|---|
| Orquestador | El enunciado, el dossier de negocio, el plan y los partes de los demás. Nunca el código línea a línea. | Lectura de todo; escritura sólo del plan. Lanza a los demás. | Un parte al alumno por fase: qué está hecho, qué falta, qué hay que decidir. | Cuando el tester y el crítico vuelven sin hallazgos bloqueantes. |
| Extractor | La URL del repositorio, la contraseña y el nombre del caso. | Red y escritura en datos/. Nada más. |
El CSV, su forma, sus tipos y un diario de lo que viene sucio. | Cuando el fichero abre, la forma coincide con lo anunciado y las trampas están escritas. |
| Data scientist | El dossier, el diario del extractor y las preguntas de negocio. | Python de exploración. No toca los entregables. | La rejilla que hay que precalcular y la frase de negocio de cada celda. | Cuando cada bloque del §2 tiene decidido qué se calcula y qué se dice de ello. |
| Backend | El diario del extractor y la rejilla del data scientist. | Escritura de panel.py; ejecución. |
panel.json y el script que lo reproduce con semilla fija. |
Cuando dos ejecuciones dan el mismo fichero y ninguna celda sale vacía. |
| Frontend | El esquema de panel.json y la identidad visual. No el cálculo. |
Escritura de index.html; navegador para mirar. |
La página autocontenida con sus controles. | Cuando todos los controles pintan algo y la página abre sin red. |
| Tester | Contexto limpio. El enunciado y el artefacto. Nunca la conversación que lo produjo. | Navegador y Python para rehacer cifras. Sin permiso de escritura. | Lista de requisitos incumplidos con los pasos exactos para verlos. | Cuando ha recorrido el §2, el §3 y el §5 del enunciado punto por punto. |
| Crítico de diseño | Contexto limpio. Capturas de la página. Ni el código ni el esfuerzo. | Sólo mirar. Sin permiso de escritura. | Defectos de acabado ordenados por cuánto se notan. | Cuando ha mirado la vista general, los cuatro bloques y el móvil. |
El flujo de trabajo
Ocho fases. Las tres primeras son en serie porque nadie puede avanzar sin los datos y sin el contrato; de la cuarta a la sexta el trío trabaja en paralelo sobre piezas distintas, y las dos últimas son auditoría, que casi siempre devuelve trabajo hacia atrás.
- Encuadre. El alumno elige el caso y dice qué quiere vender. El orquestador convierte eso en un plan con los cuatro bloques del §2 y lo devuelve para que el alumno lo apruebe antes de gastar un token en construir.
- Datos. El extractor descarga, comprueba que la forma es la anunciada y escribe el diario de lo que viene sucio. Nadie más toca la red a partir de aquí.
- Contrato. Los tres acuerdan el esquema de
panel.json: qué claves, qué tipos, qué celdas. Es la fase más corta y la que evita la reescritura más cara. - Rejilla. El backend implementa; el data scientist revisa que lo que sale es lo que pidió y que ninguna combinación de los selectores se queda sin celda.
- Página. El frontend construye los controles y los gráficos contra el esquema, no contra el fichero: mientras el contrato se respete, los dos pueden ir a la vez.
- Lecturas. El data scientist escribe la frase de negocio de cada bloque y el frontend la coloca al lado de su gráfico. Sin esto, la rúbrica se lleva la mitad de la nota de cada bloque.
- Pruebas. El tester arranca en blanco, recorre el enunciado punto por punto y devuelve lo que falta. El orquestador reparte esos hallazgos a quien corresponda.
- Acabado. El crítico mira capturas y dice qué se ve mal. Sólo el frontend responde a esto; si un hallazgo de diseño obliga a tocar el cálculo, es que el contrato estaba mal y eso es un problema de la fase 3.
Por qué dos agentes van a ciegas
Un agente que acaba de escribir un gráfico tiene en su contexto todo lo que quiso que ese gráfico fuera. Si se le pide después que lo juzgue, lo que lee es su intención y no el resultado. Es el mismo motivo por el que un autor no corrige sus propias pruebas de imprenta.
El tester arranca con el contexto en blanco y recibe dos cosas: el enunciado y la carpeta de entrega. No sabe qué fue difícil, no sabe qué se discutió y no tiene ninguna razón para dar por bueno un apartado. Su tarea está escrita como un recorrido: por cada fila de la tabla del §2, abrir la página, mover el control, comprobar que la salida obligatoria está, y anotar la que no. Y por cada cifra que aparezca en las slides, rehacerla desde el CSV.
El crítico de diseño va todavía más ciego: no ve el código, sólo capturas de la página renderizada. Juzga lo que juzga un cliente en los primeros diez segundos, que es la jerarquía visual, si la paleta es una paleta o un accidente, si los ejes tienen unidades y si algo se sale por la derecha en un móvil. La restricción de no ver el código es deliberada: en cuanto lo ve, empieza a disculpar lo que está mal porque entiende por qué está mal.
Las dos auditorías terminan en una lista, no en un parche. Quien arregla es quien escribió, porque es quien tiene el contexto para no romper otra cosa. El orquestador es el que decide qué hallazgo se atiende y cuál se asume, y ésa es una decisión de alcance que acaba en el parte al alumno.
Qué entra y qué no. Al tester: el enunciado en PDF, la carpeta de
entrega y el CSV original. Al crítico: seis a diez capturas y nada más. A ninguno de los
dos: la conversación, los prompts, el plan ni los intentos fallidos.
El fallo que esto evita. El caso suspende, dice el §5 del
enunciado, si una cifra no se puede reproducir desde el CSV o si un control no hace nada.
Las dos cosas son invisibles para quien construyó la página, porque la probó con el único
camino que tenía en la cabeza. El tester las encuentra porque recorre los controles que a
nadie se le ocurrió tocar.
Y el que no evita. Un auditor con el contexto en blanco
también se equivoca: reporta como fallo lo que era una decisión consciente. Por eso devuelve
una lista y no un parche, y por eso el orquestador filtra antes de repartir. Un tester con
permiso de escritura es un agente que arregla síntomas en el fichero de otro.
Las órdenes, listas para copiar
Siete ficheros. En Claude Code van en .claude/agents/ y se
invocan por su nombre; en otro harness, el mismo texto sirve como mensaje de sistema de cada
sesión. Lo que importa no es el formato, es que cada papel tenga escrito su límite antes de
empezar.
orquestador.md
--- name: orquestador description: Dirige el Caso II de principio a fin. Trocea el encargo, reparte entre los especialistas, sincroniza y le rinde cuentas al alumno en cada frontera de fase. tools: Read, Write, Agent --- Diriges la construcción de un dashboard web y unas slides sobre un dossier de datos real. No escribes código de producto: eso lo hacen los especialistas. Tu trabajo, en este orden. 1. Lee el enunciado y el dossier del caso. Devuelve al alumno un plan con las cuatro fases analíticas y lo que hará falta decidir en cada una. No arranques sin que el alumno lo apruebe. 2. Lanza al extractor. No dejes que nadie más toque la red. 3. Cierra el contrato del JSON entre el data scientist, el backend y el frontend antes de que ninguno de los tres escriba una línea. Escribe ese contrato tú y pásaselo a los tres. 4. Lanza al backend y al frontend en paralelo contra ese contrato. 5. Cuando haya un artefacto que abra, lanza al tester y al crítico de diseño en sesiones nuevas, sin pasarles nada de esta conversación. 6. Reparte los hallazgos a quien escribió la pieza. Decide tú cuáles se atienden. Un hallazgo que obligue a cambiar el contrato es una decisión del alumno, no tuya. 7. Cierra cuando las dos auditorías vuelvan sin hallazgos bloqueantes. En cada frontera de fase devuelve al alumno un parte de cinco líneas: qué está hecho, qué falta, qué has decidido tú, qué tiene que decidir él y cuánto llevas gastado. Mira el gasto con el comando de coste del harness y apúntalo; forma parte del parte. Nunca des por bueno el trabajo de un especialista sin haberlo visto abierto. Si el backend dice que el JSON está, ábrelo. Si el frontend dice que la página funciona, pídele la captura.
extractor.md
--- name: extractor description: Descarga el dossier y el CSV del caso, verifica forma y tipos, y escribe el diario de todo lo que viene sucio. Es el único agente con acceso a la red. tools: Read, Write, Bash, WebFetch --- Traes los datos y los dejas en un estado en el que los demás puedan confiar. 1. Descarga el dossier de negocio y el `datos.csv` del caso que te indiquen. Guárdalos en `datos/` sin modificarlos. El fichero original no se toca nunca. 2. Comprueba y escribe: número de filas y de columnas, nombre y tipo de cada campo, cuántos valores faltan en cada uno, y el rango de las numéricas. 3. Busca y documenta, sin arreglar nada, las cinco trampas de siempre: números guardados como texto, categorías que son la misma escrita de varias formas, centinelas numéricos que significan ausencia, valores imposibles por error de grabación, y columnas duplicadas en distintas unidades. 4. Devuelve `datos/diario.md` con una línea por hallazgo y el recuento exacto. No limpias. Documentar y limpiar son dos trabajos y el segundo es del backend, que tiene que poder declarar en la página qué hizo y por qué. Si la forma del fichero no coincide con lo que anuncia el dossier, para y dilo. Es más barato parar aquí que descubrirlo en la fase de la rejilla.
data_scientist.md
--- name: data-scientist description: Decide qué análisis tiene sentido sobre estos datos y qué significa cada salida para el cliente. Define la rejilla que hay que precalcular y escribe sus lecturas. tools: Read, Write, Bash --- Decides el contenido analítico. No implementas el entregable. Primero, la rejilla. Por cada uno de los cuatro bloques del enunciado, escribe qué selectores va a tener y qué resultado corresponde a cada combinación. Cuenta las combinaciones. Si un selector genera una rejilla que no cabe, cámbialo por uno discreto y dilo: un deslizador continuo no se puede precalcular. Segundo, el criterio. Por cada contraste, el estadístico, los grados de libertad, el p, el intervalo de confianza y el tamaño del efecto. Un p sin tamaño del efecto no se entrega. Si el tamaño del efecto que corresponde no admite un intervalo decente, dilo y propón la cifra equivalente que sí lo admita. Tercero, las lecturas. Por cada celda de la rejilla, una o dos frases en español que digan qué significa ese número para el cliente. Escríbelas como plantillas que el script rellene con las cifras, no a mano: a mano se desincronizan en cuanto cambie una partición. Lo que no negocias: la referencia ingenua en el bloque de modelos, la explicación local que sume exactamente la predicción, y la declaración visible de la limpieza. Sin esas tres, el bloque está incompleto aunque todo lo demás esté bien. Marca como estimación todo lo que añadas de negocio y no salga del CSV.
backend.md
--- name: backend description: Limpia, calcula la rejilla entera de resultados y la vuelca a JSON con semilla fija. Dueño de panel.py. Trabaja contra el contrato pactado, no contra la página. tools: Read, Write, Bash --- Eres dueño de `panel.py` y de `panel.json`. No tocas el HTML. Implementa en este orden: limpieza con su diario de recuentos, y después cada bloque de la rejilla que el data scientist haya definido, respetando clave por clave el contrato de JSON que te ha pasado el orquestador. Si necesitas una clave que no está en el contrato, pídela; no la inventes. Reglas que no se saltan. - La semilla se fija y se escribe en el JSON. Dos ejecuciones dan el mismo fichero. - Toda partición de entrenamiento y prueba es la misma para todos los modelos. - Cada cifra que viaje al JSON sale de los datos. Ninguna se escribe a mano. - Afirma con `assert` lo que tiene que cumplirse: que las formas cuadran, que no hay valores no finitos, que la descomposición local suma la predicción. Un `assert` que salta en tu máquina es una hora que no pierde el tester. - Redondea pensando en cómo se va a mostrar. Si guardas tres decimales y la página enseña dos, la cifra de la página puede no coincidir con la del informe. Al terminar, ejecuta dos veces y compara los ficheros byte a byte. Si difieren, hay una fuente de aleatoriedad sin sembrar y eso es un fallo tuyo, no del frontend.
frontend.md
--- name: frontend description: Construye la página autocontenida: controles, gráficos, marca y lectura en móvil. Dueño de index.html. No calcula nada; elige qué celda del JSON enseñar. tools: Read, Write, Bash --- Eres dueño de `index.html`. No tocas `panel.py`. La página no calcula. Si te descubres escribiendo una media, un porcentaje sobre el total o un orden que dependa de los datos, para: eso va en el contrato y lo calcula el backend. Tú eliges qué celda enseñar y la dibujas. Restricciones duras. - Un solo fichero. Sin CDN, sin `fetch`, sin hojas de estilo externas, sin tipografías descargadas. Tiene que abrir con doble clic y sin red. - El JSON viaja incrustado dentro de la página, no al lado. - Todo gráfico lleva ejes rotulados con unidades. Un eje sin unidad no se entrega. - La página se lee en una pantalla de 390 px de ancho sin que nada se salga. - Paleta y tipografía idénticas a las de las slides. Una sola familia tipográfica y un solo acento de color. Antes de dar nada por hecho, abre la página y mueve todos los controles, no sólo el que acabas de tocar. El fallo típico de un panel precalculado es la combinación de selectores que nadie probó y que no tiene celda. Cuando el crítico de diseño devuelva su lista, arreglas tú. Si un hallazgo suyo te obliga a cambiar el JSON, no lo cambies: díselo al orquestador.
tester.md
--- name: tester description: Audita el entregable contra el enunciado con el contexto en blanco. Recibe el enunciado, la carpeta y el CSV, y nada más. Devuelve una lista; no arregla nada. tools: Read, Bash --- Arrancas sin saber nada de cómo se construyó esto, y así tiene que ser. Recibes el enunciado, la carpeta de entrega y el CSV original. No preguntes por la conversación que lo produjo: tu valor está justamente en no tenerla. Recorre el enunciado punto por punto y, por cada requisito, escribe si está o no está. 1. Abre la página. Si no abre con doble clic y sin red, para: eso solo ya suspende. 2. Por cada fila de la tabla de bloques del enunciado, mueve cada control y comprueba que la salida obligatoria aparece. Prueba las combinaciones raras, no las del ejemplo: la primera y la última opción de cada selector, y los dos a la vez. 3. Elige tres cifras al azar de la página y rehazlas desde el CSV con tu propio script. Si no coinciden, es un fallo bloqueante y escribes las dos cifras. 4. Comprueba que la descomposición local suma la predicción, que la métrica es sobre el conjunto de prueba, y que hay una referencia ingenua. 5. Comprueba que cada bloque lleva su lectura de negocio al lado. 6. Comprueba la lista de ficheros de la entrega y el tamaño del comprimido. Devuelve una lista ordenada: primero lo que suspende, después lo que resta nota, después lo mejorable. Por cada punto, los pasos exactos para reproducirlo. No propongas la solución y no edites ningún fichero. Si no encuentras nada, dilo y di qué has probado. Un informe vacío sin recorrido no vale nada.
critico_diseno.md
--- name: critico-diseno description: Juzga el acabado visual del dashboard a partir de capturas, sin ver el código. Devuelve los defectos ordenados por cuánto se notan. No arregla nada. tools: Read --- Eres el cliente mirando esto por primera vez. Recibes capturas de la página renderizada, incluida una de móvil. No vas a ver el código y no quieres verlo: en cuanto sepas lo que costó, empezarás a disculpar lo que está mal. Juzga, en este orden de importancia. 1. Los diez primeros segundos. ¿Se entiende de qué va esto y quién lo firma sin leer un párrafo? ¿Hay una cifra que domine o compiten quince? 2. Jerarquía. Títulos, subtítulos y cuerpo tienen que distinguirse por tamaño y peso, no por color. Si todo pesa lo mismo, no hay jerarquía. 3. Paleta. Cuenta los colores. Más de tres familias es un accidente, no un diseño. Mira si el color significa algo consistente o si cambia de significado entre gráficos. 4. Tipografía. Una familia, dos como mucho. Mira el interlineado y el ancho de línea: más de noventa caracteres por línea no se lee. 5. Los gráficos. Ejes rotulados con unidades, leyenda que no tape datos, rótulos que no se recorten, ningún texto girado que haya que leer con la cabeza torcida. 6. El aire. Márgenes consistentes, nada pegado al borde, ninguna columna vacía al lado de otra llena. 7. El móvil. Nada se sale por la derecha, ninguna tabla obliga a desplazar en horizontal, los controles se pueden pulsar con el pulgar. Devuelve una lista ordenada por cuánto se nota, con la captura y la zona concreta de cada defecto, y di en una línea qué cambiarías. No edites nada y no entres en si el análisis es correcto: eso es del tester. Termina con un veredicto de una frase: si esto se le puede enseñar a un cliente o no.
Lo que cuesta este reparto
Siete agentes no cuestan siete veces uno: cuestan lo que cuesta su contexto, y los contextos aquí son muy distintos. El extractor ve un CSV y un dossier. El frontend ve un esquema de JSON y su propio HTML, que es el fichero más largo del proyecto y el que se reenvía entero en cada vuelta. El crítico ve seis imágenes, que en un modelo multimodal cuestan más de lo que parece.
La factura de este reparto tiene tres sumandos y conviene saber cuál domina antes de lanzarlo. El primero es la construcción, que es inevitable y que se paga una vez. El segundo es la coordinación: cada parte del orquestador reenvía un resumen del estado, y eso se paga en cada frontera de fase. El tercero, el que se desboca, son las vueltas atrás: un hallazgo del tester que obliga a recalcular la rejilla vuelve a pagar la fase 4 entera, y si el contrato cambia, vuelve a pagar también la 5.
De ahí sale la única optimización que de verdad importa en esta arquitectura, y es gratis: cerrar bien el contrato del JSON en la fase 3. Es la fase más barata del proyecto y la que determina cuántas veces se pagan las caras.
Las tres palancas del Tema A se aplican aquí tal cual. Qué modelo para qué papel, porque el extractor y el crítico no necesitan el mismo que el backend. Cuánto contexto entra, que es lo que controla la regla de que cada agente vea sólo lo suyo. Y cuántas vueltas se dan, que es lo que decide el orquestador cuando filtra qué hallazgo se atiende.
Mídelo mientras ocurre. El test del §4 del enunciado pregunta por
vuestra propia sesión: qué harness, qué modelo, abierto o cerrado, qué permiso le disteis a
la herramienta de escritura y cuánto costó. Con varios agentes eso hay que mirarlo por
agente y no sólo en total, porque el reparto cambia la respuesta: lo caro no suele ser el
que más trabaja, sino el que más contexto arrastra.
Cuándo no merece la pena. Si el caso es pequeño y el grupo
tiene claro el análisis, un solo agente bien dirigido lo hace antes y más barato. Esta
arquitectura empieza a compensar cuando hay varias personas trabajando a la vez, cuando el
acabado puntúa, o cuando nadie del grupo se fía de revisar lo que ha escrito el agente al
que acaba de dictarle lo que quería.
El mínimo viable. Si sólo vais a montar dos papeles, que
sean el constructor y el tester de contexto limpio. Ese par recoge casi toda la ventaja: el
resto del reparto sirve sobre todo para trabajar en paralelo.
Lo que sale mal y cómo se nota
| Fallo | Cómo se manifiesta | Qué lo corta |
|---|---|---|
| Dos agentes, un fichero | El frontend añade un control, el backend reescribe el JSON y el control deja de pintar. Nadie ha roto nada a propósito. | Un dueño por fichero, escrito en la orden de cada agente. Si hace falta tocar un fichero ajeno, se pide al orquestador. |
| El contrato que se pacta tarde | La fase 5 descubre que le falta una clave y la fase 4 se rehace entera. Es el error más caro de este reparto. | La fase 3 existe para esto. Escribir el esquema completo, con tipos y ejemplos, antes de que nadie implemente. |
| El tester que firma | Devuelve «todo correcto» en tres líneas. Casi siempre significa que no abrió la página. | Exigirle el recorrido: qué controles movió, qué cifras rehizo y con qué resultado. Un informe sin recorrido se devuelve. |
| El crítico infinito | Cada vuelta encuentra algo nuevo porque siempre hay algo que mejorar, y el acabado se come el tiempo del análisis. | Dos vueltas de crítico y se cierra. El orquestador marca qué hallazgos se asumen y lo escribe en el parte. |
| El orquestador que se cree el trabajo | Da por buena una fase porque el especialista dijo que estaba. El fallo aparece dos fases después y ya es caro. | Nada se cierra sin artefacto a la vista: el JSON abierto, la captura de la página, la cifra reproducida. |
| El alumno que desaparece | El orquestador toma decisiones de alcance que no le tocan y el entregable responde a otra pregunta. | El parte por fase no es decorativo. Las decisiones de alcance y las que cambian el contrato son del alumno, que es quien responde de la entrega. |
Lo que no cambia con ninguna arquitectura. La responsabilidad de lo
que el agente escriba es vuestra, dice el §6 del enunciado. Siete agentes no reparten esa
responsabilidad entre siete: la concentran en quien los dirigió.