Aprenda a construir y operar agentes de IA

Casi todos los agentes, cualquiera que sea la estructura que los produjo, se ensamblan a partir del mismo puñado de piezas. Aprender a diferenciarlos es la mayor parte de la depuración, porque las fallas se localizan claramente a lo largo de ellos.

El modelo es el motor del razonamiento. Lee el estado actual y decide qué sucede a continuación. La elección del modelo es una verdadera decisión de ingeniería más que una decisión predeterminada: un modelo más grande se sostiene mejor bajo instrucciones ambiguas, uno más pequeño cuesta una fracción y responde más rápido. Los agentes maduros suelen utilizar más de uno, reservando el modelo caro para los pasos que realmente necesitan juicio.

Las instrucciones, generalmente entregadas como un aviso del sistema, son un contrato más que una personalidad. Establecen el rol, las limitaciones, el formato de salida y, sobre todo, la definición de hecho. Las instrucciones vagas son la causa más común de que los agentes deambulen en círculos o se detengan a medio camino.

El contexto es todo lo que el modelo puede ver durante este paso en particular: la tarea en sí, los registros que recuperó, los resultados de llamadas anteriores a herramientas. Trátelo como un presupuesto más que como un contenedor. Cada token gastado en material irrelevante cuesta dinero, agrega latencia y diluye la atención del modelo en la única línea que realmente importa.

La memoria es lo que sobrevive entre pasos y entre carreras. La memoria a corto plazo suele ser sólo la transcripción en ejecución. La memoria a largo plazo es un acto deliberado: un resumen que persiste, un registro de decisiones pasadas, un perfil del usuario. Al combinar los dos, los agentes terminan amnésicos entre sesiones o ahogándose lentamente en su propia historia.

Las herramientas son el espacio de acción, las funciones escritas que el agente puede llamar. Sus nombres y descripciones son parte del mensaje, porque el modelo selecciona una herramienta leyéndolos. Una herramienta llamada ProcessData sin descripción será mal elegida y se le echará la culpa al modelo.

El paso de decisión es el momento en que el modelo emite una llamada a la herramienta con argumentos o una respuesta final. Todo lo anterior existe para tomar bien esa decisión.

La ejecución es el tiempo de ejecución: el componente que realmente invoca la herramienta, impone límites de bucle y reintento, adjunta credenciales, maneja errores y registra lo sucedido. Los marcos te entregan las partes de razonamiento. El tiempo de ejecución es lo que hace que el resultado sea seguro para mostrarlo a otras personas.

Montado, el ciclo dice: observar el estado, elegir una acción, ejecutarla, observar el resultado, repetir. Cuando algo va mal, el síntoma suele apuntar a una parte. Una respuesta claramente incorrecta normalmente carece de contexto. Una acción inapropiada suele ser una mala descripción de la herramienta. Una carrera que nunca termina normalmente es una definición que falta de hecho.

Un agente es tan capaz como las acciones y la información que le entrega. Aquí es donde vive la mayor parte de la ingeniería práctica.

Diseñar herramientas para que sean estrechas y con forma de verbo. Una herramienta que lee los pedidos de los clientes supera a otra que gestiona la base de datos. Las herramientas estrechas producen decisiones claras, son fáciles de autorizar y fallan de maneras que se pueden interpretar. Las herramientas amplias invitan al modelo a improvisar, y la improvisación es lo que duele.

Escribe la descripción del modelo, no de tus compañeros. Debe decir qué hace la herramienta, cuándo usarla, cuándo no usarla y qué devuelve. Escriba los argumentos y valídelos. Un esquema aquí no es burocracia, es la diferencia entre una llamada rechazada y una escritura con formato incorrecto en un sistema de producción.

Resístase a agregar herramientas de manera especulativa. La calidad de la selección se degrada a medida que crece el espacio de acción: con treinta herramientas disponibles, el modelo dedica su razonamiento a elegir en lugar de a la tarea, y elige mal con más frecuencia. Si dos herramientas se superponen, combínelas o elimine una.

El contexto debe recuperarse, no descartarse. Obtenga los registros específicos que esta tarea necesita y páselos. Cuando la fuente sea grande, divídala con sensatez y recupérela por relevancia en lugar de pegar todo el documento. Solicite las citas para poder rastrear la respuesta hasta el pasaje que la produjo.

Separar la lectura de la escritura. La mayoría de los agentes necesitan un acceso de lectura amplio y un acceso de escritura muy limitado, y tratarlos como un solo permiso es la forma en que un agente de resumen termina siendo capaz de eliminar registros. Cuando una escritura sea irreversible, coloque un humano delante de ella.

En las integraciones es donde esto se convierte en un problema organizacional en lugar de uno de codificación. Cada equipo que conecta su propia conexión al mismo sistema ascendente produce credenciales duplicadas, políticas inconsistentes y ningún rastro de auditoría único. Un estándar abierto como MCP permite que cualquier agente compatible reutilice las mismas integraciones gobernadas, con un enlace por sistema ascendente en lugar de uno por equipo.

Las credenciales merecen su propia regla, y es breve: el agente nunca guarda un secreto. Solicita la acción y la plataforma adjunta la credencial en el momento de la llamada saliente. De esa manera, un mensaje filtrado, un registro detallado o una transcripción compartida nunca se convierten en una clave filtrada.

Finalmente, planifique el fracaso parcial. Los sistemas reales limitan la velocidad, paginan, agotan el tiempo y devuelven media respuesta. Un agente que trata cada respuesta de la herramienta como un éxito no se basará en nada. Devuelve los errores como datos estructurados sobre los que el modelo puede razonar y decide de antemano qué fallos deberían detener la ejecución en lugar de solucionarlos.

Un agente que sólo se ejecuta en la máquina donde fue escrito es un prototipo. El empaque es lo que lo convierte en algo que otra persona, equipo o entorno puede ejecutar sin hacerle preguntas.

Comience con la reproducibilidad. Fije sus dependencias en lugar de aceptar lo que resuelva la última versión. Escriba las entradas y salidas con un esquema para que las personas que llaman sepan exactamente qué enviar y qué devolver. Mantenga la configuración fuera del código, para que el mismo artefacto pueda ejecutarse en la etapa de preparación y producción sin necesidad de editarlo.

Sea explícito sobre lo que no debe viajar con él. Secretos, obviamente, pero también puntos finales específicos del entorno, identificadores de cuentas codificados y rutas absolutas. Si el agente no puede comenzar sin un valor, debería fallar ruidosamente al inicio indicando qué valor falta, en lugar de hacerlo a la mitad de la ejecución.

Declare el contrato que el agente necesita para trabajar: qué herramientas espera, qué permisos requieren esas herramientas, qué modelo asume y cuánto cuesta aproximadamente por ejecución. Un revisor debería poder decidir si lo aprueba únicamente a partir de esa declaración.

Versionelo como software, porque eso es lo que es. Manténgalo en Git, apunte a una versión específica en lugar de una rama, diferencie dos versiones para ver qué cambió en el mensaje y en el código, y pueda retroceder en un comando cuando un cambio resulte ser peor de lo que parecía.

Envíe el conjunto de evaluación con el agente. Es la única descripción honesta de lo que se supone que debe hacer el agente y permite a quien la hereda verificar que su entorno se comporta como el suyo antes de confiar en el resultado.

Finalmente, escriba los límites en un lenguaje sencillo: para qué sirve este agente, qué no debe hacer nunca, quién es el propietario y qué hacer cuando falla. Esa nota cuesta diez minutos y marca la diferencia entre un agente adoptado y uno que es abandonado silenciosamente.

Un agente es un proyecto. Treinta agentes es un problema de operaciones y llega antes de lo que la mayoría de los equipos esperan, generalmente sin que nadie decida que debería ser así.

El cambio es más cualitativo que cuantitativo. Con un agente recuerdas lo que hace. Con treinta, repartidos en equipos, cada uno de los cuales eligió su propio marco, nadie tiene el panorama completo y las preguntas que importan se vuelven sin respuesta: qué se está ejecutando, quién es el propietario, qué puede tocar, qué hizo y cuánto nos está costando.

El inventario es lo primero, porque de él depende todo lo demás. Cada agente lleva consigo una identidad, un propietario y una versión, sea lo que sea que lo haya producido. Los agentes creados fuera de la plataforma se catalogan en los mismos términos que los creados en ella, que es la única forma en que el inventario se mantiene honesto.

El control se aplica de forma centralizada y se hace cumplir de manera uniforme. Un equipo de plataforma establece una política una vez y el tiempo de ejecución la aplica a los agentes de cada equipo en el momento de la acción. Este es el acuerdo que resuelve el enfrentamiento habitual entre ingeniería, que no quiere pedir permiso para cada agente, y seguridad, que no puede aprobar lo que no puede ver.

La observabilidad a escala de flota significa más que la retención de registros. Los seguimientos te permiten reproducir cualquier ejecución individual. Un registro de auditoría inmutable registra al usuario activo, las credenciales utilizadas y los resultados producidos. La puntuación de las evaluaciones se ejecuta continuamente según los criterios que usted define, cubriendo comportamiento, estructura, latencia y costo, y una verificación crítica fallida detiene al agente en lugar de presentar un informe al respecto. Ése es el paso del registro pasivo al control activo de la calidad.

El costo es la dimensión que los equipos descubren en último lugar y la que más lamentan. El gasto atribuido por agente, espacio de trabajo, usuario, proveedor y modelo, en moneda en lugar de tokens, convierte una factura inexplicable en una lista de decisiones. Los presupuestos de disyuntores lo hacen entonces procesable: avisar al ochenta por ciento, bloquear al cien y detener el exceso en lugar de informarlo después. Las alertas te avisan; sólo un interruptor detiene realmente el gasto.

Una vez que los costos son visibles, se pueden reducir de manera sistemática y no anecdótica. La optimización funciona a través de cuatro palancas: probar un modelo más pequeño, recortar las indicaciones y el contexto, eliminar herramientas que agregan costos sin mejorar los resultados y trasladar pasos deterministas del modelo al código ordinario. Cada recomendación se compara con sus propias evaluaciones antes de aplicarla, por lo que los ahorros nunca se compran silenciosamente con calidad.

Las integraciones se rigen de la misma manera central. Un enlace por sistema ascendente, un catálogo aprobado que los equipos pueden solicitar y un único registro de auditoría en todo ello, en lugar de que cada equipo establezca su propia conexión y su propia copia de las credenciales.

La coordinación se convierte en una preocupación real a escala. Los agentes se reparten trabajo entre sí, se duplican cuando dos equipos resuelven el mismo problema de forma independiente y compiten por los mismos límites de tarifas. Un catálogo compartido con agentes y habilidades reutilizables es la solución más barata para la duplicación, y también es lo que hace que el primer agente de un ingeniero se envíe en horas en lugar de semanas.

Finalmente, trate la flota como si tuviera un ciclo de vida. Los agentes son promovidos del experimento a la producción, quedan obsoletos cuando existe uno mejor y se retiran cuando su tarea desaparece. Medir la adopción por equipo, el costo por agente y el desempeño en comparación con las evaluaciones es lo que lleva la conversación más allá de contar experimentos y hacia operar con IA en lugar de simplemente usarla.