En marzo, Andrej Karpathy dejó a un agente correr alrededor de 700 experimentos de entrenamiento en su GPU durante dos días. El agente modificaba el código, medía el resultado, se quedaba con lo que mejoraba y tiraba lo que no. Sin que nadie lo supervisara turno por turno.
El número llamó la atención de todo mundo. Lo que casi nadie miró es por qué eso pudo correr solo sin convertirse en un desastre, y esa parte sí es copiable a cualquier agente de negocio.
No fue que el modelo fuera mejor. Fueron cuatro restricciones de diseño. Abajo están las cuatro, traducidas a trabajo de empresa, y la plantilla completa para pegar en tu propio agente.
Guardrail 1 — el agente puede calificar su propio trabajo
Cada cambio se medía contra el mejor resultado que llevaba hasta ese momento. Mejor, se queda. Peor, se descarta. No había opinión de por medio.
Esta es la condición que decide si un trabajo se puede delegar o no. Si una IA no puede distinguir un buen resultado de uno malo, no puede correr sola. Punto. Todo lo demás —mejor modelo, mejor prompt, más herramientas— no arregla eso.
En una operación real el criterio casi nunca es un número tan limpio, pero casi siempre existe alguno: la cotización cuadra con la lista de precios vigente, el correo tiene los cuatro datos que el cliente pidió, el registro del CRM tiene teléfono válido y etapa asignada, el reporte suma lo mismo que la fuente. Si al escribirlo no te sale nada verificable, esa tarea todavía es tuya.
Guardrail 2 — todo cambio es reversible
Una mala idea nunca rompió nada porque siempre había cómo deshacerla. Eso es lo que permite equivocarse 680 veces y quedarse con las 20 buenas.
La traducción práctica: el agente trabaja sobre copias, en borrador, o sobre un estado versionado. Nada de escribir directo sobre el registro bueno. En la práctica esto se ve como escribir en una columna nueva y no encima de la vieja, dejar el correo en borradores en vez de enviarlo, crear una rama en vez de tocar la principal, o guardar el archivo nuevo junto al original en vez de reemplazarlo.
Es la restricción más barata de implementar y la que más gente se salta por prisa.
Guardrail 3 — no cambia sus metas ni su criterio de evaluación
El agente optimizaba dentro de un objetivo que le pusieron. No podía reescribir qué era ganar ni cómo se medía.
En negocio esto falla de una forma muy concreta y muy común: le pides al agente que mejore un indicador y encuentra el atajo. Le pides que suba la tasa de respuesta y empieza a mandar asuntos sensacionalistas. Le pides que cierre tickets y los cierra sin resolver. No está haciendo trampa —está haciendo exactamente lo que le pediste, y eso es peor.
El criterio de éxito y la definición de la tarea son tuyos y no se tocan. Si el agente cree que el criterio está mal, que lo diga y se detenga, no que lo ajuste.
Guardrail 4 — no consigue recursos nuevos por su cuenta
El agente no salía a pedir más cómputo, ni a instalar lo que se le antojara, ni a expandir su propio alcance.
Traducido: lista cerrada de herramientas, lista cerrada de sistemas que puede tocar, tope de gasto, tope de tiempo. Un agente sin techo de consumo puede quemar en una tarde lo que un chat consume en un mes, y ese es el escenario que más seguido veo cuando alguien pasa de chat a agente sin cambiar nada más.
La plantilla
Pega esto arriba de las instrucciones de tu agente y llena los corchetes. Sirve igual en un prompt de sistema, en un archivo de instrucciones o en la configuración de la herramienta que uses.
# GUARDRAILS — no negociables
## 1. Criterio de éxito
Este trabajo está bien hecho si y solo si:
- [criterio verificable 1]
- [criterio verificable 2]
- [criterio verificable 3]
Antes de dar algo por terminado, verifica cada criterio contra
una fuente y dime cuál usaste. Si no puedes verificar uno,
dilo explícitamente en vez de asumirlo.
No inventes criterios adicionales ni relajes estos. Si crees
que el criterio está mal planteado, detente y dímelo — no lo
ajustes por tu cuenta.
## 2. Reversibilidad
- Nunca escribas encima de un dato original. Escribe en
[columna / carpeta / rama / borrador nuevo].
- Antes de cualquier acción que borre o reemplace algo, para
y pídeme confirmación.
- Deja registro de qué cambiaste y dónde estaba antes.
## 3. Alcance
Puedes usar exactamente estas herramientas:
- [herramienta 1] — para [qué]
- [herramienta 2] — para [qué]
Puedes leer de: [sistemas]
Puedes escribir en: [sistemas, con la restricción del punto 2]
Todo lo demás está fuera de alcance. Si necesitas algo que no
está en esta lista, detente y pídemelo. No busques un camino
alternativo para lograrlo.
## 4. Límites de consumo
- Máximo [N] pasos por tarea.
- Máximo [N] minutos de trabajo continuo.
- Si llegas al límite, para y reporta dónde te quedaste. No
entregues algo a medias como si estuviera terminado.
## 5. Cuándo detenerte y preguntar
Detente y pregunta si:
- Hay que gastar dinero o mandar algo a un tercero.
- La acción afecta a un cliente real.
- Dos interpretaciones razonables de la tarea llevan a
trabajos muy distintos.
- Los datos que necesitas no están o se contradicen.
En cualquier otra decisión chica, elige lo razonable, sigue
adelante y anótalo. No me preguntes por nombres de archivo ni
por formatos.
## 6. Reporte
Al terminar, en este orden:
1. Qué quedó hecho.
2. Cada criterio del punto 1 y con qué lo verificaste.
3. Qué cambiaste y dónde está el original.
4. Qué no pudiste hacer y por qué.
No reportes como terminado nada que no hayas verificado.El paso que todo mundo se salta: el punto 5. Un agente sin instrucciones de cuándo detenerse hace una de dos cosas, ambas malas: pregunta por todo y deja de servir, o no pregunta por nada y manda un correo al cliente equivocado. La lista de "detente y pregunta" tiene que nombrar acciones concretas de tu operación, no categorías vagas. "Acciones importantes" no es una instrucción; "antes de enviar cualquier correo a un dominio que no sea el nuestro" sí lo es.
Cómo se ve aterrizado
Caso real de estructura: un agente que limpia y enriquece registros del CRM cada noche.
- Criterio: cada registro tocado tiene teléfono en formato válido, empresa que coincide con el dominio del correo, y etapa asignada de la lista permitida. Los tres se pueden verificar sin opinión.
- Reversibilidad: escribe en campos nuevos con prefijo, nunca encima de los originales. Un humano promueve los buenos después.
- Alcance: lectura del CRM y de la fuente de enriquecimiento. Escritura solo en los campos con prefijo. Sin acceso al correo ni a nada que mande mensajes.
- Consumo: tope de registros por corrida y tope de tiempo.
Con eso puede correr toda la noche sin supervisión. Sin el criterio verificable, no. Y fíjate que la parte difícil no fue configurar el agente: fue escribir las tres reglas de qué es un registro bien hecho, que nadie en la empresa había puesto por escrito nunca.
El error que comete todo el mundo
Empezar por las herramientas. La conversación típica es "¿qué accesos le doy?", cuando la pregunta que decide todo es "¿cómo sé que lo hizo bien?".
Si empiezas por los accesos, terminas con un agente muy capaz corriendo hacia un objetivo mal definido, que es exactamente el escenario que la gente teme cuando dice que no confía en los agentes. La desconfianza no es al modelo. Es a soltarlo sin criterio.
Escribe primero el punto 1 de la plantilla. Si te cuesta trabajo, esa dificultad es la señal: todavía no es momento de automatizar esa tarea.