---

Context Graphs for Proactive Enterprise Agents: The Leap from Passive Response to Proactive Service

First, look at some data: A 2025 McKinsey survey shows that enterprise employees spend an average of 19% of their workday on information retrieval and context switching, equivalent to wasting nearly 7 working days annually. Another Gartner prediction states that by 2028, over 60% of enterprise software will embed some form of "proactive agent" to anticipate user intent and provide information or operational suggestions in advance. However, most current enterprise agents remain stuck in the "Q&A" passive response stage, requiring users to explicitly state needs before the system gives answers—this is like a smart home voice assistant that can only execute "turn on living room lights" commands but doesn't know that when you're sitting on the sofa reading, the light should automatically dim to 3000K color temperature.

My core viewpoint is clear: Context Graphs are the key infrastructure enabling enterprise agents to evolve from "following instructions" to "understanding scenarios." They solve the fundamental pain point of proactive agents—agents don't know when, at what granularity, and for whom to do what. Without context graphs, proactivity becomes harassment; with them, proactivity becomes true efficiency improvement.

---

Context Graphs from a Product Manager's Perspective: Scenarios, Timing, and Trust

In the smart home sector, we walked similar wrong paths. Early Xiaomi smart home platforms required users to manually set "Away Mode" or "Sleep Mode," with each scenario corresponding to a set of device states. This is essentially "static context"—users predefine rules, and the system strictly executes them. But true intelligence should be dynamic: phone location knows you're about to arrive home, combined with calendar data judging you just returned from the gym, so it pre-turns on the AC and adjusts the humidifier to comfortable humidity. Behind this is a real-time updated context graph: nodes for time, location, user status, device status, historical behavior, etc., interconnected to form a reasoning-capable graph structure.

Enterprise scenarios are far more complex than homes. For an enterprise agent to become a true "proactive assistant," it needs to understand:

• Who (role, permissions, current project)
• What (task type, current stage, dependencies)
• Where (physical location, virtual space, context within collaboration tools)
• When (deadlines, meeting schedules, attention state)
• Why (business goals, priority, urgency)

Weaving these dimensions into a context graph allows the agent to judge "should I proactively push last quarter's sales report now, or stay silent." The paper "Context Graphs for Proactive Enterprise Agents" attempts to use graph structures to uniformly express this information and enable agents to reason and decide on the graph.

From a product logic perspective, this is equivalent to providing the agent with a "scenario map." Each node on the map isn't an isolated data point but a semantic unit with attributes, relationships, and weights. The agent no longer blindly scans the inbox every 5 minutes but, when the "Meeting Ended" node is activated in the context graph and the deadline associated with the "Pending Decision Project" node is approaching, automatically generates a decision draft and pushes it to relevant people. This event-driven + graph reasoning pattern avoids information overload while ensuring timely service.

---

Commercial Value: From Selling Features to Subscribing to Scenarios

If you only view context graphs as a technical improvement, you might underestimate their commercial potential. As a product manager, I care more about how they change enterprise software business models.

Current enterprise collaboration tools (Slack, Teams, Feishu/Lark) basically charge by "features + storage." Users paying for DingTalk bots are essentially buying an interface for queries and message forwarding. But with proactive agents, pricing logic can shift to charging by "successful scenarios." For example, an "Auto-Scheduling Assistant" supported by context graphs can accurately coordinate cross-department meetings, charging 0.5 yuan per successful coordination. This model requires the agent to truly understand business process context, not just keyword matching.

From a user value perspective, context graphs lower the installation barrier. Traditional enterprise agents require extensive manual configuration: telling the system your role, team structure, common tools, and process norms. Graph structures naturally support incremental learning: agents can auto-generate a coarse-grained context graph from initial system data (org chart, calendars, code repos), then refine edge weights based on user behavioral feedback (accepting or ignoring suggestions). Users don't need to write config files; they just "use normally," and the agent self-learns. This aligns with my insight from working on Xiaomi's IoT platform back then: The best intelligence is where users don't feel the setup process.

---

Challenges and Concerns: Privacy, Cold Start, and Graph Maintenance

Any product manager, beyond excitement, must face risks. The core of context graphs is data connectivity, inevitably touching enterprise data privacy. Nodes in the graph may contain sensitive info (customer contract amounts, employee performance), and edge relationships may expose undisclosed internal collaboration patterns. For agents to serve proactively, they must access this data—but there's natural tension between "proactivity" and "privacy." One solution is protecting raw data during graph construction via differential privacy or federated learning, but this sacrifices some reasoning accuracy.

Cold start is another practical difficulty. For newly established or less digitized enterprises, the context graph is blank. Agents need an "observation period" to make effective recommendations. During this time, products must design guided interactions, letting users gradually "feed" graph data, rather than handing them a bot that only says "I'm still learning." My experience suggests starting with structured data (WeCom contacts, email domains, org trees) to build a rough "skeleton graph," then accelerating graph growth through small reward mechanisms (e.g., "Found a potential collaborator") encouraging user confirmation clicks.

Graph maintenance is equally non-negligible. Enterprise structures change, projects flow, and weights need dynamic updates. If the context graph stays static, proactive recommendations quickly deviate from user expectations, eventually causing users to disable the agent. This requires underlying graph storage to support real-time incremental updates, not full recalculations every midnight.

---

Trend Prediction

Within the next three years, context graphs will move from academic papers to mainstream enterprise software infrastructure. Experience in smart homes proves: Whoever builds a truly scenario-understanding context graph first will occupy the niche in the era of proactive services. Specifically, I predict that by the end of 2027, at least three top enterprise collaboration platforms (like Microsoft 365, Google Workspace, Feishu/Lark) will launch proactive agent products based on context graphs. Their core differentiation will no longer be feature count, but the authenticity of the graph structure's scenario understanding. As product managers, we should think now: how to make the graph rich enough for proactive reasoning yet lightweight enough to reduce user cognitive load. This path won't be easier than smart homes, but the direction is clear—from "waiting for instructions" to "proactive understanding," we are crossing that line.

---

Original Link: https://arxiv.org/abs/2607.07721