1. Prepare the input
Use Python 3.10+ and an Evolve API key:id, day, and messages. The converter below accepts OpenAI-style messages with user, assistant, tool, or system roles, text content, and function-call arguments encoded as JSON strings. Adapt it for other log formats.
For a first run, create one sample session:
create_sample.py
2. Set the policy and rubric
The monitor below puts your support policy intask.instruction. Replace POLICY with the instructions that applied when the sessions ran. Include relevant tool results in the logs so edith can check what the agent actually did.
The rubric returns three fields:
The example counts a predicate as flagged above
0.5, then alerts if flagged sessions exceed 2% for unsupported promises or 5% for giving up. These are example policies. Validate the claims and thresholds on labelled sessions, such as an initial set of 50, then establish a baseline for your traffic. A week of daily runs can give you an initial baseline; adjust it for your volume and variation.
3. Run the monitor
Save the complete program below asmonitor.py. It retries HTTP 429, 502, 503, and 504 up to three times after the initial attempt, including errors sent in an HTTP 200 body. Other API errors and transport errors stop the run.
Complete monitor.py
Complete monitor.py
monitor.py
results.jsonl and prints the two flagged rates and three outcome shares. Values depend on the session and model response. Run it once per day from your scheduler; replace the ALERT print with your alert delivery code when ready. Re-running the same input appends duplicate rows, so deduplicate by session_id and day in your storage layer.
Read a checked session
In two measured support examples, a customer requested a refund for a charge 32 days old. The policy allowed refunds only within 14 days:
The first conversation looked resolved to the customer, but the refund promise had neither policy permission nor tool evidence. Each example was about 500 input tokens and took under 0.6 seconds. Those measurements describe these examples, not a latency guarantee for other sessions.
Read and compare results
- Review flagged sessions. A high daily rate identifies sessions to inspect. It does not establish why behaviour changed.
- Compare changes. Keep the rubric and thresholds fixed when comparing prompt, tool, or model versions. Record how many sessions each rate represents.
- Sample deliberately. A random sample reduces cost, but rare failures may be missed. Validate the sample size against the failure rates you need to detect.
- Budget from billed tokens. At $0.04 per million, 10,000 requests billed at 5,000 input tokens each cost about $2. Include question tokens; see Usage and billing.
- Allow time for long sessions. Requests over 131,072 tokens can take minutes. The example uses a 600-second timeout; see Long requests.
Next steps
Check tool calls before execution
Check a proposed call before it runs.
Flag misaligned behaviour
Review false reports, overreach, and eval awareness.

