From Systems of Record to Systems of Context

Every enterprise tool built in the last two decades has been a system of record. Tasks, tickets, documents, messages, status changes — logged, timestamped, queryable, correct. Then AI agents arrived, we connected them to all of it, and discovered something uncomfortable: an assistant with access to everything still cannot answer the one question people actually ask every morning — what should I focus on right now?

That framing comes from a talk at AI Engineer by Omri Bruchim and Tomer Ast, engineering managers at monday.com, describing how they shifted their platform from a system of record into a system of context. Their diagnosis is the sharpest one-line summary of the whole agent-memory problem: the bottleneck was never the data or the retrieval — it was the understanding.

TL;DR — A system of record stores what happened. A system of context stores what it meant: how entities connect, what is urgent now, and the durable patterns of how work actually gets done. Agents fail at prioritisation not because they lack data — they usually have all of it — but because meaning was never written down anywhere. Teams building this precompute understanding ahead of time with a fast/slow engine split borrowed from neuroscience and data architecture. The cheapest version needs no pipeline at all: author the meaning explicitly, in markdown, where every agent can read it. That is what MDflow is for. Start free.

What is a system of context?

A system of context is software that stores not only the facts of your work but the meaning of them — which entities relate to which, what is urgent right now, and what has been learned over time about how you and your team operate. A system of record answers what is the status of this task? A system of context answers what should I do about it, and why?

The distinction is easiest to feel with a concrete example, and the monday.com talk uses a good one. You are looking at a single line of code. The record tells you it exists. git blame tells you who wrote it and when. The commit message might tell you what changed. The pull request might tell you what it fixed. And if you follow the PR to the ticket it closed, you finally learn the thing that actually explains it: a customer escalated, and this line is the answer. Every one of those hops crosses a different system of record. The meaning — customer complaint → decision → this line — exists nowhere as a first-class object. A human can reconstruct it in ten minutes of clicking. An agent, asked to reason about that code, simply cannot.

This is not a niche framing. The same shift is being named across the industry: Google Cloud engineers describe moving from a system of record to a system of intelligence with a context graph that stores "the reasoning of facts — the decisions made, the policies that governed them, and the outcomes that followed." CRM vendors are drawing the same line between record and context. Systems of record are not going away — they remain the authoritative, auditable truth. The claim is that they are no longer sufficient on their own once an agent is the one reading them.

Why systems of record fall short for AI agents

Because a log records that something happened, but never why it mattered — and an agent asked to prioritise needs the second thing. The monday.com team breaks the failure into three parts, and they generalise well beyond any one product.

1. The agent gap. Agents are extremely good at doing a task once they know what the task is, and quite bad at finding the task. Ask an agent to draft a reply to a customer escalation and it will nail it — the context is right there in the thread. Ask it what you should work on first and it guesses, because it has no model of what your priorities are or who you are. More memory does not fix this. It is not a recall problem.

2. Records without meaning. Every system faithfully logs its own events and none of them log the connective tissue between systems. The Slack thread, the calendar invite, the ticket, the commit, and the document are five records of one decision, and nothing anywhere states that they are the same decision.

3. Meaning cannot be built at runtime. This is the constraint most teams underestimate. You cannot assemble understanding in the moment someone asks a question. Retrieval can fetch the twenty documents mentioning a project in 200 ms; working out which of them matter, how they relate, and what changed this week requires reading far more than fits in a context window and far more time than anyone will wait. Understanding has to be built ahead of time. Query time is for serving it, not computing it.

The uncomfortable corollary: connecting more MCP servers does not help. If you already have the boards, the emails, the calendar, and the Slack history wired in and the answers are still generic bullet lists, adding a sixth source will produce a longer generic bullet list. The missing layer is not another pipe.

The fast/slow architecture behind a system of context

The working pattern is two engines running on different time windows: a slow one that learns who you are, and a fast one that knows what your day looks like. monday.com calls the result their "world model," and the shape is worth stealing regardless of what you are building.

• The slow engine takes weeks of activity as context and mines it for patterns — the persona, the routines, the cadence, the people you collaborate with, the projects you own. Those distil into a durable profile, and every time a pattern holds it is reinforced. This engine knows you.
• The fast engine takes a short recent window and recomputes live signals over the same entities — what is overdue, what suddenly became urgent, which colleague you have been unexpectedly pulled in with. This engine knows your day.

Both precompute offline. When the user actually asks something, only a thin slice of logic is recomputed against live data, and the already-assembled context is served to the agent, which can then decide how much of it to traverse.

The split was not invented for AI assistants — which is a good sign. It is the same architecture two unrelated fields converged on independently:

Building it this way buys two properties you would otherwise have to engineer separately. It degrades gracefully — sources are isolated, so a broken feed cannot poison the rest, and anything that fails live verification falls back to the last verified context instead of erroring. And it compounds: every day of captured activity sharpens the profile, and adding a new source only ever contributes, so the surface grows monotonically.

The honest limitations, which the monday.com team stated plainly on stage, are worth repeating: the model always trails the live world; a brand-new user has no signal to reason from; and inferred signals carry the biases of whatever produced them. The hard part is separating the important from the noise — and that is exactly where explicitly written context has an advantage.

Why this matters for developers and AI agents

For developers, the system-of-context framing changes what you build when an agent underperforms. The reflex is to add another integration or a bigger prompt. The framing says: ask whether the meaning your agent needs exists anywhere in a durable form. Usually it does not — it lives in someone's head, or is spread across five records that no field connects. Building the meaning layer is a different, smaller, more tractable project than building a smarter agent, and it is one you can start today with a text editor.

For AI agents, it is the difference between competence and usefulness. An agent handed a system of record can execute any task you name. An agent handed a system of context can tell you which task to name. That is the jump from a tool you drive to an assistant that reduces your load — and it is bounded entirely by how much meaning it can read, not by how capable the model is. As we argued in Context Engineering for AI Agents, curation beats a bigger prompt; the world model is that principle applied at the platform level.

Which applications benefit most

1. Work-management and project platforms — the canonical case. Tasks, owners, dependencies, and deadlines are already structured; what is missing is which of them matters this week and why.
2. Engineering organisations — where a code change is only interpretable through the decision, the incident, or the customer request that caused it. Architecture decision records and incident write-ups are a system of context that most teams already half-maintain.
3. Sales and customer-facing teams — a CRM records every touch and none of the judgement. Why this account stalled, what the champion actually cares about, which objection is real: that is context, not record.
4. Support and on-call — runbooks and postmortems are pure meaning-over-records. The alert is the record; the runbook is the context that makes it actionable.
5. Research and analysis teams — where the value is in the accumulated interpretation of sources, not the sources.
6. Any team running multiple AI agents — the moment two agents need to agree on what a project is, the shared meaning has to live outside both of them.

How MDflow fits

MDflow is the written layer of a system of context. The world-model approach infers meaning from behaviour with a pipeline; MDflow takes the complementary path — the meaning people already know is written down explicitly, in plain markdown, in a place every agent can read and write. The two are not rivals. Inferred context is broad and automatic but statistical and slow to warm up; authored context is narrower but immediate, precise, and auditable. Most teams need the authored layer first, because it is the one they can have this afternoon.

What already lines up today

Folder descriptions are meaning, stored as a first-class field. Every folder in MDflow carries a description that states what its documents are for — not what they contain, but the intent behind them. This is the smallest possible system of context: the connective tissue that records never carry. And it is load-bearing at retrieval time, because mdflow_get_context ranks folder descriptions above folder names and document titles when an agent asks about a topic. Describe a folder as "architecture decisions and the customer incidents that drove them" and an agent asking about a past design choice gets the right documents back — retrieval without a vector database.

Precomputed, not assembled at query time. The lesson that understanding must exist before the question is exactly why the description is a stored field you curate, rather than something inferred per request. You write the meaning once; every agent, on every future query, is served it. Workspaces add the outer bucket — a topic that clearly belongs to one part of your work can be scoped to it, so retrieval stays inside the right world.

Agents read and write it. Over MDflow's remote MCP server, Claude and the ChatGPT app connect with an OAuth sign-in and no token to paste, while Cursor, Codex, and Claude Code authenticate with a Personal Access Token. Because the write tools are real, an agent that learns something — a decision reached, a pattern noticed, a runbook step that was wrong — can write it back instead of losing it at the end of the session. That is the compounding property, at human speed.

Provenance and reversibility. Every change is version-tracked with automatic history, so the meaning layer carries the one thing an inferred profile struggles with: you can see who asserted something, when, and what it replaced. When an agent proposes a change, the diff is reviewable rather than a silent update to a black box.

Markdown, with no wrapper. Documents are stored markdown-native, and every document has a raw .md twin any tool, CI job, or agent can fetch — this post included, at /blog/systems-of-record-to-systems-of-context.md. Context that only one product can read is not context; it is a record in a nicer format. Add the web clipper for capturing sources, sharing and collections for scoping what a team or a client can see, and client-side encryption for the documents that need it.

Where we are headed

Direction, not a dated commitment: serving a whole collection of related documents to an agent as one cross-linked context bundle, so a spec, its decision log, and its glossary arrive together rather than as three retrievals; richer typed frontmatter so a document can carry status, owner, and freshness as structured signals an agent can weigh; and tighter round-trips for agent-proposed updates that a human approves before they land — the review step that makes a compounding context layer safe to let agents write to.

The bottom line

The industry spent twenty years perfecting systems of record and then handed them to agents that turned out to need something else. A system of record stores what happened. A system of context stores what it meant. The gap between them is why an assistant wired into every tool you own still answers "what should I focus on?" with a shrug in bullet-point form.

The sophisticated version of the fix is a world model: fast and slow engines precomputing structure, signals, and profile ahead of every question. The accessible version is available to anyone right now — write the meaning down where agents can read it. Folder descriptions that state intent. Decision logs that record why. Specs that define done. Plain markdown, versioned, reachable over MCP and an HTTP API.

Start free · Connect an AI agent · Read the API docs

Frequently asked questions

What is a system of context?

A system of context is software that stores not just what happened but what it meant — the entities in your work, how they connect, which are urgent right now, and the durable patterns of how you and your team operate. A system of record answers what is the status of this task; a system of context answers what should I focus on and why. The difference is understanding, not retrieval: most teams already have all the data, connected through integrations and MCP servers, and their agents still cannot prioritise.

What is the difference between a system of record and a system of context?

A system of record is the authoritative log of facts — tasks, tickets, documents, messages, status changes. It is optimised for correctness and audit. A system of context sits on top and encodes meaning: which entities relate to which, what is currently urgent, and what has been learned about how the work actually happens. Records tell you a line of code changed. Context tells you it changed because a customer escalated. Systems of record remain foundational; a system of context is the interpretation layer agents reason over.

Why can't an AI agent just retrieve context at query time?

Because understanding cannot be assembled in the second between a question and an answer. Retrieval can fetch the twenty documents that mention a project, but working out which matter, how they relate, and what is urgent requires reading far more than fits in a context window and far more time than a user will wait. That is why teams building this — monday.com's world model is a public example — precompute the structure offline and serve a thin, already-reasoned slice at query time.

What is the fast/slow engine architecture for agent context?

It is a split into two processes on different time windows. A slow engine reads weeks of activity and distils durable patterns — who you are, how you work, your projects, your collaborators — into a profile that is reinforced over time. A fast engine reads a short recent window and recomputes live signals: what is overdue, what became urgent, who pulled you in. The same split appears in neuroscience as complementary learning systems (fast hippocampus, slow neocortex) and in data architecture as the lambda architecture (speed layer plus batch layer, merged into one served view).

How do you build a system of context without a machine-learning pipeline?

Write the meaning down. Inferred context needs weeks of behavioural data and a pipeline; authored context is available immediately and is auditable. A folder description that states what its documents are for, a decision log that records why a choice was made, a spec that says what done means — these are the meaning layer, in plain markdown, that any agent can read over MCP or an HTTP API. MDflow is built for exactly that: markdown documents plus folder descriptions that rank first in retrieval.

Further reading

• AI Engineer — From Systems of Record to Systems of Context, Omri Bruchim & Tomer Ast, monday.com
• McClelland, McNaughton & O'Reilly (1995) — Why there are complementary learning systems in the hippocampus and neocortex
• Dremio — What is Lambda Architecture? (Nathan Marz's speed/batch/serving split)
• Google Cloud — From System of Record to System of Intelligence
• MDflow — Context Engineering for AI Agents · Folder Descriptions as Agent Context · AI Agent Memory vs RAG vs a Plain Markdown File · Let AI Agents Write to Your Knowledge Base · MCP documentation · API documentation