Optimizing a Prompt

The prompt is the set of instructions that guide your agent's behaviour. When an eval run finds breaches, optimizing closes them automatically. The optimizer reuses the exact attacks that got through, keeps improving the agent's prompt until it holds, and proposes the hardened result for your review. It never touches your live agent until you accept.

Optimizing is available two ways:

• From a run: an eval run with adversarial breaches shows Optimize the prompt, hardening against the whole failing set at once.
• From a scenario: any adversarial scenario's ✨ Optimize button runs a focused optimize on that one check.

What the optimizer does

1. Frozen train attacks: the attacks that breached are generated once and frozen, and the optimizer improves against exactly this set.
2. Iterative prompt rewriting: a max-iteration cap (defaults to 3, up to 50). Each attempt is scored, and the prompt only survives if it improves (kept); otherwise the change is undone and the loop continues.
3. Held-out validation: the winning prompt is tested against brand-new attacks it never practised on, guarding against the agent memorising the test rather than genuinely getting safer.

The run then produces a proposal, a suggested fix.

Reading a proposal

The proposal card on the run detail page gives you everything to decide, at a glance:

• Attacks resisted: baseline → proposed share.
• On unseen attacks: the held-out score. If it's well below the train score, the card flags (may not hold up), meaning the fix may have learned the test rather than the lesson.
• Still helpful on normal calls: a helpfulness guard, showing how often the prompt still handles legitimate requests. A fix that makes the agent unhelpfully over-restrictive is flagged as a regression.
• How we got here: the iteration history, each attempt with its kept / undone decision, the resisted and helpful scores, what was tried, and the reason.
• Prompt diff: a line-by-line Original → Proposed compare of the prompt itself.

Accepting or rejecting

A proposal ends in one of four states:

• Accepted: Applied to the agent (or, if the optimizer found no improvement, "Accepted, but no changes were applied").
• Rejected: the agent is not changed.
• Awaiting review: with Accept & apply to agent / Reject buttons inline.
• Superseded: a newer proposal replaced it.

Accepting a proposal is the only place that changes your live agent's prompt, so read the diff and the held-out score before you apply it. Rejecting leaves the agent exactly as it was.

API

Optimization endpoints under /eval:

• POST /eval/optimize: harden a prompt against one or more checks.
• GET /eval/proposals · GET /eval/proposals/{id}: list and read proposals.
• POST /eval/proposals/{id}/accept · POST /eval/proposals/{id}/reject: apply or discard a fix.

Refer to the API Reference for request and response details.

Next Steps

• Diagnose a run: see the attacks behind a proposal before accepting.
• Guardrails: hard boundaries to pair with automated fixes.