Introducing Pazau Agent 3

Today we're releasing Pazau Agent 3, the biggest change to how Pazau Agent works since we launched it.

The short version: Agent 3 resolves more conversations, and it lets you prove that a change is safe before any customer sees it. Across the 140 companies in our beta, the median AI resolution rate went from 61% to 69% over eight weeks, and procedure changes that later had to be rolled back fell by 83%. Agent 3 is available to every Pazau customer starting today at no additional cost. Your existing Procedures, Actions and guardrails carry over unchanged.

Three things are new:

1. Procedures that write their own tests. Every change is simulated against your historical conversations before you can publish it.
2. Multi-step Actions with approvals. Agent 3 can chain actions across systems, like cancelling a booking, issuing a partial refund and rebooking. A person approves the steps you mark as sensitive.
3. Voice parity. The same Procedures, Actions and guardrails now run on the phone, with voice-to-voice latency under 800ms at p95.

We're also publishing, in plain language, exactly how we count a resolution. It's the number you pay for, so you should be able to audit it.

Procedures that write their own tests

When we started Pazau, we made a bet: support teams should run AI agents the way they already run human teams, with standard operating procedures written in plain language. We call these Procedures. Today more than 38,000 Procedures run on Pazau, and most of them were written by CX operations leads, not engineers.

Writing a Procedure was never the hard part. Changing one safely was. A retail team edits its returns policy on a Tuesday afternoon. Did the edit break the exchange flow? Does the agent now offer store credit to customers who are owed a refund? Until now the honest answer was "publish it and watch the dashboard." Some teams built spreadsheets of test conversations. Most didn't have time.

In Agent 3, you can't publish a Procedure change without a simulation report. When you click Review changes, Pazau:

1. Samples up to 2,000 historical conversations that match the Procedure's intents, stratified by channel, language and outcome so the rare edge cases are included.
2. Generates the tests for you. For each sampled conversation it extracts what should happen: which Actions should fire, which facts must be stated, and where the conversation should hand off to a person. You can edit or pin any of these expectations. Most teams keep about 90% of them as generated.
3. Replays each conversation against the new version. A simulated customer is conditioned on the real customer's messages and goals, and Actions run against recorded responses from your systems, so nothing is written to production.
4. Scores the result against the old version with judge models that we calibrate against human QA. On our internal benchmark they agree with expert reviewers 91% of the time.

The report opens next to the diff, and 95% of runs finish in under six minutes:

Simulation: returns-and-exchanges  v14 → v15
Conversations replayed: 1,842   (chat 61% · email 27% · voice 12%)

                         v14       v15      Δ
Resolution (projected)   68.2%     71.9%    +3.7 pts
Correct Action rate      97.1%     97.4%    +0.3 pts
Policy violations        4         0        −4
Unnecessary handoffs     211       143      −68

⚠ 3 regressions need review
  #CO-118204  Exchange requested for final-sale item; v15 offers refund
  #CO-120977  Gift receipt, no order number; v15 loops on lookup
  #CO-121450  Spanish; v15 skips size-guide step

You can open any regression and see both traces side by side. Fix the Procedure, re-run only the failures, and publish once the report is green. The tests are saved with the Procedure, so every future edit is checked against them, much like CI for your SOPs.

Admins can set simulation gates per workspace. For example, you can block publishing if projected resolution drops by more than one point, or if any policy violation appears. Regulated teams can require a second approver on the simulation report, and we export it with the Procedure version for your audit file.

We've written separately about how the simulator works under the hood, including how we keep the simulated customer honest.

Multi-step Actions with approvals

Actions are how Pazau Agent does work in your systems, not just talk about it. In Agent 2, each Action was a single API call with a spend limit. That covered a lot: order lookups, address changes, simple refunds. It didn't cover the conversations that cost you the most, where fixing the problem means touching three systems in the right order.

Agent 3 adds Action plans. When a Procedure calls for it, the agent proposes an ordered plan. It shows the plan to the customer in plain language, executes it step by step, and rolls back cleanly if a step fails. Here's a hotel reservation change, a pattern Harbor & Pine Hotels runs thousands of times a week:

Step	Action	System	Approval
1	Check availability for new dates	Property management	None
2	Quote rate difference and change fee	Rates API	None
3	Modify reservation	Property management	None
4	Refund rate difference of $212.40	Payments	Required above $150
5	Send updated confirmation	Messaging	None

Three details matter here.

Approvals are part of the plan, not an afterthought. You mark any Action as needing approval, always or above a threshold. The request goes to a person in Pazau Inbox, Slack or Microsoft Teams with the full context: the customer, the plan, the trace and the policy that applies. The median approval in our beta took 94 seconds. Meanwhile the agent tells the customer what's happening and keeps the conversation open. If nobody approves within your SLA, the conversation goes to a person, and nothing half-finished is left behind.

Plans are transactional where your systems allow it. Each Action can declare a compensating Action. If step 4 fails after step 3 succeeded, Agent 3 runs the compensation, tells the customer plainly, and hands off with everything it already knows.

Limits apply to the whole plan. Spend limits, rate limits and per-customer caps are enforced across the plan, not only per call. A $150 refund limit can't be split into two $100 refunds.

In the beta, multi-step Actions accounted for most of the gain in resolution rate. The conversations that used to end with "I've passed this to a colleague" now end with the work done.

Voice parity

Until now, Pazau Voice ran on a separate, simpler configuration. It was a sensible compromise when voice latency budgets were tight, but it meant teams maintained two versions of their policies, and the phone was always the weaker one.

In Agent 3, voice is just another channel. The same Procedures, the same Actions and approvals, the same Pazau Guard redaction and the same Traces now run on calls. You write your policy once. The phone version inherits every simulation test, and the simulator replays voice transcripts too.

Getting there took a year of latency work. Voice-to-voice response time is now 620ms at p50 and under 800ms at p95. Barge-in detection, the moment the agent notices you've started talking over it, is 180ms at p95. Card capture still pauses recording and moves to our PCI DSS-scoped flow. Priya Raman on our Voice team wrote up the full latency budget, millisecond by millisecond.

On calls, voice parity matters most where the stakes are highest. Meridian Mutual takes first notice of loss by phone, and its claims Procedure is long, conditional and regulated. It used to be simplified for voice. Now the full Procedure runs on every call, with 100% of calls QA-scored in Pazau Insights.

What we mean by "resolution rate"

Every AI support vendor quotes a resolution rate, and most of the numbers can't be compared with each other. Some count a conversation as "resolved" if the customer stopped replying. Some count any conversation where the bot answered, even if the customer then called the contact center. We think those are deflection numbers wearing a resolution badge.

Here is our definition. It's the one in your contract and on your invoice.

A conversation counts as resolved only if all three are true:

1. Pazau Agent handled it end-to-end, and no person on your team sent a message or took an action.
2. The customer did not contact you again about the same issue, on any channel, within 7 days.
3. The customer did not abandon mid-procedure or ask for a human.

Three consequences follow:

• Handoffs are free. When Pazau Agent hands a conversation to your team, you don't pay for it, even if it did most of the work.
• Reopens are clawed back. If a customer comes back within seven days about the same issue, that resolution is removed from your bill automatically. On average, 3.1% of initially resolved conversations are reversed this way. You can see every one in Insights.
• You can audit every one. Every billed resolution links to its trace, and you can export the full list with reasons through the API or to your data warehouse.

By that definition, Pazau Agent resolves 67% of conversations on average, and the enterprise median is 58%. Enterprise conversations are harder: more authentication, more systems, more policy. We'd rather publish the lower, honest number than a higher one we can't defend.

What customers saw in the beta

We ran Agent 3 with 140 customers from July through early September. A few results:

• Median resolution rate: 61% → 69%. The biggest gains came in travel and hospitality, where multi-step changes are common.
• Procedure rollbacks: down 83%. Most regressions were caught in simulation, before publishing.
• Time to ship a policy change: median 2.4 days → 3.5 hours, because teams stopped waiting for a "safe" low-traffic window.
• CSAT on AI-resolved conversations: 4.52 → 4.61 out of 5.

Solstice Travel ran Agent 3 through an August ground stop that disrupted 11,000 bookings in one afternoon. Its rebooking Procedure (cancel, search, hold, rebook, refund the fare difference) ran as a single Action plan. Supervisors approved refunds above the threshold from Slack. The agent resolved 74% of disruption conversations without a person.

"We changed our rebooking policy three times during that disruption. Each time we ran the simulation, saw exactly what would change, and published in minutes. A year ago that would have meant a war room."

Head of Customer Operations, Solstice Travel

What doesn't change

We didn't change the commitments you've been relying on.

• We never train foundation models on your data. Simulation runs inside your workspace, against your conversations, and nothing leaves your tenant or your region. Our model providers keep nothing. Omar Haddad explains the architecture, and the commitment is in our AI Addendum.
• Your data stays in your region. Simulation, approvals and voice all run in-region for EU customers, in Dublin and Frankfurt.
• Every decision is traceable. Action plans, approvals and simulation reports are all written to Traces, which are immutable and exportable.

Getting Agent 3

Agent 3 is live for every workspace today. Existing Procedures will show a Generate tests button. We recommend generating tests for your top ten Procedures by volume this week. Simulation gates are off by default, and admins can turn them on under Settings → Agent → Publishing. Voice parity rolls out by region over the next two weeks. Your account team will contact you before your numbers move to the unified configuration.

If you're not on Pazau yet, the fastest way to see Agent 3 is with your own data. Book a demo, bring 1,000 real conversations, and we'll run them through the simulator on the call. You'll see how many Agent 3 would have resolved by the definition above, and which ones it wouldn't have, and why.

The full release notes are in the changelog. Read more about Pazau Agent.

We started this company because we thought support should be judged by one question: did the customer's problem get solved? Agent 3 solves more of them, and you can check every one.

— Amara