From Systems of Record to Systems of Context

[upbeat music] [audience applauding] Um, hey everyone.

Uh, we are super excited to be here. Thanks for having us. Uh, today we're gonna talk about how we shift monday.com from, uh, a system of record, uh, into a system of context.

And honestly, uh, the title tell the whole story, uh, in just a single line. Uh, for decades, we build, uh, software that record what happened, um, every task, every document, every message, um, every status update, um, just, uh, put into the record.

What we want to talk today is like take it a st-step further. Uh, we want, uh, software that actually understand the connection between them.

So I wanna start from a simple question that each one of us ask himself every morning, um, what should I focus on right now? Um, it sounds almost trivial, but, uh, to be honest with yourself, if you ask your agent whether Gemini, GPT, or even Claude, um, if you ever typed this question, you probably got list of

bullets, um, not related to each other. Um, list of like item dressed up like a, a confident paragraph. Um, but, but it's not really, um, um, connected to what you're working on.

Actually, I tested la-last week and, uh, Claude asked me to go to the gym. I don't know if it's a compliment or not, but, uh, this is what he suggested.

Um, and, and what really make it so frustrating is like your AI assistant, um, have all this data. It has all the boards, the tasks, the emails, the Slack messages, everything that you ever touched if you connect it.

Um, but it still can't really answer it. Um, it has all the data, um, but it has zero understanding.

Um, so this is the real challenge we are facing. Um, e-- this is the heart of the entire talk. Uh, the problem was never the missing of data, the retrieval.

Uh, the problem is like the missing understanding. Uh, those are two totally different things, and almost everyone, uh, mix between them. Understanding is the word that we're gonna focus, uh, the entire wo-- uh, the entire talk.

Um, not context, not memory, not retrieval, understanding.

So, um, quick about ourselves. My name is Tomer. My name is Omri. This is Tomer. Um, uh, we're both engineering manager at monday.com, working on the exactly, uh, the problem that we're gonna talk about.

A little, a little bit context about where we're coming from. Uh, monday.com is a global, uh, software company. Uh, the-- we build a AI work platform, uh, used by hundreds of thousands of teams.

Um, and the part that really matter for the talk is that Monday is where the work, um, lives. Uh, we help companies to doing the work, not just like saving records.

Every project, every task, every decision, every meeting, the notes, the action item, everything logs, logged into the system. And our mission has always been to help the teams to achieve their business outcome, whether you are a salesperson, so we want to help you, like, create an NFDR agent that call to your prospect and help you sell the

product. And if you are like, uh, a, a finance team or marketing, we want to help you, uh, with the, uh, research. So each one of the discipline, we want you help you to doing the job.

And together we have like, uh, four b-big bets on the AI Work Platform. We have like monday sidekick, we're gonna talk about it mostly today. Uh, monday vibe, if you want to build your own software.

monday agent, if you want to create your own agent into the platform, and like if you want some more, some more deterministic flow, we have like monday workflows. But today we're gonna focus on psychic.

Um, psychic is, uh, your intelligence AI personal assistant that's understand your work, think, and execute with you, uh, like a bird on your shoulder. Uh, he know you, he know your business.

Um, it help you with your work on every aspect. Uh, he work, work the way you do, uh, with your tones. Um, um, it's keep you totally in control.

But like putting all these bullets and, uh, building all these promises is really hard. Um, so let's talk about why it's hard. Uh, there are three point for that.

Um, first, like picture one assistant sitting on top of absolutely everything. Uh, you have your Sloc-- uh, your, uh, uh, Slack messages, you have all the notes for your meetings, um, absolutely everything.

And it's beautiful and overwhelming at the same time because as it stand, like they have wall of records everywhere. Um, so what-- why it's making so hard to connect between them?

There are three reason for that. One, it's something that we call the agent gap. Your agent, every agent is really sharp in doing task, um, when you-- when he know what to do.

Um, but he sometimes lost, find them-- find the problem. Um, if I ask my agent like, "Please help me draft and, and, and reply to like the escalation from a customer," he nail it.

He know how to do it. He take the context, 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 he have a memory of something, he still don't know what is the problem.

The second problem is like, um, y- 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 world.

Let's say that you have one line of code in your GitHub. You look at a code, maybe there is a comment on top of it, nice, but you don't really understand why someone wrote this line of code.

Today, never-- n-none of us writing code, but Somewhere in the past, someone wrote this code, line of code, and if you really want to know, you can go to git blame and understand, uh, from the commit log what, why, why someone do it.

But if you want to go further, you can go to the PR and maybe read a description. 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 complained about something.

So this is what we are trying to build. And the third point that is, uh, a bit challenging as well is like, um, it's really hard to build ahead of time, um, it, at runtime, um, the meaning of things.

Um, it's really too late. Um, you simply can't do, uh, something like that the moment someone asks the question. So understanding, understanding of the context has to be ahead of time.

Um, you need to build it much before someone asks a question. Um, and this is why we are build what we are building. We are building, uh, the Monday world model.

This is what we call. The Monday world model help you, um, understand why this matter, um, how to help you, who you are, uh, when and, and what's not to do.

Um, it's a context that follow your work. Um, he understand who you are, and it's simply not a bigger prompt. Uh, it's not a longer, uh, context window. It's a totally different, um, um, from, from what we know until now.

First, before, like, Tomer gonna talk about how we build it, what it's not. It's not a retrieval problem. 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. The problem is really to understand how it works, hun- understand how each one of these entity connected to each other.

So go ahead, Tomer.

Thank you, Omri. Hi, everybody. Um, so what's the data model? 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 reason over.

The first is how the user's work is structured, their key it- entities and relationships and connections between them, what depends on what, how a message in Slack connects to a task, who's blocking whom.

The second is a current snapshot, live signals over those entities, what's overdue, what's critically urgent right now, which coworkers you've been actively working with and why. The third is what we can learn about the user over time, their decisions and outcomes, work patterns and cadences distilled into a durable profile.

So how do we build that data model? Um, we use two engines running on different time windows and schedules, 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.

One knows you, and the other one knows your day. First, the slow engine. It takes as context user's activity over weeks and mines 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.

Those patterns get distilled into a durable profile, and every time a profile holds, it's reinforced. This engine tries over time to learn who exactly the user is and how they work.

The fast engine is the opposite. It takes as context a short recent window and recomputes a set of live signals over the user's current state. What's overdue, what's suddenly urgent, which coworkers you've been pulled in with.

This engine tries to understand your day and updates frequently.

Uh, this split isn't something we invented. It's present in two totally different fields. In neuroscience, this split is referred to as complementary learning systems, and in data processing architecture, it's referred to as a Lambda architecture.

We apply the same concepts to how we construct the agent's data model.

Our brain uses the same split. Uh, every important experience gets captured instantly by the hippocampus, and o- over time, the neural cortex distills those into durable lessons.

In data infrastructure, the same-- there's the same split, 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.

Two different fields landed on the same idea, and that's what we're trying to apply to our data model.

So how does it all come together? We collect data from everywhere our users work, uh, Monday, Slack, emails, calendar, and we turn it into data structures, signals and patterns.

Both engines precompute on top of that offline and ahead of time, 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.

Sidekick can then decide when and how to traverse and retrieve context from the data model itself, and it's primed to reason on top of it.

And building it this way gives us two behaviors out of the box. The data model, it's resilient. Sources are isolated, so a bad feed can't break the rest. 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.

So it degrades gracefully, but it doesn't fail.

Second, it actually understands the urgency of facts. It's able to understand when and how it should be proactive and notify the user, and when it should stay silent.

And the crucial part is that it compounds. Every day, the data is captured, the layers fill in, and the profile sharpens, and adding a new data source is deliberately cheap and only contributes, so the surface only grows.

The more it sees, the more it understands, and the more it understands, the more you can lean on it. And the data model is unique. It's unique to how you work.

We're not pretending this solves everything. Uh, the model itself is always trailing the actual li- life world. New users have no reliable data to reason from yet, and signals have our own biases built in, so the hardest part is actually telling the important parts from the noise.

But this is an architectural design that we can enrich and test and improve over time. Thank you. [audience applauding]

So back, uh, back to the original, uh, question that we had, what should I focus on right now? Remember the, the question. So now Sidekick can really answer that.

Uh, let's see how. So first, like, uh, Tomer said, we collect all the data point. We called it, uh, breadcrumbs. Uh, for example, the, the board that I working on right now, um, all the emails from the past, uh, month, um, the transcripts from the meeting, all the action item that I got from this 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 with your VPs, I understand that tomorrow you have another meetings.

And even, uh, uh, Slack messages from, uh, the last few days to understand if you said something in the Slack that's relevant that you didn't say in your daily, uh, uh, stand-up with the team.

We take all, all this data, and we, uh, uh, process them either fast or slow. Um, the slow builds some kind of a profile on you, so you can see it on the top, like Omri Bruchim is an engineering manager.

Uh, uh, we-- I'm working on two projects, Sidekick and Notetaker. I'm from Tel Aviv, and this is how many hours I have, uh, per day, and, like, how I work every day.

And the fast is something that's helped me to understand what is the action item. I have, like, three commitment that I promised to other people. Uh, I have to, to reply to a VP that send me email, and I didn't.

Um, so this is only from the past, uh, uh, day or few days window. This is something that's relevant more for today, and this is how Sidekick can answer those questions.

So to summarize it, the bottleneck was never, uh, the capability of where you ca- where we take all the data from. It was the understanding, how you connect each one of the dots to each other.

Um, the most capable agent in the world, whether it's, like, uh, Claude and Gemini, it doesn't understand you. He need to process it beforehand. This is what we're trying to solve at Sidekick.

Um, this is the Monday world model. Uh, this is what we are building. Um, if you have any question, uh, we are out of time. We are here, uh, uh, near the stage.

Thank you ve- very much for the time. Uh, you can follow us on LinkedIn. Uh, we post things on, uh, on the area. Thank you very much. [audience applauding] [outro jingle]