Conclusiones clave
- Comenzamos con un punto de dolor real de los clientes. Snyk Assist fue creado para facilitar que los clientes obtengan respuestas rápidas y precisas sin tener que buscar en la documentación, el contenido de soporte y los sistemas de cuentas.
- Tratamos la confianza y el control de acceso como requisitos fundamentales del producto. Dado que Snyk es una plataforma de seguridad, el agente fue diseñado para permanecer dentro de los permisos del usuario y demostrar que era seguro, confiable y correcto antes de un despliegue más amplio.
- Lo construimos para que fuera útil, medible y escalable. Un único runtime de LangGraph alimenta múltiples superficies, mientras que las evaluaciones de LangSmith ayudan al equipo a detectar regresiones, mejorar las respuestas y seguir lanzando con confianza.
Snyk es una plataforma de seguridad con IA. Su plataforma encuentra y corrige vulnerabilidades en código, dependencias de código abierto, contenedores y configuración de la nube, y se sitúa en los lugares donde los desarrolladores ya trabajan: el IDE, el pull request y el pipeline.
Construimos productos de seguridad para desarrolladores, lo que significa que nuestros clientes hacen preguntas difíciles y específicas. Quieren respuestas sobre vulnerabilidades, contexto de cuenta, problemas de soporte y comportamiento del producto, a menudo en medio de un trabajo real. Antes de Snyk Assist, esta información estaba dispersa en la documentación del producto, artículos de soporte, notas de versión, contenido de aprendizaje y datos de cuenta. Encontrar la información correcta generalmente significaba leer varias páginas o crear un ticket y esperar.
Snyk Assist es un agente conversacional construido sobre LangChain y LangGraph con observabilidad gestionada en LangSmith. Ayuda a los clientes a encontrar respuestas en lenguaje natural y puede realizar acciones en su nombre. Puede buscar problemas abiertos, verificar si un paquete tiene vulnerabilidades conocidas, abrir un caso de soporte desde la conversación o registrar una solicitud de función cuando aún no admitimos el flujo de trabajo que necesitan.
Comenzó como una herramienta interna para nuestro propio equipo de soporte. En septiembre de 2026, la trasladamos al producto principal de Snyk, donde todos los clientes de pago pueden acceder a ella.
En esta publicación, compartimos cómo construimos Snyk Assist, desde el caso de uso original de soporte interno hasta la experiencia de producto orientada al cliente. También cubrimos la arquitectura detrás de él, incluido cómo manejamos los permisos, el estado, los guardrails y la evaluación a medida que lo escalábamos.
El desafío: un soporte que no escalaba y un estándar alto para lanzar IA
Nuestro equipo de soporte maneja miles de casos cada par de semanas. Cada uno debía ser leído, clasificado por producto, gravedad y responsable, y enrutado al lugar correcto. Esto presentaba un desafío de escalabilidad a medida que crecían las consultas de los clientes. Un agente era la solución obvia, pero como construimos software de seguridad, todo lo que ponemos frente a los clientes debe cumplir con los mismos estándares que esperamos del resto de nuestro producto. Necesitábamos demostrar tres cosas: que el agente respondía correctamente, que se negaba a lo que debía negarse y que nunca devolvía nada que el usuario no pudiera ver ya.
«La parte difícil de construir agentes no es lo que el modelo puede hacer, es demostrar que el agente realmente funciona. Pasamos cada cambio por evaluaciones en LangSmith, y si no supera el estándar, no se lanza.»
—Bailey Millns, ingeniero de IA, Snyk
En lugar de lanzarlo directamente dentro del producto, comenzamos probándolo internamente con nuestro propio equipo. Este enfoque garantizó que cualquier error inicial permaneciera dentro de Snyk en lugar de afectar a los clientes de pago. También nos permitió probar de forma segura funciones más arriesgadas y observar el comportamiento del agente antes de un despliegue más amplio.
Esta fase interna nos permitió establecer nuestro modelo operativo usando LangSmith antes de introducir funciones orientadas al cliente. Cada traza de estas primeras sesiones alimentó directamente nuestros conjuntos de evaluación, lo que nos dio una sólida comprensión de cómo funcionaría el agente para cuando lo lanzamos en el portal de soporte.
Fase 1: herramientas internas
Durante aproximadamente un año, Snyk Assist funcionó como una herramienta interna para el equipo de atención al cliente, tanto como triaje de casos como agente virtual, con el personal de Snyk como únicos usuarios. Probar el agente internamente nos permitió detectar casos extremos que no aparecían en las pruebas sin conexión, y el ciclo de retroalimentación se medía en horas en lugar de ciclos de lanzamiento.
Fase 2: el portal de soporte
En abril de 2026 lanzamos Snyk Assist a los clientes en nuestro portal de soporte. En esa etapa, podía saludar a los usuarios por su nombre, comprender el contexto de la cuenta, ejecutar una verificación de estado al iniciar sesión y crear un ticket a cualquier hora del día sin esperar a que interviniera una persona.
Fase 3: el producto principal
El 1 de septiembre de 2026, Snyk Assist pasó al producto principal de Snyk, junto con nuestra nueva navegación, como un panel en la barra superior de cada página, para todos los clientes de pago.
Mantuvimos el mismo runtime del agente en cada fase. Lo único que cambió fue la superficie frente a él.
Un runtime, muchas puertas de entrada
Snyk Assist es un único agente de LangGraph detrás de varias superficies: una aplicación de Slack, una aplicación web y acceso directo a la API, todas enrutadas a través del mismo framework seguro.
Elegimos LangChain por su extensa comunidad, su robusto ecosistema y su estatus como estándar de la industria para construir agentes.
«LangChain tenía por mucho la comunidad y el ecosistema más grandes, y se estaba convirtiendo rápidamente en el estándar de facto para construir agentes.»
—Jada Ross, ingeniera de IA, Snyk
Operando como un equipo pequeño, queríamos un único runtime para poder corregir errores, lanzar funcionalidades y manejar respuestas a incidentes desde un solo lugar. Esta simplicidad nos permitió escalar rápidamente sin fragmentar nuestra arquitectura.
Además, usar el middleware de LangChain en lugar de construir una solución personalizada nos proporcionó puntos de integración definidos para contexto, guardrails y respaldos de modelo. Esta configuración nos permite actualizar o reordenar funcionalidad con simples ediciones de una línea en lugar de reescrituras extensas de código.
Estas son las cuatro decisiones de diseño que hicieron práctico ejecutar el sistema en producción:
- Herramientas como funciones tipadas, registradas por usuario. Adjuntamos las herramientas en el momento de la solicitud según los permisos que el usuario con sesión iniciada realmente tiene. Eso significa que el agente solo puede acceder a los datos que el usuario ya podía ver. La mayoría de las herramientas son microservicios independientes, lo que nos permite escalarlas de forma autónoma y añadir capacidades sin modificar el bucle del agente.
- Middleware en lugar de canalización manual. La gestión de contexto, las barreras de seguridad y los respaldos de modelo se conectan a puntos definidos del ciclo de vida del agente en lugar de integrarse a mano en el bucle. Añadir o reordenar comportamientos solo requiere un cambio de una línea en una lista, no una reescritura completa.
- Estado gestionado por el checkpointer. El historial de conversación se persiste en PostgreSQL y se indexa por sesión, de modo que la memoria multi-turno, el escalado entre pods y la reanudación de una conversación funcionan sin cableado adicional.
- El bucle como plataforma interna. Como un agente es simplemente un modelo, herramientas, un prompt, middleware y un checkpointer, una fábrica compartida devuelve el grafo compilado y cada equipo aporta su propia configuración. La mayoría de los flujos de trabajo nuevos son un cambio de configuración en lugar de una nueva arquitectura.
“Desde el punto de vista del desarrollo, LangChain nos dio una abstracción de agente completa (batteries-included) para que pudiéramos centrarnos en el impacto y la capacidad de nuestro agente, en lugar de reinventar la orquestación, las llamadas a herramientas, el streaming y el estado.”
—Matt Jarvis, Director de Ingeniería de IA, Snyk
Cómo evaluamos cada cambio
Cada llamada al modelo, llamada a herramientas y punto de decisión se ha rastreado en LangSmith desde el primer día de desarrollo. Ese rastreo se convirtió en la base de cómo lanzamos.
Usamos dos capas de evaluación.
Evaluación offline ejecuta conjuntos de preguntas de prueba en LangSmith. La primera son preguntas reales con respuestas buenas conocidas, marcadas por un segundo modelo, de modo que podemos saber rápidamente si un cambio de prompt o de modelo empeoró la calidad de las respuestas. La segunda es un ejercicio automatizado de red-teaming en el que personas intentan engañar al agente para que ignore instrucciones o entregue secretos.
CI como compuerta significa que cada pull request ejecuta el agente real contra esos conjuntos de pruebas y se bloquea según umbrales acordados comprometidos en el repositorio.
Evaluación online califica cada ejecución de producción con un trabajo programado. Comprobamos dos cosas: ¿trataba sobre Snyk y la respuesta lo respondió? Esas calificaciones nos dan una tasa de deflexión medida en lugar de una estimación. También categorizamos cada pregunta por área de producto, tema, ecosistema de lenguaje y tipo de error, lo que brinda a los gestores de producto un mapa en vivo de dónde tienen dificultades los clientes.
Cerrar el ciclo ocurre dentro de nuestros agentes de código a través del servidor MCP de LangSmith. Cuando encontramos un rastreo defectuoso, podemos investigarlo y convertirlo en un dataset sin salir del IDE.
Como cada paso está rastreado en LangSmith, podemos probar cambios contra preguntas reales, detectar regresiones antes de lanzarlas y convertir rastros defectuosos en nuevos datasets rápidamente. Eso nos da un ciclo de retroalimentación más rápido y hace que sea mucho más fácil lanzar con confianza.
El impacto: menos tickets, respuestas más rápidas
Desde que Snyk Assist salió a producción para los clientes en abril de 2026:
- más de 60,000 consultas gestionadas
- más de 500 cuentas de clientes
- 85% o más de las sesiones resueltas sin un ticket de soporte, ahorrando al equipo de soporte cientos de horas
- más de 250 casos autodetectados por el agente y escalados directamente al equipo correcto
Cada conversación se califica y categoriza, de modo que podemos ver qué partes del producto generan más confusión. Eso nos ayuda a mejorar la documentación.
Conclusiones clave y próximos pasos
Snyk Assist comenzó como una herramienta para el propio equipo de soporte de Snyk. Hoy, ha gestionado más de 60,000 consultas de clientes y resuelve más del 85% de las sesiones sin crear un ticket de soporte. Desde septiembre, Snyk Assist forma parte del producto mismo, disponible en cada página junto al trabajo que los clientes ya están realizando. Queremos que sea una parte útil de la experiencia de Snyk para cada cliente.
Enlace: https://docs.snyk.io/navigate-the-snyk-web-ui#snyk-assist