Trabajar con agentes
Esta es la parte de Eidos que peor se lee, normalmente como una limitación esperando a levantarse. No lo es. Es la restricción sobre la que se construye el resto del estándar.
Por qué existe la restricción
Sección titulada «Por qué existe la restricción»Porque una spec es un control sobre el código, y un control solo es un control si viene de otro sitio.
Deja que un agente escriba la spec y luego el código, y esa independencia desaparece. Satisface su propia spec. Cuando se le pregunta si el código está bien, compara el código con el documento que él mismo produjo. Todo concuerda, todas las revisiones pasan y no se ha verificado nada: que dos salidas del mismo proceso se corroboren no te dice nada sobre ninguna.
Un agente puede producir una spec que parece correcta. Tendrá un párrafo de intención, criterios de aceptación plausibles y una sección de no-objetivos con tres entradas razonables. Se leerá bien. Y codificará decisiones que nadie tomó.
El fallo no es que el contenido esté mal; a menudo está bien. El fallo es que carga con la autoridad de estar escrito, versionado y revisado, sin que nadie haya decidido nada de verdad. Seis meses después alguien construye contra AC4, y la respuesta honesta a «¿quién decidió esto?» es nadie.
El valor de una raíz está enteramente en que una persona la respaldó. Quita eso y tienes un documento que parece una fuente de verdad y no lo es, que es peor que la reunión que intentabas evitar.
Qué sí hace un agente
Sección titulada «Qué sí hace un agente»Mucho, y todo ello trabajo real:
Formatea. Genera el frontmatter a partir del Schema, aplica el shape, mantiene
nombres y enlaces dentro de la convención, arregla el YAML que rompió un [
inicial.
Complementa. Rellena lo que se sigue mecánicamente de lo que dijiste, y saca a la luz lo que un shape pide y tú no has cubierto.
Pregunta. Donde eres vago, pregunta. No rellena el hueco con prosa plausible. Este es el comportamiento que hay que premiar: la respuesta correcta a una pregunta aclaratoria es una respuesta, no un «decide tú».
Presiona sobre el alcance. Aprieta más fuerte en la sección de no-objetivos, porque es donde se sostiene el alcance.
Valida. Comprueba el frontmatter contra el Schema de tu Framework, informa de las secciones de cuerpo que faltan contra el flavor del Blueprint, y confirma que no se coló ningún campo de seguimiento de trabajo.
Cómo se espera que opere un agente
Sección titulada «Cómo se espera que opere un agente»Cuatro instrucciones de la propia sección de agentes del estándar, y vale la pena conocerlas porque te dicen qué esperar:
Encuentra el Framework en la raíz
Sección titulada «Encuentra el Framework en la raíz»Localiza una raíz por su marcador _eidos/, no por el nombre de su carpeta.
Toda operación lee ese _eidos/. Nunca recurras a un contrato grabado a fuego, y
nunca des por supuesto el nombre de una colección o una sección: lee lo que
declara el Framework.
Si una carpeta no tiene _eidos/, ofrece install.
Lee al actor primero
Sección titulada «Lee al actor primero»_eidos/me.md, y luego el archivo de rol que nombra. Responde como define ese
archivo el rol: léelo, no lo infieras por su nombre de archivo. Un Framework
define su propio reparto.
Más →
Navega por las hojas
Sección titulada «Navega por las hojas»README.md para orientarte, _eidos/Framework.md para el índice completo, el
index.md de cada colección para sus Blueprints. Lee estos en lugar de rastrear
el árbol, y regenéralos cuando estén desactualizados.
Saca a la luz, no bloquees
Sección titulada «Saca a la luz, no bloquees»La salida de la validación es una revisión sobre la que actúa una persona, no una barrera. Una propiedad central que falta se saca a la luz y se añade con una nota sobre el porqué. Una sección que falta se anota y se ofrece. Nunca rechaces el archivo.
Validar un Blueprint
Sección titulada «Validar un Blueprint»Lo que hace de verdad una comprobación:
- El frontmatter contra el Schema del Framework:
iden kebab-case, fechas comoYYYY-MM-DD, propiedades personalizadas acotadas a la colección correcta. - Las secciones de cuerpo que faltan contra el shape del flavor del
Blueprint: a un Blueprint en
micronunca se le reprochan las secciones defull. - Una sección de no-objetivos ausente señalada la primera entre las que faltan.
- Cualquier cosa que se salte el etiquetado que pide el shape.
- Ningún campo de seguimiento de trabajo.
Conseguir buenos resultados
Sección titulada «Conseguir buenos resultados»Define tu actor. Dos minutos con whoami cambian todas las respuestas
posteriores. Saltárselo es la razón más común de que la gente encuentre al agente
mal calibrado.
Contesta a las preguntas. Cuando pregunte si reanudar entre cuentas está en el alcance, la respuesta es sí o no, no «¿tú qué crees?». Tú eres quien tiene el contexto que lo hace decidible.
Trae el pensamiento; deja que él traiga la estructura. Habla de la unidad
como se la explicarías a un colega. En bruto está bien: para eso existe format,
para remodelar un volcado mental hacia el shape preservando tus propias palabras
y sin añadir nada.
Frénalo cuando se desvíe. Si produce algo que tú no dijiste, dilo. Su trabajo es sostener tu intención, no mejorarla.