1 min lesson
Always frame automation by impact
Use the lesson to explain "How should you frame an automation you built when describing it in an interview?" Then make the next move clear.
Step 1 of 3
Always frame automation by impact
An engineer at Cursor doesn't care that you can write a script. They care what it bought. Frame every automation in the language of impact: time saved, tickets deflected or consistency gained.
Learn more
Full explanation
How Cursor's own support team runs on Cursor
How Cursor's own support team runs on Cursorthe workflow the workshop describes
Inside Cursor, a support engineer works less like a single chat operator and more like an orchestrator. The Agents window lets you spin up many agents at once - one per incoming ticket - then review the work as it streams in and tap into each individually with little context switching. "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." runs in one agent while "what does the analytics dashboard show" runs in another, so you keep a steady flow of ticket volume instead of serializing on a single thread.
Time is the scarcest thing a support team owns, so the orchestrator pattern - many agents in flight, reviewed as they finish - is how one person keeps up with volume.
"The biggest and most important currency that we have at Cursor and support team is time."
Learn more
Full explanation
Bring the context in, not just the code
Bring the context in, not just the code
Looking at the code helps, but the real gain for a support team is pulling the platforms you lean on most into Cursor 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.. Three pillars cover almost everything: ticketing, a knowledge base and customer context. Cursor's own stack wires up Datadog to pull logs straight in for debugging, Notion for the docs they live in and Linear for bug reports.
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
Code alone is one layer; the extra context sources are what make support joined-up. Cursor's own picks in parentheses.
The platforms the team relies on - ticketing, KB, CRM, logs - are what turn isolated answers into joined-up support.
"If you're just looking at the code that can be helpful in and of itself but providing these additional sources of context is what really unlocks a team."
Meet support where it happens: Slack
Cursor's Slack integration lets you invoke Cursor from where support conversations actually live. Ask a question in a thread - "is there dark mode support in the app" - and Cursor launches a cloud agent that answers. Follow up with "Cursor, implement a dark mode" and it spins up a remote agent on a fresh VM and takes a shot at the feature. The Slack conversation is mirrored to cursor.com, where you can follow the diff line by line.
A team variant turns this into async, shared support: a dedicated channel where people spin up background agents and ask questions in the open. The rest of the team sees the agent conversation and can engage - if they know the answer they jump in, if they don't they learn. You get asynchrony (no need to stay glued to the agent in the IDE) plus a layer where knowledge gaps surface and get shared.
Run agents in a shared Slack channel, not just your local IDE - the conversation becomes a team artifact others can learn from.
"Having like a shared space, whether it be in Slack or elsewhere to engage background agents, ask questions, have these asynchronous conversations."
Scripting to bridge data the dashboard doesn't expose
Customers ask for bespoke cuts of data the product doesn't surface - say per-user clicks per day when only combined clicks exist. A support engineer knows the platform well enough to scope this themselves: first check whether an existing API can provide it, and if not, write a small script (sometimes pulling a third-party API) to gather the info, one-off or recurring. The judgment is in keeping it small. Don't write a whole new API, don't stand up a new service on a cloud provider - if the ask really needs that, it's a feature request, not a support script.
Learn more
Full explanation
Keep scripts in scope
You're babysitting the agent toward a bounded result, not letting it build infrastructure. "I don't want you to necessarily write a whole API... don't necessarily add a new service. Don't host something on a cloud provider. Don't go crazy." If it outgrows a script, qualify it as a feature request instead.
Auto-run: agents that triage high-confidence tickets
The direction this is heading is autonomous triage. Cursor uses an auto-run workflow internally that fires a background agent on incoming bug reports that meet a confidence bar. The agent runs on its own, then a human reviews: merge if it's a high-confidence fix, or iterate with the agent if not. It's currently shaped around Linear's schema, with more connectors coming. The biggest lesson wasn't about the agent at all.
The background agent was effective with the data it had; the work was fixing the intake process so the right data existed in the first place.
"We need to iterate on our bug reporting process a little bit to make the right data available."
Walk into the tooling round with a real "I automated X and it saved Y" story, told start to finish: the toil you noticed, what you built, the language and APIs you used and the measured result. One specific, quantified story beats any amount of "I'm comfortable scripting."
LLM-assisted replies are impact, not autopilot. For an AI dev-tools company supporting senior engineers, an auto-sent wrong answer is a credibility hit. Draft with the model; have a human verify and own the message. Say this out loud in the round - it shows judgment, not just enthusiasm for automation.