🤖 AI

Do Proactive Agents Really Need an LLM to Decide When to Wake and What to Anchor?

This paper proposes replacing the inefficient practice of converting structured user activity events into text for LLM-based decision-making with a lightweight, on-device temporal-graph-learning model that directly processes graph updates to trigger proactive agents, achieving significantly higher accuracy, faster inference speeds, and a smaller memory footprint.

Original authors: Xiaoze Liu, Ruowang Zhang, Amir H. Abdi, Michel Galley, Zhikai Chen, Siheng Xiong, Xiaoqian Wang, Jing Gao

Published 2026-05-29

📖 4 min read☕ Coffee break read

CC BY 4.0

Original authors: Xiaoze Liu, Ruowang Zhang, Amir H. Abdi, Michel Galley, Zhikai Chen, Siheng Xiong, Xiaoqian Wang, Jing Gao

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you have a super-smart digital assistant living on your computer. Its job is to be "proactive"—meaning it should guess what you need before you even ask. But there's a catch: if this assistant is too chatty, it becomes annoying. If it's too quiet, it's useless.

The paper asks a simple question: Do we need a giant, expensive brain (a Large Language Model or LLM) to decide when to wake up and what to talk about?

The authors say: No. In fact, using a giant brain for this is like using a supercomputer to check if your front door is locked. It's overkill, slow, and wasteful.

Here is the breakdown of their solution using simple analogies:

1. The Problem: The "Always-On" Giant

Current proactive assistants work like this:

The Scenario: You click a file, switch a window, or type a search.
The Old Way: Every single time you do this, the system takes your action, turns it into a sentence (like "The user opened email_filter.py"), and asks a giant AI (the LLM): "Hey, should I interrupt the user now? And what should I say?"
The Flaw: This is slow and expensive. It's like hiring a famous movie director to decide if you should turn on the kitchen light. It takes too long, costs too much, and the director is too busy to be watching the light switch 24/7.

2. The Solution: The "Graph Detective"

The authors propose a different approach. They realize that your computer activity isn't really a story; it's a map.

The Map: When you work, you are moving between specific points: Files, Apps, Websites, and Search Queries. These points are connected by time.
The Detective: Instead of a giant AI, they use a small, specialized "detective" (a Temporal Graph Learning model). This detective looks at the map of your activity.
- Decision 1 (The Wake-Up Call): The detective looks at the map and asks, "Is this a moment where the user needs help?" If yes, it rings the bell. If no, it stays silent.
- Decision 2 (The Anchor): If it rings the bell, it points to the specific spot on the map that matters (e.g., "It's about this specific file, not just the whole app").

3. The Magic Trick: One Pass, Two Answers

The coolest part is how efficient this is.

The Old Way: The giant AI had to read the whole story, think about the timing, then think about the content.
The New Way: The small detective looks at the map once. In that single glance, it decides both "Wake up!" and "Look at this file."
The Result: It's incredibly fast (about 11 milliseconds) and small enough to run on your laptop without slowing it down.

4. The "Giant Brain" Gets a Job, Not a Promotion

The authors aren't getting rid of the giant AI (the LLM). They are just giving it a better job.

The Detective's Job: Do the boring, constant monitoring. Decide when to speak and what to point at.
The Giant AI's Job: Only wake up when the detective rings the bell. Its job is to take the specific file or link the detective pointed to and turn it into a polite, helpful sentence for you.

The Results: Why It Matters

The paper tested this against 14 different types of "Giant Brains" (from small open-source models to massive commercial ones).

Better Accuracy: The system made fewer mistakes. It stopped interrupting when it shouldn't and gave better suggestions when it did.
Speed: It was 4 to 80 times faster than using the giant AI to make the decision.
Privacy: Because the "detective" is so small, it can run entirely on your own computer. It doesn't need to send your private file names or search history to the cloud to make a decision.

The Bottom Line

The paper argues that proactive agents shouldn't use a "sledgehammer" (a giant LLM) to crack a "nut" (deciding when to interrupt). Instead, use a small, specialized tool (a graph model) to do the heavy lifting of monitoring and deciding, and only call in the big guns when it's truly necessary. This makes the assistant faster, cheaper, and less annoying.

Technical Summary: Proactive Agents and Temporal Graph Learning

Problem Statement
Current proactive agent architectures rely on Large Language Models (LLMs) to make "always-on" decisions regarding when to intervene (triggering) and what context to provide (routing). This approach faces two critical inefficiencies:

Expensive and Slow Triggering: Running a large LLM on every user event (e.g., file opens, app switches) creates a significant latency and computational bottleneck, as the trigger decision is on the critical path of the system.
Ungrounded Suggestions: When an LLM-based trigger fires, the resulting suggestion often lacks grounding in specific user artifacts. Because the trigger and context selection are often separate stages, the intervention may default to generic session topics rather than the specific entity the user is actively manipulating.

The core issue is a mismatch in data representation: user activity is natively a structured event stream (actor, verb, object, timestamp) maintained by the operating system as a graph. Converting this structure into text and asking an LLM to recover the structure is an unnecessary "round-trip" that loses cross-event entity linkages and many-to-many event-entity structures.

Methodology
The authors propose a Graph-First, Grounded Architecture that replaces the LLM-based trigger and context selector with a small Temporal Graph Learning (TGL) model.

Graph Construction: User activity is converted into a heterogeneous temporal interaction graph. Nodes represent events and semantic entities (files, applications, URLs, queries), while edges encode temporal sequences and "has_entity" relationships.
Shared Backbone: A single TGL encoder (stacking relation-aware GATv2 layers with a Jumping Knowledge head) processes the session graph in one forward pass.
Dual-Head Output:
- Trigger Head: Operates on event nodes to output a probability ( $p_{trig}$ ) of whether to wake the downstream agent.
- Routing Head: Operates on entity nodes to output relevance scores ( $s_{rout}$ ) for specific entities, selecting the structured context to be forwarded.
Downstream Execution: The downstream language agent (LLM) is invoked only when the trigger head clears a threshold. It consumes the high-scoring routed entities as structured context to generate a fluent, user-facing suggestion.

Key Contributions

Formulation: The paper reframes proactive triggering and context selection as a joint node-level prediction problem over a heterogeneous temporal graph, rather than a language modeling problem. This enables a lightweight, always-on controller.
Architecture: The authors instantiate a unified design where a trigger head and a routing head share a single TGL backbone. They are trained jointly against a combined objective, ensuring the wake-up decision and the evidence selection are derived from the same hidden state in a single forward pass.
Efficiency and Performance: The approach decouples the "always-on" decision from the heavy reasoning of the LLM, reserving the LLM for moments that survive the trigger.

Experimental Results
Evaluated on the ProactiveAgent desktop benchmark across 14 diverse language-agent backbones (ranging from 4B to 8B open-weight models to closed APIs like GPT-4o and Claude-Opus):

Performance Gain: The TGL approach improved F1 scores on every backbone, with a mean increase of +16.7 (range +3.1 to +46.0). Notably, it outperformed fine-tuned proactive baselines (e.g., Qwen2-7B-Proact.) by using a small graph encoder add-on rather than parameter-level adaptation.
Trigger Quality: The TGL trigger achieved the highest AUC scores (0.738 on "must-fire" events) compared to rule-based, tabular, textual (BERT/MLP), and LLM-as-trigger baselines. It also demonstrated superior calibration, allowing a single global threshold to serve all backbones effectively.
Latency and Footprint:
- Speed: TGL processes events in 11.13 ms on a GPU server and 13.99 ms on a consumer laptop. This is 4–7× faster than single-forward LLM triggers and 12–83× faster than LLM triggers on consumer hardware.
- Memory: The model has a resident footprint of ~220 MiB (BF16), enabling on-device deployment alongside privacy-sensitive activity streams. In contrast, an 8B LLM trigger requires ~16 GB VRAM.

Significance and Claims
The paper claims that the "always-on" path for proactive agents is fundamentally a graph problem, not a language problem. By treating activity streams as graph updates rather than text sequences, the system avoids the inefficiency of serializing structured data for an LLM to parse.

The authors argue that a simple design principle emerges: keep a lightweight temporal model always on to handle the "wake-up" and "grounding" decisions, and reserve full LLM reasoning only for the moments that survive this trigger. This approach achieves state-of-the-art performance while drastically reducing latency and computational cost, making real-time, on-device proactive assistance feasible without compromising privacy or responsiveness. The study suggests that the trigger and context selection should share state to prevent decision drift, a property naturally achieved by the unified TGL architecture.