Forter logró involucrar a unas 200 personas en la creación de agentes de inteligencia artificial durante un sprint práctico de dos semanas, después de diseñar un entorno que reducía la necesidad de conocimientos de programación y permitía a analistas e ingenieros probar sus ideas rápidamente. Ben Maraney, ingeniero principal de la empresa, presenta la experiencia como una lección sobre la eliminación de complejidad innecesaria, en lugar de intentar resolver de una sola vez todos los desafíos de la creación de agentes.
El comienzo: un sprint práctico con un plazo de cinco semanas
El objetivo era capacitar a los equipos de investigación y desarrollo para crear sus propios agentes, incluidos analistas con formación jurídica, psicológica y científica, algunos de los cuales nunca habían escrito SQL. El equipo necesitaba preparar el entorno en cinco semanas y después ejecutar un sprint de creación de dos semanas. Por ello, el diseño se centró en tres ejes: las herramientas, las plataformas y la eliminación de obstáculos para los usuarios.
Un servidor MCP central en lugar de herramientas dispersas
Forter se apoyó en un servidor interno basado en el protocolo MCP, al que llamó Toolchain. El servidor proporcionaba una interfaz única para descubrir y probar herramientas, así como para crear las conexiones específicas de cada agente. También permitía al usuario seleccionar únicamente las herramientas que necesitaba el agente, en lugar de concederle un acceso amplio que pudiera confundirlo o llevarlo a utilizar herramientas inadecuadas.
El número de herramientas pasó de unas 20 cuando se creó el equipo a cerca de 60 al comenzar el sprint, y después a casi 100 dos semanas después de su finalización. La unificación del repositorio y la existencia de ejemplos y archivos de configuración claros ayudaron a añadir nuevas herramientas rápidamente, además de proporcionar capacidades de gobernanza como la supervisión del consumo de tokens y del uso de las herramientas.
En lugar de construir en poco tiempo un sistema personalizado de generación aumentada mediante recuperación (RAG), la empresa conectó Toolchain con la plataforma Glean, utilizada para buscar en fuentes internas como Confluence, Asana, Jira, Slack y Salesforce. Ofreció tres tipos de herramientas: búsqueda de documentos y fragmentos pertinentes, lectura del documento completo y resumen según una pregunta o un eje definido por el agente.
De una plataforma sin programación a soluciones personalizables
Forter utilizó LibreChat para ofrecer una experiencia conversacional rápida y con poca programación. Los usuarios podían ver las herramientas que había invocado el agente, las consultas y los parámetros que había enviado, y los resultados que había recibido. Esto ayudó a comprender el comportamiento de los agentes y a detectar problemas pronto, aunque la integración con MCP era inestable en ocasiones y ofrecía un control limitado de las versiones y de la personalización.
Para los casos más complejos, la empresa proporcionó repositorios de ejemplo que daban a los desarrolladores control total sobre el código y permitían añadir herramientas y subagentes, pero eran más lentos de configurar y desplegar, especialmente para los analistas. Más adelante, Forter creó una interfaz interna llamada AI Hub que permitía seleccionar el modelo, escribir el mensaje del sistema, definir las herramientas y compartir el agente en pocos pasos.
Para los agentes no interactivos, se utilizó el marco Strands junto con Argo Workflows para ejecutarlos según horarios o eventos, como la creación de tickets en Jira y Asana. Maraney señala que la existencia de un sistema de programación y ejecución ya operativo puede eliminar la necesidad de una arquitectura nueva específica para agentes.
¿Qué se construyó realmente?
Los usos incluyeron agentes que ayudaban a los analistas a formular mejores hipótesis y experimentos, revisaban informes posteriores a incidentes y analizaban la disminución del rendimiento de los comerciantes mediante Snowflake y notebooks de Databricks. La empresa también desarrolló agentes expertos, como Layla y Penny, para acceder al código, las configuraciones y los datos, y responder preguntas relacionadas con decisiones sobre transacciones y facturación. El uso de Layla se extendió a los equipos de éxito del cliente y soporte después de que su conocimiento del sistema se volviera más amplio que el de cualquier persona individual.
Entre los ejemplos de agentes no interactivos estuvieron la sugerencia de configuraciones iniciales para un nuevo comerciante basándose en comerciantes similares, la preparación de investigaciones preliminares cuando llegaba un ticket de soporte y el análisis de alertas de anomalías vinculándolas con cambios en el código. Forter también probó un agente de respuesta a incidentes, pero descubrió que sus resultados aparentemente excelentes dependían principalmente de copiar análisis de causa raíz escritos anteriormente por humanos en informes de BetterNext.
¿Qué cambia en la práctica?
Esta experiencia muestra que la observabilidad no es una característica secundaria. Mostrar las herramientas, los parámetros y los resultados en los que se basaba el agente fue esencial para descubrir que el agente de respuesta a incidentes no estaba deduciendo realmente la causa raíz. Por ello, Forter incorporó posteriormente Langfuse para rastrear las sesiones de los agentes, las llamadas a herramientas y el flujo de trabajo.
La experiencia también demuestra que la multiplicidad de plataformas puede ser intencionada: una plataforma sin programación para la experimentación rápida, soluciones de software para la personalización y agentes que funcionan mediante eventos o programaciones. En cambio, la empresa tuvo problemas con el modelo de crear un repositorio independiente para cada agente y después volvió a utilizar un número menor de repositorios que incluían agentes relacionados, para facilitar la incorporación de capacidades compartidas como el rastreo.
Maraney advierte asimismo que las métricas generales de evaluación, como la pertinencia, la coherencia y la seguridad, pueden dar una falsa impresión de calidad. Una evaluación útil debe comprobar la exactitud de la respuesta, el uso de las herramientas adecuadas y la recuperación del contexto correcto, aspectos más difíciles que requieren conocer con precisión qué significa una buena respuesta. Por ello, las evaluaciones avanzadas pueden posponerse en experimentos internos en los que el ser humano permanece dentro del circuito de toma de decisiones, pero no deben considerarse un sustituto permanente de la evaluación.
Las iniciativas de ampliación también necesitan involucrar pronto a los equipos jurídicos y de seguridad, especialmente en lo relativo al lugar donde se procesan y conservan los datos. Maraney señala que el uso de un servicio en la nube como Amazon Bedrock, junto con la documentación de las políticas de no retención de datos, ayudó a abordar estas preocupaciones dentro de los controles de la empresa, en lugar de convertir cada agente en un caso de aprobación separado.