When AI Agents Actually Belong in Your Business

Name the job before choosing the agent.

Start with a narrow statement of work. ‘Improve customer service’ is too broad to evaluate. ‘Classify incoming service requests and draft a reply using approved policy documents’ defines inputs, a bounded output and a natural review point. You can inspect errors and compare the result with the current process.

Repeatability matters, but it does not imply that AI is necessary. If a decision can be expressed as a small, stable set of rules, conventional automation may be easier to test and maintain. AI becomes more plausible when the inputs vary in language or format and interpretation is a real part of the job.

Also ask whether the process should exist. An agent that reconciles two avoidably duplicated records might be a more expensive answer than removing the duplication. Map the work before adding a new worker, especially one whose outputs require supervision.

Give it a boundary it cannot negotiate.

Separate reading, recommending and acting. An assistant that summarizes an account has a different risk profile from one that sends a refund or changes a contract. Begin with the least authority that makes the workflow useful. Expand permissions only when the evidence supports the additional exposure.

Write down which actions are allowed, which require approval and which are prohibited. Enforce these boundaries in application code and service permissions. A sentence in a prompt is not an authorization system. The service executing a tool call must validate the requested action, the record being accessed and the user's rights.

Treat external content as data, including email, uploaded documents and retrieved pages. That content may contain instructions intended to redirect the agent. Keep secrets out of the model context, restrict available tools, and prevent external text from deciding where information may be sent. Testing should include attempts to cross these boundaries.

The model can propose an action. The system must decide whether that action is permitted.

Check the information it will depend on.

A polished answer does not establish that the underlying information is correct. Identify approved sources, their owners, their update process and the access rules around them. If two policy documents disagree, determine how the system selects the authoritative one. Better retrieval will not resolve an organizational disagreement by itself.

Give reviewers a way to inspect the source behind an answer. Where information is missing, the system should say so and route the task. It should not transform an incomplete customer record into a confident promise. For sensitive decisions, require the relevant evidence to be present before the workflow can advance.

Use real, permissioned examples to build an evaluation set. Include ordinary requests, ambiguous language, outdated information, unexpected formats and adversarial inputs. Keep a portion aside for testing after changes. A handful of successful demonstrations is not a reliable estimate of daily performance.

Design the escalation before the launch.

Every autonomous path needs an exit. Name the person or queue that receives an uncertain result, explain what context travels with it and decide what the customer sees while it waits. An escalation that deposits another unexplained notification in chat has moved the work rather than resolved it.

Set review requirements according to the consequences of error. A wrong internal category may be cheap to correct. An incorrect financial commitment or disclosure of confidential information may not be. A model's self-reported confidence should not be treated as a calibrated probability; use validated checks, bounded permissions and review gates.

Maintain an audit trail of the inputs used, the proposed action, the approval where required and the outcome. Limit retention and access because these traces may contain sensitive information. Provide a way to disable the agent without disabling the underlying service. A documented manual fallback makes the system easier to trust and easier to recover.

Count the cost of the complete workflow.

Compare the current cost of a completed task with the proposed cost after review, exceptions and maintenance. Model usage is only one line. Include integration work, evaluation, monitoring, human corrections and the operational cost of a wrong action. Do not count every minute of theoretical time saved as recoverable capacity.

A useful pilot starts in shadow mode: the system produces a recommendation while the existing process remains authoritative. Compare outputs, track why a reviewer changed them and observe whether the proposed automation actually reduces effort. Then release a narrow class of low-risk work with visible ownership and a rollback path.

The decision to continue should depend on observable criteria agreed before the pilot. These may include acceptable error types, review effort, completion quality and cost per resolved task. If the workflow does not meet them, simplify it, narrow the scope or stop. An experiment that establishes where AI does not belong can still be commercially useful.

• Is the task frequent enough to justify ongoing ownership?
• Is interpretation needed, or would rules work?
• Are the data and permissions adequate?
• Can costly errors be prevented or caught before action?
• Does a person own exceptions and recovery?
• Do the economics still work after review and maintenance?