Run a support agent internally first, then give it to customers
Snyk's support agent answers customer questions, checks account details and opens tickets, but only shows what each user is already allowed to see. It ran with the support team for about a year before customers got it.
Paste this into ChatGPT, Claude or your agent tool. See the prompt
- CS / Expansion
- advanced
- CS
- RevOps
- Category
- CS / Expansion
- Difficulty
- Advanced
- Est. cost
- Not stated by source
Works with
Problem
Customer questions needed answers spread across docs, support articles, release notes and account data, and every case had to be read, classified and routed by hand as volume grew.
Setup
Snyk Assist is one LangGraph agent behind a Slack app, a web app and an API. Tools are typed functions attached per request based on the signed-in user's permissions, so it can only reach data that user could already see. It can look up open issues, check a package for known vulnerabilities, open a support case or log a feature request. Conversation state lives in PostgreSQL, and LangSmith traces every step. Changes must pass offline test sets and red-team checks in CI before they ship, and a scheduled job grades every live conversation.
Prompt
Starter prompt by The GTM Agent Weekly, written from the setup described on this page. It is not the source's own prompt; see the source link below for their write-up.
# ROLE You are a support assistant. You answer questions, look up issues, and when needed open a support case or log a feature request. You only use data the signed-in user is allowed to see. # TOOLS (attached per user, based on their permissions) - lookup_open_issues, check_package, create_support_case, log_feature_request. # HOW TO WORK 1. Understand the question. Ask one clarifying question if needed. 2. Use the tools to answer. Cite what you looked up. 3. If you can't solve it, open a support case with a clear summary: what the user tried, what they expected, what happened, relevant identifiers. 4. If it's a product gap, log a feature request with the use case in the user's words. 5. Tell the user what you did and what happens next. # GUARDRAILS - Never reveal data the user cannot access, even if asked. - Never guess about security findings; say what the tool returned. - Don't promise timelines or roadmap items. # ROLLOUT NOTE (for the team running this) Run it internally first. Before each change ships, test against saved conversations and adversarial prompts, and grade live conversations on a schedule.
Replace every {{PLACEHOLDER}} before running. Works with any capable LLM and runner.
Tools
Steps
- Start with the support team as the only users, using the agent for case triage and as a virtual agent.
- Attach tools per request from the signed-in user's permissions so answers never exceed what that user can see.
- Trace every model and tool call, and turn early internal sessions into test sets.
- Gate every change in CI on a set of real questions with known answers plus a red-team set.
- Grade every live conversation on a schedule: was it on topic and did it answer the question.
- Move the same agent to the customer support portal, then into the product, changing only the surface.
Results
Snyk reports 60,000+ queries, 500+ customer accounts and 85%+ of sessions resolved without a support ticket since the April 2026 customer launch, with resolution measured by grading each live conversation.
What goes wrong
Gotchas
- Snyk treats proving the agent works as the hard part; nothing ships unless it clears the eval bar in CI.
- Permission scoping is done at the tool level per user, not in the prompt.
- Published by LangChain, the vendor of the framework used. (editor note)
Get 5 like this every week, free.
Real agent setups with sources and failure modes, in one short weekly email.
Free. One email a week. Unsubscribe anytime.
Source and credit
Oliver Armstrong, Snyk, on the LangChain Blog · vendor
Source dated 2026-10-08 · last reviewed 2026-10-12. Summarized in our own words; see the source for details.