Interview with Omri Bruchim and Tomer Ast of monday.com on shifting from systems of record to a "system of context." Covers why raw activity data across boards, tasks, email, and chat yields retrieval without understanding; monday.com's context layer built from two engines — a slow engine mining weeks of activity into a durable work profile, and a fast engine reading recent days for urgency — a split paralleling hippocampus/neocortex in neuroscience and lambda architecture in data systems. Discusses how the precomputed context serves their Sidekick agent, when the system should speak up, and the honest limitations of the approach. # Channel Identity Observations — monday.com Talk ## Observable Presentation Evidence ### Speaker Self-Description (Explicit Claims) - **Speakers identify as monday.com engineering managers**: *"My name is Tormer. My name is Omri... we both engineering manager at monday.com working on exactly uh the problem that we going to talk about."* - **Company scope claim**: *"monday.com is a global software company. Uh we build a work platform uh used by hundreds of thousands of teams."* - **Mission claim**: *"Our mission has always been to help the teams to achieve their business outcome."* - **Product portfolio claim**: Four "bets" — **monday sidekick**, **monday vibe**, **monday agents**, **monday workflows**: *"we have like four big bats on the platform."* ### Demonstrated Content Scope - **Technical, product-architecture deep dives**: The talk centers on an AI "world model" — fast/slow engines, data models, signals, and profiles (e.g., *"a slow engine that runs on a long time window and learns the user... and a fast engine that reads what's happening right now"*). - **Cross-disciplinary framing**: References to **complementary learning systems** in neuroscience, **lambda architecture** in data processing, and a GitHub "git blame" analogy — indicating an audience comfortable with systems design and conceptual abstraction. - **Product-demo style walkthroughs**: Concrete example answering *"What should I focus on right now?"* using breadcrumbs (emails, meeting transcripts, Slack messages) feeding a user profile. ### Intended Audience - **Practitioner/technical conference audience**: Talk format with stage, time limit, Q&A offer (*"if you have any question... We are here near the stage"*), and engagement with competing agents (Claude, Gemini, GPT) suggests an AI/engineering conference crowd. - **Builders of agentic/AI products**: Content addresses agent design tradeoffs (retrieval vs. understanding, resilience, graceful degradation). ### Tone and Presentation Style - **Casual, humorous**: *"I tested last week and uh Cloud asked me to go to the gym. I don't know if it's a compliment or not."* - **Honest about limitations**: *"We're not pretending this solves everything... New users have no reliable data to reason from yet, and signals have our own biases built in."* - **Calls to follow on LinkedIn**: *"you can follow us on LinkedIn. We post things on on the area."* ## Distinguishable Categories | Type | Examples | |---|---| | **Creator claims** | Company scale, mission, "hundreds of thousands of teams," four product bets | | **Demonstrated patterns** | Technical depth, candid limitation discussion, humor, conference talk format | No private motivations inferred; all observations tied to transcript passages. # Delivery Observations: From Systems of Record to Systems of Context ## Overview A two-speaker conference talk (monday.com engineering managers Omri Bruchim and Tomer Ast), structured as a problem → solution → demo → summary arc, with a mid-talk handoff between presenters. --- ## Tone & Register - **Conversational, informal keynote style**: heavy filler words and false starts throughout — "Um, hey everyone," "Uh, we are super excited to be here." - **Self-deprecating humor** to engage the audience early: > "Actually, I tested last week and uh Cloud 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." - **Candid, hedged honesty** in the closing of the technical section: "We're not pretending this solves everything." --- ## Vocabulary & Framing Devices - **Deliberate vocabulary control** — explicitly narrowing the talk's key term: > "Not context, not memory, not retrieval, understanding." - **Binary contrast pairs** as a recurring rhetorical structure: - "system of record" vs. "system of context" (title itself) - "It has all the data. Um, but it has zero understanding." - "One knows you and the other one knows your day." - "slow engine" vs. "fast engine" - **Catchy labels for abstract concepts**: "the agent gap," "Monday world model," "breadcrumbs," "a bird on your shoulder." - **Anthropomorphizing the agent**: "he know you he know your business," "he guess because he doesn't understand what is my priority." --- ## Teaching Habits & Structure - **Rule of three**, used repeatedly: - Three difficulties: the agent gap, missing meaning, ahead-of-time understanding - Three data-model components: structure, live snapshot, durable profile - **Concrete analogy teaching** — the GitHub/git blame/PR/monday board chain to explain "a log never said what it mean." - **Cross-domain analogy** (second speaker): mapping fast/slow engines to complementary learning systems in neuroscience and lambda architecture in data processing, with the observation "Two different fields landed on the same idea." - **Callback structure**: the opening question "What should I focus on right now?" is explicitly revisited — "Remember the the question. So now Psyche can really answer that." - **Reflexive framing**: "honestly the title tell the whole story uh in just a single line." --- ## Communication Patterns - **Speaker contrast**: Speaker 1 (first section) is markedly more disfluent ("and and and reply," "back uh back back"); Speaker 2 (technical section) delivers tighter, more polished prose, e.g., "A slow engine that runs on a long time window and learns the user and their work." - **Parallelism for emphasis**: > "The more it sees, the more it understands. And the more it understands, the more you can lean on it." - **Concrete demo details** anchoring abstractions: "combin is an engineering manager... I'm working on two projects psychic and notaker. I'm from Tel Aviv." - **Time-pressured closing** acknowledged directly: "if you have any question, uh we out of time." --- ## Uncertainty Notes - Attribution of speakers by name is not directly observable; the handoff ("So go ahead. Thank you.") and "My name is Tormer. My name is Omri. This is Tor" are muddled in the transcript, so which speaker delivered which section beyond the handoff point is uncertain. - Filler-word density partly reflects transcription; exact counts are unreliable, though the pattern is clearly observable. # Video Position Record: From Systems of Record to Systems of Context ## Talk Overview - **Speakers:** Omri Bruchim and Tomer ("Tor") Ast, engineering managers at monday.com. (Note: the transcript has some speaker-name ambiguity — one introduces himself as "Tormer"/"Tomer"; attribution below follows turn-taking in the transcript.) - **Thesis:** For decades software has recorded *what happened*; the next step is software that *understands the connections* between records — shifting monday.com from a **system of record** to a **system of context**. ## Core Framing: Understanding vs. Retrieval - Central motivating question: **"What should I focus on right now?"** - Speaker 1 claims assistants (Gemini, GPT, Claude) answer this with disconnected bullet lists, not connected to your actual work. He jokes that Claude suggested he go to the gym. - Key stated position: > "It has all the data, but it has zero understanding." > "The problem was never the missing of data, the retrieval. The problem is the missing understanding." - Explicit emphasis: the talk focuses on **understanding** — "Not context, not memory, not retrieval, understanding." ## Why It's Hard — Three Stated Problems 1. **The agent gap** — Agents excel when told what to do (e.g., drafting an escalation reply) but *guess* when asked what to prioritize, because they don't know who you are or your priorities. 2. **Records without meaning** — Analogy: a line of code doesn't explain itself; you trace meaning through git blame → PR description → the monday.com item → the original customer complaint. 3. **Meaning must be built ahead of time** — Constructing context at runtime, when the question is asked, is "really too late." ## The Proposed Solution: "Monday World Model" - Speaker 1: It is **not** "a bigger prompt" or "a longer context window" — "a totally different" approach. Also "not a retrieval problem." ### Data Model (Tomer) Built from thousands of data points (status changes, activity logs, messages, meetings) into three constructs: - **Work structure** — key entities, relationships, dependencies (e.g., Slack message → task, who blocks whom) - **Live snapshot** — current signals: overdue items, urgency, active collaborators - **Durable profile** — decisions, outcomes, work patterns over time ### Two Engines - **Slow engine:** long time window; mines patterns, personas, routines, goals; reinforces a durable profile. - **Fast engine:** short recent window; recomputes live signals; understands "your day"; updates frequently. - Claimed precedent: this split mirrors **complementary learning systems** in neuroscience (hippocampus vs. neocortex) and **lambda architecture** in data processing — "Two different fields landed on the same idea." ### Stated Benefits - **Resilience/graceful degradation** — isolated sources; serve-time logic verifies against live data, falls back to last verified context. - **Urgency awareness** — knows when to proactively notify vs. stay silent. - **Compounding** — profile sharpens daily; new data sources are "deliberately cheap" and only add. ### Stated Limitations (preserved as expressed) - "We're not pretending this solves everything." - The model **trails the live world**. - **New users** have no reliable data yet. - **Signals carry biases**; the hardest part is "telling the important parts from the noise." ## Context: monday.com & Sidekick - monday.com positions itself as "where the work lives" — every project, task, decision, meeting logged. - Four platform bets: **Sidekick, Vibe, Agents, Workflows**; talk focuses on **Sidekick** (AI personal assistant, "a bird on your shoulder"). - Example flow (Speaker 1): breadcrumbs — boards, emails, meeting transcripts, action items, calendar patterns (bi-weekly VP meetings), Slack messages — processed fast/slow into a profile (role, projects, hours) plus current commitments (unanswered VP email, three promises). ## Closing Claim > "The bottleneck was never the capability… It was the understanding how you connect each one of the dots." - Even "the most capable agent in the world" doesn't understand you without preprocessing — which is what Sidekick / the Monday world model aims to solve. # Video Attribution Record ## Video - **Title:** From Systems of Record to Systems of Context — Omri Bruchim & Tomer Ast, monday.com - **ID:** `01a15ca8-670a-7f45-8fd9-57dfd9f23dd8` ## Speakers & Roles | Speaker | Role | Evidence | |---|---|---| | **Tomer Ast** ("Tor") | **Co-presenter / Speaker** — Engineering Manager, monday.com | Introduced via title and self-introduction: "My name is Tormer… we both engineering manager at monday.com"; delivers the second segment on the data model and engines | | **Omri Bruchim** | **Co-presenter / Speaker** — Engineering Manager, monday.com | "My name is Omri"; opens the talk, frames the problem, and delivers the closing segment | - Both speak in the capacity of **company representatives presenting their own product work** (monday.com / "Sidekick" / "Monday world model"). - No other voices appear; there is no separate narrator or host audible in the transcript. ## Role-Based Claim Boundaries ### Claims by Omri Bruchim - monday.com is a global work platform used by hundreds of thousands of teams. - The problem is "missing understanding," not missing data or retrieval. - Three challenges: the **agent gap**, records lacking meaning, and meaning being hard to compute at runtime. - Personal anecdote: tested an assistant last week and "Claude asked me to go to the gym." - The "Monday world model" is "not a bigger prompt" or longer context window. ### Claims by Tomer Ast - Data model built from thousands of user data points (item status changes, activity logs, messages, meetings). - Two-engine architecture: **slow engine** (long-window profile) and **fast engine** (live signals). - Draws analogies to **complementary learning systems** in neuroscience (hippocampus / neocortex) and **lambda architecture** in data processing — attributed to those fields, explicitly stated as "not something we invented." - Acknowledged limitations (speaker's own admission): model trails the live world, new users lack reliable data, signals carry biases. - Note: closing speaker ("back to the original question") says "Thomas said we collect all the data point" — an apparent misattribution in-speech; the data-model segment was delivered by Tomer Ast. ## Referenced Sources & Third-Party Claims - **AI assistants mentioned (not endorsed):** Gemini, GPT, Claude ("Cloud") — used as examples of assistants lacking contextual understanding; the gym anecdote is a personal claim about Claude. - **Concepts cited from external fields:** - Neuroscience: complementary learning systems, hippocampus/neocortex split. - Data infrastructure: lambda architecture (speed layer + batch layer). - **Platforms/products referenced:** monday.com, monday Sidekick, monday vibe, monday agents, monday workflows, Slack, GitHub ("git blame", PRs), calendar/email data sources, MCPs. ## Promotional Segments - **Entire talk is promotional on behalf of monday.com** — presented by employees about their own product (Sidekick / "Monday world model"). - **Explicit calls-to-action (flagged):** - "You can follow us on LinkedIn. We post things on the area." - "We are here near the stage" (post-talk availability). ## Comment Availability - **No information** in the supplied material regarding comment availability or audience feedback channels. ## Provenance Uncertainties - Speaker-to-segment attribution relies on verbal handoffs ("First before like Tor going to talk"; "Thank you. Hi everybody") — consistent with the two-speaker split described above. - Speaker name rendering varies in transcript ("Tormer"/"Tor" vs. title's "Tomer Ast"); the title spelling is used here. - The transcript's "Thomas" reference appears to be a transcription error for Tomer. Um, hey everyone. Uh, we are super excited to be here. Thanks for having us. Uh, today we're going to talk about how we shift monday.com from a system of record uh, into a system of context. And honestly the title tell the whole story uh in just a single line. 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. What we want to talk today is like take it step further. Uh we want software that actually understand the connection between them. So I want to 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 cloud 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 last week and uh Cloud 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 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, this is the heart of the entire talk. The problem was never the missing of data, the retrieval. The problem is like the missing understanding. uh those are two totally different things and almost everyone mix between them. Understanding is the word that we're going to focus the entire the entire talk. Not context, not memory, not retrieval, understanding. So um quick about ourselves. My name is Tormer. My name is Omri. This is Tor. 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. Uh monday.com is a global software company. Uh we build a work platform uh used by hundreds of thousands of teams. Um and the part that really mattered 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 NSDR agent that call to your prospects and help you sell the product. And if you are like a finance team or marketing we want to help you uh with the research. 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. We have like Monday sidekick we're going to 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 deterministic flow we have like Monday workflows but today we're gonna focus on psychic 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 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 putting all these bullets and uh building all these promise is really hard. Um so let's talk about why it's hard and there are three points for that. Um first like picture one assistant sitting on top of absolutely everything. You have your u your u 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 there's wall of records everywhere. Um so what why it's making so hard to connect between them. There are three reason for that. One is something that we call the agent gap. Your agent every agent is really sharp and 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 nailed it. He know how to do it. He take the context. 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 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 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, no 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 get blame and understand uh from the commit log what why why someone do it. But if you want to go farther, you can go to the PR and maybe read the 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 complain about something. So this is what we're trying to build. 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. Um it's really too late. Um you simply can't do something like that the moment someone asked the question. So understanding understanding of the context has to be ahead of time. Um you need to build it much before someone asks the question. Um and this is why we have built what we are building. We are building uh the Monday world model. This is what we called the Monday world model. Help you um understand why this matter um how to help you, who you are, when and and what's not to do. Um it's the 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 from from what we know until now. First before like Tor going to 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. Understand how each one of these entity connected to each other. So go ahead. Thank you. 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 resone over. The first is how the user's work is structured, their key 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 co-workers you've been actively working with, and why. The third is what we can learn about the user over time. There are 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 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. 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 server do, what's suddenly urgent, which co-workers 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 complimentary 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 hippocmpus and over time the new 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 premputee 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 live 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. So back uh back back to the original uh question that we had. What should I focus on right now? Remember the the question. So now Psyche can really answer that. Uh let's see how. 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 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 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. We took all this data and we uh process them either fast or slow. Um the slow build some kind of like profile on you. So you can see it on the top like combin is an engineering manager. We I'm working on two projects psychic and notaker. I'm from Tel Aviv. And this is how many hours I have 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. I have to to reply to a VP that sending 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 psychic can answer those questions. So to summarize it, the bottleneck was never uh the capability where you can where you 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 a cloud and Gemini, it doesn't understand you. He need to process it beforehand. This is what we're trying to solve at Psychic. Um this is the Monday word model. Uh this is what we're building. Um if you have any question, uh we out of time. We are here uh uh near the stage. Thank you very much for the time. Uh you can follow us on LinkedIn. We post things on on the area. Thank you very much.