Cursor for Support Teams

Kody Fisher Nov 13, 2025 1:00:00 124 transcript lines 25 terms defined Watch on YouTube Source page

Learn how support teams use Cursor to resolve issues faster and collaborate effectively with engineering.

Terms in this video

Transcript

Perfect. Awesome. Yeah. So, we'll run through these slides real quick. Um, yeah. The agenda today, I'll do a quick intro and overview. We'll talk through support at Cursor and what it looks like for us today. Noah will give a demo in terms of some of the real tangible things that you can use cursor for in this way. And we'll open up Q&A at the end. Feel free to ask questions along the way as well. We're happy to answer them and feel them throughout the

slides. Uh, no need to wait till the end necessarily, but we will leave time at the end for Q&A as well. Um uh in terms of who's here, so uh I'm here Cody. I I manage our technical sport engineering team here at Kurser. Uh and no is one members of that team.

Uh everybody wears a couple different hats here. So there's a lot of uh sharing responsibilities and just general collaborative effort to get things done no matter the role. But for us, uh our focus is a lot on on the technical support engineering side of the house and helping customers get the most out of cursor every single day. Um in terms of support cursor, what the role looks like and what we do. Um the it's similar to what you see principally

in other roles in other technical sport teams and other companies as well research understanding the product uh understanding the this field the space for us that's a lot of research into LLM into other AI tools into programming in general um and understanding things as a whole advising customers on their use cases on break fix issues uh on how to get the best out of the product uh etc and then escalating as needed support is inherently a very crossunctional role

there's a lot of work with with GTM or with sales folks with the engineering side with the product side um with everyone involved really crossunctional effort that sits at the heart of many teams across the company. Um these core principles are similar at Kurser as they are anywhere else uh in the sense of what support is and truly does. Um the big difference is the tools that we use at cursor make things a little bit different. Um some of the ways that that

define a critical support engineer define a successful sport engineer successful sport experience overall is the ability to be fast. Right? If a customer is blocked using your product, you want to be able to get them back on track pretty quickly. Uh, and let them use things as needed. If they reach out to support and it takes a long time to hear back, uh, they're not having a good experience. They they need some way to get back on into their healthy state.

Um, delivering a good experience or a satisfying experience, something that gets them back into a good and productive state. If you just tell them that something is not working, that's not a good outcome for them overall, even if you resolve the issue. Um, so delivering a satisfying response is really important. And then being resourceful as a whole. For support, you're dealing with the catch-all of many issues of what your customers can find and run into with the product that you support and offer. Um, and there's

not always a clear path for what they're running into. So, you need to be able to adapt to a lot of different things as a support engineer. Um, and help your customers get unblocked no matter what. Um, these things are all critically important pretty much no matter where you do support. But at Cursor, it's a little bit different in the sense of how we approach these things. Overall, uh, I think this next slide gives us the best like overview or sense of this uh, in

terms of like a ven diagram. support sits at the heart of these three areas where it's some level of account management, some level of technical support, and some level of product expertise. If you think about what support has been historically, a lot of these elements rely on like ingrain knowledge in your head. Like you have to remember what your product does, how it can break, how to troubleshoot, how to debug. These things are like critically

important to remember, but you have to remember them ultimately. You can have, you know, KB articles and documentation and whatnot. You have to know to find those, you have to go look through them, and you have to follow manual steps. um incredibly timeconuming, takes a lot of time to do. Um if you're fortunate that you do remember an issue off the top of your head, that's great. Makes it really fast. Um but if you don't, those are the tickets where usually your team loses a

lot of time. And if you're a TSSE or sport engineer generally [clears throat] takes a lot of time as well. Uh so building more efficient support team and building a higher performing support team involves being able to be better in these three areas mostly. Uh how cursor helps us do that. uh which no will get into some of the tangible examples but if you think of like the product expertise side for our team they're spending a lot of time interacting

directly with the codebase they can use cursor agent mode or background agents to talk directly uh to the codebase understand its context understand specific patterns if a customer is running to an error message you can easily ask cursor what that error message is how they got to that state what types of things could cause it um if a customer has experienced performance issues getting more information uh on what could cause that via cursor is extremely important too cursor helps with debugging directly um

cursor can even write responses for for you with emails and things like that. If you have the appropriate MTP servers to connect to your your support platform of choice, um, cursor helps uplevel your support engineers a ton or if you are a support engineer, it helps up level your performance every day a ton by being able to have more information readily available at your fingertips through an LLM and cursor. Um, and it makes the support experience much higher

throughput overall and a much better process as a whole. For our team, um, they're using cursor on roughly 75% of non-trivial sport interactions today. Uh, so really high usage for us. Um, and then the remaining 25% are usually pretty niche issues that require more manual debugging outside of cursor. Um, or things like billing and whatnot that require account specific context that don't necessarily want to give to an LLM. Um, so yeah, these areas are all

really important and cursor helps uplevel you in all three. For account management, as an example, you can pipe in your account management data from your CRM of choice into Cursor using an MCP server and make that readily available to the LM for use. Um, that makes it incredibly important if you have customers with specific details to maybe make them a bit unique from a contractual perspective or from a a use case perspective. Um, you don't need to

rely on your support that all offhand. You can make it available to the agent and make it really easy for your support to debug for them overall. Um, and yeah, [clears throat] cursor is fundamentally changing the way our team operates in technical support. Uh, and we think it can do the same for a lot of technical support teams, which is why we're looking to share out more information to make this more readily available to to teams overall. Um yeah, that's the intro

and the high level overview. No is going to walk through some more tangible use cases, but would love here to open up if there are any questions first before we jump into the the more tangible pieces. Let's see. Noah, do you want to kick us off with a little bit of a demo?

>> Yeah, for sure. Thanks, Cody, for for that intro. Let me just share my screen. Alrighty then. Um, so thanks everyone for joining this session. Um, we're going to kick this off with an example of a extremely contrived but hopefully illustrative example of an app that um I essentially vibe coded myself to for the purpose of this demo um which is click counter. And what this is is it counts number of times you click this button. Extremely exciting, highly commercial

opportunity. Um but essentially um we're we're showing this app as an example just to demonstrate um you know simulating me as a support engineer. How would I go about using cursor um to to support click um click counter in its operations and customer uh requests that might come in. Um and so want to run through a few things really quickly as to how cursor can be effective for this purpose. Um the first thing I'll talk about is the file structure. So um

cursor operates similar as a VS code fork in what is called a workspace and so the workspace defines basically the domain in which cursor can operate and it also sets the parameters in which the AI tooling can can operate in which the context it can provide. That's last part is the most crucial. If you have your backend docs and your front-end repos all in one workspace, what you're doing is enhancing cursor's ability to add context between those different

repositories and essentially you're enhancing the ability to get a full context um much better understanding of features end to end. So if you wanted to ask you know at when I click this button what actually happens in the back end um we can actually do that actually. We'll just go quickly to our agent, the new agent view introduced in cursor 2.0. We'll run a new agent and we'll say explain what happens when I click the button.

Um, we're using cursor's composer one model, which is our highly intelligent state-of-the-art model that was released last week. Um, and as you can see, there's context that's um, provided basically from the front end all the way through to the back end persisting that data. Um, and so that's possible because you have these different repositories included in this context. If you didn't, you may just get the single piece um of a front end.

>> Noah, can you open uh in full screen and make it a little bit bigger for the folks? >> Yeah, absolutely. Thank you for that call out. Um, cool. So, um, yeah. So, that's that's the multi-reo workspace is really important and something that maybe people don't always take full advantage of. But the other thing I wanted to call out is, um, ask mode, which is a somewhat, let me see if I can make this a little bit bigger. Um, so in cursor, we have several different types of uh, modes that you can do to change

the tooling that's available to the cursor agent, to the AI. Um, we have plan mode, which we'll talk about in a second. um ask mode and agent mode. Agent mode basically provides the full suite of um code writing, editing, file transfer and such capabilities. It has access to the terminal. It has access to um a whole host of increasing features that we're shipping constantly. Um but as a technical support engineer really what you're doing most commonly is

research. You're doing product support. You're understanding the product and the product platform. Um and so the most useful and most efficient way of doing that is using ask mode. It doesn't provide any write or code editing or file transfer abilities but it will give you sim search. It will give you the ability to understand more about your about your site. And so um you know I asked this previous question in agent mode. If I asked the same one in ask

mode it would do the same thing. Um where does the click data persist? Um, and it this will give me um with cloud 4.5 sonnet also a great model um a very similar uh response but it's cost- effective and it doesn't need to take up a ton of tokens. Um it should give your support engineers the tools they need to get the information they need. Um yeah and so whenever you're doing research u you know we recommend using mode. We use that most commonly among

our tasks. We don't necessarily need to write code as much as we're just looking it up. So really important thing to call out. Um, customer question might come in and say, "How do I log in?" I'll open up a new window, chat window here, change it to composer so it's faster, and just say, "How do I log in?" Something basic.

We were to log out. Um, pretty simple question, but we need to create a new account actually. Um, this should give you the ability I think it's going to actually describe what how to log in locally, but essentially it this illustrates that it can get the job done um in answering customer questions. Um, cool. So, the other thing that we use commonly at Cursor is the different integrations that we have available to us. Um, so you know, customer work happens in all sorts

of different places. Here at Cursor, we're a big Slack shop. Um we have a lot of conversations back and forth. Uh we have customer interactions in Slack. We talk about customers in Slack constantly. Um and it's really helpful and something that we're uh trying to uh guide the product in that direction is being able to support and use cursor wherever you are. And so being able to use cursor in Slack is one was one of our first integrations we shipped. Uh

this was a few weeks ago, but it's a really powerful tool that um and please excuse my my madeup Slack um workspace here, but um essentially using integrations with Slack, you're able to basically invoke cursor remotely um which can help a lot with sort of the context and natural conversation that you might have. So let's say you know in this example, cursor is there dark mode support in the app. Um I launched a cloud agent cursor um in based off the

integration was able to determine no there's no dark mode in the app. Um I could invoke cursor again and just say cursor implement a dark mode in the app. Um and what this is going to do is spin up a cloud agent, a remote agent that's going to generate a VM. It's going to um use the settings that we can talk about in a second, but basically provide the means by which the AI is going to um take a shot at implementing this feature. Um and so if we open in web,

I think this is the wrong login. Pardon me. If I give me one sec, I'll take a look at it. Actually, >> while you're working on that note, I can share um a little bit more detail on like the background agents use case. One thing this enables is more of like a team sport aspect of support. For us, we have a channel where people will just spin up background agents and ask questions and then the rest of the team can see that and interact with them as well. So if they know the answer, they

can engage as well. Or if they don't know the answer, they can also learn. So having like a shared space, whether it be in Slack or elsewhere to engage background agents, ask questions, have these sort of asynchronous conversations. Uh not only does having the asynchronous piece help a lot. So you don't need to be synchronously engage with the agent in the IDE. uh but also enables a little bit of a team aspect where everybody can ask questions, share what they don't know, engage with background agent and then uh

help have a little more of a collaborative element of the team. Definitely. Cool. So, uh logging back in to the correct um the correct login incursor.com um you see that conversation was sort of copied over from Slack. Um we have this my followup of implementing a dark mode in the app feature. Um we can also follow this along basically the codes uh code being changed line by line. Um you know there's uh basically going to show you in a in a new uh way of of showing

diffs and showing the the code that is being written. Um you'll see that uh we have this new editor view which we found very popular um internally and externally as well. But essentially as code gets written and generated it appears here. Um so pretty easy and intuitive to to review as you as you move along. Um but yeah it's very powerful tool to be able to use it in Slack. Um and something that we use frequently.

Cool. Um so uh that's Slack commands. Um one other thing I wanted to talk about too is the ability to um spawn a bunch of agents at once. So uh frequently the the biggest um and most important currency that we have at cursor and support team is time. Uh being able to allocate your time correctly, being able to get to every customer in an appropriate and and fast way um with with good resolution and good satisfaction is probably the utmost importance and the thing that we uh measure ourselves on most most

consistently. And so um this new agents view that was released in cursor recently basically provides the means by which you can orchestrate agents as you know a support engineer as a support architect of of the platform um to see sort of have lots of processes running at once being able to switch back and forth with little context switching um being able to maintain your consistent flow of of ticket volume. Um, and so, you know, if we're gonna put in a bunch

of different tickets, um, how do I log in with SKIM? Um, what does the analytics dashboard chart show? Um, sort of just random questions that might come in. Um, you'll see that we have this nice flow of being able to review the work as it comes in, being able to see how the agents are progressing and then tap into each one individually as it comes. Um, this is an extremely powerful workflow and something that really has turbocharged our impact here.

If we go back to the editor, we can see um what I was referring to here was this analytics dashboard um which shows all these lovely uh users of click counter um and and their individual um uh click metrics. So if we go back to the agents or type in here, but I prefer the agents view um what is measured specifically by a click. um you know we'll we'll be able to essentially just keep the workflow going. Um be able to understand a as um we view in the browser here uh the the inapp browser support um we'll be able

to sort of have an understanding of a locally run version of the app while also working within the agent itself. Um I see a couple chats. Yeah. No, I've got a question from the chat for here. >> Yes, please. >> Or I can answer it, Jim. How do you manage different areas of accumulated context such as previous answers or background dog questions for particular areas? Does it get stored in a knowledge base? >> Would you like to take a stab at that question, Cody? >> Yeah. Um, so for us, we don't store

those in like a repository or anything like that. We have a third party solution that we use and integrate with. Uh, and then that enables more deep research tools. Uh but that tool has context on all of our support tickets, all of our historical data that we've done with support interactions and then we can use that in cursor. Um so for us it's stored in a database with a vendor that we have and then we can leverage that as as data within cursor itself. Um

so the answer there is not it's not stored as like what you would think of as like a typical code repository. It's more stored in an external source and then brought in by via MCP. I do think that question is interesting because it does tap into something that could be done which is if you did have your context and in and knowledge stored in code stored in markdown stored somewhere that cursor could interact with it that would definitely provide

the context that you would be able to access within the ID within the AI itself um and would enhance the agent immensely. So, um I think there's like a a good line of thinking there that could definitely be a powerful um means of using interacting with cursor. >> Uh cool. So, before you keep going though, there's a couple more and see we can >> Yeah. Um starting from the top down here, how are these agents question agents questions answers visible to other sports if they're not done from

the Slack channel? Those are actually done from the Slack channel. So for us uh what it is is we just have a slide channel where people can invoke background agents and raise topics there. Um it's not done within like the web view for cursor or anything like that. That's not where the like team aspect comes in. It's more within a shared um team slide channel there. Uh the next one is uh let's see a common workflow as a part of as far as support escalation goes is customer opens a bug or question support triges to product

engineering if needed the issue is reviewed answered resolved the bug is open etc. Is the cursor team using ask mode solely for situations like the above? I'm just a bit curious how if the team loops in engineering your product if at all anymore. Uh do you want to take a first pass there? No one I can supplement. >> Yeah, definitely. Um so I think that this speaks to sort of the nature of support engineering itself which Cody described pretty eloquently before but in in my own words I I I do think that

escalation still happens. There's still bugs with the with the platform. there's still uh knowledge that is specific to someone who has built and is working in code uh day in day out that they would be able to solve more efficiently and more accurately than a support engineer which operates more as a generalist. Um and that triaging and that information gathering is something we focus on a lot. I know Cody is actually leading these efforts here at Kurser as well.

Um, and it's extremely important for us to be able to move quickly, basically gathering our own context so that um, there is as little thrash in passing that off to the platform engineer as possible. Um, and so, you know, we're using ask mode um, to get to the analysis and the triage and the qualifying step of is this a bug? Is this something we can fix quickly? Is this something we can educate on better? Um, and then once we gather that context, we're able to pass off a pretty informed ticket to a platform engineer

if that makes sense. >> Yeah. And then I'll I'll supplement that with uh a little bit of like a unique context in our space where we're in a period of hyperrowth. So we have far more customer asks than we have people that staff them right now. So we the team does not resolve every bug inherently. They do need to pass engineering and we do operate as a company this way. But the team does fix bugs, ship features using cursor, etc.

within technical sport which I think is a big up level from where we were in technical sport as a field in the past where it was typically very segmented between the two. There's a lot of integration overlap between uh the teams and and it's not uncommon for us to start a chat and cursor uh investigate the issue as a technical support engineer say that okay this is a bug somebody with more experience in this particular domain needs to look into it

escalate to engineering and share the cursor chat there directly so they can have context on where they've reached like what the end state was basically handing an escalation over from that point forward and handing that chat over um instead of just it being like a dry context and like this looks like a bug type of escalation. So um still very much a cross functional role in terms of an engaging engineering and product uh but it's a little bit more collaborative

and a little bit more support is able to go farther with things than they were in the past I would say. Awesome. [snorts] Uh is there a Jira and Confluence connector and is it possible for ASMO to query such knowledge bases? Um so there are Jira and Confluence MCP servers. Um, I've seen customers, we don't use those at Cursor ourselves, so I can't speak to their efficacy quite so much. I've seen some pretty good use cases uh where people are able to uh

invoke those MCP servers, get context from existing workflows within Jira, for example, and then be able to use that uh to to answer their research and help augment it. So those definitely uh do exist um but they're not built in as an integration with cursor specifically. >> Mhm. [clears throat] We do have the Jira. So if you go to the cursor MCP directory on our website, there is a one-click install for Jira in particular. I don't think we have

Confluence yet. U but you can install the Jerro one really easily within your MCP uh service and cursor. Um and then yeah, generally one of the biggest unlocks for our team uh if you think of like the three most common support plat or software platforms that your team relies on outside of uh your own product. So let's say it's you know your ticketing management system whether that's Jira or intercom or or wherever um you have some knowledge based

solution maybe it's notion maybe it's your docs etc. Um then you have some customer context solution let's say it's Salesforce or wherever bringing those in as MCP servers is what provides the context and makes support really effective in cursor 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 to to make things really seamless and integrative. Uh for

us it looks like we have a data dog integration and so we'll pull logs directly into cursor and use those to debug. Um we have our our documentation in notion so we use a notion MCP server pretty heavily. We do our bug reporting in linear so our bug reports come right into the the product etc. So um MCP servers are one of the biggest unlocks for us in terms of getting the team to to uplevel and move forward with curtainer.

>> Awesome. Uh I'll keep on moving down Noah if that's all right. >> Go for it. Yeah. I've noticed that you don't need to onboard a new chat agent to your workspace. Is this because the code base is small? Every time I start a new chat, I have to tell a new agent to first onboard itself to the workspace and customer framework before I can have a meaningful interaction.

>> Yeah, please. >> Yeah, I think that it depends on the the context really. It's number of repositories that that you have. We uh I wouldn't say our code base is small, but it's the primary context is split across like two or three repository. So the the LM is able to pick up on the context really quickly. Additionally, we use team rules. So we have a pretty good structure around like giving the agent context by default. Um so in our way it's like fairly easy for the agent to pick up really quickly. But for people

that have let's say large model repos or their their context is split across 10 different repositories. um depending on how your structure is, it may make sense where like this is more of a challenge for you where you have to educate the agent first before uh using it. That's where something like plan mode is super effective because you can then plan with the agent, give it the context and sort of like force it to think about its steps before getting into the actual

implementation um or into mode even. So, uh yeah, plan mode could be a good use case for this as well as rules uh as a good way to to give that the agent context every time instead of having to manually type it in. Um, so we got uh one more here. I'm experimenting with bootstrapping my own.

Google should let you terraform workspace administration repo by Google's open source gam to leverage cursor agent hooks Gemini CLI and terminal plus local context partnering with me on this at all. Um, yeah, John, feel free to reach out to our team highcursor.com and we'll go ahead and help follow up with you there. Uh, and maybe explore partnership opportunities more deeper. I think we'd probably want a little bit more information to before commenting anything, but sounds like an interesting

opportunity. We'd love to hear more. And John with another one. Are there any plans to ship workload identity federation connectors to cursor for better secret management versus how sometimes agent will read Cervice account keys, API keys, etc. despite any all get ignore etc. Um yeah, uh security is definitely a big u big piece for us and sec secrets management is really important. Um, LLMs are inherently nondeterministic by design. So, there's definitely an element to this that we need to be really careful with. Um,

we're adding more controls generally in terms of how secrets are managed and ensuring that the LM does not touch those depending on what you're, you know, there's various use cases for secrets management overall. So, it's not a one fix solution. Um, but like for cloud agents as an example or hooks as well. Um, a lot of ways to go about this. So, I wouldn't say that we personally are developing connectors for workload at any federation. It doesn't

mean that other providers in the space are not. From our perspective, we're more focused on like systemic ways to manage secrets in a couple ways. I know I can talk about hooks here too. >> Yeah, for as Cody mentioned, for the more deterministic uh workflows where you need to actually hook into the agent loop, um we have a feature called hooks, which basically allows you to configure um some abstract piece of code, whatever it may be, um some program that you want

to invoke yourself or application rather. Um which should allow for some of this secrets management. Um, we've seen people use it for, uh, filtering out agent responses, um, you know, searching for secrets and and the like. We've seen people use it to augment their own analytics and be able to track usage, um, on the team level. Um, so there's a lot of potential applications.

We're still sort of examining what those might be ourselves. But um this is our way to basically allow you to hook into that loop and be able to run something um that will always cons consistently run versus relying on the LLM to decide that it should.

Cool. These are really great questions. Um please keep them coming if you have any any more. This we definitely want this to be as interactive as possible. Um, but I'll keep going and I'll talk about um really quickly what happens when someone um Oops. Sorry about that. What happens when someone um writes in with a bug issue? Um something that you may not fully be able to to talk it through. So, um, one that I am going to cheat and prompt myself with is, um, I

clicked the button a bunch of times and then exited my window and the clicks didn't count. Why is that? Um, and I know the answer. Um, but we're going to just check to make sure that the AI can determine that itself. Um, and essentially the answer as as just a um spoiler is that um this is on a uh a timer that just to make it as responsive as possible when you click um we're waiting to make a network request to the back end to save these clicks. Um so let's see what happens. Uh clicks were

debounced if you close the window before the debounce was complete. The async uh async sync didn't finish depending clicks were lost at a batch end point. So this is basically um uh fixing it so that these uh clicks will happen um in a way that they will be saved even you know ensuring that if you were to navigate away from from your screen that they would be saved. I actually don't want that. I like having this sort of batch submission. So I'm just going to click undo all here and basically revert the stage back to uh

the state back to where it was before. Um if I wanted to get the information I should have put it into ask mode. So, what I'm going to do here and is say um answer the same question. Um and this way it will not actually change it. It will not take it on to it the agent will not take it onto itself to make the change that it assumes I want to make. Instead, it will just answer the question. Um which is ultimately what most of what we want when we're working in support. Um and so yeah, able to pretty clearly

list out the problem. Um and you know uh a big workflow we have here is we'll just copy and paste images, copy and paste uh full question questions directly into um the agent le take a stab and then follow up by investigating a little bit further with with the platform itself.

Um cool. So um one other thing that we do a lot at as a support engineer um is we are responsible for updating docs and ensuring docs docs are accurate. Um so I mean one thing that might be important as a follow-up for you know button clicks are not registering is we'll just check quickly is this information reflected in the docs. Um ultimately it's not just answering questions it's answering questions and enabling customers at scale. um being able to have control over something like docs, pretty low risk, pretty high

agency um and and high impact for a support team to be able to control. Um so having cursor be able to help you identify if something is documented, ship the change to it um and then review it is is very important. Um so it looks like it's not documented anywhere. Um I'm going to have cursor switch back to agent mode. Please update the docs with this information.

Um, and we'll just let the agent take care of that for us. Um, we'll go back to a couple of the we opened up a couple other agents before and we'll just take a look at those workflows here. What does the analytics dashboard show? Um, this is just a pretty self u pretty clear explanation of the clicks. Um, how long with skim? Uh, there's no skim implementation which is correct. And what does a click mean? A click is just um an authenticated user clicking that button. [clears throat] So um pretty

straightforward but and again this this example is is very small and very contrived but hopefully it you can see how it can scale to to a larger platform, a larger product. Yeah, I'll add here. Um, typically documentation writing has been something where you kind of throw it over the fence. Support finds a gap. They'll lo a jur ticket. They'll lo a ticket and then you'll have a technical writer go work on it. But this enables you to it removes that sort of like fence in the middle and just, you know, support has

done the interaction. They know how to do technical writing. They do it every day. Um, and they can go and update the docs pretty much directly based off of a cursor interaction if they have the docs the documentation reopened in their in their uh cursor instance. Um, so this like makes your process much smoother instead of having to do this big hand over to some documentation team. Uh, for us, our TSCs are updating the documentation pretty frequently. Um, and

it's all based on what we're hearing from customers. There's a very strong feedback loop in terms of where we can improve and what we can do to make the docs better. Um, which is really fantastic for us in terms of making things uh, continually improving. Definitely.

Cool. Um, so we'll just have this please implement these doc change. Yep, actually I did that. Sorry. Um, so we'll just review and take a look. Uh, click recording system uses optimistic updates. Yep, looks great. Um, please render the doc site um so that I can review the changes and so that I can review the changes and we'll just have um cursor um hoist this up for us to take a look at and make sure it looks good before we open a PR for it and update it fully. Um and so while it's doing that, another

thing I want to talk about is um the use of scripting. And so one of the most powerful ways that we're able to make a difference and the support team is connecting pieces of information that may be disperate between the platform. Um so there's a lot of information that we gather at cursor within our platform.

Um oftentimes we find customers have some pretty bespoke needs. they have some analytics needs that that isn't covered in the dashboard. Um they have some billing questions, etc. Um and sometimes they just need something that's going to get the job done either with existing APIs or something that you need to spin up quickly um on its own. May need to incorporate a third party API. Um and that's where scripting can really make a big difference. It can

really help um bridge that gap and and get the information that your customer may need either on a recurring basis or or or bespoke. Um and so um one question hypothetically is let's say you're um logged into uh click counter and all right you see all users combined clicks per day but um a customer is writing in and wants to get um per user clicks per day. Um write check to see if an API exists that can provide that. Um if not create one write a script that will gather this information or harper

atclickounter.com. Um so we'll let click on that but this is like a very common thing that happens is all right we don't exactly have this support in the platform but our support engineers are knowledgeable enough about the platform to be able to sort of come up with the steps needed. they're able to sort of uh babysit the agent to understand. All right, I don't want you to necessarily, you know, write a whole API. I I allowed it to just because

we're again in a pretty small example here, but don't necessarily add a new service. Don't host something on a on a um cloud provider. Uh don't go crazy, but get see if there's anything available um that is small and in scope. And if so, um let's try and solve this problem that way. if it needs to be a broader feature request, we can qualify it and and fix it that way as well. But um hopefully this we can get what we need just by just by doing this. I see a

few more questions which I definitely want to prioritize. Um Cody, do you want to start reading those off? >> Yes, let's do it. Um first question here. Does cursor have the ability to asynchronously watch a backlog, say Jira or Azure DevOps? Then when a work item that meets a criteria is created, triage the work item, generate a confidence or probability score. If high confidence or probability then autonomously get to work by cloning the repo, making a

change, opening a pull request. >> Wow. >> I can take that one too if you want. >> Yeah, go for it please. >> So, um, this is not released yet, but one thing that we're working on right now and that we use pretty heavily internally is called an auto run feature for tickets like this in particular. Right now, we're pretty heavily focused on linear, but you can see the applicability for things like Jira and other tools. Once we get there, what that looks like is for our bug reports,

we automatically run a background agent on them uh based on a certain set of criteria. Um that isn't particularly important for this audience, but basically ones that we feel there are high confidence in that the the agent can go fix. The background agent will run autonomously. A human will review them and then if they feel that it's a high confidence fix, they'll merge the fix. If they feel it's not quite right, they'll with the background agent, etc.

Um so it's it's very it's very much oriented around Linear's sort of like schema and way the world works. But um we are using this internally. We're working on building this externally now including more connectors as well. Um for us yeah the biggest learnings from doing that aren't that like the background agent is actually really effective with the data it's given but we found that we need to iterate on our bug reporting process a little bit to

make the right data available to the background agent in order to make this really effective. Um so it's been a really awesome learning for us in terms of how to make this a really effective and end asynchronous bug rel resolution process. Um so the answer is not quite yet in the way that you're describing Nate but we are working in that direction and we're hoping to release more soon here in the coming months. Um, I'll just add that, Nate, I think

that the way you're thinking about how to have agents orchestrated in a way that a lot of this back and forth information transfer human checking something over and over again on repeat, this is exactly the sort of problems that we're looking to solve um with the direction of the product. And so I I do think to echo Cody's point that this will be something that we will solve either directly in the product or give you the tools to solve yourself in the

notsodistant future. >> Some uh next question. One double-edged sword of easier AI jet is AI slop ruining knowledge bases. any examples of support teams doing wrote or semi-automated copy editing to catch lowquality contributions human added to our enterprise knowledge sets with little to no review editing. So we maintain highquality KBS wiks in our internal uh knowledge bases for tools.

Uh for this one um so we somewhat some people know about this some don't but we definitely fall victim to this as well where like AI will generate things that don't necessarily match our goals and intent. We have a a team command called dlop which is our term for like getting rid of AI uh things that we don't necessarily want. For us this is a lot of like encode. It's a lot of ancillary comments that explain it thinking but don't necessarily help longer term. Um

for knowledge bases and things one way of this is like to tell the agent to be very verbose uh in cases where it needs to or to be more concise where where you feel it's appropriate. Uh it's a little bit particular for your use case. Um, for us it's less on the automatically reviewing the content of the knowledge base itself and more so on the intake side when somebody's submitting a change to the knowledge base, adding better guardrails and things to help ensure

that the content that is added matches the expectations of what we would want. Um, I could see a use case for having like an agent automatically review your like you could spin up a background agent to do this and review for like cases where the knowledge base could be improved. Uh, but in terms of how we approach this is typically more on the intake side rather than the the content review side once it's already published.

Uh last one here. We have a large C++based program, thousands of source files. Uh would support teams need the full code checked out to do the same sort of thing as you're showing here? Uh so and this is a a good question. I will just say generally uh in terms of like what we've seen from customers, thousands of source files isn't uh like the largest that we've supported at Kurser. We typically have uh a really large reposit mon repositories monor

repos that we've supported pretty well from a perf perspective. Um so the thousands of repos or files requirement isn't necessarily too scary from a perf perspective. But if you did want to segment and like say give your your team access to a smaller subset of the repository. There's likely a way to do that technically um and achieve that. For us um you could use like a team rule if you wanted or use cursor ignore to exclude certain things from being

indexed. Um, we have an iteration of this where we pull our our website out into a sub repository that people can iterate with for documentation purposes. Um, so there are ways to achieve this. Technically from a product perspective, you're just opening a folder in cursor. So it's just a matter of how you what you populate in the folder, what you pull in, etc. Um, if you're more focused on the indexing side, that would be more for cursoring more use cases. But um,

yeah, there are ways to achieve this. I do think that um some elements of cursor operate within the the framework of LLMs have limited context windows and as the technology gets better that's definitely going to increase over time but or can't say definitely but I imagine it will and uh the issue of having a thousand repos in a multi- uh repo workspace um I can understand it seems a little bit daunting um as Cody says there definitely are technical solutions And and if you need some any

advice on that, please write into highcursor.com. We'd be happy to help with that. Um but I think ultimately an important thing to always remember with cursor and and any AI tool is that you need to sort of apply software engineering principles. You need to apply um problem solving principles on some level and use the intuition, use the organization that maybe hasn't made it to the agentic layer that is still, you know, we've named uh or organized

repositories in certain ways. uh those should be manually selected at this point by by users. Um and we'll continuously iterate on on ways to make uh large code bases more accessible. Um but yeah, please reach out if you you need any help on that because we'd be happy to happy to help solve that.

Cool. Again, these are great questions. Thank you. Please feel free to keep them coming. Um so, uh this kind of ran rampant um and did did a whole lot that uh maybe didn't wasn't necess ne necessary. Um, it did create a clicks per day route which is great. Um, it created a whole bunch of documentation which I didn't necessarily want but um, I think it uh did solve the issue. It gave this script uh to get Harper's clicks. Um, we'll run that in a second.

But um, ultimately I think a a big failure that I had here was I gave a couple different steps to the agent at once. Um you know this is cloally called vibe coding and um ultimately when you want effective use of cursor when you want cost efficient use of cursor um you really want to segment your problem break it down into multiple pieces or what we can do alternatively is use plan mode and so this is definitely one of the most popular features that we've

seen uh sorry I'm looking at the wrong place is um the ability to basically harness the agent to instead of just going at and changing things and writing code and editing files um give you a pretty detailed markdown that's going to explain exactly what it's going to do. Um a good way that we've seen this applied is you'll use maybe um a more state-of-the-art model like a client 4.5 sonnet an opus um a GPT 4.1 something like that. Um, this will basically allow a big context window, a lot of processing power for um, the

agent to be able to craft a plan, be able to write down the steps it's going to take, create a guideline for itself that it will more closely adhere to, and then you can use um, a faster model like composer um, to execute that plan. Um, and because all the thinking is already been done up front, um, what you're most looking for is speed. Um, and you know, you want something that's capable of executing on on that plan that has enough context and juice to do so and

composer is is great for that. I've written plans with coer composer as well. Um, for this maybe it's it's more effective just to rely on something uh like like uh cloud for.5 sonnet. We can also do something which is another very popular feature um which is our best event mode. Um this was also released in cursor 2.0. Um, so what I'm going to do here is effectively click this toggle here. Um, I'm going to basically compare the outputs of what this plan would look

like across multiple models. That way you can make you can understand for yourself which model is best suited for my purposes. You'll get a sense of what the preferences of the different models are. Um, this is basically uh running the same thing multiple times with the same inputs to better inform your own understanding of model selection. One of the most common questions we get at cursor is what are which model should I use for this? What are the best models for this purpose? And best of end is our solution to that.

You can determine it for yourself. There is a little bit more of an upfront cost because you have to basically run a prompt uh redundantly. But once you sort of get a sense of which model is best suited for this, you'll quickly see that this is a much more efficient use of tokens and spend than going down a rabbit hole with a model that isn't going to get the job done the way you think it should. and then having to run it all over again with a different

model. So, I'll show you what it looks like here. We're going to click 4.5 sonnet. We'll click um let's do composer and we'll do GBT4.1 and we'll just see the differences here. You can also um 2X a different model if you want to see you you'd be surprised and I'm always surprised at the variance that can come with one model running the same prompt twice. Um but we'll we'll do one time here and we'll do two composers just so you can get a sense how this works.

So we'll extend this a little bit. Um we see each one of them is running. Um we have our two composers um which are inevitably going to run this a little bit faster. Um but as these sort of come up with this plan um we're going to get a bunch of plan documents here uh which live in state. So they're they should um shouldn't take up any memory and you're able to add them directly. But um we'll get a sense of of which one of these is going to execute the best plan um for

this API. Um just pulling the chat, has anyone used this feature yet? Do you have any thoughts on it? Um has it been effective for for your team? >> Otherwise, we have a question in the chat too. We can go to >> Oh, please. Yeah, let's go. Let's go to that. Absolutely. One git repo has integration tests. Uh then I need to add related end to end tests to another repo for functional tests. How can I access two or more repos uh within cursor?

Um this user may have not been here at the beginning of the um uh session but I'll repeat it again. Um cursor offers the ability to open workspaces which combi can combine multiple repos. So um if I open a folder here um and I go into click counter app um this app is um basically encompassing the different uh types of files that I need and um you know we have a a docs repo, a front end repo, a scripts repo, a doc site repo. These essentially um can all be combined to create that context. So if you were

going to clone different repos from remote and pull them down locally, you could create a project folder um clone each of those into that project folder and then open that folder as the workspace um in cursor and then you'll be able to have context across those different repos.

>> Yeah, I'll say for us tactically this looks like we have our our main codebase in one repository, we have a website codebase and a docs codebase. So all that is is that you have a a parent folder that's just empty and then you get clone three into that same repository and then you open the folder.

Uh so for you this could be you have one parent folder and then you clone in uh your integration test repo, your ED test repo and then any other repos you want and you just open that parent folder in cursor as a workspace. Cool. Um so our our different plans ran um I'm going to um probably use this composer one. I I think they all sort of came to the same conclusion which is that this already exists. Um but we'll let the plan sort of validate um and verify that these scripts are executable and work

correctly. Um so that's probably what we're going to to do. So we'll build with this one and we can um just focus on this one for now. >> Um and then once it's ready uh we'll run the script to make sure it's it's working correctly. Um, yeah. So, we're we're running up against the end of end of the session.

Um, you know, a couple more interesting things that I wanted to show real quick. Um, I mentioned images before, but this is definitely something that we see a lot um at in in our in a support team. Um, if I put in nonsense values, um, oops, looks like that. I think it's in process. So, the error message maybe didn't work. No. Okay, it's not working. Essentially, if you were to have, um, an error message pop up. Um, let's say you could just copy an image here, take this image, put it into your, um,

chat. Um, a really effective means of support is if if you're someone writes in, takes a screenshot, has some context that you aren't aware of, um, and you may not fully know what they're talking about, uh, happens to us in support all the time. Um, a really effective means is just using the the image parser within cursor to get that context to understand more effectively. Um, so if I were to open a new chat and this is still nope, it's not there

anymore. Um, I don't even need to do this. I can just use the um I can use the browser tool for this. Take a screenshot. It's going to put it directly into context immediately and just say what is this? Um you know, you'd be surprised how effective that can be. Basically, just give the agent the chance to explain what it is you're looking at. Um but this can be a screenshot of anything. We've seen this with people. Um you know, they'll copy logs from their console. They'll copy error messages they see that are are

pretty specific or nuanced. Um, this is something that's been really effective for our team to help support the platform, especially as it gets bigger and you may not be coming be may not be keeping up to date with specific nuances of it. Um, helps you get a sense of exactly what it is you're looking for um much faster.

>> Awesome. with about five minutes left here. Maybe we could uh if there are any questions, feel free to drop them in the chat. We're happy to answer. Otherwise, I can share a closing statement as well with everyone before we adjourn. Uh but let's open up here any questions from the the group.

>> Awesome. If not, uh I think three biggest takeaways we'd love to sort of evangelize and share with you all here. Um cursor is typically view within within enterprises within teams right now as this sort of tool for software engineers. If you haven't given access to your sport engineers yet, we definitely encourage it. We think it could be a fantastic tool that uplevels uh your team as a whole. The ROI is a little bit different in that for engineers, you're typically looking at things like lines of code written and

PRs generated these types of things. For support, that ROI isn't quite the same, but the the level of impact is certainly similar if not greater as well. Uh we think you'll find a ton of value in using the platform and think it's really great to give to your team as well. Next is to really focus on bringing those integration points that you have with your different vendors and things into cursor. Uh whether it be your MCP servers or other integration that you

want to build. Um that's really what unlocks a team. The codebase is one piece that is super helpful in and of itself and can really uplevel your team. But having MCP servers for your given use cases and contexts is super helpful for your team. Uh and making everything come together in one place and making them almost like a a superhero in that regard where they have everything at their fingertips. Um and yeah, the last thing is is working with your team. Uh

if they're using cursor today, understanding what their pain points are and if there's gaps, we'd love to hear them and we'd love to help make this a better experience for technical support engineers as a whole. Um we're really looking to invest into this area. Um so if you had feedback for us, definitely don't hesitate to reach out. You can find no and I on LinkedIn um as well as we'll share emails here as well. We're happy to chat with anyone that has

further questions, feedback, etc. >> Perfect. >> Yeah, I'll just plug for our webinar series. Um we do these uh multiple times a month. Uh they're usually catered towards different topics. This is a very specific subset of features for cursor. There's a whole host of different use cases and applications that we've seen from, you know, about a year of selling into enterprise. Um, if anyone has any ideas or any uh use cases they'd like to see, we're always looking for for

inspiration. We want to make this as applicable to our customers as possible. Um, and thank you all so much for coming. This is really great to be able to present this to you.