How do I measure if my AI agent actually works?

Measure per action class: approval rate, edit rate, rejection rate, time saved per item, and downstream outcome. Cost per accepted action is the number that decides whether to keep a feature running.

An admin approves every new account by hand. Nothing is created until then. We reply by email; no newsletter, no sequence.

Want to see it first? Book a demo

app.salescrew.io/inbox
The unified reply inbox with classified threads

The short answer

  • Measure an AI agent per action class, not as one overall number. Track approval rate (how often output is accepted), edit rate (how often it needs a real change first) and rejection rate (how often it's thrown out). Add time saved per item and the downstream outcome once the action has played out.
  • Downstream outcome matters most and gets measured least. Think reply rate for a drafted email, accuracy confirmed later for a label, and close rate for a suggested next step. Approval alone only shows a reviewer thought it looked reasonable at the time.
  • Cost per accepted action is what it costs to produce one output a person keeps and uses. It ties usage cost to real value. That number, not a raw usage total, should decide whether a feature is worth its price.
  • 'Hours saved' from a vendor, rather than your own count, is usually a guess about how long a task would take a person. It isn't drawn from your team's real before-and-after time. Treat it skeptically unless you measured it yourself.

Why per-action-class measurement beats one overall score

A single blended score for an agent, like an overall approval rate, obscures more than it reveals once an agent does more than one kind of task. An agent might have a 95% approval rate on drafting summaries and 40% on suggesting stage changes. A blended 80% hides the split that matters. One action class works well. The other isn't ready for less oversight.

Breaking metrics out by action class turns "is this agent good" into a more useful question: which of this agent's jobs are working, and which still need review. That is also the same breakdown needed to decide which action classes are ready to move from review to automatic, so the same measurement serves both questions.

The metrics and how to compute them

MetricFormulaTarget
Approval rateItems approved as-is ÷ total items producedHigher is better; watch for it masking a high edit rate
Edit rateItems requiring a meaningful edit before approval ÷ total itemsLower is better; a rough starting bar is under 5% before considering promotion
Rejection rateItems rejected outright ÷ total itemsAs close to zero as possible for a class considered for promotion
Time saved per itemEstimated manual time ÷ time actually spent reviewingMeaningfully positive; a wash is not worth the review overhead
Downstream outcomeReply rate, confirmed accuracy, or close rate after the factComparable to or better than your team's own unassisted baseline
Cost per accepted actionTotal cost of runs for a feature ÷ number of outputs actually kept and usedThe number that decides whether a feature earns its cost

Turning the metrics into a decision

These metrics only earn their keep if someone actually looks at them on a schedule and acts on what they show. A feature with a low approval rate and a high cost per accepted action is a candidate to fix, retrain the prompt, adjust the guardrails, or cut. A feature with a high approval rate and strong downstream outcomes is a candidate to promote from review toward more autonomy, following the same clean-period logic used to move an action class to auto.

Disclosure: SalesCrew is our product. Its audit log and cost tracking are built for exactly this kind of measurement. Every tool call is logged with the agent, action, result and cost. That's the raw data these metrics come from, per action class rather than as one blended score.

'Hours saved' self-reported by the vendor is not a measurement

A vendor's estimate of time saved is built on assumptions you did not make. Measure your own team's before-and-after time on a real task, or treat any vendor-supplied hours-saved figure as a marketing claim rather than data.

Questions

Why measure per action class instead of per agent overall?
An agent's overall approval rate can hide a lot: strong performance on one task masking weak performance on another. Measuring per action class shows exactly which parts of an agent's job are working and which need attention, rather than one blended number that averages the two together.
What is 'downstream outcome' measuring, specifically?
The actual result after the action, not only whether a person approved it. A drafted email getting approved says the draft looked reasonable; a higher reply rate on approved drafts says the draft actually worked. The second is the harder, more meaningful number.
Why is 'hours saved' from a vendor not a real measurement?
Because it is usually an estimate made by the vendor, based on assumptions about how long a task would have taken a person, not a number derived from your own team's actual before-and-after time. Measure it yourself against your own baseline, or treat the vendor's figure as marketing.