Memory Is the Detector's Working State

The benchmark results show that process-aware detection needs more than a fluent model reading one turn at a time. This chapter examines how the proposed detector routes immediate artifacts, sender verification, conversation history, and user advice, then compares three ways to represent that history: a recent window, the full transcript, and a bounded running summary. The goal is to understand memory as a concrete system responsibility, including what it preserves and what it may expose or omit.

Two paths, one decision boundary

The proposed system starts by separating evidence that can be acted on immediately from evidence whose meaning depends on the conversation. An incoming message from an external sender may contain a URL, phone number, email address, or claimed brand. Those artifacts can be extracted and checked without waiting for a long exchange. A single-message detector can then judge the message as phishing, spam, or legitimate using the original text together with the verification result.

That path is valuable precisely because process-aware detection does not make message-level evidence obsolete. A harmful link can be dangerous on its own. A sender may impersonate a known organization while using a fraudulent contact address. An immediate check can catch such cases before the conversation-level system has enough turns to establish a trajectory. The system’s design restricts the artifact trigger to messages from the external party rather than running it on every user-authored message, which reduces unnecessary work and avoids treating the user’s own text as an incoming threat.

The conversation path has a different input. After the exchange reaches the system’s minimum conversation length, an investigator summarizes what has happened and assigns a current threat level. The summary can preserve claimed and inferred identity, important earlier messages, artifact events, verification history, and suspicious developments. A conversation-level detector then uses that state with recent messages to decide whether the interaction is leading toward a scam. The orchestrator coordinates when this analysis runs and supplies the state required for the decision.

flowchart LR M["Incoming external message"] --> T["Artifact trigger"] T --> X["Extract sender artifacts"] X --> V["Conditional verification"] V --> S["Single-message decision"] M --> O["Orchestrator state"] O --> R["Recent turns and\nverification history"] R --> I["Investigator\nsummary and threat level"] I --> C["Conversation-level\nrisk decision"] O -. "adaptive schedule" .-> I C --> A["Evidence-based advice"]

The boundary between the paths is functional, not absolute. The single-message path can provide an early trigger inside a longer conversation, while the conversation-level path can recognize a scam whose individual messages contain no decisive artifact. In the reported ConScamBench evaluation, the authors attribute first triggers to both paths: the conversation-level detector accounted for most of the true positives, while the single-message path covered artifact-bearing cases. The important system idea is not the exact module count. It is that different evidence types have different owners and different update rhythms.

Verification illustrates why the paths need an intermediate step. The system extracts sender-directed artifacts in a structured form and conditionally invokes verification when a claimed brand or sufficient evidence is present. The verifier returns a compact summary rather than asking the final detector to infer sender authenticity from raw search results.