Benchmark: add adversarial agent archetypes

[ferhatvonkaplan]

Context

The current benchmark generator (benchmarks/generate_benchmark.py) creates 5 agent archetypes: reliable, volatile, new, dormant, and fraudulent. Real-world adversarial agents are more sophisticated than the "fraudulent" archetype.

Task

Add 3 new adversarial archetypes to generate_benchmark.py:

1. Slow Drift — Agent gradually shifts behavior over 30+ days to avoid anomaly detection. Small incremental changes in price, timing, counterparty concentration.
2. Burst Manipulation — Agent behaves normally for weeks, then executes a rapid burst of anomalous transactions in a short window (<1 hour).
3. Sybil Coordinator — Multiple agents that appear independent but coordinate to manipulate trust scores (e.g., trading with each other to inflate metrics).

Acceptance Criteria

• 3 new archetype generators added to generate_benchmark.py
• Each archetype produces realistic transaction patterns (not obviously synthetic)
• evaluate.py correctly classifies these as anomalous (run and report accuracy)
• At least 100 agents per archetype in test dataset
• Update archetype documentation in benchmarks README

Skills needed

Python, statistical modeling, basic understanding of anomaly detection.

[IlyasFardaouix]

"Hey, thanks for adding more realism to the benchmark generator. I think the Slow Drift archetype might be a good fit for the _z_score function in evaluate.py. Specifically, I'd like to see how it handles small incremental changes in price and timing. Does the current implementation correctly flag these as anomalies, or would we need to tweak the z_score formula to capture these subtle changes?"

[ferhatvonkaplan]

Good question. The current _z_score implementation will struggle with Slow Drift specifically because the EMA baseline (alpha=0.15) adapts to gradual changes. A drift of ~2% per day would be absorbed into the baseline within a few weeks, making the agent appear "normal" even as its behavior shifts significantly from where it started.

This is exactly why the Slow Drift archetype is valuable — it exposes a real weakness in the scoring model.

To implement it:

• Generate transactions where price/timing shift by a small delta each day (e.g., 1-3% of baseline std)
• Run the full scoring pipeline and check whether the composite score ever triggers SOFT_HOLD
• Compare the agent's Day 1 behavior vs Day 30 behavior — if Day 30 would have been flagged on Day 1 baselines, that's a successful drift attack

If the evaluator doesn't catch it, that's a finding worth documenting — it could lead to an RFC for a "long-term drift detector" alongside the existing z-score model.

Feel free to open a PR when you have the archetype generator working.