Esta publicación está coescrita con Kenneth Salmon, Edward Boswell, Jack Armstrong, Robert Bahn y Nick Ciubotariu de ShipStation Global.
Responder las mismas preguntas de TI y resolver tickets rutinarios consume tiempo que los equipos de TI podrían dedicar a otras tareas. Para recuperarlo, el equipo de ingeniería de ShipStation Global construyó Deckhand, un agente de mesa de ayuda de TI con IA para Slack, sobre Amazon Bedrock AgentCore.
ShipStation Global es la plataforma líder de envíos y logística inteligente para remitentes pequeños y medianos, y opera bajo una creencia simple: cuanto más eficientes son sus equipos, mejor entrega a los clientes. Deckhand pone esa creencia en práctica. Responde preguntas rutinarias de TI y de la empresa a partir de una base de conocimientos curada, lee capturas de pantalla de mensajes de error y crea y actualiza tickets de Jira Service Management.
En esta publicación, analizamos cómo ShipStation arquitecturó Deckhand, lo que resultó en la resolución del 97.5 por ciento de las consultas entrantes del canal, mientras obtenía una calificación de retroalimentación positiva del 96 por ciento por parte de los empleados (Figura 1).
Figura 1: Cobertura del canal a 3 meses y retroalimentación positiva
Desafío empresarial
El problema que Deckhand resuelve es el que reconocerá cualquier equipo de TI: las mismas preguntas se hacen de forma rutinaria, los mensajes de error se publican fuera del horario laboral y la información debe recopilarse de diferentes equipos. En ShipStation Global, esas conversaciones tenían lugar en un concurrido canal de Slack de mesa de ayuda, donde los empleados preguntaban y TI respondía, un hilo a la vez. Las respuestas generalmente ya existían en un artículo de instrucciones de Confluence, en una página de la intranet de la empresa o en un hilo de ocho meses atrás. Encontrarlas era lo difícil.
Los datos del canal hicieron concreta la escala. En los 12 meses anteriores al lanzamiento:
- Los empleados publicaron más de 1,500 hilos, y el volumen siguió creciendo.
- Con empleados en EE. UU., Reino Unido, España, Polonia, Australia y Filipinas, más de una quinta parte de las preguntas llegaban fuera del horario laboral de EE. UU.
- Las respuestas estaban distribuidas en diferentes lugares: artículos de Confluence, páginas de la intranet y PDF, guías mantenidas por TI y el propio historial del canal.
- Las preguntas repetitivas consumían tiempo que pasos estructurados de autoservicio podrían haber gestionado.
“Creamos Deckhand porque obtener ayuda debería ser tan simple como hacer una pregunta en Slack, no descifrar un formulario de tickets ni enviar un correo electrónico al vacío. Creemos que los tickets son un indicador de fricción operativa, no de productividad. Deckhand resuelve las preguntas comunes en el momento y, cuando no puede, convierte la conversación en un ticket completamente contextualizado con un solo clic, mejorando la experiencia del empleado y liberando a nuestro equipo de repetir infinitamente la frase: ‘Por favor, abra un ticket’.”
— Chris Collins, Director Senior de TI en ShipStation Global
Descripción general de la solución
Deckhand funciona en Slack como cualquier compañero de equipo: se une a los canales, lee la conversación y extrae contexto de los perfiles de Slack para responder preguntas de TI en el momento. Lo ejecutamos en Amazon Bedrock AgentCore, una plataforma para construir, conectar y optimizar agentes a escala, con cualquier framework o modelo. AgentCore runtime, una capacidad de Amazon Bedrock AgentCore, aloja al agente en sesiones aisladas, por lo que no ejecutamos servidores ni contenedores.
La solución tiene cuatro componentes principales, como se muestra en la Figura 2:
- Servicio de Slack: Una aplicación de FastAPI y Slack Bolt, alojada en AWS App Runner. Recibe eventos de Slack, decide si el bot debe responder y construye un payload de contexto de usuario a partir del perfil de Slack del solicitante, incluidos nombre, correo electrónico, zona horaria y gerente.
- Servicio de agente: Un agente de Strands, desplegado como contenedor en Amazon Bedrock AgentCore runtime, gestiona el bucle de agente de herramientas multi-turno utilizando Claude de Anthropic en Amazon Bedrock.
- Herramientas y conocimiento: Una sola AWS Lambda función, expuesta como herramientas del Model Context Protocol (MCP) mediante AgentCore Gateway, una capacidad de Amazon Bedrock AgentCore, clasifica solicitudes, crea y actualiza tickets de Jira, y analiza imágenes. Un Base de conocimientos de Amazon Bedrock indexa contenido de Confluence, la intranet de la empresa, Slack y páginas de marketing, almacenándolo en Amazon Simple Storage Service (Amazon S3).
- Operaciones y retroalimentación. Amazon DynamoDB almacena la retroalimentación, AWS X-Ray rastrea las rutas de las solicitudes mediante OpenTelemetry, y los servicios registran logs en Amazon CloudWatch.
Figura 2: Diagrama de arquitectura que muestra los eventos de Slack entrando en el servicio de Slack y en el runtime de Amazon Bedrock AgentCore, con rutas separadas hacia una base de conocimiento de Amazon Bedrock, herramientas Lambda respaldadas por AgentCore Gateway, Jira Service Management y retroalimentación en DynamoDB.
Cuando un empleado publica en un canal donde Deckhand es miembro, el servicio de Slack ensambla el historial completo del hilo y el contexto del usuario. Luego invoca al agente a través de la API del runtime de AgentCore. El agente busca en la base de conocimiento y llama a las herramientas según sea necesario. Cuando encuentra una respuesta, devuelve una respuesta final (Figura 3). Cuando no la encuentra, hace una pregunta aclaratoria u ofrece crear un ticket (Figura 4).
Figura 3: Deckhand responde con pasos de autoservicio
Figura 4: Deckhand ofrece crear un ticket
Flujo de trabajo de Deckhand
Esta sección describe cómo está implementado Deckhand, desde los requisitos previos hasta un despliegue funcional.
Requisitos previos
Para implementar este patrón, necesita lo siguiente:
- Una cuenta de AWS con acceso a Amazon Bedrock, AgentCore runtime y AgentCore Gateway.
- Una aplicación de Slack con suscripciones a eventos, un signing secret y un token de bot con el ámbito adecuado para su caso de uso.
- Un registro de imágenes de contenedores como Amazon Elastic Container Registry (Amazon ECR).
- Un bucket de Amazon S3 y una base de conocimiento de Amazon Bedrock.
- Roles de AWS Identity and Access Management (IAM) con el ámbito adecuado para cada runtime y herramienta, y entradas en AWS Secrets Manager para las credenciales de terceros.
Construcción del agente con Strands Agents y AgentCore
El agente es deliberadamente ligero. Usando el SDK de código abierto Strands Agents SDK, un agente consiste en un modelo, un conjunto de herramientas y un prompt de sistema. El SDK gestiona el bucle de razonamiento, permitiendo que el modelo seleccione herramientas, procese resultados e itere hasta producir una respuesta. El servicio de agente de Deckhand está implementado en unas pocas líneas de Python.
from strands import Agent
from strands.models import BedrockModel
from strands.tools.mcp import MCPClient
from strands_tools import retrieve
from mcp.client.streamable_http import streamablehttp_client
model = BedrockModel(
model_id=MODEL_ID,
max_tokens=2048,
temperature=0.3,
)
gateway = MCPClient(lambda: streamablehttp_client(url=GATEWAY_URL))
agent = Agent(
model=model,
tools=[gateway, retrieve],
system_prompt=SYSTEM_PROMPT,
)El ID del modelo se establece mediante una variable de entorno, lo que permite cambiar de modelo sin modificar el código de la aplicación.
Las herramientas se integran con el agente de dos maneras. La recuperación de Amazon Bedrock Knowledge Bases es una herramienta nativa de Strands que permite buscar en la base de conocimiento con una sola importación. Otras funciones, incluidas la clasificación, la gestión de tickets, la resolución de usuarios y el análisis de imágenes, son manejadas por una función Lambda registrada en AgentCore Gateway. El Gateway las expone como herramientas MCP, y la Lambda enruta cada invocación por nombre de herramienta. Esta separación permite actualizar la lógica de las herramientas de forma independiente, y el agente puede acceder a nuevas herramientas desde el Gateway sin necesidad de una reconstrucción.
AgentCore runtime aloja el agente como un contenedor, evitando la necesidad de gestión de servidores o sesiones. El servicio de Slack llama al agente de forma síncrona para cada mensaje, proporcionando la transcripción del hilo y el contexto del usuario, y publica la respuesta final. Dado que el contexto, incluido el perfil del empleado, se incluye en cada solicitud, el agente puede completar los detalles del ticket automáticamente.
Diseño de la base de conocimiento y enrutamiento de respuestas
Deckhand responde a partir de una única base de conocimiento de Amazon Bedrock con fuentes de datos principales respaldadas por S3:
- Artículos sincronizados desde Confluence.
- Páginas internas, PDF y eventos sincronizados desde la intranet de la empresa.
- Hilos de soporte resueltos extraídos de Slack (tratados en la siguiente sección).
Cada documento incluye metadatos como título, URL de origen, tipo de contenido y fechas de eventos. Esto permite al agente filtrar el contenido, por ejemplo, cuando los usuarios preguntan por próximos eventos o los menús de almuerzo semanales en la oficina de Austin.
Minerando el historial de Slack con Modelos de Lenguaje Recursivos (RLMs)
La fuente de datos más valiosa es el archivo de hilos de soporte resueltos. Antes de que existiera Deckhand, Slack era donde se resolvían los problemas: años de empleados describiendo incidencias y de TI guiándolos hacia las soluciones. Ese historial es una base de conocimiento orgánica, validada por el mejor revisor posible: la persona cuyo problema fue resuelto. También es ruidoso: una exportación en bruto mezcla bromas, alertas automatizadas e hilos que en realidad nunca se resolvieron. Indexar una corrección no verificada o un resumen confuso significa que la base de conocimiento presenta una respuesta incorrecta con la misma confianza que una correcta, por lo que la extracción debe ser precisa.
El proceso de minería sigue un pipeline de tres etapas (Figura 5):
- Un script exporta el historial completo del canal mediante la API de Slack, recuperando las respuestas completas de cada hilo y escribiendo un volcado estructurado que incluye marcadores de hilo, marcas de tiempo y conteos de respuestas.
- El Modelo de Lenguaje Recursivo (RLM) de DSPy, ejecutando Claude en Amazon Bedrock, trata esa exportación como un espacio de memoria navegable dentro de un bucle de lectura-evaluación-impresión de Python (REPL) aislado, en lugar de un único prompt. Trabajando de forma iterativa sobre los datos, clasifica cada hilo como resuelto, no resuelto o escalado, y filtra los anuncios y las preguntas que no lo son. Criterios estrictos mantienen la calidad alta: un hilo cuenta como resuelto solo cuando la corrección completa y funcional es visible en el propio hilo.
- Para cada hilo resuelto, el RLM orquesta llamadas recursivas a sub-LLM (modelo de lenguaje grande) para extraer campos estructurados, cada uno validado contra un modelo de Pydantic. Los campos incluyen un resumen del problema, la pregunta original y la resolución. También capturan si la solución es de autoservicio o requiere un ticket, los pasos de autoservicio, la aplicación y el sistema involucrados, los mensajes de error y las etiquetas. Cuando una llamada al sub-LLM devuelve algo que falla el esquema, el bucle basado en código del RLM captura el error de validación en el intérprete y reintenta. Los resultados se escriben como un documento markdown organizado por problema. El pipeline lo sube a Amazon S3 para que la base de conocimientos lo indexe.
Figura 5: Flujo de trabajo de clasificación y extracción de la exportación de la conversación de Slack
Elegimos RLM porque mantiene todo el historial de Slack en un espacio de variables persistente de sandbox, lo que permite un razonamiento iterativo sobre la exportación y una estructura de salida consistente. Como resultado, cuando un empleado se encuentra con un problema que un colega ya resolvió, Deckhand proporciona la solución probada, a menudo como pasos accionables numerados.
Saber cuándo no responder
Un bot de IA en un canal compartido fracasa socialmente antes de fracasar técnicamente. La lógica más refinada de Deckhand decide cuándo quedarse en silencio:
- La primera decisión del agente sobre cada mensaje es si se trata de un anuncio, un mensaje social o una conversación entre personas. Si es así, emite “SKIP,” y el servicio de Slack suprime la respuesta.
- En los hilos, responde solo a quien publicó originalmente.
- Si la última respuesta vino de otro ayudante humano, permanece en silencio, porque una persona ha tomado el control.
- Si una respuesta empieza mencionando (@) a una persona, el mensaje no es para el bot.
Recopilación de retroalimentación
Cada respuesta incluye botones de retroalimentación. Un pulgar hacia arriba se registra directamente, mientras que un pulgar hacia abajo muestra un breve campo de “qué salió mal”. Las calificaciones se almacenan en DynamoDB junto con la pregunta original y la respuesta del bot.
La retroalimentación negativa es un conjunto de datos valioso que se utiliza para mejorar el prompt del sistema y el comportamiento del agente, y para actualizar la información incorrecta de la base de conocimientos.
Seguridad y validación
Las reglas del prompt mejoran el comportamiento pero no reemplazan los controles de acceso. La aplicación se gestiona mediante código e infraestructura:
- La creación de tickets requiere confirmación explícita. Cuando Deckhand ofrece crear un ticket, el servicio de Slack añade un botón Create Ticket , y al seleccionarlo se envía la confirmación a través del agente. Las actualizaciones de tickets solo aceptan claves válidas que coincidan con el patrón del proyecto de helpdesk y rechazan comentarios vacíos.
- La clasificación se valida antes de actuar. La clasificación de solicitudes se ejecuta como una llamada separada a la Amazon Bedrock Converse API que devuelve campos estructurados del ticket, validados con Pydantic antes de que algo llegue a Jira.
- La herramienta de imágenes está restringida para descargar solo desde el host de archivos de Slack. Se autentica con el token del bot, limita cada solicitud a cinco imágenes de hasta 5 MB cada una y envía los archivos a un modelo de visión usando la Converse API.
- Las credenciales permanecen fuera del código. Los tokens de Slack, el secreto de firma y las credenciales de Jira viven en AWS Secrets Manager, y cada servicio y herramienta se ejecuta bajo su propio rol de IAM con alcance delimitado.
- El prompt aplica salvaguardas de comportamiento: nunca solicitar contraseñas ni códigos de autenticación multifactor (MFA), nunca escribir credenciales en los comentarios de los tickets y nunca exponer los metadatos de perfil utilizados para los campos de los tickets.
Resultados
Deckhand se lanzó en abril de 2026. Comenzó con unos 30 mensajes al día y llegó a alcanzar 100 a principios del verano. En sus primeros tres meses gestionó 1,935 mensajes, inició 1,221 conversaciones de agente y abrió 409 tickets de Jira. Respondió al 97.5 por ciento de los mensajes. Un tercio de las preguntas llegaban fuera del horario laboral, cuando nadie del equipo de TI estaba trabajando, y Deckhand respondió al 94 por ciento de ellas. Las personas que habrían esperado hasta la mañana siguiente obtuvieron una respuesta esa misma noche.
La retroalimentación mejoró a medida que el equipo trabajaba en ello. Las calificaciones positivas pasaron del 82 por ciento en abril al 96 por ciento en junio, después de revisar el prompt del sistema y la base de conocimientos para corregir lo que la gente criticaba.
La victoria más clara fue la deflexión de tickets. Una conversación de agente es una pregunta que de otro modo se habría convertido en un ticket de Jira. De las 1,221 conversaciones, solo 409 se convirtieron en tickets. Las otras 812 se resolvieron en el chat. Presentar un ticket y luego trabajarlo y cerrarlo toma unos 30 minutos. Esas 812 conversaciones suman aproximadamente 406 horas en tres meses, o alrededor de 1,600 horas al año. Los empleados conservaron ese tiempo para su propio trabajo, y TI nunca lo gastó en la recepción de solicitudes.
Conclusión
Deckhand eliminó las preguntas repetitivas de TI de la carga de los empleados y devolvió tiempo tanto a los empleados como al equipo de TI. Funciona porque cada parte del stack tiene una sola tarea y se ejecuta como un servicio administrado: AgentCore runtime aloja al agente, AgentCore Gateway convierte una función de Lambda en herramientas MCP que el agente puede llamar, y Amazon Bedrock Knowledge Bases gestiona la recuperación de información. El equipo lo puso en producción sin levantar servidores ni mantener código de orquestación.
Para crear una solución similar, comience con una fuente de conocimiento bien mantenida y una acción claramente definida. Consulte la documentación de Amazon Bedrock AgentCore y el Strands Agents SDK para el desarrollo de agentes, y la documentación de Amazon Bedrock Knowledge Bases para conectar fuentes de contenido.
Para comentar un caso de uso de IA agéntica para su organización, contacte con su equipo de cuenta de AWS.