perf(agent): wake on state change instead of 500ms polling

[b4l4-sec]

…p pre-filter, memory compression

• Add string-similarity pre-filter to vulnerability deduplication to limit LLM comparisons to the top 10 most similar reports instead of all reports
• Replace per-request httpx.AsyncClient with persistent connection pool per sandbox, eliminating repeated TCP/TLS handshake overhead
• Execute independent tools concurrently via asyncio.gather while keeping state-modifying tools sequential
• Lower memory compression threshold from 100K to 60K tokens and cache token counts to avoid redundant litellm.token_counter calls
• Double compression chunk size from 10 to 20 messages to halve LLM calls
• Replace asyncio.sleep(0.5) polling with event-based wake signaling in agent state for immediate response to state changes

[greptile-apps]

Greptile Summary

This PR replaces the fixed asyncio.sleep(0.5) polling loop in _wait_for_input with an asyncio.Event-based wake signal, so the agent responds immediately when external input arrives rather than waiting up to 500 ms. The _wake_event is exposed via a new wait_for_wake method on AgentState and is signaled from both add_message (when waiting) and resume_from_waiting.

Confidence Score: 5/5

Safe to merge; the event-driven wake logic is sound and the only finding is a minor P2 spurious-wake on internal status messages.

No P0 or P1 issues found. The single P2 (add_message fires wake for assistant-role messages) causes one extra no-op loop iteration per waiting-state entry but does not break correctness or lose any wake signals.

strix/agents/state.py — add_message role-guard for the wake signal.

Important Files Changed

Filename	Overview
strix/agents/state.py	Adds asyncio.Event-based wake signaling to replace fixed sleep polls; minor logic issue where add_message fires the wake event for internally-generated assistant messages, causing a spurious loop iteration on every waiting-state entry.
strix/agents/base_agent.py	Single-line change: replaces asyncio.sleep(0.5) with state.wait_for_wake(timeout=0.5) to enable immediate event-driven response; change is correct and well-integrated.

Prompt To Fix All With AI

Fix the following 2 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 2
strix/agents/state.py:49-56
**Spurious wake on every waiting-state entry**

`_enter_waiting_state` in `base_agent.py` calls `enter_waiting_state()` (which sets `waiting_for_input = True`) and then immediately calls `add_message("assistant", ...)`. Because `waiting_for_input` is already `True` at that point, `add_message` fires `_wake_event.set()` on every single status message the system adds when entering a waiting state. On the next loop iteration `wait_for_wake` returns instantly (consuming and clearing the event), and the agent loops back to sleep — defeating the optimization for that first cycle. The intent of the wake signal is to notify the agent of *external* input, not of its own internal status messages.

### Issue 2 of 2
strix/agents/state.py:53-56
Consider restricting the wake to non-assistant messages so the agent's own status notifications don't fire a spurious wake signal. This ensures `_wake_event` is only set when real external input (from a user or another agent) arrives while the state is waiting.

```suggestion
        self.messages.append(message)
        self.last_updated = datetime.now(UTC).isoformat()
        if self.waiting_for_input and role != "assistant":
            self._wake_event.set()
```

_{Reviews (2): Last reviewed commit: "use PrivateAttr for _wake_event (Pydanti..." | Re-trigger Greptile}

[greptile-apps]

_{5 files reviewed, 2 comments}

_{Edit Code Review Agent Settings | Greptile}

[0xallam]

@greptile