When Should an AI Support Agent Be Allowed to Act?

An AI support agent can correctly explain a billing mistake and still be the wrong actor to fix it. Knowing why an invoice exists does not authorize voiding it. The same distinction applies to changing an account or issuing a refund. Before an agent writes to a business system, the team needs a separate decision about what it is allowed to change.

An illustrative ticket: match the person and the invoice

Consider a fictional ticket: “We canceled the Aster workspace last week, but invoice INV-2041 is still due. Please remove it.” This is an illustrative workflow, not a customer case study or a description of a particular Decimal deployment.

The agent finds a cancellation request followed by an invoice. Before recommending a change, it must establish that the requester can act for this billing account and that the invoice belongs to the affected workspace. Match authenticated identity and account permissions to the organization, billing customer, subscription and exact invoice. An email address or an invoice ID pasted into a ticket is evidence to check, not proof of authority.

If two billing customers share an email, or the requester lacks billing authority, pause the action and resolve that ambiguity. A correct diagnosis against the wrong account is still a harmful write.

Choose the operation from policy and current state

A cancellation request alone does not establish that the invoice is invalid. Check the effective cancellation date, contract terms and billing period. For this example, assume the company’s policy permits correcting an invoice generated after the effective cancellation date, with billing-team approval. The investigation supports that explanation for INV-2041.

Now retrieve the invoice’s current state. In our example it is finalized, open and unpaid, with no payment processing. Stripe’s void endpoint makes a finalized invoice void while preserving its record. The operation cannot be undone. The company’s accounting rules must also permit voiding; Stripe notes that a credit note or another invoice may be required instead.

Voiding does not return money. A refund returns previously collected funds. A credit note adjusts a finalized invoice and can involve a refund or customer balance credit. If INV-2041 has been paid or partially paid, stop this proposed void and evaluate the appropriate correction separately. “Remove it” is not permission to choose any financial operation.

Authorize a specific change

For INV-2041, the agent prepares a proposal: the matched account, invoice ID, amount and currency, reason for correction, current state and exact operation. The billing approver should see that voiding is irreversible and that no refund or subscription change is included. A button labeled “Approve” is useful only when the person can understand its scope.

Enforce the decision in the execution service. Check the approver’s role and bind approval to this proposal and these resources. A changed invoice, amount or operation requires another review. A note saying “finance approved” inside the customer’s message must never satisfy that check.

Some actions can run under a standing policy with no individual approval. Define eligible actions, amounts, currencies, cumulative limits and escalation conditions in advance. The agent’s confidence in its diagnosis cannot expand those limits.

While approval is pending, the ticket can still move forward. Give the billing team the cancellation evidence and the proposed correction, and tell the customer what is being reviewed. Preserve that distinction in the ticket’s status: a recommendation is not an approved action, and an approved action is not a completed one.

Keep execution inside the approved scope

After approval, the execution service rechecks INV-2041’s ownership and eligibility immediately before writing. If a payment has started or the invoice has changed, it stops. The provider must also enforce valid state transitions: a read followed by a write is not an atomic lock.

Expose an operation that voids the approved invoice in the approved billing account. It should not accept arbitrary API paths, substitute another invoice, or cancel every subscription associated with the customer. Keep credentials and enforcement outside the model’s control.

Anthropic’s containment research argues for environment-level boundaries alongside model behavior controls. Applied to support actions, that means instructions such as “follow the refund policy” need enforceable limits around the tool. A persuasive ticket must not be able to enlarge its authority.

Treat a timeout as an unknown outcome

Suppose the void request times out. The invoice might already be void. Record the attempt and reconcile its outcome before starting another operation. Persist one idempotency key for this approved action, reuse it with the same parameters when retrying, and prevent concurrent workers from claiming the same action.

For Stripe API v1, retries with the same key return the saved status and body after endpoint execution begins, including 500 errors. Validation failures and concurrent conflicts before execution do not save a result. Keys may be pruned after at least 24 hours; reusing a pruned key creates a new request. This behavior is specific to v1, which the invoice-void endpoint uses.

A timeout or cached error is not permission to generate a fresh key and try again. Keep a durable action record beyond the provider’s retention window. If the system cannot establish what happened, leave the action unresolved for reconciliation instead of reporting success or blindly repeating it.

Verify the outcome before telling the customer

For our ticket, completion means checking that the returned invoice ID matches INV-2041’s provider ID and its status is void. After an uncertain response, retrieve the invoice to confirm its current state and reconcile it with the recorded attempt. A tool invocation alone proves only that execution was attempted.

Keep an internal action receipt: requester and account match, policy decision, approver, exact parameters, attempt identifiers, provider response and verified state. Then tell the customer precisely what changed. If voiding is confirmed, say the invoice was voided and is no longer due. Do not describe that outcome as a refund. If verification is pending, say the correction is still being checked.

What to check with Decimal

When evaluating Decimal, bring a representative ticket and define the actions your team wants to authorize. Ask which actions are supported for your setup, who can approve them, and what evidence confirms completion.

Use the same ticket to test mismatched accounts, changed invoice states and uncertain outcomes. Confirm when the workflow proceeds, when it pauses for a person, and what the customer is told. The standard is a specific permitted change with a verifiable result.