How ShipStation Global Built an AI Information Technology Help Desk Using Amazon Bedrock AgentCore

Meta description: ShipStation Global built Deckhand, an AI-powered Slack IT help desk agent on Amazon Bedrock AgentCore, resolving 97.5 percent of channel queries.

Tags: Deckhand, Amazon Bedrock AgentCore, IT help desk, Slack, AI agent

Featured image: Abstract friendly illustration of a Slack message becoming an organized IT ticket, with no real people, logos, or text.

ShipStation Global built Deckhand, an AI-powered IT help desk agent for Slack, on Amazon Bedrock AgentCore to reduce routine support load. The agent answers common IT and company questions from a curated knowledge base, reads error-message screenshots, and creates or updates Jira Service Management tickets. The ShipStation Global Engineering team reported that Deckhand resolved 97.5 percent of incoming channel queries and earned a 96 percent positive-feedback rating by employees in a three-month view of channel coverage and feedback. The material was co-written with Kenneth Salmon, Edward Boswell, Jack Armstrong, Robert Bahn, and Nick Ciubotariu from ShipStation Global.

The IT support problem Deckhand was built to solve

ShipStation Global describes itself as a leading intelligent shipping and logistics platform for small and mid-sized shippers. The company’s internal logic is simple: when support teams spend less time repeating the same answers, they can spend more time improving the customer experience. Deckhand is the practical expression of that idea.

Before Deckhand, IT support lived in a busy help desk Slack channel. Employees asked questions, and IT staff answered them one thread at a time. The information often already existed somewhere else: a Confluence how-to article, an intranet page, a PDF guide, an IT-maintained document, or an older Slack thread. The hard part was finding it.

Channel data made the pressure visible. 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. Repetitive questions consumed time that structured self-service steps could have handled.

Chris Collins, Senior Director IT at ShipStation Global, said the team wanted help to feel as simple as asking a question in Slack, rather than deciphering a ticket form or sending an email that might disappear. In that view, tickets are a sign of operational friction, not productivity. Deckhand resolves common questions in place and, when it cannot answer, converts the conversation into a fully contextualized ticket with one click.

How Deckhand works inside Slack

Deckhand behaves like a teammate in Slack. It joins channels, reads conversations, and uses Slack profile context to answer IT questions in the same place employees already ask.

The system is built on Amazon Bedrock AgentCore, a platform for building, connecting, and optimizing agents at scale with different frameworks or models. AgentCore runtime hosts the agent in isolated sessions, so ShipStation does not need to manage its own servers or containers for the help desk workflow.

The architecture has four main parts.

First, a Slack service receives events. It is a FastAPI and Slack Bolt application hosted on AWS App Runner. It 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.

Second, an agent service handles the conversation. It is a Strands agent deployed as a container on Amazon Bedrock AgentCore runtime. The agent uses Anthropic’s Claude in Amazon Bedrock to manage a multi-turn tool loop: it searches for information, calls tools, interprets results, and then either answers or asks for clarification.

Third, tools and knowledge are separated from the agent. A single AWS Lambda function is exposed as Model Context Protocol, or MCP, tools through AgentCore Gateway. These tools classify requests, create and update Jira Service Management tickets, and analyze images. An Amazon Bedrock knowledge base indexes content from Confluence, the company intranet, Slack, and marketing pages, storing indexed content in Amazon Simple Storage Service, or Amazon S3.

Fourth, operations are observable. Amazon DynamoDB stores feedback, AWS X-Ray traces request paths using OpenTelemetry, and the services send logs to Amazon CloudWatch.

When an employee posts in a channel where Deckhand is a member, the Slack service assembles the full thread history and user context, then invokes the agent through the AgentCore runtime API. The agent searches the knowledge base and calls tools as needed. If it finds an answer, it returns self-service steps. If it cannot answer confidently, it asks a clarifying question or offers to create a ticket.

Building the agent with Strands 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, letting the model select tools, process results, and iterate until it produces an answer.

Deckhand’s agent service is implemented in a few lines of Python. The model is configured with a maximum of 2048 tokens and a temperature of 0.3. The model ID is set through an environment variable, which allows the team to switch models without changing application code.

Tools are connected 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, run in a Lambda function registered on AgentCore Gateway. The Gateway exposes them as MCP tools, and the Lambda routes each call by tool name. This separation lets the team update tool logic independently and add new tools without rebuilding the agent.

The Slack service calls the agent synchronously for each message, passing the thread transcript and user context. Because the employee’s profile context is included with every request, the agent can complete ticket details automatically when a ticket is needed.

To reproduce the pattern, ShipStation lists several prerequisites: 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 the use case; a container image registry such as Amazon Elastic Container Registry, or Amazon ECR; an Amazon S3 bucket and an Amazon Bedrock knowledge base; AWS Identity and Access Management, or IAM, roles scoped to each runtime and tool; and AWS Secrets Manager entries for third-party credentials.

Mining Slack history without poisoning the knowledge base

The most valuable knowledge source was the archive of resolved support threads. Before Deckhand existed, Slack was where problems were solved: employees described issues, and IT walked them through fixes. That history is an organic knowledge base, validated by the people whose problems were actually fixed.

It is also noisy. A raw export can contain casual conversation, automated alerts, and threads that never reached a real resolution. If unverified fixes or garbled summaries enter the knowledge base, the agent can surface an incorrect answer with the same confidence as a correct one.

The mining process uses a three-stage pipeline.

First, a script exports the channel’s full history through the Slack API. It retrieves complete replies for every thread and writes a structured dump that includes thread markers, timestamps, and reply counts.

Second, DSPy’s Recursive Language Model, or RLM, running Claude on Amazon Bedrock, treats the export as a navigable memory space inside a sandboxed Python read-eval-print loop, or REPL, rather than as a single prompt. It works through the data iteratively, classifying each thread as resolved, unresolved, or escalated, and filtering out announcements and non-questions. The criteria are strict: a thread counts as resolved only when the full, workable fix is visible in the thread itself.

Third, for each resolved thread, the RLM orchestrates recursive sub-large language model calls to extract structured fields. Each field is validated against a Pydantic model. The fields include an issue summary, the original question, the resolution, whether the fix is self-service or requires a ticket, the self-service steps, the application and system involved, error messages, and tags. If a sub-LLM call returns something that fails schema validation, 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, then uploaded to Amazon S3 for the knowledge base to index.

The team chose RLM because it keeps 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 can provide the proven solution, often as actionable, numbered steps.

When the agent should stay quiet

A bot in a shared channel can fail socially before it fails technically. Deckhand’s most refined logic is not only how it answers, but when it chooses not to.

For every message, the agent’s first decision is whether the post is an announcement, a social message, or a conversation between people. If so, it outputs SKIP, and the Slack service suppresses the reply. In threads, it replies only to the original poster. If the last reply came from another human helper, it stays silent because a person has taken over. If a reply starts by naming another person, the message is not for the bot.

Each answer includes feedback buttons. A thumbs-up is recorded directly. A thumbs-down prompts a brief field asking what went wrong. Ratings are stored in DynamoDB with the original question and the bot’s response. Negative feedback becomes a valuable dataset used to improve the system prompt.

What the results mean for IT teams and employees

Deckhand shows how an AI agent can reduce routine support friction without replacing human judgment. For employees, the benefit is immediacy: common questions can be answered in Slack, after hours, without waiting for a ticket queue. For IT teams, the benefit is time: repetitive questions are handled on the spot, and unresolved conversations become contextual tickets instead of half-finished requests.

The reported 97.5 percent channel coverage and 96 percent positive feedback suggest that the pattern can work when three conditions are met: the agent has access to trusted knowledge, the knowledge is carefully extracted and validated, and the agent knows when to step aside. For teams already using Slack, Confluence, Jira Service Management, and AWS infrastructure, the architecture provides a concrete model for building a help desk agent that fits existing workflows rather than forcing employees to change how they ask for help.