Si un agente resolvió el mismo problema cincuenta veces, ¿por qué sigue razonando? Hora de volverlo código
Los mejores agentes autónomos deberían volver innecesarias partes de sí mismos. Cinco preguntas deciden cuándo una tarea repetida debe ser un playbook probado y cuándo pagar el razonamiento.
Escuche este artículo · 5 min
Narración completa del artículo, generada con IA.
Dos relatos de ingeniería publicados el 13 de octubre llegan a la misma idea desde direcciones opuestas.
En Azure Networking, de Microsoft, un agente de guardia investiga incidentes de producción, y cuando un camino de razonamiento funciona suficientes veces se convierte en un playbook determinista que se ejecuta sin llamar al modelo. “El agente se convierte en un mecanismo para descubrir problemas nuevos, no en un impuesto permanente sobre los viejos.” Analizamos ese diseño en el agente de red de Microsoft.
En Google, Gemini 4 Argon pasó una noche explorando un código de 205.000 líneas y propuso seis optimizaciones. Los ingenieros se quedaron con dos, y lo que se publicó fue código corriente con pruebas, sin ningún modelo en el camino en tiempo de ejecución. “El agente explora, el mantenedor resta”, resumió el equipo en el relato que analizamos en seis propuestas, dos aceptadas.
En ambos casos, el producto más duradero del agente no fue una respuesta. Fue un software que hizo innecesaria la siguiente respuesta.
La tesis
Nuestra visión, y es una visión, no un hecho medido: un agente autónomo bien gestionado debería volver innecesarias partes de sí mismo con el tiempo. Los agentes son la herramienta adecuada para problemas nuevos, ambiguos o demasiado variados para especificarlos. Cuando un problema deja de ser cualquiera de esas cosas, seguir pagando a un modelo para que razone sobre él es un costo y un riesgo que nadie eligió. Es más lento que el código, más caro por ejecución, más difícil de probar y cambia de comportamiento cada vez que se actualiza el modelo, el problema que planteamos en la retirada de modelos es la nueva obsolescencia de API.
Eso no convierte el razonamiento del agente en un desperdicio. La exploración fue donde apareció el valor. El error es no convertirla nunca.
Cinco preguntas
Para cualquier tarea que un agente realiza de forma repetida, cinco preguntas deciden si se queda con el agente o se convierte en un playbook, una regla, un modelo más pequeño o código corriente.
| Pregunta | Si la respuesta es sí | Si es no |
|---|---|---|
| ¿El mismo camino ha funcionado muchas veces? | Candidata a playbook | Siga razonando; aún es descubrimiento |
| ¿Las entradas tienen un formato estable? | El código puede interpretarlas | Mantenga un paso de modelo solo para interpretar |
| ¿Se puede comprobar mecánicamente el resultado correcto? | Pruébelo como software | Mantenga la revisión humana sobre el agente |
| ¿Un error sería caro o difícil de revertir? | Conviértala antes; el código probado es más seguro | Menos urgencia |
| ¿El entorno cambia más rápido de lo que puede seguirlo el código? | Mantenga el agente; las reglas envejecerían | Conviértala |
La cuarta pregunta va contra la intuición. Los equipos tienden a dejar el trabajo más arriesgado al modelo más capaz. Pero cuando una acción arriesgada tiene un camino correcto conocido, un playbook probado con un control de aprobación es más seguro que un modelo que puede tomar otro camino la próxima vez. La autonomía para acciones con consecuencias es más fácil de justificar cuando la acción es determinista, la lógica que hay detrás de ganarse la autonomía por clase de acción.
Cómo suele ser la conversión
La conversión rara vez elimina del todo el modelo. El resultado habitual es lo que el ingeniero de Microsoft llama “esqueleto determinista, relleno probabilístico”: el código decide y ejecuta, y un paso de modelo se limita a la interpretación que el código no puede hacer, como convertir una salida desordenada en campos tipados que después comprueba un paso de validación. El diseño de cuentas por pagar de Snowflake tomó una decisión parecida, manteniendo determinista lo que debe ser determinista alrededor de las partes que necesitan un modelo. Donde sigue habiendo una decisión pero no hace falta generar texto, un modelo de decisión calibrado puede sustituir a un modelo de frontera por una fracción del costo.
Convertirlo en una práctica
Tres hábitos lo convierten en rutina y no en excepción:
- Registre los caminos de razonamiento, no solo los resultados. No se puede convertir un patrón que no se ve. Guarde qué herramientas llamó un agente, en qué orden y con qué resultado, para poder encontrar los caminos repetidos.
- Revise el historial del agente como un backlog. Una vez al mes, enumere los caminos de éxito más frecuentes y pase cada uno por las cinco preguntas. Cada conversión es un cambio, escrito a partir del historial del agente y aprobado por un ingeniero, con pruebas y rollback.
- Devuelva los fallos. Cuando un playbook se encuentre un caso que no cubre, envíelo al agente como problema nuevo. El ciclo entre descubrimiento y rutina es el sistema.
De ahí sale una métrica útil: la proporción del trabajo del agente del trimestre pasado que hoy se ejecuta como software. Si es cero, el agente no está aprendiendo nada que la organización conserve. Si sube de forma constante, el agente está haciendo su trabajo más valioso, que es encontrar el trabajo que ya no lo necesita.