Del prompt al diseño agéntico: por qué más skills no hacen un mejor agente

El prompt se quedó corto

Durante dos años, la habilidad que se vendía era escribir un buen prompt: el rol, el formato, los ejemplos, la instrucción precisa. Sigue sirviendo. Pero en las comunidades de desarrolladores la conversación se movió a otra cosa, y tiene sentido: un prompt describe una respuesta, y lo que ahora se construye son comportamientos.

A eso se le empieza a llamar diseño agéntico. En lugar de redactar un mensaje, diseñas un sistema:

Arquitecturas multiagente: varios agentes con roles distintos que se reparten un objetivo. Lo explico en sistemas multiagente.
Memoria persistente: lo que el agente aprendió ayer sigue disponible hoy.
Skills: manuales de instrucciones que el agente carga cuando la tarea los necesita.
Herramientas externas: APIs, bases de datos y servidores MCP que le permiten actuar y no solo responder.

Todo junto permite que agentes de inteligencia artificial resuelvan objetivos complejos sin que alguien los supervise en cada paso. Hasta aquí, el entusiasmo está justificado.

Cada pieza cuesta contexto

El problema aparece cuando se trata cada pieza como gratuita. No lo es. Todo lo que el agente tiene que saber para decidir vive en la misma ventana de contexto: la descripción de cada skill, el esquema de cada herramienta, lo que recuperó de memoria, el historial.

Un modelo no lee su contexto como una lista ordenada de instrucciones que va cumpliendo. Cada token compite por atención con todos los demás. Cuando el contexto crece, la instrucción importante no desaparece, pero pesa menos. Distintos estudios lo han medido desde 2025: el rendimiento de los modelos cae a medida que la entrada se alarga, incluso en tareas que con poco texto resuelven sin error.

Los sistemas de skills bien hechos lo mitigan cargando al principio solo el nombre y la descripción de cada skill, y el manual completo cuando hace falta. Ayuda, pero no elimina el problema. Con diez skills, el agente elige bien. Con ochenta, las descripciones se parecen, dos skills dan instrucciones que se contradicen, y el agente carga la que no era o ninguna. El resultado se nota así:

el agente se vuelve pesado: más tokens por paso, más latencia, más costo;
se vuelve confuso: sigue la instrucción que estaba más cerca y no la más importante;
y se vuelve impredecible: el mismo pedido activa skills distintas según cómo se formule.

El harness que nadie quiere mantener

La reacción natural es envolver al agente en más código: validaciones, reintentos, enrutadores, un orquestador que vigila al orquestador. Ese envoltorio se llama harness, y es necesario. Pero crece rápido, y llega un punto en que tiene más lógica que el agente, sin tests que la cubran, y cada cambio de modelo lo rompe por un lado distinto.

Un harness complejo tiene además el defecto que conté en la puerta que no se puede eludir: sus controles viven dentro del programa, y todo lo que vive dentro del programa se puede no llamar. Una refactorización, un camino nuevo, una herramienta que alguien agregó sin pasar por el validador, y el control queda al lado.

Mi opinión: separa lo que debería hacer de lo que no puede dejar de hacer

Muchas skills y mucho harness son, en el fondo, el mismo error: usar un único mecanismo para dos tipos de instrucción que no se parecen.

El saber hacer. Cómo se redacta un informe, qué tono usar con un cliente, qué pasos seguir para revisar un contrato. Si el agente lo hace un poco distinto, no pasa nada grave. Esto va en el prompt o en una skill, y está bien que sea una sugerencia.

Lo que no puede pasar. Que un dato de un paciente salga sin filtro. Que el agente gaste más del presupuesto. Que una conjetura del modelo se guarde como un hecho. Si esto falla una vez de cada mil, falla. Esto no puede vivir en una skill, porque una skill es texto que el modelo puede no seguir.

Escribir en una skill "nunca envíes datos personales sin anonimizar" es pedirle al modelo que se porte bien. Lo más inteligente es mover las reglas del segundo tipo a un lugar donde no se puedan eludir: el compilador. Para eso construí AXON, un lenguaje de programación que compila para un modelo en lugar de para un procesador —AXON programming language en la documentación, axon-lang en la terminal—.

La regla que en una skill sería un párrafo, en AXON es parte del tipo:

type ClinicalNote compliance [HIPAA] { patient_id: String, text: String }

shield PHIShield {
  scan: [pii_leak]
  on_breach: halt
  severity: critical
  compliance: [HIPAA]
}

Si un endpoint recibe un ClinicalNote y no declara un shield que cubra HIPAA, el programa no compila. No ocupa contexto, porque el modelo no tiene que recordarla, y no depende de que el agente elija la skill correcta, porque no hay nada que elegir. La demo completa, con la salida real del compilador, está en HIPAA y LLM.

Conviene ser preciso con lo que esto logra. Un lenguaje no hace que el modelo acierte: la respuesta sigue siendo una muestra de una distribución. Lo que sí hace es acotar qué puede pasar con esa respuesta: qué tipo tiene que tener para seguir, por qué controles cruza antes de salir, cuánto puede gastar. La salida del modelo se vuelve confiable en el sentido que importa en producción: sabes qué no puede hacer, aunque no sepas qué va a decir.

Dónde va cada regla

Tipo de regla	Ejemplo	Dónde vive	Si falla
Estilo y criterio	"Resume en tres puntos, tono formal"	Prompt	Una respuesta peor
Procedimiento experto	"Cómo revisar un contrato de arrendamiento"	Skill	El agente hace la tarea peor
Acceso al mundo	Consultar el inventario	Herramienta o MCP	El agente no puede actuar
Invariante	"La PHI nunca sale sin shield"	Tipo y compilador	El programa no compila

La cuarta fila es la que casi todos intentan resolver con las tres primeras. Y es la que más caro sale cuando falla.

Cómo adelgazar un agente

Haz inventario de tus skills y tus instrucciones. Marca cuáles son saber hacer y cuáles son invariantes.
Saca los invariantes del texto. Llévalos a un lugar que se verifique antes de ejecutar: tipos, esquemas de salida validados, y cuando el riesgo lo pide, un compilador que no deje pasar el programa.
Fusiona o borra las skills que se pisan. Dos skills parecidas cuestan más que una algo más larga.
Mide el contexto por paso. Si crece con cada skill que agregas, cada skill nueva hace un poco peores a las anteriores.
Prefiere patrones simples antes que un multiagente. Un flujo fijo con un buen paso de modelo le gana a tres agentes que discuten.

Para llevarte

El diseño agéntico es real: multiagentes, memoria, skills y herramientas resuelven cosas que un prompt no puede.
Pero cada pieza ocupa contexto y compite por la atención del modelo. Más skills pueden dar un agente más pesado y más confuso.
Un harness grande tiene controles que se pueden rodear, y se vuelve difícil de mantener.
Separa el saber hacer (prompt y skills, pueden ser sugerencias) de lo que no puede pasar (tipos y compilador, no pueden serlo).