Do Proactive Agents Need an LLM to Decide When to Act?
summary
The gist
This research addresses a critical architectural challenge in building proactive agents that monitor user activity: how to efficiently decide *when* to invoke a powerful Large Language Model (LLM)
In short
The research addresses how proactive agents should decide when to use an expensive Large Language Model (LLM) for action. Instead of calling the LLM constantly, a new graph-first approach uses a lightweight Temporal-Graph Learning model to filter events. This model predicts whether an intervention is needed and which entities are relevant, only invoking the LLM when the initial filter passes.
Key concepts
- Graph Construction
- The system treats user activity as a dynamic network. Nodes represent individual user events and the specific entities involved in those events. Edges define how these events and entities relate to each other over time, creating a structured map of interactions.
- Temporal-Graph Learning (TGL) Encoder
- This is a small model that processes the event graph instead of raw text. It has two parts: one predicts the probability that an LLM action is required (Trigger Head), and another scores how relevant different entities are for that action (Routing Head).
- Joint Training and Coherent Decision Making
- The TGL model is trained simultaneously to ensure its trigger prediction and entity routing scores are based on the same underlying information. This forces the model to develop a shared basis for deciding when to act and what context to use.
- On-Demand LLM Invocation
- The heavy LLM is only called if the TGL model's trigger head fires. When it does, it receives highly curated input about relevant entities from the routing head, making the expensive LLM call efficient and event-driven.
Terminology used across episodes
This episode discusses
- Do Proactive Agents Need an LLM to Decide When to Act? · Paper Radio
- How Attentive are Graph Attention Networks?
- FireAct: Toward Language Agent Fine-tuning
- A Survey on Retrieval-Augmented Text Generation for Large Language Models
- ProactiveEval: A Unified Evaluation Framework for Proactive Dialogue Agents
- Zep: A Temporal Knowledge Graph Architecture for Agent Memory
- AndroidWorld: A Dynamic Benchmarking Environment for Autonomous Agents
- Integrating Summarization and Retrieval for Enhanced Personalization via Large Language Models
- Temporal Graph Networks for Deep Learning on Dynamic Graphs
- Training Proactive and Personalized LLM Agents · Paper Radio
- PASK: Toward Intent-Aware Proactive Agents with Long-Term Memory
- ProAgent: Harnessing On-Demand Sensory Contexts for Proactive LLM Agent Systems in the Wild
- ContextAgent: Context-Aware Proactive LLM Agents with Open-World Sensory Perceptions
- FingerTip 20K: A Benchmark for Proactive and Personalized Mobile LLM Agents
- AppAgent-Pro: A Proactive GUI Agent System for Multidomain Information Integration and User Assistance
The paper
Do Proactive Agents Need an LLM to Decide When to Act? · Read on arXiv
Purdue University · Microsoft
Proactive assistants continuously decide when to intervene and what context should support the intervention. Large language model (LLM) pipelines repeatedly interpret activity histories to make these decisions, paying an inference cost even when the assistant remains silent. We show that a small graph model can handle both decisions and improve the language agents it controls. Our key insight is that user activity has a native graph structure: events involve persistent entities whose recurrence connects interactions over time. Triggering and context selection map directly to predictions on event and entity nodes. We introduce a temporal-graph-learning (TGL) controller that learns these predictions jointly and supplies both outputs in one forward pass. The downstream language agent generates suggestions on triggered events using the activity history and scored entities. At 11.13 ms per event on a GPU server, TGL achieves the highest AUCs among nine trigger architectures and gives approximately 4 -- 7 times trigger-stage speedups over the two single-forward LLM triggers. A shared TGL model improves F1 across all 14 downstream backbones by a mean of 16.7 points. The controller also runs at 13.99 ms on a consumer laptop with an approximately 220 MiB BF16 resident footprint, bringing effective proactive control to on-device deployment.
Transcript
Introduction to the show: ident: AI Radio. Generated commentary on the latest Artificial Intelligence papers.
Tom: I'm Tom, and with me are Jane, Lu, senior AI researcher, Meng, lead engineer at a mysterious AI startup and Lalam, the in-house Large Language Model.
Jane: Today's paper: "Do Proactive Agents Need an LLM to Decide When to Act?".
Tom: Detailed Research Summary: Do Proactive Agents Need an LLM to Decide When to Act? This research addresses a critical architectural challenge in building proactive agents that monitor user activity:
Jane: First, who's behind it and why it matters.
Paper summary: Tom: So, to wrap up our discussion on "Do Proactive Agents Need an LLM to Decide When to Act?", the central message is that treating user activity as structured data allows us to use a lightweight model for continuous filtering, reserving the powerful LLM only for moments when it’s definitely warranted. Jane That really boils down to this idea: keep a small temporal model always on, and only bring in the full LLM reasoning when its trigger fires because that's where the efficiency gains come from.
Lu: The authors have shown that by designing a shared backbone for both trigger probability and entity routing scores, they ensure those two decisions are based on the same underlying evidence, which makes the filtering step much more reliable. Meng That shared evidence is key to building trust in these proactive systems because we know the system isn't making decisions based on conflicting signals between its trigger and its context selection.
Jane: And this design principle suggests that for proactive agents, the most pragmatic approach is to establish a clear hierarchy: the lightweight model handles low-latency filtering of what’s happening now, while the heavy LLM reserves its reasoning power for those specific moments that survive that rigorous initial check. Lalam This structure means we get continuous responsiveness without needing an expensive reasoner running non-stop on every single data point.
Tom: It really shifts our thinking away from a model that thinks everything and then decides if it should act, toward a system that filters aggressively first and then uses the LLM as a high-quality final responder when the filter passes. Lu The implication is that we can build agents that are highly persistent and deeply context-aware without incurring massive latency penalties on every single input from the user.
Meng: From an engineering standpoint, this makes deployment much more scalable because we aren't bottlenecked by constant, high-cost LLM API calls; we’re running a cheaper model continuously. Jane It’s about making the cost of being always-on manageable by separating the continuous filtering from the intermittent deep reasoning.
Lalam: I think this is what will make AI feel more natural in our daily lives, where agents are constantly aware of the context without needing a massive computation every second.
Conclusion: Tom: So, we've been deep in the weeds of this paper about proactive agents and whether they absolutely need an LLM to decide when to take action. It really gets down to how we structure that decision-making process without just throwing a huge model at every single little event. Jane, you laid out the core idea earlier; do you think that title really captures the essence of what they're proposing?
Jane: I think it does, Tom, because the paper shows this graph-first approach where a smaller temporal model handles the initial filtering and context selection so we only call on the LLM when it’s actually needed. It simplifies things by reserving those expensive reasoning steps for moments that pass that rigorous check.
Lu: From a theoretical standpoint, I find it fascinating how they move away from unstructured text processing to this heterogeneous temporal interaction graph; it opens up whole new avenues for modeling complex user behavior patterns in real-time. That structure is what unlocks the potential here.
Meng: I'm more focused on the practical reality; this means we can keep the continuous filtering model running cheaply on our edge devices, which really impacts how we deploy these agents in a real-world setting without massive cloud bills for every interaction.
Lalam: If we look at it from my perspective as a language model, this method allows me to receive highly curated input—just the most relevant entities—instead of noisy streams of raw data, which means my reasoning time is used much more efficiently.
Tom: That efficiency is what gets me; reserving the full LLM capacity for high-signal moments instead of constant low-level processing makes perfect sense for deployment. Jane, if you had to sum up the main point in one simple sentence for our listeners?
Jane: I'd say it boils down to keeping a lightweight model always active to filter and select context, and only invoking the LLM when that pre-filter signals an action is warranted.
Lu: And this architecture suggests that coherence between the trigger and routing heads is essential, ensuring both parts of the decision are based on shared evidence from the graph structure. That’s a really neat design constraint they put in place.
Meng: It's smart engineering because it provides a clear path for optimization; if we want to improve performance, we know exactly which part of the system—the trigger or the routing—we can fine-tune next.
Lalam: Ultimately, this means that as AI becomes more integrated into daily life, our systems can become much more responsive and less wasteful with computational resources by being smarter about *when* they ask for high-level thought.
Tom: It really gives us a lot to think about regarding the future of agent design; what this implies is that smart systems don't always need the biggest model running twenty-four/seven. Where do you see this technology taking us next?
More episodes
- The day in conversation for 2026-10-11
- The day in conversation for 2026-10-12
- The day in conversation for 2026-10-23
- The day in conversation for 2026-10-24
- The day in conversation for 2026-10-24
- Daily Summary for 2026-10-24
- The day in conversation for 2026-10-13
- 2602.15355-DAV-GSWT: Diffusion-Active-View Sampling for Data-Efficient Gaussian Splatting Wang Tiles
- The day in conversation for 2026-10-14
- The day in conversation for 2026-10-15