Evidence-backed buyer's guide
A support agent that only drafts an answer has a different risk profile from one that refunds an order, changes an account, sends a customer message, or updates a system of record. Compare the controls around the action—not just answer quality or automation rate.
Evidence reviewed 31 August 2026. Vendor products change. The links below are official sources, but this guide is not a claim that every feature is available in every plan, channel, or integration.
Can you define which tools the agent may call, which records or fields it may change, and which identity or tenant boundaries apply?
Evidence to request: Ask for the actual policy configuration and a denied-action example, not only a general security statement.
Can risky actions pause before execution so a reviewer sees the proposed tool, arguments, risk, and intended effect?
Evidence to request: Verify whether approval applies per action, per workflow, or only through a conversation handoff.
Are business rules enforced deterministically before execution, or supplied only as natural-language guidance to the model?
Evidence to request: Request tests showing what happens when model output conflicts with the policy.
Does the platform preserve the decision path, retrieved evidence, tool arguments, approval decision, execution result, and errors?
Evidence to request: Confirm retention, exportability, access controls, and how records correlate across a conversation and external system.
Which actions are genuinely reversible, who can initiate recovery, and how are partial failures or duplicate attempts handled?
Evidence to request: Do not treat retries as rollback. Test recovery separately for every consequential integration.
Can the agent hand off on explicit rules, uncertainty, customer request, policy conditions, or failed tools while preserving context?
Evidence to request: Verify the routing target, fallback behavior, and whether autonomous execution stops after handoff.
This is an evidence boundary, not a vendor ranking. A missing public claim means “verify,” not “the capability does not exist.”
Forethought's public product material describes human-agent assistance, smart handoffs, ticket classification, and performance evaluation. The reviewed public pages do not establish a universal per-action approval or rollback contract, so buyers should verify those controls for each integration.
Intercom documents data-driven escalation rules, natural-language escalation guidance, workflow routing, and an email-only human-input option. Intercom also states that Guidance itself cannot perform most conversation actions; those require workflows or other product controls.
Ada documents configurable live and asynchronous handoffs with fallback behavior. Its data-export message schema records selected tools, arguments, result status, errors, return values, and timestamps. Buyers should still verify authorization and reversal behavior for each configured Action.
Sierra's official release-governance material describes automated checks, simulations, human merge approvals, and staged rollouts for agent changes. That is release governance; it should not be assumed to be the same as runtime approval for every customer action.
The reviewed public material was not specific enough to support claims about per-action authorization, human approval, audit export, or rollback semantics. Treat those capabilities as unverified until Decagon supplies current product documentation or a test environment.
CXOps AI is a demonstration and testing environment, not a claim of production equivalence with the vendors above. Its purpose is to make a controlled support workflow inspectable end to end.
A platform is ready for a risky workflow only when the team can explain who authorized it, what the agent intended, what actually happened, and how the organization responds when execution fails.