How to turn a Zendesk or Intercom ticket into a Cursor agent task
Turning a Zendesk or Intercom ticket into a Cursor agent task means stitching four pieces together by hand. Pull the ticket into a prompt, tell Cursor which repo and branch to work against, start the agent, and review the pull request that comes back. Neither support tool does this in one step. Cursor's own list of places an agent can be triggered from is Slack, Linear, and comments on GitHub or Bitbucket, plus its own apps and API. A support ticket isn't on that list, in Zendesk or Intercom.
That's not the same as saying it can't be done, only that nobody ships the connector. Cursor's Background Agent API takes a prompt and a repo and hands back a running agent; the ticket text and the account details behind it are what a person, or a small piece of glue code, has to supply. Here's the actual sequence end to end, and the point where teams doing this by hand start losing the context that made the ticket worth escalating in the first place.
What a Cursor agent task is made of
Strip away the UI and a Cursor background agent task is a POST request. Per Cursor's API docs, POST https://api.cursor.com/v1/agents needs one required field, prompt.text, the instruction describing the task. Everything else is optional but does real work. repos takes a GitHub URL and an optional startingRef (branch or commit) so the agent knows what to check out, model.id picks the model, name labels the run, and autoCreatePR decides whether it opens a pull request when it's done. The response returns an agent ID, a status, a URL to watch it work, and a run ID.
For a lighter-weight version of the same thing, Cursor's CLI ships a terminal agent command. Run it interactively, or non-interactively with agent -p "fix the export bug described below" for scripts and CI. Prepending a message with & hands the session off to run in the cloud instead of your terminal. Between the API and the CLI, the requirement doesn't change. Each one needs a prompt with enough in it to act on, and somewhere to put the result when it's done.
Step 1: get the ticket into a prompt that's actually a task
A raw ticket isn't a task. "Route recalculation is stuck" tells an agent there's a bug; it doesn't tell it where to look, what a passing fix looks like, or how urgent the account behind it is. Turning a ticket into a prompt means adding three things the ticket itself usually doesn't carry on its own:
- The repro, stated plainly. What action triggers it, what should happen, what happens instead.
- A pointer into the codebase, if you have one. Even a wrong guess ("probably the routing worker,
apps/dispatch") saves the agent a search pass. - The account context, copied in by hand. Plan tier, prior related tickets, whether this is one report or the fifth.
For a Zendesk ticket, that's copying the description and the requester's account fields out of the sidebar. For Intercom, it's copying the conversation and whatever's on the contact and company records attached to it. Either way, nothing does this step for you.
Step 2: decide how the agent actually starts
Three ways teams trigger the agent once the prompt exists, in roughly the order they get adopted:
- Paste it into Cursor chat. For an occasional ticket, open Cursor, paste the assembled prompt, and work the bug in a normal session. No API key, no glue code, and it's the right call below a couple of tickets a week.
- Run it through the CLI.
agent -p "<assembled prompt>"from a terminal turns the same text into a scriptable command, useful the moment more than one person on a rotation needs to kick off the same shape of task the same way. - Wire a webhook to the API. Zendesk's webhook system sends an HTTP POST with a JSON payload when ticket activity happens, and a trigger can point one at a ticket's creation. Intercom's webhook topics cover conversation creation and replies the same way. Either one can call a small handler that assembles the prompt and POSTs it to
/v1/agentswithautoCreatePR: true, no person in the loop for well-understood ticket shapes.
Step 3 is where most teams stop building. A webhook handler that knows how to fetch the ticket is a day of work. One that also knows how to fetch the account plan tier, check for related tickets in a different tool, and decide whether this is a duplicate of something already fixed is a different, larger piece of software.
“we need SSO before rollout”
“any update on single sign-on?”
“SSO came up twice on this call”
Linear issue, quotes attached
insight report in Notion
CursorWhere the DIY pipeline runs out
The webhook-to-API pipeline, once it exists, does exactly what it was built to do. It turns one ticket into one prompt into one agent run, and it has three limits that show up in that order as volume grows.
It only sees the system it's wired to, so a handler built against Intercom's webhooks doesn't know a Zendesk ticket exists, and vice versa; covering both means building and maintaining two integrations, not one. Account context has to be fetched separately every time, too, because neither Zendesk's nor Intercom's ticket payload carries the customer's plan tier, ARR, or history in another tool, and someone writes that lookup once and keeps it working as account systems change. And nothing dedupes across channels. A ticket and a Slack message describing the same bug look unrelated to a webhook handler that only reads one source, so the same root cause gets reported, and sometimes fixed, more than once from different starting points.
Below a handful of these tickets a week, a person doing the copying by hand is a reasonable and cheap answer. The pipeline is worth building once the volume makes the manual version the bottleneck, and worth reconsidering once the gap in it, missed duplicates, missing account context, starts costing more than the automation saves.
What Modem does instead of the webhook handler
We build Modem for the dedupe-and-context step between the ticket and the agent task, and this guide comes from Modem. Modem's Zendesk and Intercom integrations read tickets and conversations continuously, the same way a webhook handler would, but cluster them against everything else Modem already has, including Slack messages, sales calls, and tickets from other tools, into one topic per underlying issue with every report and requester attached. An Intercom conversation, an earlier Zendesk ticket, and a Slack message describing the same failure land as one topic instead of three separate signals nobody connected.
From there, Modem's Cursor integration skips the prompt-assembly step entirely. The Modem agent composes the task brief from the topic, the actual bug reports and customer quotes, and delegates it straight to a Cursor Cloud Agent, which opens the PR against the connected repo the same way the manual pipeline does. The account tier and prior history a CLI alias never sees are already part of the brief, because Modem built the topic from all three sources before the task was ever created. It's the same building block from the routing-to-coding-agents comparison, applied specifically to Cursor.
If a ticket only ever needs a single, obvious fix and nothing about the account changes the urgency, the manual or CLI route from earlier costs nothing and stays worth using. Modem stops being optional once the same bug is showing up in more than one tool and the person triaging it has no way to know that without checking each one by hand, which is exactly what leaves a fix covering one report while two others go unconnected.
The prompt template comes before the webhook
Before building any webhook, write down the three-line prompt a well-scoped ticket needs: repro, a guess at the file, and the one line of account context that changes how urgent it is. Try it by hand first, through Cursor chat or the CLI, on the next few tickets that come in. When that same lookup keeps happening and starts costing real time, that's the signal to either script the webhook path above or connect something that's already watching every channel a customer uses, not just the one the ticket happened to land in. For the context-lookup half of this same problem on a single bug, see giving Cursor context about a specific customer bug report.
