AI or rules: choosing how to automate each business task

Imagine a customer request arriving by email. Someone needs to extract the details, find the customer in the CRM, check an amount, assign an employee and prepare a reply. Giving all of this to one AI agent combines several different decisions with several different kinds of authority.

Assigning a deal by region may require only a rule. Interpreting an unusual request may benefit from a language model. Sending a delivery commitment requires permission to make that promise, regardless of which technology drafted it.

When I assess a workflow, I examine each operation separately: its input, the expected result, how that result will be used and the consequences of getting it wrong. This makes it possible to choose a method for each step without committing to an all-purpose agent.

Four criteria for choosing a method

Start with the consequences of an error and whether it can be corrected. An incorrect internal tag is usually easy to replace. A delivery promise already sent to a customer changes their expectations. Refunds, price changes and deletions need agreed authority and controls. Some commercial actions can run automatically within defined limits; important or hard-to-reverse actions often need employee approval.

Look for decision conditions that are already known. If an employee can explain the decision through thresholds, lists and exceptions, try expressing it as rules. Rules make it easier to test the logic and show why a particular action occurred. A large number of conditions does not, by itself, justify a language model.

Check whether comparable data could reveal the conditions. Sometimes employees cannot supply a rule, but there are many records with consistent fields. Data investigation may uncover useful patterns. To evaluate them, you need to understand both kinds of error: allowing an unwanted event through and incorrectly rejecting a valid one.

Determine whether meaning and context matter. A large language model, or LLM, can help interpret the same idea expressed in different ways. Text alone is not enough reason to use one. A scan may first need optical character recognition, which extracts text from an image. Standard messages may be parsed with rules, while a narrow task may suit a specialized model.

These criteria can apply together. A model might extract information from an email, code might validate the required fields and amount, and an employee might approve a reply containing commercial terms.

Matching an invoice amount against accounting records or routing CRM deals by region and value usually does not require a language model. If the existing software already supports the rule, configuration may be sufficient. If employees have no agreed procedure and negotiate the next step each time, clarifying that procedure should come first.

Choosing the wrong method creates work in either direction. Using a model for a known condition adds usage costs, delays and review. Trying to interpret varied customer language through an ever-growing keyword list makes the rules fragile. Compare the options on real inputs, including incomplete, incorrect and ambiguous examples.

Known conditions: automating media buyers' rules

At a large international advertising agency, media buyers, the specialists who purchase advertising, were manually checking placements across hundreds of campaigns. During interviews, I examined the metrics they used, their exceptions and the conditions under which they disabled underperforming segments.

Their decision logic could be formalized. I built the campaign optimizer around rules the buyers configure themselves.

The conditions could account for geography, devices, placement lists and combinations of these factors. The buyers already knew how to make the decisions. Their difficulty was applying that knowledge frequently enough across the volume of campaigns.

The optimizer runs checks much faster and more often than manual reviews. It can disable an underperforming segment while allowing the rest of a campaign to continue. Buyers can understand which condition triggered an action and change the rule when necessary.

The integrations still required substantial development effort. APIs, the interfaces software uses to exchange data and request actions, behaved differently across ad networks. Some statistics arrived late; some requests returned errors. Acting on stale statistics could disable an effective placement while leaving a poor one running.

Integration work therefore needs its own assessment, separate from the decision method. AI assistance with coding does not remove the need to validate data, respect external systems' limits and handle failures.

Unknown conditions: investigating click data

For the same agency's traffic fraud detection system, there was no ready-made decision logic. The existing filter was letting unwanted traffic through, and the alternative services I tested did not provide the quality needed on the agency's traffic.

I investigated data from tens of millions of clicks, tested hypotheses and used the patterns I found to build a custom click-scoring system. Code and rules applied those findings. A language model did not make the filtering decisions.

This required more than interviewing employees. I needed comparable technical records, evidence to test each hypothesis and an understanding of the financial consequences. A bot that gets through causes losses, but blocking a genuine visitor also costs the agency revenue: it is paid for quality traffic. Problematic traffic also includes more than bots.

For major campaigns, I calculated filtering thresholds by comparing the harm from problem traffic with the revenue from genuine visitors. After the custom system launched, problem advertising traffic fell more than 20-fold.

Further investigation has diminishing returns. Once obvious problems are removed, the remaining cases are rarer and provide less evidence. Each improvement takes more work, and stricter filtering may start blocking valuable visitors.

The business therefore needs to choose an acceptable balance between remaining problem traffic, research costs and losses from false positives, meaning valid visits incorrectly rejected. A demand to block everything suspicious ignores that trade-off.

Varied language: a model working within a larger system

The agency's sales team needed to find potential advertisers in a large volume of scattered market information. There was no single current directory of companies with promising partnership terms, and competitors sometimes reached suitable companies first. Direct searches through ChatGPT and other language models had not produced the results the team needed.

For the advertiser discovery system, I gathered requirements, built a prototype, then independently developed and launched the complete system.

It collects specialist industry analytics through source APIs and interfaces. Custom algorithms process and structure that information, and the system identifies the legal entities behind the businesses. Web search and language models then help find contacts, partnership terms and affiliate programs. Leads that meet the criteria are added to Google Sheets.

The model receives prepared information and handles material expressed in varied language. For the selected advertiser category, the system regularly supplies potential partners with contacts and context for outreach. Salespeople still negotiate; meeting the selection criteria does not mean a deal has been signed.

A similar research task should give the model a result that can be checked. For example, it could find affiliate program details and identify the source. Review should establish whether the contacts belong to the right company, whether the source supports the conclusion and whether a guess has been presented as a fact. Missing information should remain unknown.

When conversation is the product

Some products depend on automatic conversation, so manually approving every response would defeat their purpose. They need controls within the conversation itself.

For a Telegram bot for psychological self-help, the psychologist supplied his method. I selected the language model and developed the technical solution. The model's instructions account for the method, context and current task. Conversation-state tracking and checks on adherence help detect deviations and steer the dialogue back, including when the model makes an error.

I also implemented controls for the order and priority of issues discussed, automatic selection of reasoning depth and caching to reduce token costs. Tokens are the units of text processed by the model. A short free conversation precedes an offer of paid access; payment handling and the admin dashboard are separate parts of the product.

This affects the development estimate. Connecting a model does not establish the desired conversation flow. The client's method, dialogue controls and ordinary application functions each require work.

Treat external text as untrusted input

An email or website can contain instructions addressed to the model. The application should treat those instructions as source material, with no authority to change the agent's permissions, bypass approval or disclose internal information.

If incoming material contains personal data, agree on permitted processing, access and data location before development. A cloud-hosted model and a model on your own server require different technical arrangements. Neither a provider's name nor self-hosting alone establishes that the setup meets the organization's requirements. The organization defines those requirements with relevant specialists; the engineer implements them. The article on AI document processing explores these choices in more detail.

Give a CRM agent permission for specific operations

Here, an AI agent means an application that uses a model and can interact with business systems to perform actions. Drafting a reply and sending it should be separate permissions. Permission to find a deal should not automatically allow the program to delete a customer or change an amount.

When designing access, distinguish four levels:

• Reading: allow access only to the records, communication history and statuses needed for the task.
• Proposing: let the agent prepare a draft or suggest a record change without altering live data or contacting the customer.
• Making limited, reversible changes: internal tags, priorities or assignments may be automated within agreed limits, with logging and a way to restore the previous state.
• Taking important or hard-to-reverse actions: define permitted scenarios separately for customer messages, deletions, amount changes, refunds and cancellations. For risky actions, an employee should approve the exact operation and its parameters. Some permissions are better withheld entirely.

Commercial impact does not automatically rule out automation. In the campaign optimizer, a buyer enables automation and sets the rules, after which the system acts independently within them. A CRM agent needs equally explicit conditions for what it may do.

Separate access and technical responsibility

An agent should use a dedicated company-controlled account with only the necessary permissions. Sharing an employee's login mixes the person's actions with the application's and makes it harder to revoke one without affecting the other. Administrator access grants unnecessary capabilities. Credentials for the CRM and other services should stay out of source code.

I included similar requirements in the release process for employee-built AI prototypes that I designed and agreed on for a company within a corporate group. Employees prepare their applications within their abilities, following instructions. A designated technical owner reviews and improves the code. DevOps, the specialists responsible for deployment and operation, deploys the prepared application to test and production environments through an automated release process.

The technical owner continues maintaining the application and coordinating with DevOps and administrators after launch. The employee who proposed an automation may not be able to diagnose its code or failures. Technical review and ongoing support need an explicitly assigned specialist.

Record enough to investigate, and design recovery separately

An action log should show what the agent proposed, which source records it used, the operation parameters, what actually happened and who approved it. Source links or record IDs are often useful for reconstructing events.

That does not require copying every email, personal detail and secret into the log. Define the minimum information needed for investigation, restrict access and set retention periods.

A log also does not undo an action. Recovery must be designed separately. The landing page builder I developed for the agency's media buyers includes both logging and rollback, allowing users to reverse an unsuccessful edit without changing code. For a CRM agent, recovery depends on the operation. An internal tag can be restored; a customer cannot unread a message already sent.

Human review must fit into the working day

Adding an approval button does not establish that someone can review the work properly. Before launch, estimate the number of cases requiring approval each day and the average time needed for one review:

Daily review workload = number of cases × average review time per case.

Compare that total with the time employees can actually set aside. If the work exceeds their capacity, the queue will grow or approval will become a routine click.

The interface matters as well. Reviewers need the original message or a link to it, the matching CRM record, the proposed action with its parameters and the evidence behind it. If they must find the customer again, reread the correspondence and recalculate the amount, much of the work has simply moved into the approval step.

For an operation that requires approval, silence must not count as consent. If the total workload, including manual tasks and approvals, is too high, narrow the tasks being automated, improve the information prepared for review or identify safe cases that can run under an agreed rule. If you narrow automation, assign people, a process and time to the excluded tasks, which still need to be done manually.

Expand permissions using observed results

A useful starting point is suggestion-only mode: the system prepares actions but cannot execute them independently. This reveals where it makes mistakes, what employees need to double-check and how long review actually takes.

When a particular type of suggestion is consistently accepted without changes, consider allowing automatic execution. Those operations still need verifiable conditions, limited permissions and a defined response to failures. Good model responses alone do not justify full CRM access.

Sometimes the trial reveals that the decision can be expressed as an ordinary rule. Examples make an employee's previously intuitive judgment explicit. The model may remain useful for interpreting the incoming text while code handles the subsequent decision.

The useful output of this analysis is a short workflow map: for each operation, record the method, the consequence of an error, the permitted action and how the result will be checked. That gives you something concrete to evaluate and estimate before buying a broadly defined agent.

If you would like to discuss a workflow, send a short description and a few typical situations, including one difficult case. For a free initial written exchange, it is enough to explain what information the employee receives, what they do next and which mistake matters most to prevent.