How do I stop the agent from suggesting the same five generic remediation steps every time?

I've been conducting a deep-dive analysis of our AI SOC platform's automated investigation outputs over the last quarter, and a persistent, statistically significant pattern has emerged that is degrading the operational value of the system. The core issue is one of output entropy, or rather, the lack thereof. Regardless of the alert type—be it a suspicious PowerShell execution, a potential data exfiltration attempt, or a novel phishing campaign—the triage agent's recommended remediation steps are converging on the same narrow set of generic actions.

My analysis, pulling from the platform's recommendation log table, shows that approximately 87% of all incidents receive a variation of the following five steps, simply re-ordered:
* Isolate the affected endpoint.
* Reset credentials for the implicated user account.
* Block the indicated hash, domain, or IP address at the perimeter.
* Collect and review relevant logs from the host.
* Escalate to Tier 2 for further investigation.

While these are *technically* correct actions, their generic nature makes them increasingly useless for our Tier 1 analysts. The lack of contextual specificity—such as which specific registry keys to check for a particular persistence mechanism, or which lateral movement technique to hunt for based on the initial compromise—forces analysts to do the heavy investigative work anyway, nullifying the promised efficiency gains of the AI agent.

I suspect the root cause lies in the prompting or the knowledge retrieval layer of the agent. It seems to be falling back on a high-level, "safe" playbook rather than executing a true contextual analysis of the incident artifacts to pull from a granular, technique-specific repository. My hypothesis centers on two potential failure points in the data pipeline feeding the agent:

1. **Poorly Differentiated Vector Embeddings:** The remediation steps in the knowledge base may not be chunked and embedded in a way that allows the RAG system to distinguish between a broad "containment" step and a specific "containment step for Azure AD compromise via device registration."
2. **Overly Broad Prompt Instructions:** The system prompt governing the agent's behavior may be emphasizing completeness and safety over specificity, effectively instructing it to always return a set of high-level categories.

Has anyone else instrumented their AI SOC to measure recommendation diversity? I'm looking to design a test to validate my hypothesis. My initial approach would be to log the agent's internal steps, specifically the similarity scores for retrieved knowledge chunks. The SQL query below is a simplified version of what I'm running to quantify the problem in our environment.

```sql
-- Query to assess remediation step redundancy
SELECT
alert_type,
COUNT(DISTINCT incident_id) as total_incidents,
-- Using a Jaccard similarity on the step keywords
AVG(remediation_similarity_score) as avg_similarity_across_incidents,
COUNT(DISTINCT remediation_step_hash) as unique_step_patterns
FROM
ai_soc.recommendation_log
WHERE
generated_at > DATEADD(month, -3, GETDATE())
GROUP BY
alert_type
ORDER BY
avg_similarity_across_incidents DESC;
```

My goal is to move from this low-value, repetitive output to a system where the recommendations are driven by a rich context of the MITRE ATT&CK technique, affected asset criticality, and observed campaign indicators. I am particularly interested in architectural or prompt-engineering strategies that have successfully increased the specificity and actionable detail of automated remediation plans. Vendor documentation on this topic tends to be abstract; I'm seeking concrete implementation details or tuning parameters others have used.

- dan