Who Owns the Results of Your AI Agent?
Before I put an AI agent in front of customers, I want to know who will be responsible for its results. Engineering can keep it running. Someone also has to decide whether its work is worth paying for.
An agent can be technically reliable and still produce work the business does not value. Meeting volume is a useful example: it can rise before anyone knows whether the extra conversations are worthwhile.
Salesforce's Vanessa Tabbert described a sales agent booking 150 meetings in its first month and, after tuning, 150 in a single week. Does that provide ROI? Who knows…
Give the owner authority
Before launch, I would want the business owner to set success criteria with the technical and sales teams and define what the agent is allowed to do. After launch, I would give that person the authority to prioritize improvements, secure engineering time to make them, and pause or narrow the agent when results slip.
I would put that owner on the business side, ideally the leader who already owns the outcome the agent supports. It doesn't need to be a new role, provided they have time and access to the engineers who maintain it.
The business owner doesn't need to edit prompts or change integrations, and changes to the system should still go through normal engineering review. I would have engineering own technical reliability, while the business owner stays accountable for whether the work advances the business goal.
Suppose sales starts rejecting the meetings
Suppose the agent books more meetings, but sales rejects a growing share of them. I would want to understand the cause before choosing a permanent fix. The qualification criteria might be too loose. The agent might lack data that would screen out poor fits, such as a company outside the target market or a duplicate booking for an opportunity already being handled. Or the handoff might omit context the seller needs, so a reasonable prospect looks weak on first contact.
A stricter qualification rule, an additional data source, and a better handoff solve different problems, and sometimes more than one is needed. I'd have the owner and technical team review a sample of rejected bookings, including the agent's qualification notes and the sellers' reasons. Then I'd test the proposed fix against both rejected meetings and cases the agent handled well, and monitor a limited rollout on new leads.
I would track both the acceptance rate and the number of accepted opportunities. An agent can improve its acceptance rate by pursuing only the safest prospects, while producing fewer useful opportunities overall.
What I would measure
Activity belongs on the scorecard, but on its own it can't settle whether to expand. I would track:
- The share of booked meetings that actually take place.
- The share of attended meetings that sales accepts as qualified.
- Seller time per accepted opportunity.
- Net value added over a fixed evaluation period.
By net value, I mean the additional margin attributable to the agent after implementation and operating costs. That includes supervision and the seller time spent working its leads, even when those costs sit in another budget. More weak meetings don't automatically make the economics worse. They do when the cost of working them exceeds the margin they add.
Meeting attendance and qualification provide early signals. Commercial results take longer, so I would give comparable groups of leads the same amount of time to convert before judging them.
That comparison needs a baseline. My preferred design, where practical, is to randomly assign eligible leads between the agent and the existing process and compare results over the same period. I would compare margin per eligible lead, then account for the additional costs of running the agent. A before-and-after comparison can't establish causation on its own, since lead mix and seasonality shift too.
If meeting volume rises while accepted opportunities fall and seller time increases, I would narrow the rollout while the team investigates. I would want that decision assigned before launch.
Who can make that call in your organization?
Originally published on LinkedIn on October 6, 2026.
