Snyk moves its Assist support agent from internal tool to every paying customer

From support triage to a customer-facing assistant

Snyk describes itself as an AI Security Platform that finds and fixes vulnerabilities in code, open source dependencies, containers and cloud configuration. Its customers ask detailed questions about vulnerabilities, account context, support issues and product behavior, often in the middle of real work. Before Snyk Assist, the answers were spread across product documentation, support articles, release notes, learning content and account data. Finding them usually meant reading several pages or filing a ticket and waiting.

Snyk Assist is a conversational agent that answers in plain language and can act on a customer's behalf. According to the case study, it can look up open issues, check a package for known vulnerabilities, open a support case from the conversation, or log a feature request when a needed workflow is not yet supported.

The support workload was the original driver. Snyk's support team handles thousands of cases every couple of weeks, and each had to be read, classified by product, severity and owner, and routed. That became a scaling problem as customer inquiries grew.

Three phases, one runtime

Snyk did not launch directly inside the product. For roughly a year, Snyk Assist ran as an internal tool for the customer support team, acting as both a case triage tool and a virtual agent, with Snyk staff as the only users. The team says this surfaced edge cases that did not appear in offline testing, and that the feedback loop was measured in hours rather than release cycles.

• Phase 1: internal tooling for the support team.
• Phase 2: in April 2026, a launch to customers in the support portal. There it could greet users by name, understand account context, run a health check on login, and raise a ticket at any time of day without waiting for a human.
• Phase 3: on 1 September 2026, a move into the core Snyk product as a panel in the top bar of every page, for every paying customer.

The same agent runtime was kept through each phase. Only the surface in front of it changed.

Architecture: permissions, middleware and state

Snyk Assist is a single LangGraph agent behind a Slack app, a web app and direct API access, all routed through the same secured framework. Snyk says a small team wanted one runtime so it could fix bugs, ship features and handle incident response from one place.

The team lists four design decisions:

• Tools registered per user. Tools are attached at request time based on the permissions the signed-in user actually has, so the agent can only reach data that user could already see. Most tools are separate microservices that can be scaled independently.
• Middleware instead of plumbing. Context management, guardrails and model fallbacks hook into defined points in the agent lifecycle. Adding or reordering behavior takes a one-line change to a list.
• State in the checkpointer. Conversation history is persisted in PostgreSQL and keyed by session, which covers multi-turn memory, scaling across pods and resuming conversations.
• The loop as an internal platform. A shared factory returns the compiled graph and each team supplies its own configuration, so most new workflows are a config change rather than a new architecture.

Evaluation as a shipping gate

Because Snyk builds security software, the team says it had to prove that the agent answered correctly, refused what it should refuse, and never returned anything the user was not already allowed to see. Bailey Millns, AI Engineer at Snyk, is quoted in the post: "We run every change through evals in LangSmith, and if it doesn't clear the bar, it doesn't ship."

Offline evaluation uses two sets of test questions in LangSmith. One contains real questions with known good answers, marked by a second model, to show quickly whether a prompt or model change made quality worse. The other is an automated red-teaming exercise in which people try to trick the agent into ignoring instructions or handing over secrets. In CI, every pull request runs the real agent against those suites and blocks on thresholds committed to the repo.

Online evaluation grades every production run with a scheduled job, checking whether the question was about Snyk and whether the response answered it. Snyk says this gives a measured deflection rate rather than an estimate. Questions are also categorized by product area, topic, language ecosystem and error type, which gives product managers a live map of where customers struggle. Bad traces can be investigated and turned into datasets from the IDE through the LangSmith MCP server.

Results so far

According to the case study, since Snyk Assist went live to customers in April 2026 it has handled 60,000+ queries across 500+ customer accounts, and 85%+ of sessions were resolved without a support ticket. These figures are reported by Snyk and LangChain in the post.

For customers, the change means answers and routine actions such as opening a case are available inside the product they already use. For teams building their own agents, the example shows one approach: start internally, keep a single runtime across surfaces, tie tool access to user permissions, and make evaluation a condition for release.