Snyk turns its internal support agent into a customer-facing feature, Snyk Assist

Snyk, a company known for scanners that find vulnerabilities in code and dependencies, has taken an agent that initially served only its own support team and put it in front of customers. The result is Snyk Assist, a customer-facing feature built on three components of the LangChain ecosystem: LangChain, LangGraph and LangSmith. The case study comes from LangChain's own blog, so it is the vendor's account. It gives no figures for the share of tickets resolved, response speed or cost. The main value of the story is therefore the route: from internal tool to product.

Why the path starts inside

An internal support agent is the safest place to test. The users are employees who know the product and will spot a mistake. A human stays in the loop: an engineer checks each answer before it goes out. Feedback arrives quickly, and the reputational risk is close to zero. Over that period the team can build a base of real questions, find where the model is confidently wrong, and improve its knowledge sources.

The requirements change when customers come into the picture. Answers go out directly, with no colleague as a safety net. The agent has to account for the context of a specific account and must not mix data from different organizations. For a company that sells security, a mistake costs more than it does for the average SaaS vendor. Bad advice about a vulnerability or a scanner setting undermines trust in the core product, not just in the chat assistant.

What each tool in the stack does

The roles of the components map well onto the task of moving an agent from internal to external use.

• LangChain handles the integration layer: connecting models, tools and data sources.
• LangGraph describes the agent as a state graph. It supports branching, checkpoints, and the option to insert a human-in-the-loop step or an escalation to a live engineer.
• LangSmith provides traces of every run, sets of test queries, and evaluation of answer quality before and after changes.

The pairing of LangGraph and LangSmith is arguably the key point of this case. The graph turns the agent's behavior into an explicit schema that can be read and constrained. Traces show exactly where the agent took a wrong turn. Without them, a customer-facing release becomes a lottery: you tweak a prompt for one scenario and quietly break three others.

What is known and what is not

• Product: Snyk Assist, a feature for Snyk customers.
• Origin: an internal support agent.
• Stack: LangChain, LangGraph, LangSmith.
• Source: the LangChain blog, published on October 9, 2026.
• Not disclosed in the available description: the models used, the share of resolved requests, latency, cost per ticket, and the policy for escalating to a human.

The last item matters. Without metrics, there is no way to say whether Snyk Assist reduced the load on support or merely shifted it elsewhere. A vendor case study, by definition, shows the best-case scenario.

What you can take from this

The main lesson is the order of operations. If you have an internal agent that reliably works for your support or DevRel team, it is not a finished customer product, but it is a good starting point. Before launching it externally, work through a few steps.

First, turn your accumulated internal conversations into a regression test set and run it on every model or prompt change. Second, define the agent's boundaries explicitly in the graph: what it answers, where it hands a request to a human, and which data it cannot access. Third, enable tracing from day one, not after the first incident. Fourth, choose your metrics in advance, for example the share of tickets resolved without escalation and the share of answers that had to be corrected. Without them, any discussion of impact will be as vague as it is in this case study.

One last point: treat vendor publications as architectural hints, not as benchmarks. Snyk's choice of stack is perfectly reasonable, but only your own numbers can confirm its benefit.