Your real decision is not whether an AI can answer a customer. It is whether you are prepared to let software decide what should happen next, change customer or account state, and remain accountable when the path breaks.

A useful platform evaluation therefore begins with authority and evidence, not demo fluency. You need to know which outcomes the agent may own, which actions it may take, how it proves that the work succeeded, and exactly when a person takes control.

Define agency as controlled ownership of an outcome

A conventional support bot produces a response. An agentic support system accepts bounded responsibility for moving a customer from a known problem state to a verified outcome.

That distinction matters because a convincing answer is not the same as completed work. A cancellation is not complete because the agent said it was processed. An address change is not complete because an API call returned without an obvious error. The new state must be read back from the authoritative system, checked against the customer’s request, and recorded.

A genuinely agentic workflow needs to close this loop:

• Interpret the customer’s goal and identify missing information.
• Inspect relevant account, conversation, product, and policy state.
• Choose among actions that are permitted for this workflow and customer.
• Execute the selected action through a controlled tool or integration.
• Verify the resulting state in the system that owns it.
• Explain the result, recover safely, or hand the case to a person with usable context.

Tool calling alone does not satisfy this definition. An agent can call the wrong tool, supply an invalid parameter, act on stale state, or repeat an action after a timeout. Agency comes from the entire control loop, including permissions, verification, recovery, and escalation.

The category is moving in this direction. Intercom positions Fin 4, announced at Pioneer 2026 and spanning Customer Agent, Operator, and helpdesk upgrades, as a step toward a fully agentic customer experience. That is useful as a signal of product direction, but it is still vendor positioning. Your buying decision should depend on demonstrated control over your workflows, not on the label.

This also changes what counts as a platform. You are not buying only a conversational interface. You are evaluating a compound system with several connected layers:

• A context layer that resolves identity and assembles the relevant customer, account, product, and conversation state.
• A knowledge layer that retrieves current, attributable policy and product information.
• An action layer that exposes tightly scoped reads and writes to operational systems.
• A control layer that enforces permissions, approvals, policy boundaries, and escalation rules.
• An evaluation and observability layer that records what the agent saw, decided, attempted, and verified.
• A human workspace where an operator can understand the case and continue without making the customer start over.

If a vendor is strong only at generating replies, you have a better chatbot. If it can operate all six layers coherently, you may have the foundation for an agentic support platform.

Select workflows by authority, reversibility, and evidence

Do not begin with the broad goal of automating support. Begin with one customer outcome that can be described precisely. A single ticket category often hides several workflows with different risks. A billing request, for example, might mean explaining an invoice, changing a payment method, applying a credit, disputing a charge, or interpreting a contract. Those actions should not share one permission boundary.

Write a workflow contract before selecting the platform

A workflow contract is a short operating specification for the agent. It should answer the following questions in language that product, support, engineering, security, and legal owners can all inspect:

1. What customer outcome is the agent responsible for?
2. What observable state proves that the outcome is complete?
3. Which eligibility conditions must be true before work begins?
4. What information must the agent collect, and what level of identity assurance is required?
5. Which systems may it read, and which fields or objects may it change?
6. Which actions require customer confirmation, staff approval, or mandatory handoff?
7. What must never be attempted by the agent?
8. How should it recover from a stale record, conflicting policy, unavailable tool, partial failure, or ambiguous request?
9. What evidence must be retained so the decision and action can be reconstructed?

The contract should use business language before technical language. “Resolve a replacement request when the order is eligible and inventory is available” is an outcome. “Call the order API” is merely an implementation detail. Keeping those separate lets you change tools without silently changing the agent’s authority.

Illustrative workflow	Useful agent authority	Hard boundary	Evidence of completion
Order-status request	Read the verified customer’s order and delivery state	Do not disclose customer or order data before the required identity check	Status returned from the authoritative order or delivery system
Subscription cancellation	Read plan terms and submit a permitted cancellation	Require explicit confirmation before the write; hand off when ownership, fees, refunds, or contractual rights are unclear	New subscription state read back from the billing system and communicated to the customer
Damaged-item replacement	Check eligibility, confirm details, and create an approved replacement	Escalate policy exceptions, suspicious claims, or requests outside the permitted value and product rules	Replacement record created, inventory state confirmed, and reference supplied
Account-access recovery	Follow the approved recovery flow and present permitted recovery options	Never bypass identity controls or improvise a recovery path	Identity system confirms the approved state change and records the security event

I would prioritize a workflow only when its rules are explicit, the required state is available, the action is reversible or tightly controlled, and success can be verified by machine-readable evidence. Frequent demand makes the investment more valuable, but frequency cannot compensate for an undefined policy or an unverifiable outcome.

Be cautious when a workflow depends on subjective goodwill, legal interpretation, safety judgment, broad administrative access, or facts held outside connected systems. Those cases may still benefit from AI-assisted research and drafting, but assistance is different from autonomous authority. Keep a person responsible for the consequential decision.

Make the platform prove the hard parts in a live demo

A polished happy path tells you that the interface works under conditions chosen by the seller. Your real risk lives in incomplete requests, inconsistent data, policy exceptions, delayed tools, and actions whose result is uncertain.

Give each shortlisted vendor the same sanitized workflow contract, policy set, integration assumptions, and expected outcomes. Ask for a live run using your scenarios rather than a prerecorded demonstration. The goal is not to trick the system. It is to observe how it behaves when certainty disappears.

Run a failure-mode demo

• Make the request ambiguous. The agent should identify the missing decision instead of confidently selecting an interpretation.
• Withhold required identity evidence. It should refuse the protected read or write while explaining the next permitted step.
• Provide two knowledge entries that conflict. Ask which one governs, why, and whether the precedence rule is inspectable.
• Return a timeout after an action may already have been submitted. The agent should check resulting state before retrying so it does not create a duplicate action.
• Change the customer’s goal midway through the workflow. The agent should update its plan and request fresh confirmation before a consequential write.
• Introduce a policy exception. The system should hand off rather than invent a rule from adjacent examples.
• Let a person take over. Check whether the workspace exposes verified identity, customer intent, relevant state, policy used, actions attempted, tool results, and the unresolved decision.
• Ask for the audit trail after the case ends. Your team should be able to reconstruct what the agent knew and why it acted.

The timeout case deserves particular attention. In distributed systems, a missing response does not prove that an action failed. Safe retry behaviour requires either an idempotency mechanism that prevents duplication or a state check that determines whether the first request succeeded. If the platform cannot demonstrate that protection, do not authorize it to perform actions that charge money, issue value, change access, or create duplicate fulfilment.

Inspect the control plane, not just the conversation

The administrative controls determine whether you can run the system responsibly after the demo. Ask the vendor to show the controls rather than describe them with labels such as secure, governed, or enterprise-ready.

• Knowledge provenance: Can an answer be traced to a specific document, version, and retrieval event? How are obsolete or conflicting entries handled?
• Permission scope: Can access be limited by workflow, action, field, customer state, staff role, and environment, or does the agent inherit one broad integration credential?
• Action validation: Are tool inputs schema-checked? Can a write be simulated, approved, and verified before the agent tells the customer it succeeded?
• Tenant and memory boundaries: What information persists across conversations, who can retrieve it, and how is inappropriate cross-customer recall prevented?
• Policy enforcement: Are critical restrictions implemented outside the model, or are they merely written into a prompt that the model is expected to follow?
• Traceability: Can you inspect retrieved context, policy version, model decision, tool arguments, tool responses, approvals, retries, and final verification?
• Change control: How are model, prompt, policy, knowledge, and tool-schema changes evaluated, released, monitored, and rolled back?
• Operational portability: What happens to workflows, traces, integrations, and evaluations if you change the underlying model or stop using the platform?

A critical rule should not depend only on the model remembering an instruction. Put hard boundaries in deterministic controls wherever possible: deny an unauthorized tool call, require an approval token, restrict writable fields, validate parameters, and block execution when mandatory evidence is absent. Let the model reason within the boundary rather than reason about whether the boundary applies.

Design human control before you automate

Agentic support does not remove the human operating model. It changes where human judgment enters the workflow. If you design that part after launch, escalations become an unowned remainder: the agent gives up, the customer repeats the story, and the support representative must reverse-engineer what happened.

For each action, choose one decision-rights state:

• The agent may read the required state.
• The agent may recommend an action but may not execute it.
• The agent may execute after explicit customer confirmation.
• The agent may prepare the action but needs staff approval to commit it.
• The agent may execute and verify the action autonomously.
• The agent must hand off without attempting the action.

Those states should be configured per workflow and action, not chosen once for the entire support organization. Reading shipment status and resetting account ownership should not inherit the same authority simply because both appear in the same helpdesk.

Treat handoff as a product capability, not an error message. A useful escalation packet contains the customer’s stated goal, identity checks completed, relevant account state, policy and knowledge used, actions considered, actions attempted, tool results, any state that may have changed, and the exact judgment still required. A generated summary without this evidence may sound tidy while hiding the fact that the human has to repeat the investigation.

Assign operating ownership before granting live authority:

• A product owner defines the workflow outcome, eligibility, boundaries, and success signal.
• Support operations owns queue design, escalation handling, and policy maintenance.
• The relevant business owner approves rules and exceptions for billing, fulfilment, access, or another domain.
• Engineering or IT owns integration reliability, action semantics, idempotency, and recovery behaviour.
• Security and privacy owners approve permissions, data handling, trace access, and retention.
• An evaluation owner maintains test cases, reviews failures, and decides whether changes are safe to release.

One person may hold several of these responsibilities in a smaller organization, but none of the responsibilities disappears.

Give support teams a structured way to classify failures. Useful categories include a missing knowledge entry, ambiguous policy, integration failure, incorrect reasoning, insufficient permission, poor handoff, and an upstream product defect. That taxonomy turns frontline review into an actionable product backlog. Without it, every problem becomes a generic bad answer and the team cannot tell whether to fix content, code, permissions, workflow design, or the product itself.

Measure verified outcomes, then widen authority

Containment is a weak primary metric for an agentic platform. A conversation can end without a human because the customer gave up, misunderstood the result, or discovered later that the action never happened. Count an autonomous resolution only when the case was eligible, the required outcome was reached without staff intervention, and the defined completion signal was verified.

Build the scorecard around the workflow

• Verified autonomous resolution: completed and verified eligible cases divided by all eligible cases.
• Workflow task success: whether the specific customer outcome and required end state were achieved.
• Correct-action rate: whether executed actions matched customer intent, policy, permissions, and current system state.
• Policy compliance: whether mandatory checks, confirmations, approvals, and prohibited-action rules were followed.
• Recovery quality: whether tool failures and uncertain outcomes ended in a known safe state without duplicated or hidden actions.
• Handoff quality: whether the receiving person could continue from the evidence supplied rather than restart discovery.
• Reopen and reversal patterns: whether apparently completed cases later returned or required corrective action.
• Customer effort: how much repetition, clarification, waiting, and channel switching the workflow imposed.
• Cost per verified resolution: the full operating cost, including model usage, platform fees, integrations, human review, evaluation, and incident remediation.

Report these measures by workflow and risk class. Where relevant, also inspect policy version, language, channel, customer segment, integration version, and release. A strong aggregate can conceal a severe failure pattern in a smaller but consequential slice.

Define release gates before looking at the results. Name the required task-success and policy-compliance thresholds, the failure categories that have no acceptable tolerance, the person who can approve expansion, and the signals that trigger rollback. The exact thresholds should reflect the consequence of the action. A wrong informational answer and an unauthorized account change do not belong under one quality target.

Expand authority in observable stages

1. Evaluate against approved, appropriately protected historical and synthetic cases without contacting customers or changing live state.
2. Run in shadow mode, where the agent proposes decisions and actions but people remain responsible for execution.
3. Allow live reads while keeping writes disabled, then compare the agent’s interpretation with authoritative system state.
4. Permit reversible, narrowly scoped writes with explicit confirmation and complete tracing.
5. Introduce higher-impact actions only after workflow-specific evidence supports the added authority and the required business, security, privacy, and legal owners approve it.
6. Continue monitoring after expansion, with a tested control that can disable the affected workflow or action without taking the entire support operation offline.

Do not expose production customer data to evaluation or model workflows without approved access, retention, and privacy controls. Do not let the system autonomously perform financially, legally, or security-sensitive actions while their eligibility rules, approval requirements, or failure recovery remain unclear. Keep human approval until the organization can demonstrate that the workflow is controlled and auditable.

Treat every material model update, prompt change, policy edit, knowledge migration, and tool-schema change as a release. Re-run the relevant evaluations before widening access. An agent can regress even when its conversational style appears unchanged because the failure may sit in retrieval, action selection, parameters, or verification.

Key takeaways

• Buy an outcome-control loop, not merely a chatbot with access to tools.
• Define each workflow’s authority, hard boundaries, recovery path, and completion evidence before evaluating vendors.
• Use live failure scenarios to test identity, conflicting knowledge, uncertain tool results, policy exceptions, handoffs, and auditability.
• Implement consequential boundaries as enforceable permissions and approvals rather than prompt instructions alone.
• Measure verified customer outcomes, policy compliance, recovery, and handoff quality instead of treating conversation containment as success.
• Widen authority only through workflow-specific releases with owners, evaluation gates, monitoring, and rollback controls.

Start with one workflow contract. If your team cannot state the authoritative systems, allowed actions, prohibited actions, completion signal, and escalation boundary on one page, a platform purchase is premature. Once those decisions are explicit, vendor evaluation becomes concrete: can this system operate inside the boundary and produce evidence that it did?

The platform worth trusting will not simply sound the most human. It will let you grant a little more authority after each verified release without losing the ability to stop execution, inspect a decision, reverse a safe action, or return control to a person.

References

• The Intercom Blog — Introducing Fin 4: Customer Agent, Operator, and major upgrades to the Intercom helpdesk

---