Cursor for Technical Support Engineers: Workflows, MCP and ROI

Because the answers a support engineer needs are usually in the code, the docs, the logs or the customer record, and Cursor lets you query them instead of remembering them. The workshop presenters come from Cursor's own technical support engineering team. They described the role as the overlap of account management, technical support and product expertise. All three used to depend on knowledge in someone's head and slow manual searches through KB articles.

That leaves roughly 25%, which the presenters described as niche issues that need manual debugging outside Cursor, plus billing and account work whose context the team chooses not to give an LLM.

They judge good support on three traits. Speed matters because a blocked customer needs to get back to work quickly. The answer has to satisfy, since telling someone "it's broken" is a poor outcome even when the ticket closes. Support also has to be resourceful, because it catches the unpredictable issues that have no clear path. In the presenters' account, Cursor speeds up all three, and the engineer's judgment still decides the answer.

Use Ask modeA read-only mode for asking questions about a codebase without changing files; the safe way to explore unfamiliar or legacy code. Press Enter for the full definition. as the default, as the presenters recommend for research. Most support work is looking things up and understanding the product, not writing code, and their team uses Ask most often. Cursor's help center describes Ask as read-only and built for understanding a codebase: the agent explores, but it doesn't edit. That keeps it from "fixing" code you never asked it to touch. The presenters pair Ask with a cost-effective model, so a lookup doesn't spend many tokens.

Open every relevant repo in one workspace. As the presenters explained it, Cursor is a VS Code fork that works in a workspace, and the workspace decides what the agent can see. With your backend, frontend and docs repos together, Cursor can trace a feature end to end. In the presenters' example, asking "what happens when I click this button" with only the frontend open returns the frontend piece. With all the repos open, the agent follows the click through to where the backend stores the data.

1. 1Create one empty parent folder.
2. 2git clone each repo (main app, website, docs, scripts) into that folder.
3. 3Open the parent folder in Cursor as the workspace.
4. 4Ask modeA read-only mode for asking questions about a codebase without changing files; the safe way to explore unfamiliar or legacy code. Press Enter for the full definition. can now trace behavior across repos, not just within one.

A codebase with thousands of source files is not large by Cursor's standards, the presenters said, and Cursor handles very large monorepos. To give a team a smaller subset, they suggested .cursorignore, which keeps files away from the agent, or a team rule. Their own team pulls Cursor's website out into a sub-repo that people can iterate on for docs.

Team rules also give the agent default context, which is why the presenters' agents don't need a fresh briefing in every new chat. Team rules need a Teams or Enterprise plan. When context is split across ten or more repos, the presenters' advice is to use Plan modeA mode that makes no edits: it researches the codebase and produces an editable plan you review before any code changes. Press Enter for the full definition. to brief the agent before it implements anything.

Three, according to the presenters: your ticketing system, your knowledge base and your customer-context system. Ticketing means Jira or Intercom, the knowledge base means Notion or your docs, and customer context means Salesforce or another CRM. In their view, the code alone helps, but these three sources hold much of what a support engineer would otherwise keep in their head or hunt for by hand.

Their own team runs a Datadog MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition. that pulls logs in for debugging, a Notion MCP for docs, which it uses heavily, and Linear for bug reports. In the workshop, Cursor's MCP directory had a one-click install for Jira, and the presenter didn't think Confluence was there yet. The Cursor Marketplace, which offers one-click installs of official plugins, now lists an Atlassian pluginA Cursor marketplace package that bundles MCP servers and skills (sometimes sub-agents and hooks); one click installs all of it into your Cursor instance. Press Enter for the full definition. with MCP and skills for both Jira and Confluence. Cursor's docs say MCP servers like these are built by external vendors, not by Cursor.

Cursor's support team starts one agent per ticket in the Agents WindowCursor's surface listing your agent runs; open a run to read its diff and search transcripts from the command palette. Press Enter for the full definition. and reviews the work as it streams in. The presenters called time the most important currency a support team has. Instead of waiting on a single agent, you act as the orchestrator. You launch one agent for "how do I log in with SCIMSystem for Cross-domain Identity Management. A standard for automatically creating and removing user accounts when people join or leave. Press Enter for the full definition.", another for "what does the analytics dashboard show", and so on. Then you check each one in turn with little context switching, and one person keeps up with a steady flow of tickets.

Cursor's Slack integration brings this to where support conversations already happen. Mention @cursor with a prompt and Cursor starts a cloud agent. In the demo, a question about dark mode support got an answer, and "implement a dark mode" started an agent on its own VM that attempted the feature. The thread then opened on cursor.com, where the presenter followed the diff line by line. Cloud agents aren't included on Free or Plus.

A shared Slack channel for these agents, which the presenters also described, turns triage into async team support. Teammates see each agent's questions and answers, jump in when they know the answer, and learn when they don't.

Yes, and the presenters count docs among support's most valuable work, calling it low-risk, high-agency and high-impact. The old path was slow: support found a gap, filed a ticket, and a technical writer handled it eventually. With the docs repo in the workspace, support can check whether something is documented, make the change, render the doc site to review it, and open a PR from the same customer interaction. The docs then improve with what customers run into.

Scripts fill data gaps the dashboard doesn't cover. In the presenters' example, a customer wants clicks per user per day, and only combined clicks exist. First check whether an existing API can provide the data. If not, write a small script, sometimes around a third-party API, to collect it once or on a schedule. The presenters said support engineers know the platform well enough to scope this work and keep watch over the agent while it runs.

The demo also showed what goes wrong without that scoping. The presenter handed the agent several steps at once (check for an API, create one, write a script), and it ran rampant, generating routes and docs nobody wanted. The presenter's fix is to segment the problem or use Plan modeA mode that makes no edits: it researches the codebase and produces an editable plan you review before any code changes. Press Enter for the full definition., and to qualify an ask that needs a real feature as a feature request instead of scripting around it.

Match the model to the stage of the work, as the presenters do. For research in Ask modeA read-only mode for asking questions about a codebase without changing files; the safe way to explore unfamiliar or legacy code. Press Enter for the full definition., they pick a cost-effective model that gives a strong answer without using many tokens. For planning, they use a more capable model with a large context window to write a detailed plan. Then they switch to a fast model to carry it out, because the thinking is done and speed matters most. Cursor describes ComposerCursor's own fast coding model, tuned for the editor and priced well below frontier models; the recommended day-to-day model for executing a plan. Press Enter for the full definition. as its fast, cost-efficient model for interactive coding, and the presenters noted it can write plans too.

When you can't decide, compare. Cursor's /best-of-n command in the IDE gives each model its own worktree and runs the same task in all of them at once, so you can see which one suits the job. The presenter who ran the demo also runs one model twice to see how much results vary between runs, a variance he said always surprises him.

Running a prompt more than once costs tokens up front. In the presenters' view, it costs far less than working with the wrong model for a while and then redoing everything. They also said the plan documents are kept in state, so they don't use up memory. "Which model should I use?" is the most common question Cursor gets, the presenters said, and Best-of-N is their answer.

Cursor's support team escalates by sharing the Cursor chat itself, not a dry bug report. Escalation still happens, because some platform bugs need the code knowledge of an engineer who works in that code every day. In the presenters' workflow, support first investigates and qualifies the issue in Ask modeA read-only mode for asking questions about a codebase without changing files; the safe way to explore unfamiliar or legacy code. Press Enter for the full definition.: is it a bug, can it be fixed quickly, can customers be taught better? Support gathers its own context to cut back-and-forth, then shares the chat so engineering sees how far support got and where it ended.

In a company growing as fast as Cursor, the presenters said, the line between support and engineering blurs. Their support team also fixes bugs and ships small features with Cursor instead of handing everything off.

At the time of the workshop, they also described an unreleased internal feature called auto-run. It started a background agent on each incoming bug report that met a confidence bar, and a person reviewed and merged high-confidence fixes or iterated with the agent. It worked with Linear's schema, with more connectors planned. Cursor has since documented Automations, which run cloud agents on a schedule or on events from sources including Linear.

Auto-run's biggest lesson for the presenters concerned their own bug-reporting process. The agent did well with the data it got, but they had to change how bugs were reported before the right data was there.

Support's ROIReturn on Investment. The value gained versus what it cost, the language an economic buyer funds deals in. Press Enter for the full definition. doesn't fit the usual engineering measures of lines of code and pull requests, the presenters said, but its impact is similar if not greater. In our view, the closest support measures are the traits the presenters started with: how fast customers get unblocked and whether the answer satisfies them. To make the case inside a company, they suggested three steps: give support engineers access, bring your vendor tools in as MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition. servers, and work with the team to find its real pain points.

One limit is the context a team won't share. For the presenters, billing and account-specific work stays in the roughly 25% handled outside Cursor, because it carries context the team doesn't want to give an LLM. That line is a choice, and it can move. Account-management data can come in from your CRM over MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition. when it's safe to expose.

The presenters also said AI doesn't replace software engineering and problem-solving skill. The way people name and organize repos hasn't reached the agent yet, so human structure and choices still matter. Knowledge bases need guardrails too: their team uses a command it calls "de-slop" to strip AI artifacts, and it prefers quality checks when content comes in over reviewing what is already published.