From Systems of Record to Systems of Context

Omri Bruchim, monday.com, Tomer Ast, monday.com15:58 · Jul 2026 · 1,354 views
Thumbnail for From Systems of Record to Systems of Context Watch on YouTube
TL;DR
  1. 1

    AI assistants can retrieve a user's work records while still failing to understand what those records mean or what deserves attention.

  2. 2

    monday.com's world model builds context ahead of time from a slow profile of how someone works and a fast view of what is happening now.

  3. 3

    Precomputed context lets Sidekick reason about priorities, verify recent facts, remain useful when sources fail, and improve as it observes more work.

Summary

Omri Bruchim and Tomer Ast argue that the main problem with work assistants is not retrieval. An assistant may have access to boards, tasks, emails, Slack messages, meetings, and documents, yet still give disconnected advice, such as telling Omri to go to the gym. A system of record stores what happened, but does not explain why it happened, how items connect, or what matters to a particular person. monday.com's answer is a world model that builds this understanding before a user asks a question. Its slow engine learns durable patterns from weeks of activity, while its fast engine tracks recent urgency and collaboration. Sidekick uses the resulting context to decide what to retrieve, how to reason, and when to speak. The design has limits: new users have little history, the model trails the live world, and its signals can contain bias. The speakers present it as an architecture that can be tested and improved over time.

Key ideas
01:00

Retrieval does not give an assistant understanding

Omri says a basic question such as "what should I focus on right now?" often produces unrelated bullets dressed up as a confident answer. When he tested Claude, it told him to go to the gym, even though the assistant could access his boards, tasks, emails, and Slack messages. The failure was not a lack of data. It was a lack of understanding about what the records mean and how they connect. The speakers make this distinction the foundation of the talk. Memory, context windows, and retrieval can expose more records, but they do not by themselves explain a user's priorities.

02:36

The assistant needs to understand work across monday.com and external sources

monday.com is where many teams keep projects, tasks, decisions, meetings, notes, and action items. The speakers describe Sidekick as a personal work assistant that can understand a user's work, think with them, and execute tasks while keeping the user in control. They place Sidekick alongside monday vibe, monday agent, and monday workflows. The important setting is broader than the monday.com boards themselves. The context model also draws from Slack, email, calendars, meeting transcripts, and other work activity, because a person's priorities are spread across those systems.

04:31

An agent can perform a defined task without knowing what to prioritize

The speakers describe an "agent gap." An agent may draft a reply to a customer escalation well once the task is specified, but it may guess when asked what to do first. It does not know enough about the user's identity, priorities, or current commitments. Records also lack meaning. A line of code can be connected to its blame record, pull request, monday.com item, and the customer complaint that caused it, but those links are not present in the line itself. The third difficulty is timing. The system must build meaning before the user asks, because constructing it at question time is too late.

07:19

The Monday world model connects records into an explanation of work

monday.com's proposed world model is meant to capture who a user is, how they work, when something matters, and what should not be done. Omri says it is not simply a larger prompt or a longer context window. The model describes relationships between entities rather than just fetching the entities. It can connect a message to a task, identify dependencies, and explain why an item exists. This gives the assistant a prepared representation of the user's work instead of a pile of records that must be interpreted from scratch for every question.

08:15

The data model combines structure, live state, and durable user patterns

Tomer describes three things the model constructs from thousands of data points such as status changes, activity logs, messages, and meetings. It represents how work is structured, including entities, relationships, dependencies, and blockers. It maintains a current snapshot with overdue items, urgent work, and active collaborators. It also learns durable patterns over time, including decisions, outcomes, routines, work rhythms, and recurring collaboration. These layers give the agent both an explanation of how work fits together and a view of what is happening to the user now.

09:21

A slow engine learns the person while a fast engine follows the day

The model uses two engines with different time windows. The slow engine examines weeks of activity and distills routines, work rhythms, collaborators, goals, projects, and a user persona into a durable profile. Repeated observations reinforce that profile. The fast engine reads a short recent window and recomputes live signals, such as what suddenly became urgent, what the user has committed to, and which coworkers have recently pulled them into work. Tomer summarizes the split simply: "One knows you and the other one knows your day."

10:21

The two-engine design follows ideas from neuroscience and data systems

The speakers connect their architecture to complementary learning systems in neuroscience and lambda architecture in data processing. They describe the hippocampus as capturing important experiences quickly, while the neocortex distills them into durable lessons over time. In data infrastructure, a speed layer handles recent real-time activity and a batch layer processes the full history. The two views are merged into one served view. monday.com applies the same pattern to the user's data model, combining long-term understanding with recent signals before Sidekick responds.

11:14

Precomputed context makes Sidekick more resilient and selective

Data from monday.com, Slack, email, and calendars is converted into structures, signals, and patterns offline and ahead of time. When Sidekick is used, only a thin layer of logic recomputes recent activity, while the broader context is served from the model. Sources are isolated, so a bad feed does not break everything else. Recent checks can verify part of the context against live data, while the rest falls back to the last verified version. The model can also judge when a fact is urgent enough to prompt the user and when it should remain silent.

12:52

The model improves with use, but it still trails reality

The speakers say the data model compounds as each day adds more observations and the profile becomes sharper. New sources can be added without rebuilding the whole design. They are also direct about the limits. The model is always behind the live world, new users do not yet have reliable history, and the signals contain their own biases. The hard problem remains separating important information from noise. In their example, the slow profile identifies Omri as an engineering manager working on Sidekick and Notetaker, while the fast layer identifies recent commitments, including a reply owed to a VP.

"The problem was never the missing of data, the retrieval. The problem is like the missing understanding."01:48
Who should watch
  • You are building an assistant that has access to many work systems but still gives generic or poorly prioritized answers.
  • Your product needs to combine long-term user patterns with fast-changing signals without rebuilding all context at request time.
  • You want an architecture that handles stale data, missing sources, new users, and proactive notifications without hiding those limitations.