BigQuery Agent Analytics SDK Feature Wish List

### 1. Automated Side-by-Side (SxS) Behavioral Diffing
**Feature:** Implement a comparative SxS analysis mode in the SDK that analyzes two different agent runs (e.g., two release candidates) on identical tasks to diagnose exactly *why* one performed better than the other. It should identify the exact "Divergence Point" (the step where strategies drifted apart) and generate "Cross-Pollination" suggestions.
**Why BQAA should support it:** High-level metrics and aggregate pass rates do not explain the behavioral differences between two runs. As agentic evaluation becomes more complex, developers need to easily compare a baseline model with a new implementation (e.g., hierarchical vs. parallel orchestration). By isolating the exact divergence point and rating capabilities like Strategic Planning and Verification Rigor, BQAA will shift from just reporting scores to providing actionable architectural diffs.

### 2. Streaming Evaluation for Real-Time Observability
**Feature:** Move beyond the current batch-oriented evaluation model to support streaming evaluation, allowing sessions to be evaluated as events arrive using BigQuery subscriptions or Pub/Sub integration.
**Why BQAA should support it:** Currently, users must wait for traces to fully land and batch process them in BigQuery to get evaluations. For production deployments, real-time observability is critical. Streaming evaluation would allow developers to set up real-time alerting for severe agent hallucinations, tool execution loops, or critical safety threshold breaches without waiting for batch jobs to finish.

### 3. Agent Self-Improvement & Feedback Loop API
**Feature:** Expose an API endpoint or ADK skill within BQAA that allows agents to query their own historical failure modes and actionable suggestions (derived from BQAA's `insights.py`) to adapt their behavior in real-time or during Reinforcement Learning (RL).
**Why BQAA should support it:** The ultimate goal of agent analytics is not just human debugging, but continuous agent self-improvement. By allowing agents to call a `get_feedback` or `update_learnings` routine that interfaces with BQAA’s evaluation tables, you enable dynamic prompt rewriting during SFT/RL training. Furthermore, failure modes identified by BQAA could automatically feed into a "Task Proposer Agent" to generate targeted synthetic training data specifically designed to overcome those weaknesses.

### 4. Holistic HTML Reporting with Trajectory Grounding
**Feature:** Add a module to compile BQAA's evaluations, insights, and anomalies into a standalone, shareable HTML report that features interpretable metrics (like frequency counts of failure modes) and concrete, clickable trajectory citations.
**Why BQAA should support it:** While BQAA natively produces pandas-compatible DataFrames and Looker Studio templates, looking through complex agentic traces manually remains tedious. Generating an aggregated HTML report heavily grounded in direct trajectory citations reduces LLM hallucination and drastically boosts human developers' trust in the analytics tool. It provides a seamless, single-stop solution for sharing insights with stakeholders who do not want to write SQL or run Jupyter notebooks.

### 5. Multi-Agent Trace Correlation and Delegation Analytics
**Feature:** Enhance trace reconstruction (`trace.py`) to natively handle complex multi-agent orchestration, supporting cross-session trace correlation, agent-specific evaluations within a broader session, and delegation pattern detection.
**Why BQAA should support it:** The current trace reconstruction algorithms handle single-agent sessions well, but future agentic architectures will heavily rely on orchestrators delegating to sub-agents or transferring contexts (e.g., using `TransferToAgentTool`). BQAA needs the ability to evaluate a sub-agent's isolated performance and trace the exact lineage of how tasks are decomposed and passed between different autonomous entities.

### 6. Standardized Evaluation Result Persistence
**Feature:** Implement a unified `evaluation_results` BigQuery table with a consistent schema across all evaluator types (Code metrics, LLM-as-judge, Trajectory match).
**Why BQAA should support it:** While the SDK can store some evaluation results, lacking a standardized persistence layer prevents seamless long-term tracking. A unified table would unlock out-of-the-box historical trend tracking, automated regression detection across multiple CI/CD deployments, and simplified integration with enterprise dashboards.

### 7. Advanced Context Graph Evolutions
**Feature:** Expand the new Context Graph module to include temporal graph versioning (snapshotting the graph at each HITL checkpoint), cross-session entity resolution (deduplicating `BizNodes`), and graph-based anomaly detection via GQL pattern matching.
**Why BQAA should support it:** As agents take on long-running, real-world tasks with Human-in-the-Loop (HITL) safety checks, it is vital to know if the real world has drifted since the agent made its decision. Temporal versioning creates strict audit trails. Furthermore, standard tabular anomaly detection (like the current Autoencoder) struggles to detect structural behavioral anomalies; using native Graph Query Language (GQL) pattern matching can detect highly unusual execution paths or logical leaps that metric thresholds miss.

### 8. Vector-Based Semantic Drift Detection
**Feature:** Wire up the existing `_SEMANTIC_DRIFT_QUERY` in the `feedback.py` module to fully activate embedding-based drift detection.
**Why BQAA should support it:** Currently, BQAA’s drift detection (comparing golden curated datasets against production traffic) relies on exact keyword overlap matching. This severely limits its accuracy because users phrase the same requests in countless different ways. Activating vector-based semantic search will vastly improve BQAA's ability to accurately detect coverage gaps and true semantic drift in production.

### 9. Component-Level Cost Attribution
**Feature:** Extend the `CodeEvaluator.cost_per_session()` to support granular cost attribution broken down by individual tools, specific sub-agents, and prompt versions.
**Why BQAA should support it:** Estimating overall session cost from token counts is a great start, but production teams need to know exactly which components are driving up their API bills. Granular cost attribution enables developers to perform targeted cost optimization—such as swapping a heavy LLM for a lighter one on a specific sub-task, or refactoring a highly inefficient tool.