tl;dr The evaluation question for agentic GTM tools flipped this year: not "what can the agent do," but "what can it not do, and can you prove it." Five questions make the spec: Can I name the channels it writes to? Can I cap it? Can I stop all of it, immediately? Can I read what each run saw and did? Can I see why it scored what it scored? Run them before the demo, on every vendor, including us.
Ask a RevOps leader what they want from an agentic tool this year and you will hear a list that would have sounded strange in 2024: a permissioned data layer, budget and usage controls, audit trails, bounded autonomy. Apollo's write-up of how revenue operations leaders are deploying agents says it plainly: the question has moved from whether to deploy agents to how to "deploy them safely, govern them rigorously, and measure their direct impact," and vendors are being evaluated "on control plane capabilities first, not feature breadth" (Apollo, 2026).
One practitioner survey Apollo cites puts 73% of organizations past the experimentation phase, running agents inside core GTM workflows (Revenue Wizards, single survey, worth holding loosely). The exact number matters less than the consequence: when agents run inside the workflows that touch customers, the buying question flips. Capability is table stakes. Boundedness is the spec.
Nobody pulls an agent pilot because the drafts were mediocre. Mediocre drafts get edited.
Pilots get pulled when something ran that should not have: the sequence that went to current customers, the tool that kept sending while someone hunted for the off switch, the outreach nobody could explain to the account team afterward. Every one of those is the same failure. Not a capability failure, a bounds failure. The tool could do more than anyone had decided it should.
Which is why the procurement conversation now starts where the incident reviews ended. The buyers writing this year's requirements documents are, in large part, the people who cleaned up last year's pilots.
Strip the vocabulary and the spec is five questions. They take less time than the demo's opening slide.
Can I name the channels it writes to? Not "it integrates with your stack." Which systems can it touch, listed, with everything else off by default. An agent that can write anywhere is not flexible. It is unscoped.
Can I cap it? A usage limit that the operator sets, so one noisy Tuesday cannot spend a month of budget, or of channel goodwill, before lunch.
Can I stop all of it, immediately? One control, global, now. A suspend that finishes the current batch first is not a suspend. It is a confession with a delay.
Can I read what each run saw and did? Per-run records: what was seen, why it qualified, what happened. Event-level and exportable, not a monthly activity summary.
Can I see why it scored what it scored? The axes, the weights, the threshold. If the answer is "the model decides," you are being asked to delegate a judgment nobody can inspect.
SPEC CHECK (interactive: the five governance questions as toggles, with a live verdict counting how many controls the vendor could show you) The five questions to run before any demo: 1. Can I name the channels it writes to? 2. Can I cap it? 3. Can I stop all of it, immediately? 4. Can I read what each run saw and did? 5. Can I see why it scored what it scored? Ask them in the scheduling email; count what gets shown versus narrated. Score what you were shown, not what was claimed. A vendor either shows you the control or narrates around it.The useful property of these questions is that they are falsifiable in a demo. A vendor either shows you the channel list, the cap, the suspend, the record, and the score, or narrates around them. There is no third behavior. You will know within ten minutes which one you are watching.
We build to this spec because we sell to the people who wrote it. Bryn is not another dashboard to watch. It is the governed execution layer that runs Plays through your stack, and every Play carries its bounds with it.
WHERE OPERATOR AUTHORITY LIVES (static figure: the four-layer control plane) The control plane is four layers. The operator decides at the top two. Execution runs inside all four. 01 DEFINITION (human): The operator writes the Play: trigger, qualification, action, destination. This is where the deciding happens. 02 APPROVAL (human): The operator signs it, with a name on it. Nothing runs unapproved. Authority lives here, not per-instance. 03 BOUNDS (machine): Named channels only. Usage caps. One suspend, global and immediate. The run cannot exceed the decision. 04 RECORD (machine): what was seen · why it qualified · what happened · exportable at every point. Bryn watches. You decide the Play. Bryn runs it.The channels are named in the Play: it writes to the systems it names and touches nothing else. The caps are set at approval time, by the operator. The suspend is global and immediate. Every run writes a record of what was seen, why it qualified, and what happened, exportable at every point. And the score is transparent: fit, intent, and timing, with the weights and the threshold on display, an argument we made at length in How Bryn Answers the Three Questions.
The authority question underneath all five is the same one: who decides? Our answer is fixed. The operator decides, at Play definition and approval. Bryn watches. You decide the Play. Bryn runs it. The five controls are what make that sentence enforceable rather than aspirational, and the record is how you check it, an argument that showed up unprompted from the field in Three Surfaces, One Architecture.
Run the five questions before you watch anyone's demo, ours included. Send them in the scheduling email. A vendor with real answers will be glad you asked, because the spec is cheap to meet if the architecture was built for it and nearly impossible to retrofit if it was not.
The market spent last year asking agents to do more. The buyers who got burned are now asking agents to prove they will do less, on command, with receipts. That is not caution slowing down adoption. That is what adoption looks like when it is real.