Un promptware es una unidad de agente autónoma que almacena sus propias instrucciones, memoria (Memory), permisos de herramientas (Tools) e historial de ejecución (Logs) en forma de archivos, y que revisa sus instrucciones y memoria tras cada ejecución. En Ivy Tendril, cada etapa del ciclo de vida del plan, desde la redacción de un borrador hasta la apertura de un pull request, es gestionada por una de estas unidades. Las instrucciones son archivos versionados en el repositorio, por lo que pueden ser revisados, inspeccionados con diff, revertidos y compartidos con todo el equipo como cualquier otro archivo de código fuente. Este artículo explica la estructura de una unidad, su bucle de ejecución (run loop), los siete promptwares integrados y los dos modos de fallo que conviene vigilar.

Qué contiene una unidad de promptware

Una unidad de promptware es un directorio compuesto por cuatro partes. Cada parte tiene una única responsabilidad.

Parte	Contenido	Quién lo escribe
`Program.md`	Las instrucciones que sigue el agente en su etapa. El agente las revisa tras una ejecución; los humanos las revisan.	El agente y los humanos
`Memory/`	Aprendizajes persistentes sobre la base de código y las convenciones del equipo. Se añaden tras cada ejecución.	El agente
`Tools/`	Los permisos acotados para esta etapa: qué comandos, archivos e integraciones puede utilizar el agente.	Los humanos
`Logs/`	El historial de ejecución: qué leyó, ejecutó y modificó el agente, y a qué conclusiones llegó.	El agente (solo añadir)

Program.md es prosa, no código. Una sección para una unidad de ejecución de planes podría verse así:

## Antes de abrir un pull request

- Ejecuta `pnpm lint` y `pnpm test` desde la raíz del repositorio. No abras un PR si alguno de los dos falla.
- Limita el diff estrictamente a los archivos nombrados en el plan. Si se debe modificar otro archivo, indícalo en la descripción del PR.
- Utiliza el formato de mensaje de commit `type(scope): summary`.

Una entrada de memoria registra algo que el agente ha aprendido, que no resulta evidente a partir del código y que las ejecuciones futuras deberían saber:

### 2026-08-21, plan #412

El módulo de facturación en `src/billing/` no tiene tests. Añade tests antes de refactorizarlo.
`pnpm test` ejecuta primero las migraciones de la base de datos; una ejecución tarda unos cuatro minutos en una copia limpia.

Ambos archivos difieren en su naturaleza. El programa establece qué hacer. La memoria describe qué es cierto sobre este repositorio. Mantenerlos separados permite a un revisor aceptar un nuevo dato fáctico sin necesidad de aceptar un cambio en el procedimiento, y viceversa.

El bucle de ejecución

Cada ejecución de un promptware sigue los mismos cuatro pasos.

Cargar el programa. El agente lee Program.md y los permisos configurados en Tools/. Nada fuera de esos permisos estará disponible para él.
Leer la memoria. El agente lee Memory/ para que los hechos aprendidos en ejecuciones previas estén presentes en el contexto antes de comenzar.
Ejecutar la tarea. El agente realiza el trabajo de la etapa: redactar un plan, detallarlo, ejecutarlo en un worktree o abrir un pull request. Cada llamada a herramientas y su salida correspondiente se añade a Logs/.
Reflexionar y escribir de vuelta. El agente compara lo que ocurrió con lo que el programa le indicaba que debía esperar. Los hechos nuevos se guardan en Memory/. Si una instrucción era incorrecta, faltaba o era redundante, el agente revisa Program.md.

El ciclo de actuar, observar el resultado y revisar la siguiente instrucción coincide con el patrón que describe el artículo sobre ReAct para agentes de razonamiento; un promptware se diferencia principalmente en que la revisión se escribe en un archivo que perdura más allá de la ejecución. Este cuarto paso es lo que hace que las instrucciones mejoren con el tiempo en lugar de degradarse. También es el paso que requiere mayor supervisión, como se explica en la sección sobre riesgos.

Los promptwares integrados

Ivy Tendril incluye siete promptwares integrados, uno para cada etapa del ciclo de vida descrito en del issue de GitHub al pull request. Cada uno cuenta con su propio programa, memoria, permisos y registros.

CreatePlan transforma una idea, un issue de GitHub o un reporte de error en un borrador de plan: objetivo, alcance, archivos afectados y pasos de verificación.
ExpandPlan añade detalles a un borrador que carece de información suficiente para ser ejecutado, como criterios de aceptación faltantes o decisiones de diseño sin resolver.
UpdatePlan reescribe un borrador en respuesta a los comentarios insertados en línea por el desarrollador.
SplitPlan divide un plan cuyo alcance ha crecido demasiado en varios planes más pequeños que se pueden ejecutar en paralelo.
ExecutePlan ejecuta el plan aprobado con el agente de código elegido (Claude Code, Codex CLI, Copilot CLI, Gemini CLI, OpenCode o cualquier agente por CLI) dentro de un git worktree aislado. Las mejores prácticas de Claude Code de Anthropic defienden con los mismos argumentos el uso de archivos de instrucciones versionados que este artículo sostiene para Program.md.
CreatePr abre el pull request una vez que el diff ha superado la verificación automatizada y la revisión humana.
CreateIssue crea un issue en GitHub a partir de una recomendación o un hallazgo surgido durante la ejecución.

Dado que cada unidad es independiente, la memoria de CreatePlan (por ejemplo, «el equipo exige que los planes nombren los archivos de test que van a modificarse») no se comparte con ExecutePlan, y el permiso de ExecutePlan para ejecutar comandos de terminal no se otorga a CreatePlan. La documentación de promptwares detalla el contenido por defecto de cada unidad.

Instrucciones versionadas y los dos riesgos

Por qué los archivos en el repositorio superan a los prompts ad hoc

Un prompt improvisado en una ventana de chat existe una sola vez, para una sola persona, y desaparece en cuanto termina la sesión. Un archivo Program.md guardado en el repositorio aporta cuatro ventajas de las que carece un prompt efímero:

Revisión. Un cambio en el programa se convierte en un diff dentro de un pull request. Un ingeniero sénior puede rechazar una instrucción como «omitir tests si el cambio es pequeño» antes de que afecte a futuras ejecuciones.
Diff. Cuando la calidad del resultado varía, git log en el directorio del promptware revela exactamente qué instrucción cambió y en qué momento.
Rollback. Una modificación defectuosa se revierte con un simple commit.
Compartición. Todos los desarrolladores del equipo, y cada ejecución del agente, utilizan las mismas directrices. Una convención aprendida en una ejecución el lunes la aprovechan todos el martes.

Este es el mismo principio que motivó el paso de la infraestructura configurada manualmente a código bajo control de versiones, y el mismo fundamento de separar la configuración del código en The Twelve-Factor App; se sostiene exactamente por los mismos motivos. Otras formas de estructurar el trabajo de los agentes y su comparación con el promptware se analizan en patrones de orquestación de agentes para desarrollo de software.

Riesgo 1: deriva de instrucciones (instruction drift)

Un agente con permisos para editar su propio programa también puede empeorarlo. Una ejecución que falle debido a un test inestable (flaky) podría añadir la directriz «reintentar los tests fallidos hasta tres veces», lo que ocultará un problema real en la siguiente ocasión. Dos factores mitigan este riesgo. Primero, el programa es un archivo versionado, por lo que cualquier ajuste es un diff visible que el revisor puede evaluar y revertir. Segundo, Logs/ registra la ejecución concreta que motivó el cambio, permitiendo comprobar si el razonamiento fue correcto antes de aprobarlo.

Riesgo 2: sobrecarga de memoria (memory bloat)

Una memoria que no deja de crecer se convierte en un coste sin beneficio añadido. Un archivo con 400 entradas, la mitad de ellas obsoletas, consume tokens en cada ejecución y dificulta que el modelo encuentre los datos verdaderamente útiles. Dos prácticas la mantienen eficiente: Asignar fecha y alcance a cada entrada, como se muestra en el ejemplo anterior, para localizar rápidamente las notas desactualizadas. Podar durante la revisión: cuando un plan toca un área del código, el revisor inspecciona las entradas de memoria vinculadas y elimina aquellas que ya no sean válidas. El seguimiento de costes y tokens por plan y por tarea visibiliza este crecimiento, ya que una unidad con memoria saturada mostrará un incremento en tokens sin un aumento proporcional en el tamaño del plan — motivo por el cual la medición del rendimiento de agentes de código rastrea el coste por pull request fusionado en lugar de por ejecución individual.

Cómo empezar

Instala Ivy Tendril, abre un repositorio y crea un plan. Los siete promptwares integrados están disponibles desde la primera ejecución.

curl -sSf https://cdn.ivy.app/install-tendril.sh | sh

En Windows, utiliza irm https://cdn.ivy.app/install-tendril.ps1 | iex. Lee los archivos Program.md antes de iniciar una ejecución y revisa las primeras entradas de memoria y ajustes del programa con el mismo rigor que aplicarías a un cambio en el código fuente. Tras completar unos diez planes, la memoria reflejará aquellas áreas de la base de código donde el agente encontró dificultades, que casi siempre coinciden con los puntos donde un desarrollador humano también dudaría. La documentación de promptwares contiene más detalles sobre las unidades integradas.

Preguntas frecuentes

¿El agente modifica Program.md sin preguntar?

El agente revisa su programa al concluir una ejecución. Dado que Program.md es un archivo versionado, la modificación es un diff que puedes inspeccionar, aceptar o revertir, y el registro de la ejecución que lo motivó queda guardado junto a él.

¿Puedo crear mis propios promptwares?

Las siete unidades integradas cubren las etapas principales del ciclo de vida. Sus programas, memorias y permisos de herramientas son archivos de texto sin formato, por lo que puedes editarlos libremente para adaptarlos a las convenciones de tu equipo. Consulta la documentación para conocer las opciones de extensión vigentes.

¿Dónde se almacenan la memoria y los registros?

En la propia máquina que ejecuta Tendril. No se envían ni suben a los servidores de Ivy. Las únicas llamadas de red que realiza Tendril son hacia la API del LLM que hayas configurado y hacia GitHub.

Primeros pasos con Ivy Tendril

¿Listo para la orquestación paralela de agentes a nivel de desarrollador?

Explora el código: Conoce Ivy Tendril en GitHub (Código abierto).
Consulta la documentación: Encuentra guías de integración en tendril.ivy.app.
Agenda una sesión técnica: Contacta a renco@ivy.app para una consulta de arquitectura de 30 minutos.

Promptware: agentes que conservan y mejoran sus propias instrucciones