[Music]

Hey guys.

Cool. Um, yes. So, my name is Yash. Um,

I work at Kurs on the engineering team.

And, um, I'll apologize in advance

because we don't have anyone who work

who has slides. So, I had to just kind

of put these together my own. So uh you

know bear with the very poor design but

anyways um so I'm gonna talk a little

bit about how we approach context

generally.

>> Wait ying one key point here.

>> Yes and um I have been working on

memories um by myself at cursor for the

past few months just prototyping and

we're kind of making our way out of the

woods so going to talk about that.

>> Okay so Yash isn't bragging for himself

as much as he wants to ask them how many

people are working at memory and cursor

and he goes I'm the only one. So we're

talking about a $9 billion IDE here

where memory is a loadbearing process

for it and Yasha is the one that's

working on it. So very excited to see

this.

>> Thank you so much.

>> Um

thank you. Um but yeah, so I think like

very similar to um what other folks have

touched upon, uh when you try and look

at context as this big kind of word, I

think it gets really really confusing

and muddy. And so we kind of tried to

break it down into three different

categories for our agent. Um and

obviously this is very much an art and

not a science. So and it's very product

dependent as well. But for us we kind of

have three different types. So you have

directional and the idea there is uh

when you present a highle task to the

agent um usually like it will kind of

begin its search um wide and directional

context will allow it to narrow that

search early and earlier and kind of get

to the relevant set of files as quickly

as it can. Um the next thing is

operational and that's kind of runbook

related. So how do I deploy a service?

How do I make edits in this particular

file? What are the conventions? Um and

so we have already created cursor rules

for that which are written by a human,

but the model will basically fetch them

when they're relevant to context and use

that to guide its edits. Um and the last

thing is a little bit more fuzzy. It's

kind of similar to the holistic theory

of mind that Sam mentioned earlier. Um

and that's kind of like a behavioral

context where you want the model to act

in a certain way when it's um going back

and forth with you. And so we had this

concept of user rules um where you could

specify, okay, please only speak to me

in Spanish or something like that. Um

but to be honest, most of our effort so

far has been just focused on the first

category of codebased search. And

recently we've kind of been branching

out, which is what I've been working on.

Um, and so the goal of memories was is

basically to augment all three of these

types of contexts with the idea that,

you know, you can rely less and less on

cursor rules, less and less on user

rules, and maybe even less and less on

codebased search once we've learned more

and more about how you interact with the

agent.

Okay. Um, and yeah, so like most things

at Cursor, we start with prototypes. So

I've been prototyping memories for about

a month and a half now. Um, and our

general principle was to start pretty

conservative. And the reason for that is

because um cursor is a coding agent

where the user generally likes to feel

in control. And one of the most

frustrating things about using cursor is

when it kind of goes off the rails and

stops listening. Uh which I'm sure if

any of you have used it, you must have

experienced it before. Um, and so one

worry and one thing that we saw a lot

during prototyping is if the model gets

an incorrect memory about your codebase

or about how you like to run the

terminal or anything really um it's a

really frustrating experience um because

the model will refuse to do certain

things or will do things incorrectly and

then when you try and tell it like hey

this isn't the right way it will

actually like double down because it's

like oh no I have a memory like this has

got to be correct. Um and so I'll get to

that part later but basically when we

started prototyping um we began with

kind of two parallel approaches that I

tried out. So one we called like the

sidecar approach and this is where uh

the model doesn't call any tools to

generate memory but rather in the

background as you interact with the

agent we kind of pull relevant parts of

context into a smaller model and that

smaller model makes a decision on what

to save if to save anything at all and

also what to update in the existing uh

knowledge that it has. Um and then the

second approach we tried was a tool call

approach where you just give the model a

tool called update memory. Um and the

model kind of as it detects you

interacting with the agent will decide

on its own you know this memory is

incorrect. I'm going to update it or I'm

going to delete it or I'm going to add

something new.

So in the second one the mo

okay so in the sidecar approach you

basically have a small model listening

to your conversation and at some points

you basically send the conversation off

to that small model and the small model

makes the decision completely

independent of the main of the main

thread. Um and then versus the tool call

approach is all in the main thread. Um,

>> uh, the sidecar doesn't necessarily have

to be an agent. Like you can choose to

give it tools if you want to, but you

could also, we've tried, we tried both.

Um, so yeah. Um, also feel free to

interrupt me with questions at any

point. Um, no, no, no, that was great.

I'm sure other people had questions,

too. Um, and so yeah, I'll start with

tool call memories. Um, this was

definitely the simplest thing to to

implement. Um and so you just have the

model kind of reflect um and decide when

the user has expressed something to it

that it determines is like worth

remembering and in that case um it will

create a memory itself. Um and so what's

interesting is we noticed like as I was

prototyping over the past few months

like model capabilities have improved in

such a way that this is like a legit

approach where you can just give the

tool to the model and it works. Um, and

so specifically, Sonnet 4 and Opus 4 as

well are really good at instruction

following and they've also been RL

specifically on anthropic's definition

of memories. But the tricky thing is

Anthropic actually has a different

definition of memories than what we

have. And it kind of goes to the point

that everyone has you need to decide

what memories are for your product. You

can't just think of it in the abstract.

Um, and what Sonnet wants to do with

memories is kind of create a task log.

So you can see that in like their

Pokemon example where they where the

agent kind of keeps a log of all the

things that it's tried to do. Um and so

when we just gave the gave sonnet 4 a

memory tool, it would try and save like

task specific memories which is in

coding agents like at least for us it's

kind of the opposite of what you want

because you don't want to remember like

the things that were specific to one

particular conversation. You want to

remember the things that were

generalizable and will be useful in a

future like completely unrelated

generation. Um and to that end uh we've

now like kind of tried to keep sonnet 4

and keep um opus 4 from generating new

memories but they are still really good

at reflection. So uh if the model has an

incorrect memory and the user just in

natural language kind of expresses

disagreement then they're really good at

just updating their memory themselves

without having to do anything fancy in

the background.

And the second approach is the sidecar

which I was talking about. And so I

spent weeks iterating here on the

prompting. It was like a whole roller

coaster of up and down where I kind of

lost hope and got hope back and kind of

settled in somewhere where I'm happy.

Um, and the biggest thing that I was

fighting is this concept of like a task

specific memory because in an coding

agent interaction probably 90 plus% of

what you're saying to the agent is not

worth remembering. It's very specific to

the task that you've given the agent.

Um, and so probably in most

conversations there isn't even anything

worth remembering. um for this

particular type of memory. It depends on

what you want to remember. Um and so I

tried a bunch of different approaches to

basically keep the model from focusing

too much on task specific things. Um and

similarly like with the uh tool calls it

kind of changed as the models got

better. So, um, you know, back when

cloud 3.7 was the latest model, um, I

was kind of prompting it super

aggressively, like giving it a bunch of

examples. Um, and it sort of worked, but

it also wasn't super great and a lot of

things kind of slipped through the

cracks. Um, and with the newer set of

reasoning models, um, essentially you

can just kind of give them like a very

brief description of the problem. uh you

can lay it out very you have to lay it

out very precisely like every word will

matter but you don't actually need that

much text you don't need that many

examples and they'll do a pretty good

job at the task um so eventually like we

didn't end up with a super complicated

system for the sidecar model it was very

simple um and the last thing was

evaluation so um evaluating memories in

our experience has been really tough

because it's the type of feature that

you notice when it's taken away not when

it's like necessarily there and So um

you can try and think of evals where

like the memories would help you get to

the solution faster but in some sense

it's kind of cheating because you come

up with the examples such that the

memories are useful and so when we

evaluated the memories sidecar model

like I focused it basically on the

quality of the me memory generated not

on the retrieval side and specifically

mostly just filtering out these task

specific memories. Um and so we ended up

in a place where we're pretty happy with

um the quality of memories that were

getting generated. And then the next big

question was kind of UX which is um how

much do you want to expose your memory

bank to your users and I think one big

learning has been what users think the

model should remember are not

necessarily what are useful and

especially like users get really frantic

and think that their memory bank has to

be perfect which is like so far from the

truth because in reality like even if

you give a model like 50% memories 50%

of them are junk 50% of them aren't

applicable like the models are smart

enough now to kind of filter about the

noise largely. Um, and so that was like

a really interesting thing. And so as a

result, we've kind of kept the

generation a bit hidden. And like

obviously you can go in and change it if

you don't like it. Um, but most of the

editing of memories happens like when a

model will choose to site a memory in

its generation. And then you can kind of

hover over and delete. But on the actual

generation side, we don't use it. Cool.

Um, but yeah, so it's kind of what I've

been talking about, but what's next? Um,

so so far now we can understand the

users. Um, but we want to learn a lot

more about your codebase. Um, and in

particular like we want to have an

understanding of the things that happen

in your codebase outside of just the

code because like you know we can turn

through and uh embed your entire

codebase and probably get a decent

representation of just what's happening

but there's a lot of things that you do

with your codebase that you know you

express in the sidebar like when you're

chatting with the agent but they don't

live anywhere. Um, and so we're trying

to figure that out basically. Um, going

to be a lot more prototyping and just

like you know shooting in the dark but

we'll I'm confident we'll get there. Um,

and then with that kind of new set of

memories where they can't just be

applied all the time in context, um, we

need new approaches to including

memories in context. And so, um, there's

some things we've been experimenting

there with changing the way that our

search pipeline works to include

memories. Um, but it's all just

prototypes so far. Um, and then kind of

the north star we're shooting for is

teamwide knowledge where um the if if

someone can learn from my mistakes um

that I made with the agent and they

don't their agent won't make that same

mistake, like that's the north star. But

it's also like really really important

to get it right because if you start

sharing bad memories teamwide, it's like

it's a huge degradation of quality. Um,

so this is what we're working towards,

but you know, we've still got some ways

to go. Uh, but yeah, I had a Q&A slide,

but I think we're gonna save the night.

Thank you guys.

[Applause]