AI Agents Drift: Identificación y Corrección de Fallos Sutiles

Buenas tardes a todos. Mi nombre es Sam. Soy un ingeniero desplegado en el campo convertido en fundador. Mi trabajo diario gira en torno a la construcción de agentes de producción que están realizando una amplia variedad de tareas en la agricultura. Como estoy seguro de que han escuchado hasta el cansancio hoy, y como estoy seguro de que han visto en línea, la tendencia de las empresas de construir sus propios agentes desde cero ya no es una actividad de nicho. Esto es algo en lo que muchas organizaciones están invirtiendo, y las razones son bastante obvias. Las tecnologías detrás de muchas de estas bibliotecas y plataformas son de código abierto. Son gratuitas. Son muy robustas. Además, es mucho más barato. Sabes, si vas a contratar a una empresa externa para que venga y construya estos agentes desde cero, ese es un costo que tendrás que asumir.

Además, de manera crítica, todo el contexto que tú y tu organización tienen sobre tus productos, la historia de tu empresa, el panorama competitivo, todo eso, vas a necesitar condensarlo y de alguna manera dárselo a este tercero. No es un proceso sin pérdidas. A menudo es mucho mejor simplemente construir estas cosas por tu cuenta.

La otra cara de eso, sin embargo, es que ahora eres responsable de mantener estos agentes, arreglarlos cuando están rotos, mejorar su eficiencia, el tiempo que tardan en hacer las cosas. Esencialmente tienes este nuevo sistema que tienes que depurar. La depuración de agentes es este campo que, creo, está madurando más pero aún es bastante nuevo.

Muchas de las plataformas que la gente usa, todavía son muy jóvenes. El objetivo de esta charla es introducir solo algunas de esas tecnologías, cómo se ven esos bucles de retroalimentación, y luego lo concluiré con algunos de los aprendizajes que encontré en algunas industrias diferentes que podrían ser pertinentes para la tuya también. Nuevamente, solo quiero comenzar con lo que realmente es un agente. Nuevamente, estoy seguro de que has visto esto muchas veces hoy, así que no insistiré en ello.

En su núcleo, un agente es algún tipo de modelo de razonamiento ejecutado en un bucle. Se ejecuta en un entorno, por lo que puedes pensar en esto como la arquitectura en la que realmente se está ejecutando. Tiene herramientas que usará para interactuar con ese entorno. De manera crítica, va a tener contexto sobre, nuevamente, tu negocio, cuál es su tarea.

Y luego, además de todo eso, tendrás algún tipo de evaluaciones u observabilidad, tal vez algunos permisos, seguridad, cosas así. Y al mirar esto inmediatamente, es obvio por qué, potencialmente por qué, la depuración de agentes es tan difícil. Si un agente se comporta mal, ¿es probable que sea el modelo? Probablemente no. Pero, ¿podría una herramienta estar mal configurada? ¿Podría haber un contexto faltante o contradictorio? Tal vez hay algún permiso que está desviado. Todas estas cosas podrían ser lo que está causando el mal funcionamiento o la ineficiencia. Y depende de ti rastrear de principio a fin qué exactamente está sucediendo y por qué.

A menudo hago la analogía de que es similar a este paradigma de errores de tiempo de compilación versus tiempo de ejecución, para aquellos de nosotros que somos ingenieros de software. Cuando tu código se compila, si hay algún error con la sintaxis, si una variable ha sido definida incorrectamente, se te dirá muy claramente, específicamente, dónde está el problema y qué es. Es muy fácil de arreglar. Si hay un error de tiempo de ejecución, si ingresas algún tipo de valor en un formulario y eso causa que toda la aplicación se bloquee, o si incluso algo como la solicitud de red está tardando demasiado, hay demasiada latencia, depurar el porqué es una bestia completamente diferente en sí misma. Y esto es mucho más parecido a lo que es la depuración de agentes en realidad. De hecho, es mucho más cercano a casi una evaluación psicológica de lo que está sucediendo, por qué el agente se comporta de cierta manera y qué puedes hacer al respecto.

Específicamente, ¿a dónde van los tokens? ¿Quién está notando esto primero? ¿Son tus ingenieros? ¿Es algún sistema que has configurado? Es un proceso diferente por sí solo. Para solucionar esto, necesitamos observabilidad de agentes. Necesitamos saber qué está pasando, y tenemos que poder solucionarlo. La mayoría de las bibliotecas de observabilidad de agentes, bueno, no debería decir todas, la mayoría de las que encontrarás en línea, están construidas sobre este protocolo de telemetría abierta. Esto proviene de la ingeniería de sistemas, y se adapta bastante bien al paradigma de los agentes. Esencialmente, cuando instancias un agente y le das una tarea, hasta que muere, eso se considera un rastro. Y luego todos los pasos atómicos intermedios, ya sea una llamada de herramienta, un bucle de razonamiento, todo eso, cada uno de esos se considera un span.

Críticamente, cada span va a tener, obviamente, el modelo o la herramienta que fue llamada. También tendrá el número de tokens que se usaron, por lo que puedes deducir el costo a partir de eso. Tendrá cosas como latencia, todas estas diferentes, o incluso cualquier etiqueta que hayas agregado manualmente. Tendrá una plétora de metadatos para que los examines.

Así que digamos que has instanciado un agente, le has dado una tarea y lo has dejado correr. Ahora tienes todos estos spans en el único trace. ¿Qué haces ahora? Bueno, si el agente que fue instanciado funciona durante tal vez media hora, y solo tienes un par de docenas de spans, puedes leerlo bastante fácilmente, linealmente. Verás los diferentes pasos de razonamiento, todas las herramientas que fueron llamadas. Es bastante fácil deducir qué está pasando y por qué. Obviamente, si hay una llamada de herramienta que tal vez no debería haberse hecho, o hay algún error, al mirar el razonamiento justo antes de eso, en el paso de inferencia de LM, a menudo te dirá un poco sobre por qué.

Llegaremos a algunos ejemplos un poco más tarde. Pero esto es más o menos lo mismo cuando se trata de arquitectura multi-agente también, aunque es un poco más difícil. Si tienes múltiples agentes que están operando en el mismo entorno, todos editando los mismos artefactos, puede volverse bastante desordenado, pero muchas plataformas están trabajando activamente en esto desde una perspectiva de UX.

Ahora, la siguiente pregunta lógica es, bueno, si tenemos un trace que, digamos, un agente ha ejecutado durante tres o cuatro horas, y tenemos decenas de miles de spans, ¿vamos a leer eso linealmente? Probablemente no, ¿verdad? La mayoría de las plataformas tienen este concepto de un chat con tu trace, algún tipo de superposición de LM sobre los datos. Esto se hace ya sea alimentando todos los metadatos del trace como parte de la inferencia, o harán cosas ingeniosas como vectorizar la ejecución del agente, todos los diferentes spans, y luego ejecutar la inferencia sobre eso. De cualquier manera, la interfaz para ti es exactamente la misma. Puedes hacer preguntas muy básicas como, resume esta ejecución, ¿dónde estuvo la concentración de tokens? E incluso puedes hacer preguntas como, ¿qué puedo hacer para mejorarlo? Y muy a menudo, obtendrás respuestas muy detalladas y buenas.

El siguiente paso es imaginar que tienes un agente en producción, ¿verdad? Este no es un agente que está trabajando para ti personalmente. Digamos que tienes uno que está en el entorno. Decenas de miles de ellos están funcionando diariamente. Y quieres encontrar patrones en el comportamiento. Si piensas en un agente y en última instancia cuál es su poder, es extremadamente poderoso en el sentido de que puedes darle diferentes bits de contexto, diferentes entradas, incluso diferentes entornos, y aún así podrá operar con un cierto grado de efectividad. El problema, sin embargo, es que si introduces algún tipo de cambio, digamos que añades contexto, añades una herramienta, y quieres ver si hay un cambio en el comportamiento, no es estadísticamente significativo hacerlo solo para una o una docena de ejecuciones de agentes. Tienes que probar cientos y cientos. Y pasar por esos manualmente para deducir la efectividad no es factible.

Este concepto de un clúster tomará lo que mencioné antes sobre vectorizar una ejecución de agente. Tomará esos vectores y luego verá si hay algún clúster de comportamientos, comportamientos específicos que puedas buscar. Estos podrían ser cosas como el uso ineficiente de tokens. Podría ser algo como un usuario que se agita en el curso de una conversación. Todos estos comportamientos serán detectados y luego podrás analizarlos después del hecho, ver si alguno de ellos tuvo lugar, y luego profundizar en las ejecuciones específicas que puedan estar agrupadas allí. Estos son algunos ejemplos de comportamientos comunes que querrás observar. Muy a menudo los clústeres tendrás que configurarlos tú mismo, por lo que no tendrán una opción solo para agrupar en cualquier comportamiento.

Normalmente serán cosas como, como dije, uso ineficiente de herramientas o uso de tokens, si hay demasiado contexto o si hay muy poco. Y luego también creo que uno importante, como mencioné, es si los usuarios se están frustrando o si generalmente les gusta un agente.

Ahora, el lado opuesto de esto es que algunos comportamientos que los agentes llevarán a cabo, cosas como el alto uso de tokens o digamos comportamiento crítico para la misión, no quieres saberlo después del hecho. No quieres tener estos clústeres de cientos de ejecuciones de agentes que cayeron víctimas del alto uso de tokens.

En cambio, lo que quieres configurar es algún tipo de señal que detecte si una ejecución particular de un agente está exhibiendo alguno de estos comportamientos objetivo y luego te notificará a través de Slack o correo electrónico o lo que sea. El proceso para configurarlos es muy similar a los clústeres anteriores. Defines tu comportamiento y como dije, serás notificado en tiempo real si hay un comportamiento del que quieres saber.

Estas son algunas de las señales de ejemplo que creo que vale la pena configurar. Son muy similares a los clústeres que buscarás, excepto que, como dije, serán más críticas para la misión. Entonces, si es algo que no te importa aprender dos semanas después de que sucedió, probablemente no valga la pena configurarlo como una señal. Solo obtendrás costos más altos. Si es algo que va a ser crítico para la misión, entonces querrás saberlo a medida que sucede.

Y luego, la pieza final que muchas de estas plataformas ofrecerán es este concepto de eval o prueba de cambios. Digamos que has definido algún comportamiento que un agente está haciendo incorrectamente y tienes una posible solución, tal vez falta algún fragmento de contexto. Volviendo a nuestro punto original de asegurarnos de que las soluciones se demuestren de manera estadísticamente significativa, ¿cómo defines que tu solución, tu contexto adicional, realmente resolverá el problema? Aquí es donde entra este concepto de evals. Puedes definir criterios de éxito, que podrían ser algo como una cadena o Booleano o un entero, o muy a menudo podría ser simplemente comportamiento en texto plano.

Y muchas de estas plataformas hacen cosas inteligentes en el back end para probar eso. En última instancia, es solo inferencia LM. El resultado es que defines los criterios de éxito, lanzarás un cierto número de pruebas en paralelo, y luego puedes ver claramente si el cambio que hiciste para una variedad de entradas es exitoso. Esto ayuda con cosas como la depuración. Esto también ayuda con cosas como la optimización. Digamos que se lanza un nuevo modelo y en última instancia va a costar cinco veces el precio del estado del arte actual. ¿Quieres integrarlo? Tal vez sí, pero no si no tiene un gran efecto en la efectividad. Esta es una forma en que puedes probar eso.

De manera similar, creo que una tendencia que realmente me entusiasma en los próximos meses o tal vez el próximo año es este concepto de optimización de costos. ¿Podemos usar modelos más baratos, tal vez incluso de código abierto para hacer el trabajo de modelos propietarios? Y si estás trabajando en una organización que quiere optimizar ese costo, no solo quieres lanzar un modelo de peso abierto en tu agente y hacer algunas pruebas dudosas para determinar si sigue siendo efectivo. Esta es una buena manera de probar con diferentes modelos, ver si realmente te da el resultado que aún deseas.

Sí, un poco más sobre ebals. Así que, ahora sobre algunos de los aprendizajes que he obtenido. La primera parte será que la mayoría de los problemas de comportamiento de los agentes son fundamentalmente problemas de contexto. Típicamente, cuando estás depurando por qué un agente tal vez no seleccionó una herramienta particular para el trabajo o dio un consejo incorrecto a un usuario, se reducirá a algo en su ventana de contexto. Ahora, en muchas de las plataformas que he destacado, en cada punto del bucle de inferencia, puedes seleccionar para ver qué exactamente está en contexto en cualquier momento dado. Típicamente, será demasiado grande para revisarlo tú mismo, pero puedes simplemente ejecutar inferencia sobre él y preguntar, ¿está esta información particular allí?

Y es un gran bucle de desarrollo que tendrás. De manera similar, demasiado contexto también será un gran problema, simplemente volcar todo en tu inferencia es, A, va a contaminar la ventana de contexto. Probablemente obtendrás compactaciones mucho más a menudo. Además, lo que es bastante genial es que las compactaciones también están incluidas en muchas de estas observabilidades, por lo que puedes ver exactamente cómo estas diferentes empresas de LLM, cómo compactaron el contexto, lo cual es bastante interesante. Pero sí, no quieres poner demasiadas cosas en contexto. También te da la oportunidad de tener un contexto contradictorio, lo cual será simplemente un problema. Y luego, lo último que mencionaré es este concepto de simplemente volver a los flujos de trabajo multi-agente.

The state of the art in terms of observability platforms is such that they don't have a great answer for multi-agent workflows. A, because I don't think the industry's adopted them quite widely. But B, it's just, it's naturally a difficult UX problem, right? You don't know, I mean, you have different agents spotting other ones. It's this weird linear or illinear problem. And I think the last part I guess I'd say about this is if you have a multi-agent architecture, don't be surprised if the many platforms you look at don't support this too well. There are some answers, but not many.

So yeah, finally, I hope the goal of this is just to give you a bit of background about observability, hopefully convince you if you have agents operating in the wild to install a platform. I can't recommend specific ones. I think it's mostly just a case of asking an LLM. It'll give you a far better answer than I can. But it's extremely important. You get a lot of benefits from it. And a lot of these systems are open source and free. So it costs you nothing to try them.

Thank you for your time. Fantastic, amazing, amazing. Thank you so much, Sam. We have a couple of questions up on the screen. For Sam, how can success be evaluated for an agent whose output requires significant interpretation compared to an agent with a limited range of outputs or a clear it works or it does not work result? Yeah, it's a good question. So I think there are two options for you. The first is maybe a bit closer to what you're asking, which is a lot of these platforms allow you to define human in the loop evals. Essentially, they set up a web platform where a human will look at the different, I guess, the output of these different agents and judge them themselves. So if you have a task that can't really be easily defined by either booleans or strings or even just by a plain text description, this is a good option. I will say, though, that the LLM inference has gotten quite good, obviously, depending on the model you use, but you can define very vague behaviors, success criterias, and typically the platform will do a good job of judging those. But yes, human in the loop is also an option.

Fantastic. The next question I have is, reading context-widden window routes, there are a lot of observations on whether there is a hard threshold on token count to enter the dump zone or a passage. What's your experience with this generally? So sorry. Could you, so there's the percentage of, is it the, So is there sort of like a hard kind of threshold to reaching like token route? Hmm. Like getting your model to start becoming normal. Yeah. In terms of like what's in context. Yeah. I don't know. I mean, obviously different models are going to have different context window sizes. In terms of a percentage, to be honest, I don't think there's one particular for all models. I've used some, some open weight models, like there was a poolside or deep seek. And if their, if their context gets to like, you know, 50 or 60%, I've noticed a decent downgrade in performance. But then I think proprietary models, Sonic, Opus, I think they're quite good at, like you can pack the context full. But they also have quite good compaction strategies. I think that's the, maybe the thing that open weight models suffer from, you have to implement those yourself. So I wouldn't, I think it's model dependent, unfortunately. Yeah. Fantastic. Thank you so much.

Next one. How do you deal with observability in a situation where content of sessions need to be kept private? That's a great question. So many, many platforms will offer some sort of PII redacting service. They'll do this either. This is either a manual process that you can configure similar to the human in the loop evals, or you can set some, some private LLM to do it for you. Basically once the, once the, the trace comes in, like plain text right to the observability platform, PI is redacted and then it goes through the process of clustering, defining signals, all of these things. So yeah, most of the platforms will have that. Fantastic. Next one. How can you go about choosing what content, context to provide? Okay.

Like choosing what context to provide. I mean, yeah, I think. So I think in general, if it's not pertinent, well, it depends on first of all, what your agent's doing for something like software development. I have found that context around, you know, your, your competition landscape, your applications history. I found that to be quite useful when the agent's deciding what's structural changes to make to the code base. Then again, if it's an agent doing something very specific, I would argue the less context, the better. I think as a general rule, I would start with as little context as is necessary. And, and then using that, the, the eval loop to potentially add more context and hoping that the, the outcome will be better and seeing if it is and if it isn't going from Fantastic.

How do you make context available by reference? Can you expand on this? I think very similar questions. Context available by reference. Yeah. Sorry. What reference in what regard? So does anyone want to speak on this is anonymous right here. Reference in context available by reference, I guess maybe like you said, providing the less amount of context as possible as you need. Yeah. I mean, if it ref, if you mean reference in terms of like, if, if the, if something in the debugging loop indicates that like refers to a bit of context that you might need or, or is missing. Then I, I think again, again, starting with as little context as possible as, as possible, just to not pollute. And then if you, you typically won't see context that's missing reference, cause obviously the agent isn't going to know, you know what, what, what it's missing. But if you, if you notice that, you know, tool, there's a certain tool call that you've introduced and it's not using it or it's not using it correctly. Or if, you know if you're building a customer service agent and there's some database that should be pinged and it's not, those, then you, then you can test adding those to context. And if it, if it has an update, I hope that was helpful.

How could context be injected efficiently so that the agent can continue longer without hitting limits? Yeah. It's a good question. I think it's important to this paradigm of like making it to what we're talking to our point about trying to not pollute context. A lot of people will advise similar to how MCP works, where agents are not given this giant list of tools and all the inputs that it takes, what's helpful for they're given a very brief description, maybe even just the title. And then as they need, they will query. So the last question, just before we leave is how do you evolve orchestrating agents? Any ends are observing such complexity and direct plus indirect side effects. Seems like we should be avoiding this as much as possible.

So the last question, just before we leave is how do you evolve orchestrating agents? Any ends are observing such complexity and direct plus indirect side effects. Seems like we should be avoiding this as much as possible. So if by orchestrate agents, you mean agents with a lot of complex infrastructure around them, I do think in general that avoiding that is best. Obviously, as I said, if you have a lot of different moving parts, trying to figure out where in this big ecosystem, something went wrong is going to be more challenging than I think it needs to be. I do think typically how I structure agents is to give them an environment that is packed full of tools that they can use if they want. You don't need to orchestrate things like I mean, I've seen people put like web browser tools on Lambdas that agents can query themselves. It's just this insane AWS architecture that I can't even wrap my head around. When in reality, I think just keeping it very simple, even just a VPS where your agents running, give it a browser, give it maybe a browser use tool and then letting it use that. I think that's that'll lend itself better to the debugging process than it would otherwise. Fantastic. Thank you so much, Sam. Give it up for Sam.