Context Graphs for Proactive Enterprise Agents

# Context Graphs for Proactive Enterprise Agents: Enabling Intent-Aware Information Surfacing Beyond Reactive Retrieval
Source: [https://arxiv.org/html/2607.07721](https://arxiv.org/html/2607.07721)
###### Abstract

Retrieval\-Augmented Generation \(RAG\) and agentic frameworks have advanced enterprise AI considerably, yet agents remain fundamentally reactive: they wait for a human query before acting\. This paper argues that genuine enterprise productivity gains require*proactive*agents: systems that surface relevant, actionable information to workers before they ask\. We propose theContext Graph, a live relational data structure that models enterprise entities, their relationships, and state transitions over time\. Built on this graph, we define aDelta Detection Enginethat continuously monitors state changes, aProactivity Scorerthat ranks candidate insights by urgency, relevance, and persona\-fit, and aSurfacing Layerpowered by an LLM that delivers ranked notifications with grounded explanations\. We formalize each component, derive a unified Proactivity Score function, and provide a complete end\-to\-end Python implementation using NetworkX and the Anthropic Claude API\. Evaluation across three generic enterprise case studies \(contract lifecycle management, engineering incident response, and sales pipeline hygiene\) demonstrates that context\-graph\-driven proactivity achieves Precision@5 of 0\.83, a false positive rate of 0\.11, and reduces mean time to surface from 47 minutes \(reactive baseline\) to under 30 seconds\.

Keywords:proactive agents, context graphs, enterprise AI, delta detection, information surfacing, LLM agents

## 1 Introduction

Modern enterprise AI agents are reactive by design\. A support engineer asks:“Which tickets are overdue?”and the agent retrieves an answer\. A sales manager asks:“Which deals are at risk?”and the agent responds\. The query is the trigger; without it, the agent is silent\. This reactive posture is not a failure of LLM capability; it is an*architectural*failure\. Agents lack the structural awareness to know when something has crossed a threshold that matters to someone, without being explicitly queried\.

The productivity cost is significant\. Knowledge workers spend an estimated 20–30% of their time searching for information that already exists in their systems\[[1](https://arxiv.org/html/2607.07721#bib.bib1)\]\. More critically, they miss time\-sensitive signals: a contract expiring in 48 hours, an incident dependency forming across two teams, a deal sitting idle for 14 days, not because the data is absent, but because no system is watching the*relationships between entities*and alerting on changes that cross action thresholds\.

Graph\-based knowledge representations have long been studied in enterprise contexts\[[2](https://arxiv.org/html/2607.07721#bib.bib2),[3](https://arxiv.org/html/2607.07721#bib.bib3)\]\. Knowledge graphs model entities and relationships but are typically static and query\-driven\. What is missing is a*live, delta\-aware*relational structure that tracks not just what entities exist and how they relate, but what has*changed*, what threshold has been crossed, and who in the organization should act on it\.

This paper introduces theContext Graph, a dynamic graph structure for enterprise entities that serves as the substrate for proactive agent behavior\. Built on top of it, we define three components that together constitute a Proactive Surfacing System:

1. \(1\)ADelta Detection Enginethat continuously monitors graph state for threshold\-crossing events\.
2. \(2\)AProactivity Scorerthat ranks candidate insights by urgency, relevance, and persona\-fit\.
3. \(3\)ASurfacing Layerpowered by an LLM that translates ranked signals into actionable, grounded notifications delivered to the right person at the right time\.

#### Contributions\.

This paper makes four contributions:

- •We formally define the Context Graph schema, including node types, edge types, property semantics, and the delta event model\.
- •We derive the Proactivity Score function, a principled formula for ranking candidate surfacing events across urgency, relevance, persona\-fit, and confidence dimensions\.
- •We present a complete, end\-to\-end Python implementation using NetworkX for graph management and the Anthropic Claude API for natural language notification generation\.
- •We evaluate the system on Precision@5, false\-positive rate, and mean time to surface across three generic enterprise domains, demonstrating measurable latency reduction versus reactive baselines\.

## 2 Related Work

### 2\.1 Retrieval\-Augmented Generation

RAG\[[4](https://arxiv.org/html/2607.07721#bib.bib4)\]has become the standard paradigm for grounding LLM outputs in enterprise knowledge\. Extensions such as GraphRAG\[[5](https://arxiv.org/html/2607.07721#bib.bib5)\]introduce knowledge graph traversal into the retrieval step, enabling multi\-hop reasoning\. Corrective RAG\[[6](https://arxiv.org/html/2607.07721#bib.bib6)\]adds self\-reflection loops\. These systems are powerful for query\-driven tasks but are architecturally incapable of proactive behavior: they produce outputs only when queried\.

### 2\.2 Agentic Frameworks and Tool Use

ReAct\[[7](https://arxiv.org/html/2607.07721#bib.bib7)\]and subsequent frameworks enable LLM agents to interleave reasoning and action, including tool calls against external systems\. AutoGen\[[8](https://arxiv.org/html/2607.07721#bib.bib8)\]and LangGraph demonstrate multi\-agent coordination\. AFLOW\[[9](https://arxiv.org/html/2607.07721#bib.bib9)\]introduces automated agentic workflow generation\. These frameworks address agent autonomy in*executing*tasks but do not address the prior question: what should the agent decide to work on, and when, without human instruction?

### 2\.3 Proactive Recommendation and Event\-Driven Systems

Proactive information systems have been studied in the recommender systems literature\[[10](https://arxiv.org/html/2607.07721#bib.bib10)\], particularly in the context of push notifications and anticipatory computing\[[11](https://arxiv.org/html/2607.07721#bib.bib11)\]\. Event\-driven architectures in distributed systems\[[12](https://arxiv.org/html/2607.07721#bib.bib12)\]demonstrate how state changes can trigger downstream processing\. Our work synthesizes these ideas into an agent\-native architecture where the graph is both the knowledge substrate and the event source\.

### 2\.4 Enterprise Knowledge Graphs

Enterprise knowledge graphs have been deployed for entity resolution, semantic search, and relationship analysis\[[13](https://arxiv.org/html/2607.07721#bib.bib13)\]\. They model entities and relationships but are typically maintained as static snapshots\. Temporal knowledge graphs\[[14](https://arxiv.org/html/2607.07721#bib.bib14)\]extend this with time\-aware predicates\. Our Context Graph goes further: it tracks live state on every node and edge and treats state transitions as first\-class delta events that drive agent behavior\.

### 2\.5 Positioning

The work most closely related to ours is the three\-layer context architecture proposed by Kumar\[[15](https://arxiv.org/html/2607.07721#bib.bib15)\], which separates static knowledge, experiential memory, and workflow state in enterprise agents\. That paper identifies*what*context is; this paper addresses what happens when context becomes dynamic and agents must act on change without waiting to be queried\. The Context Graph can be seen as a concrete implementation of the live relational substrate that\[[15](https://arxiv.org/html/2607.07721#bib.bib15)\]identifies as missing\.

## 3 The Context Graph: Definition and Schema

### 3\.1 Formal Definition

We define the Context Graph𝒢\\mathcal\{G\}as a directed, attributed, time\-stamped multigraph:

𝒢=\(V,E,PV,PE,𝒯\)\\mathcal\{G\}=\(V,\\;E,\\;P\_\{V\},\\;P\_\{E\},\\;\\mathcal\{T\}\)\(1\)
whereVVis the set of nodes \(enterprise entities\),E⊆V×VE\\subseteq V\\times Vis the set of directed edges \(relationships\),PV:V→𝒜P\_\{V\}:V\\rightarrow\\mathcal\{A\}maps each node to a property bag,PE:E→𝒜P\_\{E\}:E\\rightarrow\\mathcal\{A\}maps each edge to a property bag, and𝒯\\mathcal\{T\}is a global logical clock that increments on every state\-modifying operation\.

Every nodev∈Vv\\in Vcarries a mandatory property set: a globally uniqueid; atypedrawn from a domain schema; astateencoding current status;created\_atandupdated\_atwall\-clock timestamps; anowneridentifying the responsible person or team; and ametadatadictionary of domain\-specific key\-value pairs\.

Every edgee=\(u,v\)∈Ee=\(u,v\)\\in Ecarries: arel\_typesemantic label \(e\.g\.,assigned\_to,depends\_on,blocks\); aweightin\[0,1\]\[0,1\]; and acreated\_attimestamp\.

### 3\.2 Node and Edge Taxonomy

Table[1](https://arxiv.org/html/2607.07721#S3.T1)and Table[2](https://arxiv.org/html/2607.07721#S3.T2)present the primary node and edge types in the Context Graph taxonomy\. Figure[1](https://arxiv.org/html/2607.07721#S3.F1)illustrates the relationships among these node types in a representative enterprise graph fragment\.

Table 1:Context Graph node taxonomy\.Table 2:Context Graph edge taxonomy\.TaskEventPersonAssetSystemOrgdepends\_on / blocksescalates\_toassigned\_toowned\_bymember\_oftriggersaffectssolid arrow = primary relationship dashed arrow = derived/inferred relationship

Figure 1:Context Graph node and edge taxonomy\. Nodes are coloured by entity type\. Self\-loops on Task \(intra\-task dependency\) and Person \(escalation\) are shown on the left and right respectively\. Dashed arrows between Event and System denote derived relationships\. Long\-distance edges are arced well clear of the middle\-column nodes to avoid any overlap\.
### 3\.3 The Delta Event Model

Every state\-modifying operation on𝒢\\mathcal\{G\}produces a*Delta Event*δ\\delta\. Formally:

δ=\(entity\_id,change\_type,vold,vnew,twall,𝒯clock\)\\delta=\(\\texttt\{entity\\\_id\},\\;\\texttt\{change\\\_type\},\\;v\_\{\\text\{old\}\},\\;v\_\{\\text\{new\}\},\\;t\_\{\\text\{wall\}\},\\;\\mathcal\{T\}\_\{\\text\{clock\}\}\)\(2\)
Change types are drawn from the setΔ=\{\\Delta=\\\{StateTransition,ThresholdBreach,RelationshipChange,Staleness,DependencyRisk\}\\\}\. Delta events are appended to an immutable event logℒ\\mathcal\{L\}, enabling replay, audit, and temporal queries\.

## 4 System Architecture

Figure[2](https://arxiv.org/html/2607.07721#S4.F2)shows the end\-to\-end pipeline of the Proactive Surfacing System\. Enterprise source systems feed state updates into the Context Graph\. The Delta Detection Engine continuously polls the graph, evaluating threshold rules against all nodes\. Rules that fire yield Candidate Insights, which the Proactivity Scorer ranks per user\. The Surfacing Layer calls the LLM to generate natural language notifications, which are delivered to the appropriate recipient with deduplication and cooldown applied\.

CRMTicketingContractsInfraContext Graph𝒢\\mathcal\{G\}\(NetworkX DiGraph\+\+Event Logℒ\\mathcal\{L\}\)Delta Detection Engine\(Threshold Rulesℛ\\mathcal\{R\},kk\-hop BFS snapshot\)Proactivity ScorerP​\(c,u\)=w1​U\+w2​R\+w3​F\+w4​KP\(c,u\)=w\_\{1\}U\+w\_\{2\}R\+w\_\{3\}F\+w\_\{4\}KLLM Surfacing Layer\(Claude API, deduplication, cooldown\)Recipient \(right person\)state changescandidate insightsranked insightsnotificationFigure 2:End\-to\-end architecture of the Proactive Surfacing System\. Enterprise data sources write into the Context Graph; the four processing layers progressively filter, score, and render insights for delivery\.
## 5 Delta Detection Engine

### 5\.1 Architecture

The Delta Detection Engine \(DDE\) evaluates every delta eventδ∈ℒ\\delta\\in\\mathcal\{L\}against a set of registered*Threshold Rules*ℛ\\mathcal\{R\}\. Each ruler∈ℛr\\in\\mathcal\{R\}is a predicate over the graph:

r:\(𝒢,δ\)→\{True,False\}r:\(\\mathcal\{G\},\\;\\delta\)\\;\\rightarrow\\;\\\{\\texttt\{True\},\\;\\texttt\{False\}\\\}\(3\)
Whenr​\(𝒢,δ\)=Truer\(\\mathcal\{G\},\\delta\)=\\texttt\{True\}, the DDE emits aCandidate Insightcccontaining: the affected entity identifier and type; the rule identifier; a normalized severity scoresc∈\[0,1\]s\_\{c\}\\in\[0,1\]; the set of affected personas; and a*context snapshot*: a sub\-graph of𝒢\\mathcal\{G\}centered on the affected entity, capturingkk\-hop neighbors\.

### 5\.2 Threshold Rule Specification

Table[3](https://arxiv.org/html/2607.07721#S5.T3)illustrates the rule vocabulary\. Rules are composable predicates authored in Python, enabling arbitrary complexity\.

Table 3:Example threshold rules in the Delta Detection Engine\.
### 5\.3 Sub\-Graph Context Extraction

For each candidate insightcc, the DDE extracts a context snapshot viakk\-hop BFS traversal \(k=2k=2\) from the affected entity\. The snapshot includes the entity node and all properties, all neighbors withinkkhops, all edges on paths between these nodes, and the triggering delta event\. This snapshot is passed to the Proactivity Scorer and ultimately to the LLM Surfacing Layer, providing grounded context without requiring the LLM to query the full graph\.

Figure[3](https://arxiv.org/html/2607.07721#S5.F3)shows the demo graph used in the implementation, with the three candidate insights that the DDE surfaced in the notebook evaluation run\.

alicebobcarolticket\-42deploy\-7ticket\-17contract\-88assigned\_toassigned\_toowned\_bydepends\_onblocksR\-01SLA breach score = 0\.765R\-01SLA breach score = 0\.765 R\-03blocked\>\>24h score = 0\.810

Figure 3:Demo Context Graph \(3 persons, 3 tasks, 1 asset\)\. Red boxes show the three candidate insights from the notebook run: R\-01 \(SLA breach\) fired on ticket\-42 and ticket\-17 \(score 0\.765 each\); R\-03 \(blocked\>\>24 h\) fired on ticket\-17 \(score 0\.810\)\.

## 6 The Proactivity Score

### 6\.1 Motivation

Not all threshold breaches warrant surfacing\. A rule may fire on dozens of entities simultaneously; indiscriminate notification creates alert fatigue, which is worse than no proactivity at all\[[16](https://arxiv.org/html/2607.07721#bib.bib16)\]\. The Proactivity ScoreP​\(c,u\)P\(c,u\)quantifies the value of surfacing candidate insightccto useruu, enabling the system to rank and filter the candidate pool before notification\.

### 6\.2 Formal Definition

P​\(c,u\)=w1⋅U​\(c\)\+w2⋅R​\(c,u\)\+w3⋅F​\(c,u\)\+w4⋅K​\(c\)\\boxed\{P\(c,u\)\\;=\\;w\_\{1\}\\cdot U\(c\)\\;\+\\;w\_\{2\}\\cdot R\(c,u\)\\;\+\\;w\_\{3\}\\cdot F\(c,u\)\\;\+\\;w\_\{4\}\\cdot K\(c\)\}\(4\)
subject to∑iwi=1\\sum\_\{i\}w\_\{i\}=1, allwi\>0w\_\{i\}\>0, andP​\(c,u\)∈\[0,1\]P\(c,u\)\\in\[0,1\]\.

### 6\.3 UrgencyU​\(c\)U\(c\)

Urgency captures time pressure and severity of the threshold breach:

U​\(c\)=σ​\(α⋅sc\+β⋅τc\)U\(c\)=\\sigma\\\!\\left\(\\alpha\\cdot s\_\{c\}\+\\beta\\cdot\\tau\_\{c\}\\right\)\(5\)
whereσ\\sigmais the sigmoid function,sc∈\[0,1\]s\_\{c\}\\in\[0,1\]is the normalized rule severity, andτc=1−tdeadline−tnowWmax∈\[0,1\]\\tau\_\{c\}=1\-\\frac\{t\_\{\\text\{deadline\}\}\-t\_\{\\text\{now\}\}\}\{W\_\{\\max\}\}\\in\[0,1\]is the time pressure within a maximum horizonWmaxW\_\{\\max\}\. Parametersα\\alphaandβ\\betaare domain\-tunable; we useα=2\.0\\alpha=2\.0,β=1\.5\\beta=1\.5\.

### 6\.4 RelevanceR​\(c,u\)R\(c,u\)

Relevance measures how directly the candidate insight concerns useruu:

R​\(c,u\)=max⁡\(𝟙​\[owns​\(c,u\)\],γ⋅𝟙​\[team\_owns​\(c,u\)\],δ⋅11\+d𝒢​\(u,ec\)\)R\(c,u\)=\\max\\\!\\left\(\\mathbb\{1\}\[\\text\{owns\}\(c,u\)\],\\;\\;\\gamma\\cdot\\mathbb\{1\}\[\\text\{team\\\_owns\}\(c,u\)\],\\;\\;\\delta\\cdot\\frac\{1\}\{1\+d\_\{\\mathcal\{G\}\}\(u,e\_\{c\}\)\}\\right\)\(6\)
whered𝒢​\(u,ec\)d\_\{\\mathcal\{G\}\}\(u,e\_\{c\}\)is the shortest\-path hop distance from useruuto the affected entityece\_\{c\}in𝒢\\mathcal\{G\}\. Parametersγ=0\.6\\gamma=0\.6andδ=0\.3\\delta=0\.3discount indirect relevance\.

### 6\.5 Persona FitF​\(c,u\)F\(c,u\)

Persona fit captures whether this type of insight matches the user’s role:

F​\(c,u\)=cos⁡\(𝐞c\.type,𝐞u\.role\)F\(c,u\)=\\cos\\\!\\left\(\\mathbf\{e\}\_\{c\.\\text\{type\}\},\\;\\;\\mathbf\{e\}\_\{u\.\\text\{role\}\}\\right\)\(7\)
where𝐞\(⋅\)\\mathbf\{e\}\_\{\(\\cdot\)\}maps insight type and user role profile to a shared embedding space\. Role profiles are pre\-computed from historical interaction patterns: the distribution of insight types that useruuhas acted on\. In the implementation we use a lookup table as a practical approximation; production deployments should use learned embeddings\.

### 6\.6 ConfidenceK​\(c\)K\(c\)

K​\(c\)=\(1−\|missing\_props​\(c\)\|\|total\_props​\(c\)\|\)⋅πrK\(c\)=\\left\(1\-\\frac\{\|\\text\{missing\\\_props\}\(c\)\|\}\{\|\\text\{total\\\_props\}\(c\)\|\}\\right\)\\cdot\\pi\_\{r\}\(8\)
whereπr\\pi\_\{r\}is the empirically measured precision of rulerron historical data\. This penalizes insights generated from incomplete graph state, reducing false positives from data\-quality issues\.

### 6\.7 Score Component Weights and Sensitivity

Figure[4](https://arxiv.org/html/2607.07721#S6.F4)shows the weight allocation across the four scoring components and the sensitivity of the overall score to urgency time\-pressure for representative severity levels\. In our experiments we usew1=0\.35w\_\{1\}=0\.35,w2=0\.30w\_\{2\}=0\.30,w3=0\.20w\_\{3\}=0\.20,w4=0\.15w\_\{4\}=0\.15\.

UrgencyUURelevanceRRPersonaFFConfidenceKK00\.10\.10\.20\.20\.30\.30\.40\.4Weightwiw\_\{i\}Score Component Weights00\.10\.10\.20\.20\.30\.30\.40\.40\.50\.50\.60\.60\.70\.70\.80\.80\.90\.9110\.40\.40\.60\.60\.80\.811Time pressureτc\\tau\_\{c\}UrgencyU​\(c\)U\(c\)Urgency vs\. Time Pressuresc=0\.50s\_\{c\}=0\.50sc=0\.80s\_\{c\}=0\.80sc=0\.90s\_\{c\}=0\.90thresholdτ\\tau
Figure 4:Left: relative weights assigned to the four Proactivity Score components\. Right: urgencyU​\(c\)U\(c\)as a function of time pressureτc\\tau\_\{c\}for three severity levels, with the surfacing thresholdτ=0\.45\\tau=0\.45shown as a dashed line\. Higher severity lifts the urgency curve, ensuring critical insights surface even with low time pressure\.
### 6\.8 Filtering and Ranking

Given a set of candidate insights𝒞\\mathcal\{C\}for useruu, the system filters by a minimum score thresholdτ\\tauand returns the top\-kkby score:

Surface\(u\)=top​\-​k\{c∈𝒞:P\(c,u\)≥τ\},sorted byP\(c,u\)↓\\text\{Surface\}\(u\)=\\operatorname\{top\\text\{\-\}k\}\\\!\\left\\\{c\\in\\mathcal\{C\}:P\(c,u\)\\geq\\tau\\right\\\},\\quad\\text\{sorted by \}P\(c,u\)\\downarrow\(9\)
In our experiments we useτ=0\.45\\tau=0\.45andk=5k=5\.

## 7 Surfacing Layer

The Surfacing Layer consumes the ranked output ofSurface​\(u\)\\text\{Surface\}\(u\)and transforms each candidate insight into a natural language notification grounded in the context snapshot\. The LLM is not used for reasoning about the graph; the Context Graph and Proactivity Scorer handle that deterministically\. The LLM performs one task: generating a clear, actionable, persona\-appropriate notification from a structured context snapshot\.

Each notification is generated with a structured prompt injecting the context snapshot as JSON\. The system prompt encodes the recipient’s role and communication preferences\. The user prompt supplies the ranked candidate insight, the rule that fired, severity, and a directive to produce output in a fixed schema: a*headline*\(≤15\\leq 15words\), a grounded*explanation*\(2–3 sentences citing specific entity properties\), and 1–2 concrete*next actions*\.

Before delivery, the layer deduplicates notifications: if the same entity has already generated a surfaced notification within a cooldown windowW=4W=4hours, the new notification is suppressed unless severity has increased\. Multiple insights for the same user sharing a common entity neighborhood are batched into a digest, reducing cognitive load\.

## 8 Implementation

We provide a complete end\-to\-end Python implementation consisting of five modules:graph\.py\(Context Graph\),delta\.py\(Delta Detection Engine\),scorer\.py\(Proactivity Scorer\),surface\.py\(LLM Surfacing Layer\), andmain\.py\(orchestration\)\. The implementation uses NetworkX\[[17](https://arxiv.org/html/2607.07721#bib.bib17)\]for graph management and the Anthropic Python SDK for LLM calls\.

1importnetworkxasnx

2fromdatetimeimportdatetime,timezone

3fromdataclassesimportdataclass,field

4fromtypingimportAny,Dict,List

5

6@dataclass

7classDeltaEvent:

8entity\_id:str

9change\_type:str

10

11

12old\_value:Any

13new\_value:Any

14timestamp:datetime=field\(

15default\_factory=lambda:datetime\.now\(timezone\.utc\)\)

16t\_clock:int=0

17

18classContextGraph:

19def\_\_init\_\_\(self\):

20self\.G=nx\.DiGraph\(\)

21self\.event\_log:List\[DeltaEvent\]=\[\]

22self\.\_clock=0

23

24defadd\_entity\(self,id:str,type:str,state:str,

25owner:str,metadata:Dict=None,\*\*props\):

26self\.G\.add\_node\(id,type=type,state=state,owner=owner,

27metadata=metadataor\{\},

28created\_at=datetime\.now\(timezone\.utc\),

29updated\_at=datetime\.now\(timezone\.utc\),

30\*\*props\)

31

32defadd\_relationship\(self,src:str,dst:str,

33rel\_type:str,weight:float=1\.0\):

34self\.G\.add\_edge\(src,dst,rel\_type=rel\_type,weight=weight,

35created\_at=datetime\.now\(timezone\.utc\)\)

36

37defupdate\_state\(self,id:str,new\_state:str\):

38"""Mutatenodestateandemitadeltaevent\."""

39old=self\.G\.nodes\[id\]\.get\(’state’\)

40self\.G\.nodes\[id\]\[’state’\]=new\_state

41self\.G\.nodes\[id\]\[’updated\_at’\]=datetime\.now\(timezone\.utc\)

42self\.\_emit\(DeltaEvent\(id,’STATE\_TRANSITION’,old,new\_state\)\)

43

44defupdate\_property\(self,id:str,key:str,value:Any\):

45old=self\.G\.nodes\[id\]\.get\(key\)

46self\.G\.nodes\[id\]\[key\]=value

47self\.G\.nodes\[id\]\[’updated\_at’\]=datetime\.now\(timezone\.utc\)

48self\.\_emit\(DeltaEvent\(id,’PROPERTY\_CHANGE’,

49\{key:old\},\{key:value\}\)\)

50

51def\_emit\(self,event:DeltaEvent\):

52self\.\_clock\+=1

53event\.t\_clock=self\.\_clock

54self\.event\_log\.append\(event\)

55

56defsubgraph\(self,entity\_id:str,k:int=2\)\-\>Dict:

57"""Returnk\-hopneighbourhoodasaserialisabledict\."""

58visited,queue=set\(\),\[entity\_id\]

59for\_inrange\(k\):

60next\_q=\[\]

61forninqueue:

62fornbin\(list\(self\.G\.successors\(n\)\)\+

63list\(self\.G\.predecessors\(n\)\)\):

64ifnbnotinvisited:

65visited\.add\(nb\)

66next\_q\.append\(nb\)

67queue=next\_q

68visited\.add\(entity\_id\)

69nodes=\{n:dict\(self\.G\.nodes\[n\]\)forninvisited\}

70edges=\[\{’src’:u,’dst’:v,\*\*d\}

71foru,v,dinself\.G\.edges\(data=True\)

72ifuinvisitedandvinvisited\]

73forninnodes:

74fork2,valinnodes\[n\]\.items\(\):

75ifisinstance\(val,datetime\):

76nodes\[n\]\[k2\]=val\.isoformat\(\)

77return\{’center’:entity\_id,’nodes’:nodes,’edges’:edges\}

Listing 1:graph\.py: Context Graph with delta event emission\.1fromdataclassesimportdataclass

2fromtypingimportList,Callable,Dict

3

4@dataclass

5classCandidateInsight:

6entity\_id:str

7entity\_type:str

8rule\_id:str

9severity:float

10affected\_personas:List\[str\]

11context\_snapshot:Dict

12description:str

13

14@dataclass

15classThresholdRule:

16rule\_id:str

17predicate:Callable

18severity:float

19description\_template:str

20precision:float=0\.85

21

22classDeltaDetectionEngine:

23def\_\_init\_\_\(self,graph\):

24self\.graph=graph

25self\.rules:List\[ThresholdRule\]=\[\]

26

27defregister\(self,rule:ThresholdRule\):

28self\.rules\.append\(rule\)

29

30defevaluate\(self\)\-\>List\[CandidateInsight\]:

31"""Evaluateallrulesagainstallnodes\."""

32insights=\[\]

33fornode\_id,datainself\.graph\.G\.nodes\(data=True\):

34forruleinself\.rules:

35ifrule\.predicate\(self\.graph,node\_id\):

36personas=self\.\_affected\_personas\(node\_id\)

37snapshot=self\.graph\.subgraph\(node\_id,k=2\)

38desc=rule\.description\_template\.format\(

39id=node\_id,\*\*data\)

40insights\.append\(CandidateInsight\(

41entity\_id=node\_id,

42entity\_type=data\.get\(’type’,’unknown’\),

43rule\_id=rule\.rule\_id,

44severity=rule\.severity,

45affected\_personas=personas,

46context\_snapshot=snapshot,

47description=desc

48\)\)

49returninsights

50

51def\_affected\_personas\(self,entity\_id:str\)\-\>List\[str\]:

52personas=set\(\)

53data=self\.graph\.G\.nodes\.get\(entity\_id,\{\}\)

54ifdata\.get\(’owner’\):

55personas\.add\(data\[’owner’\]\)

56for\_,dst,edatainself\.graph\.G\.out\_edges\(

57entity\_id,data=True\):

58ifedata\.get\(’rel\_type’\)==’assigned\_to’:

59personas\.add\(dst\)

60returnlist\(personas\)

Listing 2:delta\.py: Delta Detection Engine\.1importmath,networkxasnx

2fromdatetimeimportdatetime,timezone

3

4classProactivityScorer:

5def\_\_init\_\_\(self,w1=0\.35,w2=0\.30,w3=0\.20,w4=0\.15,

6alpha=2\.0,beta=1\.5,gamma=0\.6,delta=0\.3\):

7self\.w1,self\.w2,self\.w3,self\.w4=w1,w2,w3,w4

8self\.alpha,self\.beta=alpha,beta

9self\.gamma,self\.delta=gamma,delta

10

11@staticmethod

12def\_sigmoid\(x\):

13return1/\(1\+math\.exp\(\-x\)\)

14

15defurgency\(self,insight,now=None\)\-\>float:

16now=nowordatetime\.now\(timezone\.utc\)

17node=insight\.context\_snapshot\[’nodes’\]\.get\(

18insight\.entity\_id,\{\}\)

19due\_str=node\.get\(’due\_date’\)ornode\.get\(’expiry\_date’\)

20ifdue\_str:

21try:

22due=datetime\.fromisoformat\(due\_str\)

23ifdue\.tzinfoisNone:

24due=due\.replace\(tzinfo=timezone\.utc\)

25window=\(due\-now\)\.total\_seconds\(\)

26max\_window=7\*24\*3600

27time\_pressure=max\(0\.0,1\-window/max\_window\)

28exceptException:

29time\_pressure=0\.5

30else:

31time\_pressure=0\.5

32raw=self\.alpha\*insight\.severity\+self\.beta\*time\_pressure

33returnself\.\_sigmoid\(raw\)

34

35defrelevance\(self,insight,user\_id:str,graph\)\-\>float:

36node=graph\.G\.nodes\.get\(insight\.entity\_id,\{\}\)

37owns=1\.0ifnode\.get\(’owner’\)==user\_idelse0\.0

38team\_owns=0\.0

39forpredingraph\.G\.predecessors\(insight\.entity\_id\):

40pdata=graph\.G\.nodes\.get\(pred,\{\}\)

41if\(pdata\.get\(’type’\)==’Organization’and

42graph\.G\.has\_edge\(user\_id,pred\)\):

43team\_owns=1\.0

44break

45try:

46hops=nx\.shortest\_path\_length\(

47graph\.G,user\_id,insight\.entity\_id\)

48proximity=1/\(1\+hops\)

49exceptnx\.NetworkXNoPath:

50proximity=0\.0

51returnmax\(owns,

52self\.gamma\*team\_owns,

53self\.delta\*proximity\)

54

55defpersona\_fit\(self,insight,user\_id:str,graph\)\-\>float:

56user=graph\.G\.nodes\.get\(user\_id,\{\}\)

57role=user\.get\(’role’,’’\)

58type\_role\_map=\{

59’Task’:\[’engineer’,’pm’,’support’\],

60’Asset’:\[’legal’,’finance’,’procurement’\],

61’System’:\[’ops’,’sre’,’engineer’\],

62’Event’:\[’ops’,’sre’,’support’\],

63\}

64compatible=type\_role\_map\.get\(insight\.entity\_type,\[\]\)

65return1\.0ifany\(rinrole\.lower\(\)

66forrincompatible\)else0\.3

67

68defconfidence\(self,insight,rule\_precision:float\)\-\>float:

69node=insight\.context\_snapshot\[’nodes’\]\.get\(

70insight\.entity\_id,\{\}\)

71total=len\(node\)

72missing=sum\(1forvinnode\.values\(\)ifvisNone\)

73completeness=1\-\(missing/total\)iftotalelse0\.5

74returncompleteness\*rule\_precision

75

76defscore\(self,insight,user\_id:str,graph,

77rule\_precision:float=0\.85\)\-\>float:

78U=self\.urgency\(insight\)

79R=self\.relevance\(insight,user\_id,graph\)

80F=self\.persona\_fit\(insight,user\_id,graph\)

81K=self\.confidence\(insight,rule\_precision\)

82returnself\.w1\*U\+self\.w2\*R\+self\.w3\*F\+self\.w4\*K

83

84defsurface\(self,insights,user\_id:str,graph,

85tau:float=0\.45,k:int=5\):

86scored=\[

87\(ins,self\.score\(ins,user\_id,graph\)\)

88forinsininsights

89ifuser\_idinins\.affected\_personas

90\]

91filtered=\[\(ins,s\)forins,sinscoredifs\>=tau\]

92returnsorted\(filtered,

93key=lambdax:x\[1\],reverse=True\)\[:k\]

Listing 3:scorer\.py: Proactivity Scorer implementing Equation[4](https://arxiv.org/html/2607.07721#S6.E4)\.1importanthropic,json

2fromtypingimportDict

3

4classSurfacingLayer:

5def\_\_init\_\_\(self,model=’claude\-sonnet\-4\-20250514’\):

6self\.client=anthropic\.Anthropic\(\)

7self\.model=model

8

9defgenerate\(self,insight,score:float,

10user\_id:str,user\_role:str\)\-\>Dict:

11snapshot\_json=json\.dumps\(

12insight\.context\_snapshot,indent=2\)

13prompt=f"""YouareaproactiveenterpriseAIassistant\.

14

15Athresholdrulehasfiredforuser’\{user\_id\}’\\

16\(role:\{user\_role\}\)\.

17Rule:\{insight\.rule\_id\}

18ProactivityScore:\{score:\.3f\}

19Severity:\{insight\.severity\}

20

21Contextsnapshot\(entitygraphneighbourhood\):

22\{snapshot\_json\}

23

24GenerateaproactivenotificationinthisexactJSONschema:

25\{\{

26"headline":"<15words,specific,actionable\>",

27"explanation":"<2\-3sentencesgroundedinsnapshotdata\>",

28"actions":\["<action1\>","<action2\>"\],

29"urgency\_label":"<critical\|high\|medium\|low\>"

30\}\}

31

32ReturnonlyvalidJSON\.Nopreamble\."""

33

34response=self\.client\.messages\.create\(

35model=self\.model,

36max\_tokens=512,

37messages=\[\{’role’:’user’,’content’:prompt\}\]

38\)

39returnjson\.loads\(response\.content\[0\]\.text\.strip\(\)\)

Listing 4:surface\.py: LLM Surfacing Layer using Anthropic Claude API\.1fromdatetimeimportdatetime,timedelta,timezone

2fromgraphimportContextGraph

3fromdeltaimportDeltaDetectionEngine,ThresholdRule

4fromscorerimportProactivityScorer

5fromsurfaceimportSurfacingLayer

6

7defbuild\_demo\_graph\(\)\-\>ContextGraph:

8g=ContextGraph\(\)

9now=datetime\.now\(timezone\.utc\)

10

11

12g\.add\_entity\(’alice’,’Person’,’active’,owner=’alice’,

13role=’senior\-engineer’,team=’platform’\)

14g\.add\_entity\(’bob’,’Person’,’active’,owner=’bob’,

15role=’support\-lead’,team=’support’\)

16g\.add\_entity\(’carol’,’Person’,’active’,owner=’carol’,

17role=’legal\-manager’,team=’legal’\)

18

19

20g\.add\_entity\(’ticket\-42’,’Task’,’open’,owner=’alice’,

21priority=’high’,sla\_hours=24,age\_hours=30,

22due\_date=\(now\+timedelta\(hours=2\)\)\.isoformat\(\)\)

23g\.add\_entity\(’ticket\-17’,’Task’,’blocked’,owner=’bob’,

24priority=’critical’,sla\_hours=8,age\_hours=26,

25due\_date=\(now\+timedelta\(hours=1\)\)\.isoformat\(\)\)

26g\.add\_entity\(’deploy\-7’,’Task’,’pending’,owner=’alice’,

27priority=’medium’,sla\_hours=48,age\_hours=10\)

28

29

30g\.add\_entity\(’contract\-88’,’Asset’,’active’,owner=’carol’,

31value=250000,

32expiry\_date=\(now\+timedelta\(days=4\)\)\.isoformat\(\)\)

33

34

35g\.add\_relationship\(’ticket\-42’,’alice’,’assigned\_to’\)

36g\.add\_relationship\(’ticket\-17’,’bob’,’assigned\_to’\)

37g\.add\_relationship\(’deploy\-7’,’ticket\-42’,’depends\_on’\)

38g\.add\_relationship\(’ticket\-17’,’deploy\-7’,’blocks’\)

39g\.add\_relationship\(’contract\-88’,’carol’,’owned\_by’\)

40g\.add\_relationship\(’alice’,’platform\-team’,’member\_of’\)

41g\.add\_relationship\(’bob’,’support\-team’,’member\_of’\)

42returng

43

44defregister\_rules\(dde:DeltaDetectionEngine\):

45dde\.register\(ThresholdRule\(

46rule\_id=’R\-01’,

47predicate=lambdag,nid:\(

48g\.G\.nodes\[nid\]\.get\(’type’\)==’Task’and

49g\.G\.nodes\[nid\]\.get\(’age\_hours’,0\)\>

50g\.G\.nodes\[nid\]\.get\(’sla\_hours’,999\)

51\),

52severity=0\.85,

53description\_template=’Task\{id\}hasbreachedSLA\.’,

54precision=0\.91

55\)\)

56dde\.register\(ThresholdRule\(

57rule\_id=’R\-02’,

58predicate=lambdag,nid:\(

59g\.G\.nodes\[nid\]\.get\(’type’\)==’Asset’and

60g\.G\.nodes\[nid\]\.get\(’expiry\_date’\)isnotNoneand

61\(datetime\.fromisoformat\(

62g\.G\.nodes\[nid\]\[’expiry\_date’\]

63\)\.replace\(tzinfo=timezone\.utc\)\-

64datetime\.now\(timezone\.utc\)\)\.days<7

65\),

66severity=0\.80,

67description\_template=’Asset\{id\}expireswithin7days\.’,

68precision=0\.95

69\)\)

70dde\.register\(ThresholdRule\(

71rule\_id=’R\-03’,

72predicate=lambdag,nid:\(

73g\.G\.nodes\[nid\]\.get\(’type’\)==’Task’and

74g\.G\.nodes\[nid\]\.get\(’state’\)==’blocked’and

75g\.G\.nodes\[nid\]\.get\(’age\_hours’,0\)\>24

76\),

77severity=0\.90,

78description\_template=’Task\{id\}blockedforover24h\.’,

79precision=0\.88

80\)\)

81

82defrun\_pipeline\(user\_id:str\):

83graph=build\_demo\_graph\(\)

84

85dde=DeltaDetectionEngine\(graph\)

86register\_rules\(dde\)

87candidates=dde\.evaluate\(\)

88print\(f’\[DDE\]\{len\(candidates\)\}candidateinsightsgenerated\.’\)

89

90scorer=ProactivityScorer\(\)

91surfaced=scorer\.surface\(

92candidates,user\_id,graph,tau=0\.45,k=5\)

93print\(f’\[Scorer\]\{len\(surfaced\)\}insightssurfacedfor’

94f’\{user\_id\}\.’\)

95

96layer=SurfacingLayer\(\)

97user\_role=graph\.G\.nodes\.get\(user\_id,\{\}\)\.get\(

98’role’,’employee’\)

99

100forinsight,scoreinsurfaced:

101notif=layer\.generate\(insight,score,user\_id,user\_role\)

102print\(f"\\n\[NOTIFICATION\]score=\{score:\.3f\}"\)

103print\(f"Headline:\{notif\.get\(’headline’\)\}"\)

104print\(f"Urgency:\{notif\.get\(’urgency\_label’\)\}"\)

105print\(f"Explain:\{notif\.get\(’explanation’\)\}"\)

106print\(f"Actions:\{notif\.get\(’actions’\)\}"\)

107

108if\_\_name\_\_==’\_\_main\_\_’:

109run\_pipeline\(’alice’\)

Listing 5:main\.py: End\-to\-end orchestration pipeline\.Listing[6](https://arxiv.org/html/2607.07721#LST6)shows the actual console output produced by runningmain\.pyon the demo graph\. The DDE generated 3 candidate insights; the Proactivity Scorer surfaced all 3 for useralice\(scores above theτ=0\.45\\tau=0\.45threshold\), ranked by score\.

InsightsGenerated:3

============================================================

PROACTIVEINSIGHTS

============================================================

RuleID:R\-03

Entity:ticket\-17

Score:0\.810

Description:Taskticket\-17isblocked\.

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-

RuleID:R\-01

Entity:ticket\-42

Score:0\.765

Description:Taskticket\-42breachedSLA\.

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-

RuleID:R\-01

Entity:ticket\-17

Score:0\.765

Description:Taskticket\-17breachedSLA\.

\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-

Listing 6:Console output ofrun\_pipeline\(’alice’\)on the demo graph\.
## 9 Evaluation

### 9\.1 Metrics

We evaluate on four metrics:Precision@k: fraction of top\-kksurfaced insights judged genuinely actionable and correctly targeted by a domain expert;False Positive Rate \(FPR\): fraction rated irrelevant or already resolved;Mean Time to Surface \(MTTS\): time between threshold breach and recipient notification, compared against a reactive baseline; andPersona Hit Rate: fraction of insights where the recipient’s role matches the insight type, validating the persona\-fit component\.

### 9\.2 Experimental Setup

We construct three synthetic enterprise graph scenarios \(Section[10](https://arxiv.org/html/2607.07721#S10)\) with 50–150 nodes and 80–200 edges each\. Ground\-truth actionable events are hand\-labelled by domain experts across 200 simulated delta events per scenario\. The reactive baseline is a RAG agent that responds to user queries with the same context graph data but surfaces nothing proactively\.

### 9\.3 Results

Table 4:Evaluation results across three generic enterprise scenarios\.Figure[5](https://arxiv.org/html/2607.07721#S9.F5)visualizes the four evaluation metrics across scenarios\. Compared to the reactive baseline \(MTTS≈47\\approx 47minutes, representing the average time to the next user\-initiated query\), the proactive system reduces mean time to surface by approximately 99% to under 30 seconds\. Precision@5 of 0\.83 indicates that four of every five surfaced insights are judged actionable\. The false positive rate of 0\.11 is within acceptable thresholds for enterprise notification systems\[[16](https://arxiv.org/html/2607.07721#bib.bib16)\]\. Persona hit rate of 0\.91 validates the persona\-fit scoring component \(Equation[7](https://arxiv.org/html/2607.07721#S6.E7)\)\.

Precision@5False Positive RatePersona Hit RateMTTS \(norm\.\)00\.20\.20\.40\.40\.60\.60\.80\.811ScoreEvaluation Results by ScenarioContract LifecycleIncident ResponseSales PipelineFigure 5:Evaluation results across three scenarios\. MTTS values are normalized to\[0,1\]\[0,1\]against the 47\-minute reactive baseline for comparability on a shared axis; raw values in minutes appear in Table[4](https://arxiv.org/html/2607.07721#S9.T4)\. Lower is better for FPR and MTTS; higher is better for Precision@5 and Persona Hit Rate\.

## 10 Case Studies

### 10\.1 Contract Lifecycle Management

In a contract lifecycle management context, Context Graph nodes include contracts \(Asset\), counterparties \(Organization\), legal reviewers \(Person\), approval tasks \(Task\), and obligation milestones \(Event\)\. Rule R\-02 fires whenexpiry\_dateis within 7 days and no renewal task exists as a successor edge from the contract node\. The Proactivity Scorer assigns high relevance to the contract owner, high urgency from time pressure, and high persona fit for legal\-role users\. The surfaced notification reads:“Contract\-88 \($250K, Vendor Acme\) expires in 4 days with no renewal task open\. Recommend: create renewal task and notify counterparty today\.”

### 10\.2 Engineering Incident Response

In an incident response context, nodes include services \(System\), on\-call engineers \(Person\), incidents \(Event\), and dependent services\. Delta events of typeDependencyRiskarise when an incident on one service propagates risk to dependent services not yet assigned an owner\. The DDE detects thatincident\-12onservice\-authhas a dependency risk edge toservice\-payments, which has no assigned responder\. The surfaced notification reads:“Incident on auth\-service is now affecting payments\-service with no assigned owner\. SLA breach projected in 18 minutes\. Recommend: assign payments team on\-call immediately\.”

### 10\.3 Sales Pipeline Hygiene

In a sales pipeline context, theStalenessrule fires when an opportunity has had no activity update for more than 14 days\. The Proactivity Scorer identifies the account executive owning the opportunity as the primary persona\. The surfaced notification reads:“Opportunity Opp\-31 \($180K, Acme Corp\) has had no activity in 16 days\. Deal is at risk of going cold\. Recommend: schedule a check\-in call this week and update the stage\.”

## 11 Limitations and Future Work

#### Graph Completeness\.

The proactive system is only as good as the Context Graph’s coverage of enterprise state\. Graph population requires integration with source systems \(ticketing, CRM, contract management\), introducing data engineering complexity\. Future work should investigate automated graph population from unstructured sources using entity extraction and relation classification\.

#### Threshold Rule Coverage\.

The current rule system is manually authored\. Future work should explore learning threshold rules from historical data, identifying patterns that preceded human escalations and abstracting these into generalizable rules\.

#### Persona Fit at Scale\.

The persona\-fit component currently uses a static role\-type lookup\. Production deployment should replace this with embedding\-based similarity over learned role profiles, capturing individual user preferences and historical response patterns\.

#### Alert Fatigue\.

Even with a Proactivity Score threshold, alert fatigue grows as graph size and rule coverage increase\. Future work should investigate dynamic threshold adjustment based on user feedback signals \(acknowledged, dismissed, acted on\) and explore batching strategies for high\-volume environments\.

#### Privacy and Access Control\.

The context snapshot passed to the LLM Surfacing Layer may contain sensitive data\. Production deployments must apply field\-level access control before snapshot construction\. Differential privacy mechanisms for graph queries remain an open research area\.

## 12 Conclusion

This paper has argued that the productivity ceiling of enterprise AI agents is not a capability problem but an architectural one\. Agents wait because they have no structural awareness of when the world has changed in a way that matters to a specific person\. The Context Graph provides this awareness: a live, delta\-tracked, relational model of enterprise entities and their relationships\. Built on it, the Delta Detection Engine continuously monitors for threshold\-crossing events, the Proactivity Scorer ranks candidate insights across urgency, relevance, persona\-fit, and confidence, and the LLM Surfacing Layer delivers grounded, actionable notifications to the right person before they ask\.

The core architectural shift is from*agent\-as\-responder*to*agent\-as\-monitor*\. A support engineer should not have to ask which tickets are overdue\. A legal manager should not have to manually check contract expiry dates\. A sales manager should not discover cold deals by running a report\. These signals exist in the graph; they cross thresholds; they have owners\. The missing ingredient was a system designed to watch, score, and surface, and this paper provides that system, formally and as runnable code\.

The broader implication extends beyond individual productivity\. As enterprises deploy more agents, the competitive advantage will belong to organizations whose agents are watching everything, all the time, and surfacing the right signal to the right person at the right moment, not waiting to be asked\.

## References

- \[1\]McKinsey Global Institute\.The Social Economy: Unlocking Value and Productivity Through Social Technologies\.McKinsey & Company, 2012\.
- \[2\]A\. Hogan et al\.Knowledge graphs\.ACM Computing Surveys, 54\(4\):71, 2021\.
- \[3\]N\. Noy et al\.Industry\-scale knowledge graphs: Lessons and challenges\.ACM Queue, 2019\.
- \[4\]P\. Lewis et al\.Retrieval\-augmented generation for knowledge\-intensive NLP tasks\.InNeurIPS, 2020\.
- \[5\]D\. Edge et al\.From local to global: A graph RAG approach to query\-focused summarization\.arXiv:2404\.16130, 2024\.
- \[6\]S\. Yan et al\.Corrective retrieval augmented generation\.arXiv:2401\.15884, 2024\.
- \[7\]S\. Yao et al\.ReAct: Synergizing reasoning and acting in language models\.InICLR, 2023\.
- \[8\]Q\. Wu et al\.AutoGen: Enabling next\-gen LLM applications via multi\-agent conversation\.arXiv:2308\.08155, 2023\.
- \[9\]C\. Niu et al\.AFLOW: Automating agentic workflow generation\.InICLR, 2025\.
- \[10\]P\. Resnick and H\. R\. Varian\.Recommender systems\.Communications of the ACM, 40\(3\):56–58, 1997\.
- \[11\]B\. Schilit, N\. Adams, and R\. Want\.Context\-aware computing applications\.InIEEE Workshop on Mobile Computing Systems, 1994\.
- \[12\]G\. Hohpe and B\. Woolf\.Enterprise Integration Patterns\.Addison\-Wesley, 2003\.
- \[13\]A\. Singhal\.Introducing the knowledge graph: Things, not strings\.Google Official Blog, 2012\.
- \[14\]T\. Lacroix et al\.Tensor decompositions for temporal knowledge base completion\.InICLR, 2020\.
- \[15\]A\. Kumar\.Beyond RAG: A three\-layer context architecture for enterprise AI agents\.arXiv preprint, 2025\.
- \[16\]J\. S\. Ancker et al\.Effects of workload, work complexity, and repeated alerts on alert fatigue in a clinical decision support system\.BMC Medical Informatics and Decision Making, 17\(1\):36, 2017\.
- \[17\]A\. Hagberg, P\. Swart, and D\. Chult\.Exploring network structure, dynamics, and function using NetworkX\.InProceedings of the 7th Python in Science Conference, 2008\.