Con una cuenta desbloqueas el cuestionario, el foro de dudas y el tutor con IA de esta lección, además del registro de progreso y el certificado verificable al terminar «IA Agéntica: Agentes que Operan Sistemas Reales».
Nueve lecciones atrás definimos un agente como un lazo cerrado con un entorno, y desde entonces cada lección añadió una pieza que ese lazo necesita para sobrevivir en producción. Los contratos de la lección 2 dan al modelo una superficie de acción explícita y validada. El grounding de la lección 3 separa lo que sabe de lo que le fue inyectado, y lo hace trazable. MCP (lección 4) convierte esa superficie en plomería reutilizable y federable. La planificación de la lección 5 decide cuánto control cede el diseño y fija presupuestos. El multi-agente de la lección 6 reparte y verifica cuando compensa. La seguridad de la lección 7 acota el peor caso suponiendo que el modelo será engañado. La gobernanza de la lección 8 permite demostrar qué pasó. Y la evaluación de la lección 9 dice si todo eso funciona, y si sigue funcionando tras el próximo cambio de modelo.
Vale la pena decir en voz alta lo que emerge del conjunto: un buen sistema agéntico es, en su mayor parte, ingeniería ordinaria. Contratos, permisos, bitácoras, pruebas. El modelo aporta juicio en unos pocos puntos bien delimitados; el resto es lo que siempre hizo falta para operar sistemas que producen efectos.
Un cálculo antes de empezar
Antes de escribir tu catálogo, una cifra que orienta las proporciones. Ocho herramientas bien documentadas — nombre, descripción con su cuándo usarla e inputSchema — ocupan del orden de 90 tokens cada una:
8×90=720 tokens⇒128000720≈0.56%
Menos del 0.6% de la ventana. Compáralo con lo que cuesta una sola iteración evitable del lazo, Δ=1850 tokens (lección 1): 1850/720≈2.6 veces el catálogo entero. La conclusión es contundente y contraria a la intuición de quien optimiza tokens a ciegas: nunca ahorres en descripciones. Una descripción que evita una sola llamada equivocada ya pagó todo el catálogo, dos veces y media.
El proyecto
Vas a diseñar el agente de operaciones de OrbitEye, la estación terrena automatizada del ecosistema: seguimiento con rotor, recepción con SDR, grabación y decodificación, todo expuesto por una API REST. No vas a implementarlo: vas a diseñarlo, que es donde se ganan o se pierden estos sistemas. Cuatro entregables: catálogo de herramientas MCP, modelo de seguridad, memoria y grounding, y plan de evaluación y gobernanza. Las instrucciones completas están en la tarea de esta lección.
Qué distingue un buen diseño
Tres cosas, y ninguna es la extensión del documento.
Cada decisión viene justificada con un patrón del curso. No basta con escribir "las tools son de grano medio": hay que decir por qué esa granularidad y qué se pierde con la alternativa. No basta con "el agente es fail-closed": hay que decir en qué operaciones y por qué en esas.
Los intercambios son explícitos. Todo lo que vale algo se paga: el fan-out cuesta tokens, la verificación cuesta exhaustividad, la aprobación humana cuesta latencia, el mínimo privilegio cuesta flexibilidad. Un diseño que solo enumera ventajas es un diseño que no se ha pensado.
La incertidumbre se declara. Si no sabes qué tasa de éxito tendrá una familia de tareas, dilo y explica cómo lo medirías. Es la misma honestidad operativa que le exiges al agente en la lección 8: reportar lo que se sabe, lo que no, y qué falta por verificar.
En tu diseño, la operación apuntar_antena(azimut, elevacion) recibe sus argumentos de un plan generado a partir de un ticket externo. ¿Qué combinación de patrones corresponde?
Cómo se evalúa
La rúbrica tiene cuatro criterios de 25 puntos: catálogo de tools, modelo de seguridad, memoria y grounding, evaluación y gobernanza. Se puntúa la calidad de las decisiones y su justificación, no el volumen. Un documento de mil quinientas palabras con ocho decisiones bien argumentadas vale más que uno de cinco mil que describe herramientas sin explicar por qué son esas.
Y con esto se cumple el lema de la casa: no evaluamos con exámenes, evaluamos con despliegues en producción. Tu entrega no es un examen sobre agentes: es el documento de diseño que un equipo tomaría para construir el agente que opera una antena real. Escríbelo como si alguien fuera a hacerlo el lunes.