ShipStation details Deckhand’s Slack workflow and Jira safeguards

ShipStation Global has detailed Deckhand, a production IT help-desk agent that answers employees in Slack and can create or update Jira Service Management tickets through controlled tools. In a deployment account co-written with ShipStation staff, the company said Deckhand launched in April 2026. During its first three months, it handled 1,935 messages, started 1,221 agent conversations and opened 409 Jira tickets.

ShipStation said Deckhand replied to 97.5% of messages over that period. The company also said one-third of questions arrived after hours and the agent answered 94% of them. The post does not define the after-hours window, provide the underlying message-level data or cite an independent audit.

The workflow begins when an employee posts in a Slack channel where Deckhand is present. A service built with FastAPI and Slack Bolt gathers the full thread and requester context before calling a Strands agent that runs Anthropic’s Claude through Amazon Bedrock. The agent can search a Bedrock knowledge base, ask a clarifying question or offer to create a ticket when the available material does not provide an answer.

The knowledge base draws from Confluence articles, intranet pages and files, and resolved support threads extracted from Slack. ShipStation said its extraction pipeline classifies historical threads and validates structured summaries before writing them into a document for indexing. AWS documentation describes Bedrock Knowledge Bases as retrieving relevant information from connected data sources to support generated responses; that mechanism does not independently establish Deckhand’s answer quality.

Retrieval and actions are separated. A Lambda function exposes classification, ticket management, user resolution and image analysis as Model Context Protocol tools through AgentCore Gateway. AWS’s Gateway documentation says Lambda functions can be exposed as MCP tools, with Gateway translating tool requests and responses.

Creating a ticket requires user confirmation. When Deckhand proposes one, Slack displays a Create Ticket button. Selecting it sends confirmation through the agent before the ticket is created. Ticket updates accept only keys matching the help-desk project pattern and reject empty comments. A separate Bedrock Converse API call produces ticket classification fields, which are validated with Pydantic before reaching Jira.

ShipStation described narrower limits for other capabilities. The image-analysis tool may download files only from Slack’s file host and accepts no more than five images of up to 5 MB each per request. Slack and Jira credentials are stored in AWS Secrets Manager, and each service and tool has a separately scoped IAM role. Prompt rules prohibit asking users for passwords or multi-factor authentication codes, as well as adding credentials to ticket comments.

Deckhand is also designed to avoid intervening in announcements, social posts and conversations between people, according to the company. Within threads, it replies only to the original poster, stays silent after another person begins helping and does not respond when a reply is addressed to a named person.

AgentCore Runtime hosts the agent as a container and maintains conversational sessions. AWS’s Runtime documentation says each session runs in a dedicated microVM with isolated CPU, memory and filesystem resources. ShipStation’s disclosed operations stack uses DynamoDB for feedback, AWS X-Ray for request tracing and CloudWatch for logs.

ShipStation said positive employee ratings rose from 82% in April to 96% in June after changes to the system prompt and knowledge base. The company did not publish the number of ratings, the participation rate, an accuracy evaluation or the underlying response data.

Of the 1,221 agent conversations, ShipStation counted 812 as handled in chat because 409 became Jira tickets. The company characterized those 812 conversations as tickets avoided and estimated about 406 hours saved over three months by assigning 30 minutes to filing, working and closing each ticket. It extrapolated that estimate to roughly 1,600 hours a year. The post did not provide a control group, deployment costs or evidence that every conversation handled in chat would otherwise have become a ticket.