The Two Clocks Problem: Missing the reasoning layer
Look at enterprise software today, and you notice a glaring blind spot. We have built massive infrastructures to capture what is currently true. Your CRM records a lost deal. Your Git repository contains the final codebase. Your ticketing system shows an incident as resolved. These platforms are excellent at preserving state.
The difficulty arises because they discard the reasoning behind those states. We do not track why a system timeout limit changed from five seconds to thirty. We lose the context of why a clinician deviated from standard protocol. That institutional knowledge dissolves into undocumented hallway conversations, forgotten Slack messages, and the silent intuition of senior engineers.
This creates a fundamental issue for artificial intelligence. We expect AI agents to make complex decisions, yet we feed them systems of record containing only outcomes. It is akin to asking a junior lawyer to argue a case using a list of past verdicts, without any access to the underlying case law. When companies connect a language model to their databases, the results fall flat because the model sees the data but remains blind to the organisation’s decision logic.
Entering the Context Graph: Modelling decisions
Bridging the gap between current state and historical reasoning is known as the two clocks problem. Resolving it requires a shift away from traditional databases and basic vector search towards a dynamic layer that captures decision traces.
Building a context graph is not a matter of giving an AI agent more memory or dumping documents into a retrieval system. It involves joining data across five distinct coordinate systems that do not share common keys: the event itself, the timeline, the semantics, the attribution, and the final outcome.
Organisational reality is messy. You cannot predefine a rigid schema for this. The definition of a “customer” means one thing to a consumer application and something different to a B2B SaaS platform. Instead, a context graph learns the structure through observation. As AI agents navigate arbitrary systems to solve problems, their trajectories map the implicit structure of the business. They act as informed explorers, turning broad searches into specific reasoning patterns.
The reality of implementation
Once a context graph accumulates enough structural data, it transitions from a simple retrieval index into a simulator. It encodes the specific physics of your organisation.
When multiple coding agents collaborate on a repository, they need a shared workspace to understand architectural decisions, dependencies, and priorities. A mature context graph provides this shared reasoning layer. It allows engineering teams to move beyond basic search queries and start asking hypothetical questions that yield context-aware answers.
The implementation challenges are real. Entity resolution across disconnected platforms remains a difficult engineering hurdle. A contributor might be “S. Popat” in a legal contract, “Swapnil Popat” in an email thread, and “@swapnilpopat” on an external platform. Matching these identities reliably at scale takes significant effort. Moreover, no system can capture the reasoning that was never written down in the first place.
Despite these hurdles, the direction is clear. The next phase of enterprise software will not be defined by who has the smartest foundational model. It will be defined by who can best capture and simulate the institutional intelligence connecting data to action.
Footnotes:
- Koratana, Animesh. “How to build a context graph.”Akoratana.com, January 2026.
- Rakić, Branimir. “The next big shift in AI agents: shared context graphs.” Medium, April 2026.
