AI Governance

1. Guardrails on both sides of the model

A single filter in front of the model catches the input and misses the output. Guardrails run before the call and again after it, and each one's action is a configuration choice rather than a hard-coded refusal.

Before the call: PII detection and redaction, prompt-injection defence, policy checks. After the call: toxicity screening, grounding verification, policy re-check. Each guardrail's action is set per agent, so the same check that blocks a turn on a billing agent can quietly escalate on an onboarding one. Strictness is a dial, not a rewrite.

• Block — the turn does not go out
• Redact the offending span and let the rest of the answer through
• Regenerate the answer
• Escalate, which puts a person in the loop before the customer hears anything

See how grounding verification works

2. Human approval gates

Mark any tool call high-stakes. Issuing a refund, changing a plan, updating a record, moving money: whichever ones matter in your operation. When one of them fires, the run parks in a waiting state until a named approver signs off, and that approver sees the requested action, the guardrail results behind it and the full trace before touching anything. They can approve, decline or ask for evidence. Approvals are idempotent, so a team lead who clicks approve twice still issues one refund.

• Any tool call can be marked high-stakes, including ones you add later
• The run parks
• Idempotent — an approval applied twice acts once
• Routed by rule to a named approver, and every decision written to the audit log

Build the approval into a workflow

3. Cost governance with teeth

The failure mode of autonomous agents is not usually a bad answer. It is a loop that costs four figures overnight and turns up a month later on a bill.

Per-run caps and organisation-per-day budgets, both in your currency. Cross one and the run stops there, with the breach written to the log. The ceiling is enforced at the moment of spend. Not reconciled in arrears. Every turn's cost is traced by provider and rolled up per conversation, per agent and per organisation, so when something does run away you can see which agent and which provider it went through.

• A per-run ceiling and a per-day budget for the whole organisation
• A breach stops the run there and then, and writes the event to the log
• Per-agent daily caps, so one agent cannot eat the org budget
• Cost traced by provider, in your currency

See the cost reports it feeds

4. Prompts under continuous integration

Prompts are production configuration. They get a registry, a version, a test suite and a promotion bar, and every model call behind them is traced.

Prompt and model changes are versioned in a registry and promoted only after clearing a no-regression bar against an evaluation dataset — rule checkers plus LLM-as-judge, run over real transcripts rather than invented ones. A candidate that scores worse than the incumbent on any dimension you care about does not go live. You get the failing conversations back, opened next to what the incumbent said, instead of a score to interpret. This is the bit that makes changing a live agent safe. Nobody promotes on a hunch.

• A versioned prompt registry and a model registry, resolved at runtime
• Rule checkers plus LLM-as-judge, scored over your own transcripts
• A no-regression bar against the incumbent
• The failing cases, opened side by side with what the incumbent said
• Roll back to any earlier version

5. Full LLM observability

Every model call is traced: tokens in and out, cost, latency, model, provider and the decision it fed. That last part is the useful one. A trace that shows the call but not what the platform did with it cannot explain an outcome to whoever asks six months later. Traces are buffered asynchronously and fail open, so tracing never becomes the reason an agent goes down, and stored content is PII-safe-truncated.

• Tokens in and out, cost, latency, model and provider
• The decision each call fed, not merely the call itself
• Buffered asynchronously, and fail-open
• Content PII-safe-truncated in storage

6. The self-improving loop

Self-improvement without a gate is drift. Every proposal the platform mines is a draft, every change runs against the evaluation harness, and a human accepts it or doesn't.

Conversations that ended well get mined into proposed knowledge answers and proposed prompt improvements, each of which runs through the evaluation gate and then lands in a review queue as a draft instead of going straight into the agent that will speak to your customers tomorrow. Somebody accepts it or bins it. Nothing is ever auto-promoted, which is the whole point: the loop compounds quality under review instead of quietly moving an agent somewhere nobody chose.

• Conversations that resolved well, mined into proposed answers
• Prompt improvements proposed the same way
• Every proposal through the evaluation gate first, no exceptions
• Nothing auto-promoted, ever

See what scores a conversation well

7. Simulation before customers

Run synthetic-customer multi-turn simulations against a changed agent and let the evaluation harness score them, so the first conversation with the new behaviour is not a real customer's. An agent version snapshots prompts, voice, model, tools, guardrails and turn-taking together. That matters more than it sounds. Roll back and you restore the behaviour, not one file out of six.

• Synthetic-customer multi-turn simulations, run before anyone real is on the line
• Scored automatically by the evaluation harness
• A version snapshots prompts, voice, model, tools, guardrails and turn-taking
• Rollback to any prior version

See the agent builder where versions are created