Replacing rules with AI: define exceptions and task boundaries
Before replacing rules with AI, check exceptions and choose each task's approach and maintainer.
Key points
- Check exceptions against real requests
- For each task, choose rules or AI
- Record rule storage and maintainers
Overview diagram in preparation
Contents
Keep exceptions whose purpose is unclear
A&A perspective
A branch in a business rule splits the process according to a condition, such as referring special contracts to a designated person. Choose the first task to give AI from work where you can explain the exceptions those rules protect. Being able to explain them does not make the change safe; you still need to check it against real requests.
Hypothetical example
Suppose rules have accumulated over time for routing incoming requests or preparing quotes. Moving everything to AI just because the process diagram looks complicated risks removing exceptions whose original purpose is no longer clear.
From the sources
AI developer Anthropic has published a case study about Decagon, a company that provides AI customer support systems. Anthropic reports that Rippling, an HR and payroll software company featured in the story, replaced automated decision trees, which split processing according to conditions, with AI guidance.
From the sources
Anthropic reports that this system guides users through HR and payroll procedures while complying with local regulations.
A&A perspective
However, the story does not say whether a separate process for checking regulatory compliance was retained.
A&A perspective
Automate & Augment (A&A), the author of this article, proposes checking with the people responsible why each exception was introduced before replacing the rules. The three options and migration table below are proposals for small companies to apply to their own operations.
Hypothetical example
Consider a creative production company handling requests for quotes. Suppose ordinary requests go to sales, while requests from customers previously promised a special deadline go to the company owner. This is a hypothetical example, not an implemented project.
Hypothetical example
The person handling incoming requests selects examples involving special contracts and explains which conditions led them to refer each one to the owner. Keep branches whose purpose is unclear, and check contracts and past requests. Having AI read a process diagram is not enough to decide that an exception is unnecessary.
Hypothetical example
Ordinary requests alone cannot test how special contracts are handled. Check who receives an ordinary request, a special-contract request, and a request with missing information. At this stage, choose candidates to give AI and the parts of the current process to retain while you investigate their purpose.
Choose a migration approach for each task
A&A perspective
For each task that staff can explain, choose whether to keep the rules, give the work to AI, or combine existing operations into a single call. A boundary such as "the entire intake screen" mixes reading requests with checking contract terms.
From the sources
Anthropic has also published an article about designing tools for AI. Here, a tool means an operation, such as retrieving information, that AI can call when needed. The article identifies simply turning existing software functions into AI tools as a common mistake. It recommends starting with a small number of tools suited to specific tasks.
From the sources
It also explains that one tool can combine several operations, using the collection of customer information as an example.
A&A perspective
A&A proposes defining the scope by where a task starts and ends, rather than by the number of screens or files. A description such as "read the request and give the person responsible a list of points that need clarification" makes the input and the required stopping point clear.
Hypothetical example
In the creative-firm example, keep checking special-contract terms through the current process. For reading a request and listing points that need clarification, try having AI suggest the points and sales review them. The proposal is to move only the reading of ambiguous text first.
Hypothetical example
Meanwhile, checking whether a contract exists, retrieving past quotes, and finding the person responsible could be combined into a single call. AI would ask to "retrieve the customer information needed to handle this request," and the existing system would return the specified fields.
Hypothetical example
Combining operations into one call does not replace rules with AI judgment. The underlying processes remain; the way AI calls them is combined. If a check is required partway through, end the combined operation before that check.
Hypothetical example
The following table sets out the three options. It is a hypothetical creative-firm example, not a claim that the companies in the sources used this division of work. Completing the table is not a reason to switch immediately if a task includes exceptions whose purpose is still unclear.
| Example task | Approach after migration | Checks to retain |
|---|---|---|
| Check special-contract terms | Keep existing rules | Staff confirm the purpose of each exception |
| Read requests and list points needing clarification | Trial AI drafts | Sales checks for omissions and misreadings |
| Collect contracts and past quotes | Combine existing operations into one call | Check that all specified information is present |
Assign the authoritative rule and its maintainer
A&A perspective
Alongside tasks and exceptions, the migration table should record where the conditions used for decisions are stored and who maintains them. Conditions will continue to change after AI takes on the task. Only when you decide who updates what can you see the full scope of the migration.
Hypothetical example
If special-contract terms appear in both the existing system and the instructions given to AI, someone may update only one copy. In this example, designate the existing system as the authoritative home for those terms and have AI query it.
Hypothetical example
One row in the migration table might read: "List points needing clarification / refer special contracts to the owner / AI only suggests / contract terms stay in the existing system / sales checks the result." A list of screen names alone cannot capture this division of responsibility.
Hypothetical example
During a trial, you can give the same request to both the current system and AI and compare their results. Only the person currently responsible sends anything to the customer. Comparing the two outputs does not mean having both send messages to customers.
Hypothetical example
Check for missing clarification points, special contracts treated as ordinary requests, and the time staff spend making corrections. Compare this with the time the current intake process takes, and record the effort involved in review and rule updates as well as AI usage fees. You cannot know the savings until you measure them.
Hypothetical example
If AI misses a special contract, stop the switch and return to the current intake process. In the migration table, name the internal staff member or contractor who will investigate the missed exception and the person who will decide whether to try again after it is fixed.
A&A perspective
Decagon, the company featured in the source, supplies software to many businesses. Its migration costs and ways of reverting changes differ from those of a company gradually changing its own internal system. The results reported in that case cannot serve as a forecast for your company.
A&A perspective
The decision here is which task to move first and which processes to keep afterward. For conditions used to accept a contractor's deliverables, see the related article "AI Agent or Workflow: Acceptance Terms for Your Vendor's Quote". For the actions AI may perform, see "Letting AI take action: decide by whether you can undo it, not the amount".
Summary
A&A perspective
Use real requests to check the exceptions your intake rules protect. Keep the parts whose purpose is unclear.
A&A perspective
For each task, choose whether to retain existing rules, give the work to AI, or combine existing operations into a single call.
Record where decision conditions are stored and who maintains them in the migration table. Writing down the exceptions does not prove that it is safe to switch.
FAQ
How many rule branches justify replacing them with AI?
There is no threshold. Even with many branches, keeping a process is an option if it checks fixed conditions. This article proposes choosing a task where reading text is difficult and checking how exceptions are handled as well.
What if no employee knows why an old rule exists?
Keep that part in place and investigate it. If contracts and past requests do not explain it, exclude it from the migration. A plausible explanation from AI alone is not a reason to remove the rule.
What should I give a contractor first?
Share the current process and examples of ordinary requests, exceptions, and requests with missing information. Include the expected treatment of each example. Mark unexplained exceptions as unverified, and discuss the work to investigate separately from the work to trial with AI.
Sources & editorial note
Primary pages read for this article. Publication dates below belong to the sources; access dates record our research.
- Decagon delivers white-glove customer service at scale with Claude
Anthropic · No publication date shown
Accessed 2026-10-30 - Writing effective tools for agents — with agents
Anthropic · 2025-09-11
Accessed 2026-10-30