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

> Saber escribir un buen prompt ya no alcanza: ahora se diseñan comportamientos con multiagentes, memoria, skills y herramientas. Pero cada pieza ocupa contexto y agrega mantenimiento. La clave es separar lo que el agente debería hacer de lo que no puede dejar de hacer.

- Fuente canónica: https://www.ricardovelit.com/blog/p/del-prompt-al-diseno-agentico
- Nivel: intermedio · Lectura: 6 min · Publicado: 2026-09-28
- Etiquetas: agentes, diseño-agéntico, skills, contexto, axon
- Relacionados: [patrones-de-diseno-de-agentes-de-ia](https://www.ricardovelit.com/blog/p/patrones-de-diseno-de-agentes-de-ia.md), [sistemas-multiagente](https://www.ricardovelit.com/blog/p/sistemas-multiagente.md), [la-puerta-que-no-se-puede-eludir](https://www.ricardovelit.com/blog/p/la-puerta-que-no-se-puede-eludir.md)
- Contiene componentes interactivos que solo funcionan en la versión web.

---
## 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](/p/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](/p/mcp-model-context-protocol) que le permiten actuar y no solo responder.

Todo junto permite que [agentes de inteligencia artificial](/p/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](/p/atencion-en-transformers) 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](/p/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:

```text
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](/p/hipaa-llm-fuga-de-phi-error-de-tipo).

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

1. **Haz inventario de tus skills y tus instrucciones.** Marca cuáles son saber hacer y
   cuáles son invariantes.
2. **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.
3. **Fusiona o borra las skills que se pisan.** Dos skills parecidas cuestan más que una
   algo más larga.
4. **Mide el contexto por paso.** Si crece con cada skill que agregas, cada skill nueva
   hace un poco peores a las anteriores.
5. **Prefiere [patrones simples](/p/patrones-de-diseno-de-agentes-de-ia)** 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).