Autonomous resolution agent

An execution agent is bought to close a whole ticket type without a person in the loop. The result is a change in a live system. Money moves back to a card. A credential is reset. A plan field is updated. The customer then receives a message describing what happened, and the ticket closes with that change attached. Fini, Ada, and Intercom Fin are sold for this job.

What the agent does not do is decide policy. It applies a rule somebody wrote and approved. It also does not work out what went wrong. Fact gathering and cause ranking happen earlier, in a read-only investigation step. An execution agent that also diagnoses will eventually act on its own bad guess. Keep the reading and the writing in separate systems, with separate credentials.

Two risks sit inside every autonomous resolution, and they are not the same size. One is the account change, which is usually reversible and always visible in a ledger. The other is the wording sent under the company name, which cannot be recalled once it lands. Treat them as separate approvals. A refund of nine dollars can be automatic while the sentence explaining it still gets reviewed.

An execution agent is only as safe as its action registry. Each entry needs six fields. The system and the exact operation. The largest amount or scope it may touch. The conditions that must hold first. The reversal path. And the name of the person who owns that action. Anything missing a reversal path is not an autonomy candidate. It stays on the manual list until one exists.

Caps do more work here than any model setting. A refund action might allow up to $50 per ticket and $500 per customer per year. Above that, the agent prepares the refund and stops. Scope caps matter just as much as money caps. An account update action should name the exact fields it may write, not the object. Permission to edit the subscription record is permission to change the price.

Reversal has to be tested before launch, not designed on paper. Somebody runs each action on a real test account and then undoes it. Write down how long the undo takes and what the customer sees while it is pending. A password reset cannot be reversed at all. It can only be followed by a second reset, which means the customer is locked out twice. Actions like that deserve tighter conditions than a refund does.

Before any write, the agent runs the checks a careful human would run. Is this person authorized on the account. Does the plan include what they are asking for. Has the same request already been handled this week. Is there an open dispute or a hold on the record. Each check should be a query against a system, not an inference from the ticket text. A failed check ends the run and hands the ticket to a person. It does not lower the bar and continue.

Identity deserves its own line, because it is the check people skip. An email address in a ticket is a claim, not proof. Password resets and account changes need the same verification the help desk uses on the phone. Context pulled at intake helps here. Having account and plan data attached to the ticket removes a lookup step. It does not replace the verification.

Every write needs an idempotency key and a log line. The key stops a retry from issuing the same refund twice. The log records the rule that allowed the action. It also records the value before and after the change. Agent actions should be readable in the same audit trail as human actions, tagged as automated. A separate log that nobody opens is not an audit trail.

Here is an invented case with invented numbers. A company runs shared e-scooters and bikes in several cities. A rider writes that her trip ended at 8:12am, but the app kept billing until 9:40am. She was charged $18.60 for a ten-minute ride. The agent has three actions available: partial refund, ride adjustment, and account note. None of them may exceed $50.

The checks run first. The rider is the account holder, verified through her app session. Telemetry shows the scooter stationary and locked from 8:12am. No refund has been issued on this account in ninety days. The charge sits under the cap. The correct fare for ten minutes is $4.10. The agent refunds $14.50 and adjusts the ride record to match the corrected duration.

The reply states what was refunded, why, and when the money should appear. It does not promise that the docking fault is fixed. That part goes to a hardware queue as a separate note, since the agent has no way to confirm it. Both writes land in the audit log with the rule name attached. Total time from ticket to closed is under a minute. A supervisor spot-checks a sample of these the next morning.

Silent scope creep is the first problem. Someone adds a new refund reason to the rules table, and the agent inherits it without review. Rules that expand what an autonomous system may do belong under change control. Treat the action registry like production code. Two names on every edit, with a date. Support ops should be able to say when a cap last moved and who moved it.

Partial completion is the ugliest failure. The refund goes through and the account update fails, leaving a customer who was paid but not fixed. Chained actions need a defined state for a half-finished run and a named person who gets paged. A single-action agent should refuse to start a second write until the first is confirmed. Longer sequences belong in an orchestrated path with checkpoints between steps.

Confident action on a misread ticket costs more than a wrong label. A customer asking about cancelling next month is not asking to cancel today. Ambiguous intent should route to a human, not to the nearest matching action. Volume hides this, because the agent looks excellent right up to the day it does not. Track reversals, not just resolution rate. The reversal count is the honest number.

Some actions never go automatic, whatever the accuracy numbers look like. Anything that closes an account, cancels a contract, or changes a legal record needs a human. So does any refund above the cap, and any action on an account already in dispute. The list should be short, written down, and boring to read. Revisit it whenever somebody asks to move an action off it. A long exceptions list usually means the automation was scoped wrong in the first place.

The wording is its own decision. An agent can execute a refund correctly and still say something the company cannot stand behind. Reply text drawn from approved sources is a separate drafting step. Riskier replies also pass a check for commitments and tone before send. Execution and language are different permissions, and one can be granted without the other.

Confirming that the fix actually worked stays outside the agent as well. An executed action is not a proven outcome. Re-running the failing operation against the account is the step that settles it. The support lead who owns the queue signs off on the action registry every quarter. That review is the only place where the reach of each action gets argued about on purpose.