Draft Zendesk replies from Pinecone, or flag a knowledge gap

Build an agent workflow that reacts to every new Zendesk ticket by searching our Pinecone index of previously resolved tickets and help center articles. When the retrieved passages are a confident match, draft a suggested reply grounded only in those passages and leave it on the ticket as an internal note. When the best match falls below my confidence threshold, skip the draft entirely and post a knowledge gap alert to Slack instead.

Trigger: an incoming webhook from Zendesk. A Zendesk admin will create an outgoing webhook plus a trigger in Admin Center under Apps and integrations, Webhooks, that fires on ticket created and POSTs JSON containing at least the ticket id, and ideally the subject, description, requester id, tags, brand id, and ticket form id. The workflow should accept that payload as its input and tolerate a payload that only carries the ticket id.

Step 1. Read the ticket. Call Zendesk Show Ticket with the ticket id from the webhook payload. Take the subject and the description, which is the customer's first message. If the body is HTML, strip it to plain text before searching. Keep the ticket id, the requester, and the ticket URL for later. If the ticket has no usable description, stop without posting anything.

Step 2. Resolve the Pinecone index host once. Pinecone data plane calls do not go to api.pinecone.io, they go to the per index host. Call Pinecone Describe Index for my index name and read the host field, then reuse that host for the search. I will give you the index name and namespace during setup.

Step 3. Search the index. Call Pinecone Search Records against that host with the ticket subject and description combined into a single query text. Search Records is the integrated inference endpoint, so it accepts raw text and embeds it server side, which means no separate embedding provider is needed. This requires an index created with an integrated embedding model, so if the search rejects a text query, tell me clearly that the index is not set up for text search rather than silently falling back. Ask for the top 5 matches, request the fields that hold the title, the resolution text or article body, and the source link, and turn on reranking so the scores are comparable across tickets. Read back every match with its relevance score.

Step 4. Apply the confidence threshold. Compare the best match's score against my threshold. Default it to 0.5 when reranking is on, or 0.75 on raw cosine similarity if it is not, and make the number easy for me to change in one place. Also sanity check the content, not just the number: a high score on a passage that is plainly about a different product or a different question is not a match. If the best match clears the threshold, go to step 5. If it does not, go to step 6. Never do both.

Step 5. Draft the reply and post it as an internal note. Write a short reply in our support voice, under roughly 200 words, that acknowledges the customer's issue in their own words and walks through the resolution. Every factual claim, step, and link must come from the retrieved passages. Do not add steps from general knowledge, and do not invent URLs. Attribute as you go, so each part of the answer carries a marker naming the past ticket or article it came from, and close with a short sources block listing each cited item with its title, its link, and its relevance score. Then call Zendesk Update Ticket on the same ticket id, adding a comment with public set to false so it lands as an internal note. Open the note with a one line header such as 'Suggested reply (draft, not sent)' so agents recognise it instantly. Do not change status, priority, assignee, or tags.

Step 6. Flag the knowledge gap in Slack. When the best match is below threshold, post no draft at all, not even a weak one. Instead call Slack Send a Message to my knowledge gap channel with the ticket subject, a one line description of what the customer is asking about, the ticket link, the best score we saw, and the titles of the two or three near misses so the team can judge whether an article is genuinely missing or just badly worded. Frame it as a likely documentation gap rather than a failure. This channel is meant to accumulate into a list of topics with no documentation behind them, so keep each message short and scannable.

Guardrails. The note must always be internal and never a public reply, since the assigned agent edits and sends it themselves. Never state anything the retrieved passages do not support, and if the passages only partially answer the question, say which part is uncovered rather than filling the gap. Before posting, call Zendesk List Ticket Comments and skip if a note with our header already exists, so retries never double post. If Pinecone or Zendesk errors, retry once and then stop quietly rather than posting a half finished note.