Tercer artículo de la serie de 6 partes sobre los escenarios del CCA-F — código fuente completo de cada escenario: aicert-labs.
El escenario, tal como está en el exam guide
Un agente coordinador delega en subagentes especializados — búsqueda, análisis de documentos, síntesis, generación de reportes — para producir informes citados y completos.
| Dominio | Peso | Dónde aparece en este escenario |
|---|---|---|
| Agentic Architecture & Orchestration | 27% | El coordinador planea subtemas, ejecuta un subagente por subtema y luego sintetiza |
| Tool Design & MCP Integration | 18% | Un servidor MCP con dos tools, no una — la separación es deliberada |
| Context Management & Reliability | 15% | Qué puede — y no puede — ver el coordinador una vez que un subagente termina |
Delegar es la parte fácil
Es tentador pensar que el problema difícil en "coordinador delega en subagentes" es la delegación misma — decidir dividir el trabajo. No lo es. El problema difícil, y el que las preguntas de escenario del CCA-F están hechas para evaluar, es qué cruza la frontera entre un subagente y el coordinador.
La versión ingenua hace que el coordinador mantenga una única conversación larga y llame él mismo a cada tool, subtema tras subtema. Su contexto crece con todo: cada búsqueda, cada documento leído que resultó irrelevante, para cada subtema, todo en la misma conversación. Para el tercer subtema, el contexto del coordinador ya es en su mayoría ruido de búsqueda — y, como todo compite por la misma ventana de contexto, ese ruido es exactamente lo que desplaza los hallazgos relevantes del primer subtema.
researchSubtopic() en aicert-labs soluciona esto dando a cada subtema su propia conversación desechable. Devuelve exactamente una cosa al coordinador: { subtopic, findings: [{ claim, documentId, source }] }. No la transcripción. No qué documentos rechazó. Un puñado de hechos estructurados. El contexto del coordinador crece con el número de subtemas, no con cuánto tuvo que buscar cada uno.
Dos tools, no una
El servidor MCP expone search_documents (barata, devuelve resultados compactos) y get_document (obtiene el texto completo de un documento) como tools separadas, en lugar de una sola que busque y devuelva el texto completo en una llamada. Esa separación obliga al subagente a decidir qué vale la pena leer por completo — no todo entra al contexto por defecto solo porque coincidió con una palabra clave. La propia descripción de get_document le indica al subagente que los snippets no son seguros para citar, el mismo patrón que process_refund del Escenario 1: poner la regla en el contrato de la tool, no en una nota del system prompt fácil de olvidar tres llamadas de tool después.
Ejecútalo tú mismo
git clone https://github.com/AICERT-STUDY/aicert-labs
cd aicert-labs/cca-f/scenario-3-multi-agent-research
npm install
cp .env.example .env # agrega tu ANTHROPIC_API_KEY
npm run research -- "Does a 4-day work week actually work?"
El corpus simulado (seis fuentes sobre investigación de semana laboral de 4 días) incluye deliberadamente documentos que discrepan entre sí — un estudio de manufactura no encuentra ganancia de productividad donde estudios de trabajo de conocimiento sí — así que la síntesis realmente tiene que reconciliar fuentes, no solo concatenarlas.
Pon a prueba tus conocimientos
1. ¿Por qué researchSubtopic() devuelve solo { subtopic, findings } en lugar del historial completo de mensajes del subagente?
Respuesta: para que el contexto del coordinador crezca con el número de subtemas, no con cuánto tuvo que buscar y leer cada subagente.
Si el coordinador mantuviera la transcripción completa de cada subagente, su contexto se llenaría de ruido de búsqueda proporcional al esfuerzo, no a lo que realmente es relevante para el informe final — y ese ruido desplaza los hallazgos que importan.
2. ¿Cuál es la razón arquitectónica para separar search_documents y get_document en dos tools en lugar de una sola que devuelva el texto completo directamente?
Respuesta: obliga al subagente a decidir qué vale la pena leer por completo, en lugar de que el texto completo de cada resultado de búsqueda entre al contexto por defecto.
Una única tool de buscar-y-devolver-todo optimiza por menos llamadas a tools a costa de un crecimiento de contexto sin revisar. Separar el punto de decisión en su propia llamada es un intercambio deliberado: un viaje de ida y vuelta extra a cambio de que el subagente solo traiga lo que realmente juzga relevante.
3. El subagente de investigación tiene una tool record_finding en lugar de simplemente responder con una lista de hallazgos en su mensaje de texto final. ¿Por qué?
Respuesta: una tool dedicada le da al coordinador un resultado estructurado y analizable, en lugar de depender de que el modelo formatee texto libre correcta y consistentemente.
Es el mismo principio detrás de los resultados tipados de tools en otros puntos de esta serie: una llamada a una tool es algo en lo que el código llamador puede confiar estructuralmente; un párrafo de prosa exige que quien lo llama lo interprete correctamente cada vez, sin garantía de consistencia entre ejecuciones.
4. Si dos documentos dan respuestas contradictorias sobre el mismo subtema, ¿en qué etapa de esta arquitectura se reconcilia eso?
Respuesta: en la síntesis — los subagentes de investigación individuales no intercambian información entre sí; solo la etapa de síntesis del coordinador ve los hallazgos de todos los subtemas a la vez.
Cada subagente de investigación trabaja en un subtema de forma aislada y no tiene visibilidad de lo que encontraron otros subagentes. Reconciliar contradicciones requiere un punto de vista que vea todo a la vez, lo cual, por diseño, solo tiene la etapa de síntesis.
5. El coordinador ejecuta los subagentes de investigación secuencialmente, en un bucle for, en lugar de en paralelo. ¿Qué tendría que ser cierto para que cambiar a Promise.all fuera seguro?
Respuesta: los subagentes tendrían que ser independientes entre sí, sin estado mutable compartido y sin que un subtema dependa de los hallazgos de otro — lo cual ya es el caso aquí.
Como cada llamada a researchSubtopic() solo lee del corpus MCP compartido y escribe en su propio array local de findings, nada en la arquitectura realmente exige ejecución secuencial — es una elección de legibilidad del log en consola, no una cuestión de corrección.
Simulacro gratuito del CCA-F, cubriendo los 5 dominios: aicert.study/certifications/ccaf.