ShipStation Global 如何基于 Amazon Bedrock AgentCore 构建 AI IT 服务台

本文由 ShipStation Global 的 Kenneth Salmon、Edward Boswell、Jack Armstrong、Robert Bahn 和 Nick Ciubotariu 共同撰写。

反复回答相同的 IT 问题、处理常规工单，会耗费 IT 团队原本可投入其他事务的时间。为重新获得这些时间，ShipStation Global 工程团队基于 Amazon Bedrock AgentCore 构建了 Deckhand——一款面向 Slack 的 AI 驱动 IT 服务台 Agent。

ShipStation Global 是面向中小型发货商的领先智能航运与物流平台，其运营基于一个简单理念：团队效率越高，就越能为客户提供更好的服务。Deckhand 将这一理念付诸实践。它从经过筛选的知识库中回答常规 IT 和公司问题，读取错误信息截图，并创建和更新 Jira Service Management 工单。

本文将介绍 ShipStation 如何设计 Deckhand。该系统最终解决了 97.5% 的频道传入查询，并获得员工 96% 的正面反馈率（图 1）。

图 1：三个月的频道覆盖率与正面反馈

业务挑战

Deckhand 所解决的问题，是每个 IT 团队都能理解的：相同的问题被反复提出，错误信息会在工作时间之外被发出，而且信息需要从不同团队收集。在 ShipStation Global，这些对话都发生在一个繁忙的服务台 Slack 频道中，员工提问，IT 团队逐条线程回复。答案通常早已存在于 Confluence 操作指南文章、公司内网页面，或者八个月前的一条讨论线程中；困难在于如何找到它们。

频道数据让问题规模变得具体。在上线前的 12 个月中：

• 员工发布了超过 1,500 个线程，且数量持续增长。
• 员工分布在美国、英国、西班牙、波兰、澳大利亚和菲律宾，超过五分之一的问题在美国工作时间之外到达。
• 答案分散在不同位置：Confluence 文章、内网页面和 PDF、由 IT 维护的指南，以及频道自身的历史记录。
• 重复性问题占用了本可由结构化自助步骤解决的时间。

“我们创建 Deckhand，是因为获取帮助应该像在 Slack 中提问一样简单，而不应是解读工单表单，或把电子邮件发到无人回应的黑洞。我们相信，工单是运营摩擦的信号，而不是生产力的标志。Deckhand 可以当场解决常见问题；当它无法解决时，只需单击一下，就能将对话转化为一份包含完整上下文的工单。这既改善了员工体验，也让我们的团队不再无休止地重复：‘请提交工单。’”

— ShipStation Global IT 高级总监 Chris Collins

解决方案概述

Deckhand 在 Slack 中的工作方式与任何一位团队成员相同：加入频道、阅读对话，并从 Slack 个人资料中提取上下文，在原处回答 IT 问题。我们在 Amazon Bedrock AgentCore 上运行它；这是一个可使用任意框架或模型，大规模构建、连接和优化 Agent 的平台。作为 Amazon Bedrock AgentCore 的一项能力，AgentCore Runtime 在隔离会话中托管 Agent，因此我们无需运行服务器或容器。

该解决方案由图 2 所示的四个主要组件构成：

1. **Slack 服务：**一个 FastAPI 和 Slack Bolt 应用程序，托管在 AWS App Runner 上。它接收 Slack 事件，决定机器人是否应当响应，并根据请求者的 Slack 个人资料构建用户上下文负载，其中包括姓名、电子邮件、时区和直属经理。
2. **Agent 服务：**一个 Strands Agent，以容器形式部署在 Amazon Bedrock AgentCore Runtime 上，使用 Amazon Bedrock 中 Anthropic 的 Claude 管理多轮工具型 Agent 循环。
3. **工具与知识：**单个 AWS Lambda 函数通过 AgentCore Gateway 作为 Model Context Protocol（MCP）工具公开；AgentCore Gateway 是 Amazon Bedrock AgentCore 的一项能力。该函数负责请求分类、创建和更新 Jira 工单以及图像分析。一个 Amazon Bedrock 知识库 为来自 Confluence、公司内网、Slack 和营销页面的内容建立索引，并将其存储于 Amazon Simple Storage Service（Amazon S3）。
4. 运维与反馈：Amazon DynamoDB 存储反馈；AWS X-Ray 使用 OpenTelemetry 跟踪请求路径；各项服务将日志写入 Amazon CloudWatch。

图 2：架构图展示 Slack 事件进入 Slack 服务和 Amazon Bedrock AgentCore Runtime，并分别通向 Amazon Bedrock 知识库、由 AgentCore Gateway 支持的 Lambda 工具、Jira Service Management 和 DynamoDB 反馈。

当员工在 Deckhand 所在的频道中发帖时，Slack 服务会汇总完整的线程历史记录和用户上下文，随后通过 AgentCore Runtime API 调用 Agent。Agent 搜索知识库，并在需要时调用工具。找到答案时，它会返回最终响应（图 3）；找不到答案时，它会提出澄清问题或提供创建工单的选项（图 4）。

图 3：Deckhand 以自助步骤回复

图 4：Deckhand 提供创建工单选项

Deckhand 工作流

本节将介绍 Deckhand 的实现过程，从前置条件到可工作的部署。

前置条件

要实现这一模式，需要具备以下条件：

• 一个 AWS 账户，并可访问 Amazon Bedrock、AgentCore Runtime 和 AgentCore Gateway。
• 一个 Slack 应用，配置了事件订阅、签名密钥，以及符合你的使用场景权限范围的机器人令牌。
• 一个容器镜像注册表，例如 Amazon Elastic Container Registry（Amazon ECR）。
• 一个 Amazon S3 存储桶和一个 Amazon Bedrock 知识库。
• 分别限定每个 Runtime 和工具权限范围的 AWS Identity and Access Management（IAM）角色，以及用于存储第三方凭证的 AWS Secrets Manager 条目。

使用 Strands Agents 和 AgentCore 构建 Agent

该 Agent 的设计有意保持轻量。通过开源的 Strands Agents SDK，一个 Agent 由模型、一组工具和系统提示词构成。SDK 管理推理循环，使模型能够选择工具、处理结果并反复迭代，直至生成答案。Deckhand 的 Agent 服务仅用几行 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,
)

模型 ID 通过环境变量设置，因此无需修改应用程序代码即可切换模型。

工具通过两种方式集成至 Agent。Amazon Bedrock Knowledge Bases 检索是一个原生 Strands 工具，只需一次导入即可支持知识库搜索。其他功能，包括分类、工单管理、用户解析和图像分析，则由注册在 AgentCore Gateway 上的 Lambda 函数处理。Gateway 将这些功能作为 MCP 工具公开，Lambda 则根据工具名称路由每次调用。这种分离方式使工具逻辑能够独立更新，并且 Agent 无需重新构建，即可从 Gateway 访问新工具。

AgentCore Runtime 将 Agent 作为容器托管，无需进行服务器或会话管理。Slack 服务会针对每条消息同步调用 Agent，提供线程转录内容和用户上下文，并发布最终回复。由于每次请求都包含上下文（包括员工个人资料），Agent 可以自动补全工单详情。

知识库设计与答案路由

Deckhand 从一个 Amazon Bedrock 知识库中回答问题，该知识库具有以下以 S3 为后端的核心数据源：

• 从 Confluence 同步的文章。
• 从公司内网同步的内部页面、PDF 和活动信息。
• 从 Slack 挖掘出的已解决支持线程（将在下一节介绍）。

每份文档都包含标题、来源 URL、内容类型和活动日期等元数据。这使 Agent 能够筛选内容，例如当用户询问即将举行的活动或奥斯汀办公室每周午餐菜单时。

使用递归语言模型（RLM）挖掘 Slack 历史记录

最有价值的数据源是已解决支持线程的归档。在 Deckhand 出现之前，Slack 是问题得到解决的地方：多年来，员工描述问题，IT 团队引导他们完成修复。这些历史记录是一种自然形成的知识库，并经过最理想的审核者验证：问题得到解决的当事人。但它也充满噪声：原始导出数据混杂了闲聊、自动告警，以及实际上从未解决的线程。为未经验证的修复方案建立索引，或采纳混乱的摘要，意味着知识库会以与正确答案相同的置信度呈现错误答案，因此提取过程必须精确。

挖掘流程采用三阶段管道（图 5）：

1. 一个脚本通过 Slack API 导出频道完整历史记录，获取每个线程的完整回复，并写入包含线程标记、时间戳和回复数量的结构化转储文件。
2. 运行在 Amazon Bedrock 上 Claude 的 DSPy 递归语言模型（RLM），将该导出文件视为沙箱化 Python 读值求值打印循环（REPL）内可导航的内存空间，而非单个提示词。它以迭代方式处理数据，将每个线程分类为已解决、未解决或已升级，并过滤公告和非问题内容。严格的标准确保高质量：只有当完整、可执行的修复方案在线程本身中清晰可见时，线程才会被认定为已解决。
3. 对于每个已解决线程，RLM 会编排递归子 LLM（大语言模型）调用，以提取结构化字段；每个字段都根据 Pydantic 模型验证。这些字段包括问题摘要、原始问题和解决方案；还会记录修复方案是自助式还是需要工单、自助步骤、涉及的应用程序和系统、错误信息以及标签。当子 LLM 调用返回不符合 schema 的内容时，RLM 基于代码的循环会在解释器中捕获验证错误并重试。结果被写入按问题组织的 Markdown 文档。该管道将其上传至 Amazon S3，以供知识库建立索引。

图 5：Slack 对话的导出、分类和提取工作流

我们选择 RLM，是因为它会将完整 Slack 历史记录保留在持久化的沙箱变量空间中，从而能够对导出数据进行迭代推理，并维持一致的输出结构。因此，当员工遇到此前已有同事解决过的问题时，Deckhand 会提供经过验证的解决方案，通常以可执行的编号步骤形式呈现。

知道何时不回答

共享频道中的 AI 机器人在技术失败之前，往往会先在社交层面失败。Deckhand 最精细的逻辑决定了它何时应保持沉默：

1. Agent 对每条消息的首个判断，是该消息是否为公告、社交消息或人与人之间的对话。如果是，它会输出“SKIP”，Slack 服务则抑制回复。
2. 在线程中，它只回复原始发帖者。
3. 如果最后一条回复来自另一位人工协助者，它会保持沉默，因为

This post is co-written with Kenneth Salmon, Edward Boswell, Jack Armstrong, Robert Bahn, and Nick Ciubotariu from ShipStation Global.

Answering the same IT questions and clearing routine tickets drains time that IT teams could spend elsewhere. To reclaim it, the ShipStation Global Engineering team built Deckhand , an AI-powered IT help desk agent for Slack, on Amazon Bedrock AgentCore.

ShipStation Global is the leading intelligent shipping and logistics platform for small and mid-sized shippers, and it operates on a simple belief: the more efficient its teams are, the better it delivers for customers. Deckhand puts that belief to work. It answers routine IT and company questions from a curated knowledge base, reads error-message screenshots, and creates and updates Jira Service Management tickets.

In this post, we discuss how ShipStation architected Deckhand, which resulted in resolving 97.5 percent of incoming channel queries while earning a 96 percent positive feedback rating by employees (Figure 1).

Figure 1: 3-month channel coverage and positive feedback

Business challenge

The problem Deckhand solves is the one every IT team will recognize: the same questions are routinely asked, error messages are posted after business hours, and information needs to be gathered from different teams. At ShipStation Global, those conversations lived in a busy help desk Slack channel, where employees asked, and IT answered, one thread at a time. The answers usually already existed in a Confluence how-to article, on a company intranet page, or in a thread from eight months earlier. Finding them was the hard part.

The channel data made the scale concrete. In the 12 months before launch:

• Employees posted more than 1,500 threads, and volume kept growing.
• With employees in the US, UK, Spain, Poland, Australia, and the Philippines, more than a fifth of questions arrived outside US business hours.
• Answers were split across different places: Confluence articles, intranet pages and PDFs, IT-maintained guides, and the channel’s own history.
• Repetitive questions consumed time that structured self-service steps could have handled.

“We created Deckhand because getting help should be as simple as asking a question in Slack, not deciphering a ticket form or sending an email into the void. We believe that tickets are an indication of operational friction not productivity. Deckhand resolves common questions on the spot and, when it can’t, converts the conversation into a fully contextualized ticket with one click, improving the employee experience and freeing our team from endlessly repeating the phrase: ‘Please file a ticket.’”

— Chris Collins, Senior Director IT at ShipStation Global

Solution overview

Deckhand works in Slack like any teammate—joining channels, reading the conversation, and drawing context from Slack profiles to answer IT questions in place. We run it on Amazon Bedrock AgentCore, a platform to build, connect, and optimize agents at scale, with any framework or model. AgentCore runtime, a capability of Amazon Bedrock AgentCore, hosts the agent in isolated sessions, so we run no servers or containers.

The solution has four main components, shown in Figure 2:

1. Slack service: A FastAPI and Slack Bolt application, hosted on AWS App Runner. It receives Slack events, decides whether the bot should respond, and builds a user-context payload from the requester’s Slack profile, including name, email, time zone, and manager.
2. Agent service: A Strands agent, deployed as a container on Amazon Bedrock AgentCore runtime, manages the multi-turn tool agent loop using Anthropic’s Claude in Amazon Bedrock.
3. Tools and knowledge: A single AWS Lambda function, exposed as Model Context Protocol (MCP) tools through AgentCore Gateway, a capability of Amazon Bedrock AgentCore, classifies requests, creates and updates Jira tickets, and analyzes images. An Amazon Bedrock knowledge base indexes content from Confluence, the company intranet, Slack, and marketing pages, storing it in Amazon Simple Storage Service (Amazon S3).
4. Operations and feedback. Amazon DynamoDB stores feedback, AWS X-Ray traces request paths using OpenTelemetry, and the services log to Amazon CloudWatch.

Figure 2: Architecture diagram showing Slack events entering the Slack service and Amazon Bedrock AgentCore runtime, with separate paths to an Amazon Bedrock knowledge base, AgentCore Gateway-backed Lambda tools, Jira Service Management, and DynamoDB feedback.

When an employee posts in a channel where Deckhand is a member, the Slack service assembles the full thread history and user context. It then invokes the agent through the AgentCore runtime API. The agent searches the knowledge base and calls tools as needed. When it finds an answer, it returns a final response (Figure 3). When it doesn’t, it asks a clarifying question or offers to create a ticket (Figure 4).

Figure 3: Deckhand responds with self-service steps

Figure 4: Deckhand offers to create a ticket

Deckhand workflow

This section walks through how Deckhand is implemented, from prerequisites to a working deployment.

Prerequisites

To implement this pattern, you need the following:

• An AWS account with access to Amazon Bedrock, AgentCore runtime, and AgentCore Gateway.
• A Slack app with event subscriptions, a signing secret, and a bot token scoped to your use case.
• A container image registry such as Amazon Elastic Container Registry (Amazon ECR).
• An Amazon S3 bucket and an Amazon Bedrock knowledge base.
• AWS Identity and Access Management (IAM) roles scoped to each runtime and tool, and AWS Secrets Manager entries for third-party credentials.

Building the agent with Strands Agents and AgentCore

The agent is intentionally lightweight. Using the open source Strands Agents SDK, an agent consists of a model, a set of tools, and a system prompt. The SDK manages the reasoning loop, allowing the model to select tools, process results, and iterate until it produces an answer. Deckhand’s agent service is implemented in a few lines of 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,
)

The model ID is set through an environment variable, which allows switching models without modifying application code.

Tools are integrated with the agent in two ways. Amazon Bedrock Knowledge Bases retrieval is a native Strands tool that supports knowledge base search with a single import. Other functions, including classification, ticket management, user resolution, and image analysis, are handled by a Lambda function registered on AgentCore Gateway. The Gateway exposes these as MCP tools, and the Lambda routes each invocation by tool name. This separation allows tool logic to be updated independently, and the agent can access new tools from the Gateway without requiring a rebuild.

AgentCore runtime hosts the agent as a container, avoiding the need for server or session management. The Slack service calls the agent synchronously for each message, providing the thread transcript and user context, and posts the final response. Since context, including the employee’s profile, is included with every request, the agent can complete ticket details automatically.

Knowledge base design and answer routing

Deckhand answers from a single Amazon Bedrock knowledge base with core S3-backed data sources:

• Articles synced from Confluence.
• Internal pages, PDFs, and events synced from the company intranet.
• Resolved support threads mined from Slack (covered in the next section).

Each document includes metadata such as title, source URL, content type, and event dates. This allows the agent to filter content, for example, when users ask about upcoming events or weekly lunch menus in the Austin office.

Mining Slack history with Recursive Language Models (RLMs)

The most valuable data source is the archive of resolved support threads. Before Deckhand existed, Slack was where problems got solved: years of employees describing issues and IT walking them through fixes. That history is an organic knowledge base, validated by the best possible reviewer: the person whose problem got fixed. It’s also noisy: a raw export mixes banter, automated alerts, and threads that never actually got resolved. Indexing an unverified fix or a garbled summary means the knowledge base surfaces an incorrect answer with the same confidence as a correct one, so extraction needs to be precise.

The mining process follows a three-stage pipeline (Figure 5):

1. A script exports the channel’s full history via the Slack API, retrieving complete replies for every thread and writing a structured dump that includes thread markers, timestamps, and reply counts.
2. DSPy’s Recursive Language Model (RLM), running Claude on Amazon Bedrock, treats that export as a navigable memory space inside a sandboxed Python read-eval-print loop (REPL) rather than a single prompt. Working iteratively over the data, it classifies each thread as resolved, unresolved, or escalated and filters out announcements and non-questions. Strict criteria keep quality high: a thread counts as resolved only when the full, workable fix is visible in the thread itself.
3. For each resolved thread, the RLM orchestrates recursive sub-LLM (large language model) calls to extract structured fields, each validated against a Pydantic model. The fields include an issue summary, the original question, and the resolution. They also capture whether the fix is self-service or needs a ticket, the self-service steps, the application and system involved, error messages, and tags. When a sub-LLM call returns something that fails the schema, the RLM’s code-based loop catches the validation error in the interpreter and retries. The results are written as a markdown document organized by issue. The pipeline uploads it to Amazon S3 for the knowledge base to index.

Figure 5: Export classification and extraction workflow of the Slack conversation

We chose RLM because it maintains the entire Slack history in a persistent sandbox variable space, allowing iterative reasoning over the export and consistent output structure. As a result, when an employee encounters a problem previously solved by a colleague, Deckhand provides the proven solution, often as actionable, numbered steps.

Knowing when not to answer

An AI bot in a shared channel fails socially before it fails technically. Deckhand’s most refined logic decides when to stay quiet:

1. The agent’s first decision on every message is whether it’s an announcement, a social message, or a conversation between people. If so, it outputs “SKIP,” and the Slack service suppresses the reply.
2. In threads, it replies only to the original poster.
3. If the last reply came from another human helper, it stays silent, because a person has taken over.
4. If a reply starts by @naming a person, the message isn’t for the bot.

Collecting feedback

Each answer includes feedback buttons. A thumbs-up is recorded directly, while a thumbs-down prompts a brief “what went wrong” field. Ratings are stored in DynamoDB with the original question and the bot’s response.

Negative feedback is a valuable dataset used to improve the system prompt and agent behavior, and to update incorrect knowledge base information.

Security and validation

Prompt rules enhance behavior but do not replace access controls. Enforcement is managed through code and infrastructure:

• Ticket creation requires explicit confirmation. When Deckhand offers to create a ticket, the Slack service adds a Create Ticket button, and selecting it sends confirmation through the agent. Ticket updates only accept valid keys matching the helpdesk project pattern and reject empty comments.
• Classification is validated before it acts. Request classification runs as a separate Amazon Bedrock Converse API call that returns structured ticket fields, validated with Pydantic before anything reaches Jira.
• The image tool is restricted to downloading only from Slack’s file host. It authenticates with the bot token, limits each request to five images of up to 5 MB each, and sends the files to a vision model using the Converse API.
• Credentials stay out of code. Slack tokens, the signing secret, and Jira credentials live in AWS Secrets Manager, and each service and tool runs under its own scoped IAM role.
• The prompt enforces behavioral safeguards: never request passwords or multi-factor authentication (MFA) codes, never write credentials in ticket comments, and never expose profile metadata used for ticket fields.

Outcome

Deckhand launched in April 2026. It started at about 30 messages a day and reached as many as 100 by early summer. In its first three months it handled 1,935 messages, started 1,221 agent conversations, and opened 409 Jira tickets. It replied to 97.5 percent of messages. A third of the questions came in after hours, when no one on the IT team was working, and Deckhand answered 94 percent of those. People who would have waited until the next morning got an answer that night.

Feedback improved as the team worked on it. Positive ratings went from 82 percent in April to 96 percent in June, after they revised the system prompt and knowledge base to fix what people complained about.

The clearest win was ticket deflection. An agent conversation is a question that would otherwise have become a Jira ticket. Of the 1,221 conversations, only 409 turned into tickets. The other 812 were handled in chat. Filing a ticket and then working and closing it runs about 30 minutes. Those 812 conversations add up to roughly 406 hours over three months, or around 1,600 hours a year. Employees kept that time for their own work, and IT never spent it on intake.

Conclusion

Deckhand took repetitive IT questions off people’s plates and gave the time back to employees and the IT team. It works because each part of the stack has one job and runs as a managed service: AgentCore runtime hosts the agent, AgentCore Gateway turns a Lambda function into MCP tools the agent can call, and Amazon Bedrock Knowledge Bases handles retrieval. The team shipped it without standing up servers or maintaining orchestration code.

To build a similar solution, begin with a well-maintained knowledge source and a clearly defined action. Refer to the Amazon Bedrock AgentCore documentation and Strands Agents SDK for agent development, and the Amazon Bedrock Knowledge Bases documentation for connecting content sources.

To discuss an agentic AI use case for your organization, contact your AWS account team.

---

About the authors

Kenneth Salmon

Kenneth is a Software Engineer at ShipStation Global specializing in integrations, workflow automation, and AI-driven systems. His work centers on leveraging applied AI, large language models, and conversational agents to solve complex operational challenges.

Edward Boswell

Edward is a Senior Software Engineer at ShipStation Global specializing in AI applications and rapid prototyping. He is passionate about using AI to remove operational bottlenecks and improve team efficiency. Outside of work, Edward is a former professional magician who enjoys entertaining at meetings.

Jack Armstrong

Jack is a Senior Software Engineer at ShipStation Global. He is a polyglot programmer experienced with Python, TypeScript, and other languages, with vast knowledge in software engineering systems, especially Amazon Bedrock.

Robert Banh

Robert is a Director of Engineering at ShipStation Global, where he leads a SWAT team focused on deploying AI across departments. He is passionate about solving problems and leveraging data to drive actionable improvements.

Nick Ciubotariu

Nick is the Chief Technology Officer at ShipStation Global. He has spent over two decades shipping enterprise-scale software and AI systems used by hundreds of millions of people.

Ravi Kashyap

Ravi is a Senior Solutions Architect at AWS who works with retail and e-commerce companies to build, scale, and optimize their cloud and AI workloads. He focuses on automation and applied AI, and he gives back to the developer community as an active open source contributor.