When AI Learns a Workaround, Who Approves the Rule?

A senior support rep makes an exception to keep a customer moving. An AI system observes the resolution and proposes a new procedure. The proposed procedure looks sensible. It might even handle the next ticket faster.

Before it becomes standard practice, someone needs to answer a different question: was that exception something the business wants repeated?

On October 1, Decagon introduced Duet Apprentice in beta. The company describes a system that learns from onboarding documents, escalated support conversations, and discussions in Slack and Microsoft Teams. That context can inform workflow drafts and proposed changes to agent operating procedures. These are announced capabilities, not results we have independently tested.

The practical opportunity is easier access to knowledge that rarely reaches a process manual. The operating challenge is deciding which of that knowledge should change how the business acts. Our recommendation is to make each proposed procedure change a reviewable release, with an owner and evidence behind it.

A successful exception is still an exception

Consider a hypothetical service business that normally requires payment before booking work. A manager allows a long-standing customer to book while a billing dispute is resolved. The job proceeds successfully.

An agent learning from that conversation could infer several different rules. Established customers may book without payment. Customers with billing disputes get an exception. Managers can approve an exception. Only this customer, on this occasion, had approval.

Those interpretations have very different effects on cash collection and staff authority. A transcript can show what happened without establishing which interpretation the business intended.

This is why a proposed workflow should identify the source of its rule and the authority behind it. Repetition alone is insufficient. A workaround used ten times may reveal a broken integration or an unresolved policy problem. Automating it could make the underlying problem harder to see.

Review the change in business terms

The person approving a new procedure should see what will change for customers and staff, without having to interpret a long prompt or technical configuration.

For the booking example, a useful proposal would state the current rule, the proposed exception, the customers it applies to, and the approval it still requires. It would link to the observed case and identify any policy document that supports or contradicts it. Missing evidence should remain visible.

The proposal should also explain the action the agent will take. Drafting a suggested exception for a manager is a different release from allowing the agent to confirm a booking itself. Both may use identical knowledge while carrying different operating consequences.

We recommend separating the person who prepares the change from the person authorized to approve its business effect when the consequences warrant it. A support lead may own response wording. The owner of collections should approve a change to payment conditions. Someone still needs responsibility for implementing the approved version correctly.

This extends the distinction we discussed in AI Agent Permissions Need More Than a Prompt: understanding a possible action does not establish authority to take it.

Test what the new rule might break

A procedure learned from a difficult case should be evaluated on more than that same case. Otherwise, a team can approve a fix that merely reproduces the example that inspired it.

Use a separate set of representative cases, including ordinary work that the current procedure already handles correctly. Include nearby situations where the proposed exception should be denied. In the booking example, that could mean a new customer, an unresolved dispute without manager approval, or a customer whose account has a separate restriction.

For each case, define the expected business outcome before running the comparison. Did the agent request the right approval? Did it avoid making an unauthorized commitment? Did it send an unresolved conflict to the correct person with enough context to decide?

Evaluate the current and proposed procedures against the same cases. Record both improvements and regressions. A higher overall completion rate should not hide a new failure in a financially consequential step. This is also where a well-designed exception path earns its place: uncertainty needs somewhere useful to go.

Release narrowly and keep the previous version

A passed evaluation is evidence for a controlled release. It does not answer every question about live use.

Start with a defined scope, such as one queue or a limited class of requests. Keep the approved procedure version attached to each execution so reviewers can explain why a particular action happened. Where practical, begin with recommendations that staff review before allowing the agent to act directly.

Decide in advance what would trigger a pause. Examples might include an unauthorized booking, a conflicting approval record, or repeated staff reversals of the agent's recommendation. The appropriate threshold depends on the consequence, and the business owner should set it explicitly.

Keep a working route back to the prior version. Rolling back a procedure will not undo commitments already made to customers, so the release plan also needs an owner for reviewing affected cases and correcting them.

Give learning an operating owner

The business case for faster learning includes the work required to review what the system proposes. If suggestions arrive faster than a qualified owner can evaluate them, the review queue becomes the constraint.

For a first pilot, choose one procedure that changes often enough to matter but has a manageable consequence when it goes wrong. Name the policy owner, define the evaluation cases, and agree on release authority before enabling continuous suggestions. Measure review effort alongside accepted improvements and downstream corrections.

AI can help surface the knowledge buried in everyday work. Turning that knowledge into a dependable procedure remains an operating decision.

If you're considering an agent that learns from your team's work, talk with Revival Group about designing the approval and release process around one real workflow.