WEBVTT

NOTE Sentence-level transcript of https://www.youtube.com/watch?v=Btk8wDUVs74

NOTE One cue per sentence. Cue ids are the line anchors on /transcripts/Btk8wDUVs74.html. A cue ends where the next begins, or 2 s after its last word.

s1
00:00:01.309 --> 00:00:03.309
[music]

s2
00:00:14.480 --> 00:00:16.000
Um, hey everyone.

s3
00:00:16.000 --> 00:00:17.760
Uh, we are super excited to be here.

s4
00:00:17.760 --> 00:00:19.119
Thanks for having us.

s5
00:00:19.119 --> 00:00:27.119
Uh, today we're going to talk about how we shift monday.com from a system of record uh, into a system of context.

s6
00:00:27.119 --> 00:00:32.079
And honestly the title tell the whole story uh in just a single line.

s7
00:00:32.079 --> 00:00:45.120
Uh for decades we build uh software that record what's happened um every task, every document, every message um every status update um just put into the record.

s8
00:00:45.120 --> 00:00:48.640
What we want to talk today is like take it step further.

s9
00:00:48.640 --> 00:00:53.840
Uh we want software that actually understand the connection between them.

s10
00:00:53.840 --> 00:00:59.600
So I want to start from a simple question that each one of us ask himself every morning.

s11
00:00:59.600 --> 00:01:02.480
Um what should I focus on right now?

s12
00:01:02.480 --> 00:01:14.640
Um it sounds almost trivial but uh to be honest with yourself if you ask your agent whether Gemini GPT or even cloud um if you ever typed this question

s13
00:01:14.640 --> 00:01:19.520
you probably got list of bullets um not related to each other.

s14
00:01:19.520 --> 00:01:24.080
um list of like item dressed up like a a confident paragraph.

s15
00:01:24.080 --> 00:01:30.000
Um but but it's not really um um connected to what you're working on.

s16
00:01:30.000 --> 00:01:34.400
Actually, I tested last week and uh Cloud asked me to go to the gym.

s17
00:01:34.400 --> 00:01:38.400
I don't know if it's a compliment or not, but uh this is what he suggested.

s18
00:01:38.400 --> 00:01:47.439
Um and and what really make it so frustrating is like your assistant um have all this data.

s19
00:01:47.439 --> 00:01:54.240
It has all the boards, the tasks, the emails, the Slack messages, everything that you ever touched if you connect it.

s20
00:01:54.240 --> 00:01:57.600
Um, but it still can't really answer it.

s21
00:01:57.600 --> 00:01:59.920
Um, it has all the data.

s22
00:01:59.920 --> 00:02:04.000
Um, but it has zero understanding.

s23
00:02:04.000 --> 00:02:06.399
Um, so this is the real challenge we are facing.

s24
00:02:06.399 --> 00:02:09.200
Um, this is the heart of the entire talk.

s25
00:02:09.200 --> 00:02:12.560
The problem was never the missing of data, the retrieval.

s26
00:02:12.560 --> 00:02:15.120
The problem is like the missing understanding.

s27
00:02:15.120 --> 00:02:21.040
uh those are two totally different things and almost everyone mix between them.

s28
00:02:21.040 --> 00:02:25.440
Understanding is the word that we're going to focus the entire the entire talk.

s29
00:02:25.440 --> 00:02:30.160
Not context, not memory, not retrieval, understanding.

s30
00:02:30.160 --> 00:02:32.560
So um quick about ourselves.

s31
00:02:32.560 --> 00:02:33.599
My name is Tormer.

s32
00:02:33.599 --> 00:02:34.480
My name is Omri.

s33
00:02:34.480 --> 00:02:35.440
This is Tor.

s34
00:02:35.440 --> 00:02:45.920
Um uh we both engineering manager at monday.com working on exactly uh the problem that we going to talk about a little a little bit context about where we coming from.

s35
00:02:45.920 --> 00:02:48.800
Uh monday.com is a global software company.

s36
00:02:48.800 --> 00:02:54.400
Uh we build a work platform uh used by hundreds of thousands of teams.

s37
00:02:54.400 --> 00:03:00.879
Um and the part that really mattered for the talk is that Monday is where the work um lives.

s38
00:03:00.879 --> 00:03:04.879
uh we help companies to doing the work not just like saving records.

s39
00:03:04.879 --> 00:03:12.800
Every project, every task, every decision, every meeting, the notes, the action item, everything logs logged into the system.

s40
00:03:12.800 --> 00:03:18.080
And our mission has always been to help the teams to achieve their business outcome.

s41
00:03:18.080 --> 00:03:26.000
Whether you are a salesperson, so we want to help you like create an NSDR agent that call to your prospects and help you sell the product.

s42
00:03:26.000 --> 00:03:32.080
And if you are like a finance team or marketing we want to help you uh with the research.

s43
00:03:32.080 --> 00:03:40.959
So each one of the discipline we want you help you to doing the job and together we have like four big bats on the platform.

s44
00:03:40.959 --> 00:03:44.400
We have like Monday sidekick we're going to talk about it mostly today.

s45
00:03:44.400 --> 00:03:47.360
Uh Monday vibe if you want to build your own software.

s46
00:03:47.360 --> 00:03:57.439
Monday agent if you want to create your own agent into the platform and like if you want some more deterministic flow we have like Monday workflows but today we're gonna focus on psychic

s47
00:03:57.439 --> 00:04:09.360
um psychic is your intelligence AI personal assistant that's understand your work think and execute with you like a bird on your shoulder uh he know you he know your business

s48
00:04:09.360 --> 00:04:20.959
um it help you with your work on every aspect uh he work the way you do uh with your tones Um um it's keep you totally in control but like

s49
00:04:20.959 --> 00:04:24.800
putting all these bullets and uh building all these promise is really hard.

s50
00:04:24.800 --> 00:04:30.080
Um so let's talk about why it's hard and there are three points for that.

s51
00:04:30.080 --> 00:04:36.400
Um first like picture one assistant sitting on top of absolutely everything.

s52
00:04:36.400 --> 00:04:40.240
You have your u your u slack messages.

s53
00:04:40.240 --> 00:04:42.720
You have all the notes for your meetings.

s54
00:04:42.720 --> 00:04:53.919
um absolutely everything and it's beautiful and overwhelming at the same time because as it stand like there's wall of records everywhere.

s55
00:04:53.919 --> 00:04:59.600
Um so what why it's making so hard to connect between them.

s56
00:04:59.600 --> 00:05:02.000
There are three reason for that.

s57
00:05:02.000 --> 00:05:05.040
One is something that we call the agent gap.

s58
00:05:05.040 --> 00:05:11.039
Your agent every agent is really sharp and doing task um when you when he know what to do.

s59
00:05:11.039 --> 00:05:14.960
Um but he sometimes lost find them find the problem.

s60
00:05:14.960 --> 00:05:22.800
Um if I ask my agent like please help me draft and and and reply to like the escalation from a customer he nailed it.

s61
00:05:22.800 --> 00:05:24.080
He know how to do it.

s62
00:05:24.080 --> 00:05:25.120
He take the context.

s63
00:05:25.120 --> 00:05:38.720
I like doing the work but asking him what should I focus on first he guess because he doesn't understand what is my priority who am I it doesn't matter if you have a memory or something

s64
00:05:38.720 --> 00:05:54.960
he still don't know what is the problem the second problem is like um we have the records but we don't have the meaning um a log never said what it mean let's take an analogy from our

s65
00:05:54.960 --> 00:05:58.080
Let's say that you have one line of code in your GitHub.

s66
00:05:58.080 --> 00:06:01.199
You look at a code, maybe there is a comment on top of it.

s67
00:06:01.199 --> 00:06:02.000
Nice.

s68
00:06:02.000 --> 00:06:06.319
But you don't really understand why someone wrote this line of code.

s69
00:06:06.319 --> 00:06:08.639
Today, no none of us writing code.

s70
00:06:08.639 --> 00:06:12.639
But somewhere in the past, someone wrote this code line of code.

s71
00:06:12.639 --> 00:06:20.880
And if you really want to know, you can go to get blame and understand uh from the commit log what why why someone do it.

s72
00:06:20.880 --> 00:06:26.080
But if you want to go farther, you can go to the PR and maybe read the description.

s73
00:06:26.080 --> 00:06:38.080
And if you really want to go hard, you can go to your Monday board and see which PR connected to this item and understand that this line of code came because some customer complain about something.

s74
00:06:38.080 --> 00:06:41.039
So this is what we're trying to build.

s75
00:06:41.039 --> 00:06:51.600
And the third point that is a bit challenging as well is like um it's really hard to build ahead of time um at runtime um the meaning of things.

s76
00:06:51.600 --> 00:06:53.680
Um it's really too late.

s77
00:06:53.680 --> 00:06:59.919
Um you simply can't do something like that the moment someone asked the question.

s78
00:06:59.919 --> 00:07:04.880
So understanding understanding of the context has to be ahead of time.

s79
00:07:04.880 --> 00:07:10.240
Um you need to build it much before someone asks the question.

s80
00:07:10.240 --> 00:07:13.680
Um and this is why we have built what we are building.

s81
00:07:13.680 --> 00:07:16.000
We are building uh the Monday world model.

s82
00:07:16.000 --> 00:07:18.479
This is what we called the Monday world model.

s83
00:07:18.479 --> 00:07:28.160
Help you um understand why this matter um how to help you, who you are, when and and what's not to do.

s84
00:07:28.160 --> 00:07:31.280
Um it's the context that follow your work.

s85
00:07:31.280 --> 00:07:38.160
Um he understand who you are and it's simply not a bigger prompt.

s86
00:07:38.160 --> 00:07:40.800
uh it's not a longer uh context window.

s87
00:07:40.800 --> 00:07:45.840
It's a totally different um from from what we know until now.

s88
00:07:45.840 --> 00:07:49.039
First before like Tor going to talk about how we build it.

s89
00:07:49.039 --> 00:07:51.520
What it's not it's not a retrieval problem.

s90
00:07:51.520 --> 00:08:01.120
The problem never been getting the data we don't we have all the data we have all the connection to what all the provider that we want to get all the MCPS.

s91
00:08:01.120 --> 00:08:04.879
The problem is really to understand how it works.

s92
00:08:04.879 --> 00:08:08.560
Understand how each one of these entity connected to each other.

s93
00:08:08.560 --> 00:08:10.960
So go ahead.

s94
00:08:10.960 --> 00:08:12.160
Thank you.

s95
00:08:12.160 --> 00:08:13.759
Hi everybody.

s96
00:08:13.759 --> 00:08:17.199
Um so what's the data model?

s97
00:08:17.199 --> 00:08:28.400
We collect thousands of data points on the user every item status change their activity log messages and meetings and construct three things the agent can resone over.

s98
00:08:28.400 --> 00:08:36.399
The first is how the user's work is structured, their key entities and relationships and connections between them.

s99
00:08:36.399 --> 00:08:42.080
What depends on what, how a message in Slack connects to a task, who's blocking whom.

s100
00:08:42.080 --> 00:08:54.399
The second is a current snapshot, live signals over those entities, what's overdue, what's critically urgent right now, which co-workers you've been actively working with, and why.

s101
00:08:54.399 --> 00:08:57.360
The third is what we can learn about the user over time.

s102
00:08:57.360 --> 00:09:04.720
There are decisions and outcomes, work patterns and cadences distilled into a durable profile.

s103
00:09:05.040 --> 00:09:06.959
So how do we build that data model?

s104
00:09:06.959 --> 00:09:11.040
Um we use two engines running on different time windows and schedules.

s105
00:09:11.040 --> 00:09:20.720
A slow engine that runs on a long time window and learns the user and their work and a fast engine that reads what's happening right now and how it affects the user's work.

s106
00:09:20.720 --> 00:09:24.959
One knows you and the other one knows your day.

s107
00:09:24.959 --> 00:09:26.800
First the slow engine.

s108
00:09:26.800 --> 00:09:42.640
It takes as context users activity over weeks and minds it for patterns and the type of persona the user is their routines their work rhythm who they collaborate with their main goals and current projects.

s109
00:09:42.640 --> 00:09:48.880
Those patterns get distilled into a durable profile and every time a profile holds it's reinforced.

s110
00:09:48.880 --> 00:09:55.600
This engine tries over time to learn who exactly the user is and how they work.

s111
00:09:56.000 --> 00:09:58.160
The fast engine is the opposite.

s112
00:09:58.160 --> 00:10:06.080
It takes as context a short recent window and recomputes a set of live signals over the user's current state.

s113
00:10:06.080 --> 00:10:11.440
What server do, what's suddenly urgent, which co-workers you've been pulled in with.

s114
00:10:11.440 --> 00:10:16.320
This engine tries to understand your day and updates frequently.

s115
00:10:16.480 --> 00:10:19.680
Uh this split isn't something we invented.

s116
00:10:19.680 --> 00:10:22.399
It's present in two totally different fields.

s117
00:10:22.399 --> 00:10:26.800
In neuroscience, this split is referred to as complimentary learning systems.

s118
00:10:26.800 --> 00:10:31.279
And in data processing architecture, it's referred to as a lambda architecture.

s119
00:10:31.279 --> 00:10:36.720
We apply the same concepts to how we construct the agent's data model.

s120
00:10:37.279 --> 00:10:39.440
Our brain uses the same split.

s121
00:10:39.440 --> 00:10:50.399
Uh every important experience gets captured instantly by the hippocmpus and over time the new cortex distills those into durable lessons.

s122
00:10:50.560 --> 00:10:54.640
In data infrastructure, the same there's the same split.

s123
00:10:54.640 --> 00:11:07.040
A fast speed layer over a recent real-time window and a slow batch layer over the full history that gets recomputed and the two are merged into a single served view.

s124
00:11:07.040 --> 00:11:13.920
Two different fields landed on the same idea and that's what we're trying to apply to our data model.

s125
00:11:14.240 --> 00:11:16.720
So how does it all come together?

s126
00:11:16.720 --> 00:11:19.760
We collect data from everywhere our users work.

s127
00:11:19.760 --> 00:11:27.279
uh Monday, Slack, emails, calendar, and we turn it into data structures, signals, and patterns.

s128
00:11:27.279 --> 00:11:32.480
Both engines premputee on top of that offline and ahead of time.

s129
00:11:32.480 --> 00:11:42.880
And when a user engages with Sidekick, a thin slice of logic is recomputed for recent activity, and the entire context is served to the agent.

s130
00:11:42.880 --> 00:11:48.720
Sidekick can then decide when and how to traverse and retrieve context from the data model itself.

s131
00:11:48.720 --> 00:11:53.120
and it's primed to reason on top of it.

s132
00:11:53.120 --> 00:11:57.040
And building it this way gives us two behaviors out of the box.

s133
00:11:57.040 --> 00:11:59.440
The data model, it's resilient.

s134
00:11:59.440 --> 00:12:03.839
Sources are isolated so a bad feed can't break the rest.

s135
00:12:03.839 --> 00:12:13.680
And the thin layer of logic that runs at serve time verifies part of the context against live data while the rest falls back to the last verified context.

s136
00:12:13.680 --> 00:12:18.079
So it degrades gracefully, but it doesn't fail.

s137
00:12:18.079 --> 00:12:21.120
Second, it actually understands the urgency of facts.

s138
00:12:21.120 --> 00:12:29.839
It's able to understand when and how it should be proactive and notify the user and when it should stay silent.

s139
00:12:30.560 --> 00:12:33.200
And the crucial part is that it compounds.

s140
00:12:33.200 --> 00:12:38.560
Every day the data is captured, the layers fill in and the profile sharpens.

s141
00:12:38.560 --> 00:12:43.279
And adding a new data source is deliberately cheap and only contributes.

s142
00:12:43.279 --> 00:12:45.440
So the surface only grows.

s143
00:12:45.440 --> 00:12:47.760
The more it sees, the more it understands.

s144
00:12:47.760 --> 00:12:51.040
And the more it understands, the more you can lean on it.

s145
00:12:51.040 --> 00:12:52.480
And the data model is unique.

s146
00:12:52.480 --> 00:12:55.920
It's unique to how you work.

s147
00:12:56.240 --> 00:12:58.720
We're not pretending this solves everything.

s148
00:12:58.720 --> 00:13:04.560
Uh the model itself is always trailing the actual live world.

s149
00:13:04.560 --> 00:13:11.440
New users have no reliable data to reason from yet, and signals have our own biases built in.

s150
00:13:11.440 --> 00:13:16.160
So the hardest part is actually telling the important parts from the noise.

s151
00:13:16.160 --> 00:13:22.800
But this is an architectural design that we can enrich and test and improve over time.

s152
00:13:22.800 --> 00:13:24.959
Thank you.

s153
00:13:25.659 --> 00:13:27.659
[applause]

s154
00:13:28.320 --> 00:13:32.560
So back uh back back to the original uh question that we had.

s155
00:13:32.560 --> 00:13:34.240
What should I focus on right now?

s156
00:13:34.240 --> 00:13:35.760
Remember the the question.

s157
00:13:35.760 --> 00:13:38.079
So now Psyche can really answer that.

s158
00:13:38.079 --> 00:13:39.120
Uh let's see how.

s159
00:13:39.120 --> 00:13:50.800
So first like Thomas said we collect all the data point we called it breadcrumbs for example the board that I working on right now um all the emails from the past uh months

s160
00:13:50.800 --> 00:14:03.440
um the transcript for the meeting all the action item that I got from those meeting and we processing them offline um we see a full picture of your calendar this is what help us to understand the pattern so if you have like bi-weekly

s161
00:14:03.440 --> 00:14:17.600
with your VPs I understand that tomorrow you have another meetings and even slack messages from the last few days to understand if you say something in the Slack that's relevant that you didn't say in your daily uh standup with the team.

s162
00:14:17.600 --> 00:14:23.040
We took all this data and we uh process them either fast or slow.

s163
00:14:23.040 --> 00:14:26.639
Um the slow build some kind of like profile on you.

s164
00:14:26.639 --> 00:14:30.480
So you can see it on the top like combin is an engineering manager.

s165
00:14:30.480 --> 00:14:33.519
We I'm working on two projects psychic and notaker.

s166
00:14:33.519 --> 00:14:34.800
I'm from Tel Aviv.

s167
00:14:34.800 --> 00:14:40.000
And this is how many hours I have per day and like how I work every day.

s168
00:14:40.000 --> 00:14:43.199
And the fast is something that's helped me to understand what is the action item.

s169
00:14:43.199 --> 00:14:46.720
I have like three commitment that I promised to other people.

s170
00:14:46.720 --> 00:14:50.399
I have to to reply to a VP that sending email and I didn't.

s171
00:14:50.399 --> 00:14:56.079
Um so this is only from the past uh uh day or few days window.

s172
00:14:56.079 --> 00:15:01.199
This is something that's relevant more for today and this is how psychic can answer those questions.

s173
00:15:01.199 --> 00:15:08.160
So to summarize it, the bottleneck was never uh the capability where you can where you take all the data from.

s174
00:15:08.160 --> 00:15:12.560
It was the understanding how you connect each one of the dots to each other.

s175
00:15:12.560 --> 00:15:18.720
Um the most capable agent in the world whether it's like a cloud and Gemini, it doesn't understand you.

s176
00:15:18.720 --> 00:15:20.560
He need to process it beforehand.

s177
00:15:20.560 --> 00:15:22.639
This is what we're trying to solve at Psychic.

s178
00:15:22.639 --> 00:15:24.880
Um this is the Monday word model.

s179
00:15:24.880 --> 00:15:26.480
Uh this is what we're building.

s180
00:15:26.480 --> 00:15:29.040
Um if you have any question, uh we out of time.

s181
00:15:29.040 --> 00:15:31.279
We are here uh uh near the stage.

s182
00:15:31.279 --> 00:15:33.120
Thank you very much for the time.

s183
00:15:33.120 --> 00:15:34.880
Uh you can follow us on LinkedIn.

s184
00:15:34.880 --> 00:15:37.120
We post things on on the area.

s185
00:15:37.120 --> 00:15:39.680
Thank you very much.

s186
00:15:39.935 --> 00:15:41.935
[applause]
