Cada vez me convenzo más de que el enfoque de la herramienta Unix, que consiste en tener un conjunto de unidades funcionales enfocadas y componibles que pueden usarse de forma aislada o como parte de una pipeline más amplia, es también el mejor enfoque para herramientas para codificar agentes. El problema de intentar crear un sistema grande y unificado que lo haga todo es que cada persona tiene sus propios flujos de trabajo y formas de desarrollar, y normalmente es demasiado difícil intentar hacer un proyecto único que pueda acomodar eso sin que se convierta en una complejidad enorme que no funciona bien en la práctica. Así que tengo una herramienta para el correo de agentes, una para la gestión de tareas (las cuentas de Steve Yegge), una herramienta para la selección de tareas (bv), una herramienta para búsqueda de historial pasado (cass), una herramienta para el linting poliglota y detección de bugs (ubs), una para manejo de comandos sensibles (slb), una para gestionar tmux y sesiones de agente (ntm), una para memoria (csm), etc. Y puedes usar uno, algunos o todos. Y están parcialmente integrados entre sí, pero siempre de forma opcional. Así que SLB puede usar Agent Mail si lo tienes configurado, pero también funciona de forma independiente. Y NTM puede mostrar información de BV pero no está forzado. Se convierten en pequeños bloques de Lego que puedes usar para montar el sistema que quieras, y se vuelve fácil crear tus propias herramientas para añadir la funcionalidad que quieres. Y entonces tu archivo md dot de AGENTS se convierte en una especie de sistema operativo donde "instalas" las herramientas en la memoria de trabajo del agente y las configuras describiendo cómo, cuándo y por qué usarlas (curiosamente, ahora tienes que preocuparte por convencer a la máquina para que use las herramientas). Así que puedes tener todas tus herramientas configuradas en tu máquina pero solo activar las específicas según el proyecto, incluyendo solo los resúmenes relevantes que explican las herramientas que quieres usar.