Especificación
Permisos
Inyección
Exportar
Anatomía
Verificación
Afirmaciones
Evals
Prompt
Elementos completados: 0/6ObjetivoQué cambiaQué NO cambiaRestriccionesDecisionesCriterios
Texte & documents
Nombres & calcul
Données & formats
Sécurité
Développement & DevOps
Intelligence artificielle
Finances
Santé et bien-être
Productivité
Jeux et divertissement
Multimédia & design
Entreprise
Guide d'utilisation
Los dos rombos son lo único que decide
Quita el nombre del framework y todo agente son los mismos siete componentes en bucle. Y lo interesante no son las cajas: son las dos preguntas —¿puedo contestar ya? y ¿objetivo cumplido?—, los únicos sitios donde el agente decide algo. El resto es fontanería. Cuando un agente se porta mal, el fallo casi siempre está en cómo se especificaron esas dos, no en el modelo razonando.
Los guardarraíles van en vertical, no en la puerta
Se consultan antes de cada acción, no una vez al empezar. Una puerta a la entrada no dice absolutamente nada de lo que el agente decida hacer en el paso cuatro — y el paso cuatro es donde están los problemas.
Trazar no es evaluar
Una traza te dice qué hizo el agente; no si lo que hizo era correcto. Por eso la pestaña de verificación mide sobre ella cosas que no necesitan modelo: vueltas, bloqueos, fallos de los que se recuperó y repeticiones sin motivo, que es como se ve un ciclo. Lo determinista va primero; el juez con modelo se reserva para lo que de verdad exige criterio.
Por qué una especificación y no un prompt
Un prompt dice cómo se comporta el agente. Una especificación dice qué debe pasar: qué cambia, qué no cambia, qué contratos se respetan y qué evidencia hace falta para dar algo por bueno. Son artefactos distintos y la spec va por encima: sin ella, el prompt más cuidado sigue sin decir cuándo la tarea está terminada.
«Qué NO debe cambiar» es la mitad que falta
Es el campo que casi nadie rellena y el único que acota de verdad. Sin él, un agente puede cumplir el objetivo rompiendo cualquier otra cosa y seguir teniendo razón: nadie le dijo que eso también importaba. Por eso aquí es un error y no un aviso.
Criterios: ejecutables, binarios e independientes
Un buen criterio es un comando que se puede correr, da pasa o no pasa —«razonablemente rápido» no lo es— y comprueba una sola cosa, para que al fallar se sepa cuál. Escritos así se traducen casi 1:1 a casos de prueba, que es de lo que se trata.
Un modelo no distingue instrucciones de datos
Le llega un solo texto. Si dentro de lo que tú creías que era un dato —una página que el agente lee, un documento recuperado, un correo, el README de una dependencia— hay algo con forma de orden, el modelo puede obedecerla. No es un fallo que arregle un modelo mejor: es la forma del problema. Por eso la indirecta es la peligrosa: en la directa el atacante es el propio usuario, pero en la indirecta lo mete un tercero y la víctima eres tú.
El filtro de entrada da falsa seguridad
Es lo primero que pone todo el mundo y lo que menos protege: una lista de frases solo caza las frases que alguien anotó. En el banco de esta pestaña no atrapa ni uno de los ataques disimulados, que son exactamente los mismos ataques escritos de otra manera. Lo que sí los para es la arquitectura: mínimo privilegio, confirmación humana y verificar la salida — o sea, los tres cubos de permisos que ya escribiste al lado.
«Respaldado» no es «cierto»
Esto no dice si algo es verdad: no puede, y ninguna herramienta que corra en tu navegador puede. Dice si una afirmación viene acompañada de una fuente y de qué nivel es esa fuente, que es otra cosa y esa sí se comprueba. La lectura útil va al revés de lo que parece: no busques el sello verde, busca las frases categóricas y sin nada detrás, que suenan igual de seguras que las demás.
Un arXiv es un preprint, y un DOI no lo salva
Citar un preprint no está mal; presentarlo como si fuera un artículo revisado, sí. Y el matiz que casi nadie hace: un preprint también tiene DOI. El DOI es un registro, no un certificado de revisión — por eso 10.48550/arXiv.… aquí sale como preprint y no como fuente formal.
Una aserción que no puede fallar no es una aserción
Es el fallo que arruina un banco de evals, y es silencioso: un contiene vacío pasa siempre, una regex como .* pasa siempre, un caso sin aserciones pasa siempre. Un banco lleno de esas da 100% el primer día, no vuelve a bajar nunca y no ha medido nada en su vida. Por eso aquí el banco se revisa a sí mismo antes de dar ningún porcentaje.
El número total no es lo accionable
Que un banco pase del 80% al 78% no dice qué hacer. Lo que se arregla es el caso concreto que pasaba y ha dejado de pasar. Por eso se guarda una pasada de referencia y se comparan las dos. Y si el banco cambió a la vez que el modelo, los casos que solo están en una de las dos salen aparte: esa comparación no compara nada, y más vale verlo que creérsela.
No inventamos formato
Se exporta a lo que ya leen los agentes: un SPEC.md suelto, los tres ficheros de Kiro (requirements, design, tasks), un CLAUDE.md con lo permanente, o los tres cubos de permisos. Los ficheros valen más que la herramienta que los genera: por eso no te atamos a ella.
