AI Agents for Business: What to Automate and How to Check It

An AI agent is useful when it helps someone finish real work. A customer gets an accurate answer. An enquiry reaches the right person. A document gets reviewed without staff copying it between five systems. A fluent conversation is only part of the job. The system also needs correct information, limited permissions, reliable connections and someone responsible when it fails.

Start with the task. What takes too long? What information is often missing? Which decisions can someone check? Which actions must stay with a person? These questions can reveal a useful AI project. They may also show that a form or ordinary software rules would solve the problem more cheaply.

This guide covers customer service, staff knowledge tools, document processing and marketing administration. Its examples are proposed designs, not Lucid Growth Media client results. A supplier announcement tells you what a product offers. Only testing your own task can show whether it will help your business.

Define what the agent can do

The word agent can mean a simple chatbot or software that chooses and carries out several steps. Avoid buying a label. Write down what information the system receives, which sources it may read, which tools it may use, and when it must stop.

Ordinary automation follows steps set in advance. An AI-assisted process might sort a message or extract details, then let ordinary software finish the job. An agent can choose its next step from the tools it has been given. Anthropic draws a similar distinction between fixed workflows and model-directed agents. A more flexible design is not automatically more useful. [1]

For example, copying an enquiry into a customer relationship management system, or CRM, rarely needs an agent. A CRM stores customer and sales records. AI may help when it must understand an unclear enquiry, check a service list, ask a follow-up question and prepare a summary for staff. Ordinary software can still decide which team receives it.

Write a promise you can test: use the approved service list to collect missing project details, create a clear summary and send it to an available reviewer. Also state what the agent cannot do. It must not invent prices, negotiate contracts, claim unchecked availability or contact unrelated people.

Start with a workflow that has a visible owner

A good first project has a person who understands the work and can judge whether the output is useful. This owner need not be a developer. It may be the support manager who knows why tickets reopen, the operations lead who reviews supplier documents, or the marketing manager who checks campaign reports.

Interview the people doing the task, then observe a few real examples with appropriate permission. The documented process may say that every request contains an account number. The actual inbox may show that most people describe their problem informally, attach an unreadable screenshot, or mix several requests together. These differences determine the design.

Record where time is spent. Separate active handling time from time waiting for another team. An agent that writes a summary in seconds may not reduce a process dominated by a two-day approval queue. In that case, clearer routing and review responsibility might matter more than a better model.

Choose a workflow where successful completion can be observed in the business system. A correctly created appointment, a reviewed extraction, or a resolved request provides stronger evidence than a positive-sounding response. Also identify a manual fallback that staff can use during the pilot. If nobody can explain how to complete the task without the agent, the process may be too poorly understood to automate safely.

Assess suitability before selecting technology

Ask four questions about each possible task. Does it happen often enough to matter? Do people describe it in different ways? Can you check the result? Can you contain the harm from a mistake? A small internal task can be a good starting point if it lets staff learn without putting customers at unnecessary risk.

• Repeated administrative transfers usually favour ordinary integration when fields and rules are stable.
• Language-heavy interpretation can justify an AI step when people express the same need in different ways.
• Tasks with reliable source material are easier to evaluate than tasks whose answers depend on undocumented judgement.
• Reversible actions are better early candidates than payments, deletion, publication, or legally significant decisions.
• Work without an available reviewer or fallback should be redesigned before automation expands.

Consider an illustrative purchase-order workflow. Extracting vendor name, date, reference, and totals from varied files might warrant AI assistance. Matching those fields to existing records, checking arithmetic, and enforcing approval limits should use explicit rules. A model should not decide that an unexplained mismatch is probably acceptable.

Fix conflicting source material first. If the company has three different refund policies, appoint a policy owner before building a chatbot. Write down the expected benefit, required systems, known risks and reasons to stop. Rejecting an unsuitable task is a useful decision.

Agree how the task should work

Define what starts the task, the required information, approved sources, output format and proof of completion. Name the owner and the route for exceptions. Add a short list of actions the system must never take. These requirements give the business and developers the same target.

For a customer-support assistant, the trigger might be an authenticated request about an existing order. The trusted source might be the order system plus a current policy library. The completion signal might be a correct status explanation or an accepted human handoff. The prohibited actions might include changing delivery details without verification or promising a refund that has not been approved.

Specify uncertainty behaviour. If two records match, the agent should request a safe distinguishing detail or pass the task to a person. If the source is unavailable, it should report that limitation rather than fill the gap from general knowledge. If the customer asks for a person, that request should not trigger another persuasion loop.

Check the conversation and the task separately. The answer should be clear and respectful. The action should be correct, permitted and recorded. A polite answer cannot excuse an unauthorised change. Include accessibility from the start so people can use the service and check what happened.

Make the knowledge base dependable before making it larger

A retrieval system searches approved documents and gives relevant passages to the model. This helps the model use evidence, but it does not make the documents accurate or guarantee a correct answer. Decide which sources are authoritative before adding more material.

Start with a compact source register. Give each source an owner, access group, effective date, review date, and status. Remove superseded policies from active retrieval while retaining any required archive separately. Explain precedence where several documents cover the same topic. A service agreement may override a general help page for a particular customer, but only when access and account context support that interpretation.

Search systems often split long documents into smaller sections, called chunks. Keep related information together. A delivery-charge table needs its locations, conditions and prices. A policy exception needs the rule that explains who qualifies. Test whether search returns enough evidence to answer correctly, rather than a sentence with matching words.

Check access rights when the search runs. Do not put all departments’ documents in one searchable collection and trust the model to hide restricted material. Search results must match the user’s permissions. Where useful, show a source link so staff can inspect the original record.

Design tools around narrow business actions

Tool access is where an agent moves from generating text to affecting systems. Design that access around specific business actions. A tool that retrieves an order by an authorised identifier is easier to control than a general database interface. A tool that creates a draft response is safer than one that can send arbitrary messages to arbitrary addresses.

Each action should validate its inputs independently of the model. Check identifiers, allowed values, ownership, amounts, and current record state. Return clear results that distinguish success, rejection, temporary failure, and missing information. Do not make the agent infer whether an update happened from a vague response.

Keep reading and changing records as separate permissions. Also separate preparing a change from applying it. Staff can review a proposed CRM update before software saves it. For important changes, approval must apply to the exact proposed action and current record, not a different action made later.

OWASP’s excessive-agency guidance identifies unnecessary functionality, permissions, and autonomy as contributors to risk. [2] The practical implication is to remove capabilities the workflow does not need, including tools left over from prototypes. A warning in the prompt is weaker than withholding the capability altogether. Review the agent’s service account as carefully as any employee or integration account, and record who can change its permissions.

Handle retries, duplicate events, and partial completion

Ordinary system failures can create duplicate work. A request may time out after the update was already saved. A webhook, which is an automatic message from another service, may arrive twice. A user may close the browser during a booking. Test these cases even when the conversation sounds right.

Give each task and action a stable reference. An API is the connection software uses to request work from another system. If that API supports idempotency, use it: this means repeating the same request does not create a second booking or charge. Otherwise, add a check for existing work and a way for staff to resolve uncertain results. Retry only when the action is safe to repeat.

Record the current stage of the task. An appointment might move through details collected, availability checked, customer confirmation, booking sent and booking verified. The final message must match the verified stage. If the result is unclear, say confirmation is pending and send it to staff to check.

Decide what happens when only part of a task succeeds. A CRM note might be saved while a notification fails. Retrying the whole workflow could create another note. Instead, resume the failed step from recorded state. Keep an audit trail that a person can understand without reconstructing every model response.

Treat outside content as information, not authority

An agent that reads email, websites, documents, or support attachments will encounter text written by people outside the organisation. Some of that text may contain instructions intended to redirect the agent. A document could ask it to reveal internal records or ignore approval requirements. This is a design risk even when the material looks like ordinary business content.

Keep authorised instructions separate from text found in documents or websites. A webpage cannot change the task or approve an action. Limit where the agent may send data. Check generated output before another system runs it as a command or uses it to change records.

Test attacks that resemble the actual workflow. An invoice might include hidden text. A support message might claim to come from an administrator. A retrieved page might contain a fake instruction to upload files for verification. The test should examine whether the system resists the action, preserves legitimate work, and records a useful reason for escalation.

OWASP’s agentic security work provides a current reference for assessing systems with tool access and coordination. [3] Use such guidance to structure review, while recognising that no checklist eliminates every attack. A practical defence combines limited capability, isolation, validation, monitoring, and human review. The objective is to keep an unexpected model response from gaining more authority than the workflow intended.

Use the simplest design that works

One model request with document search may be enough for an internal help tool. Fixed steps can extract, check and review document details. An agent is more useful when the next step varies and cannot be set reliably in advance. Several agents may help with separate tasks, but only if their extra complexity is justified.

Every extra step adds delay, cost and more things to test. Several agents can repeat the same error or reach conflicting answers. A second model agreeing with the first is not the same as checking the original evidence.

Compare designs using the same sample tasks. Include an ordinary software option, a simple AI process and a more flexible agent if needed. Measure correct completion, staff review time, cost and the seriousness of mistakes.

OpenAI’s August 2026 builder guidance discusses keeping reasoning across steps, running agent tasks in parallel and using code for fixed processing rules. [4] These options may be worth testing. Adopt them only when they improve your measured results within the agreed permissions and cost.

Build a useful evaluation set from actual work

Gather a permitted sample of past requests and remove unnecessary personal data. For each, describe the expected result. Include everyday work, unclear requests, missing information, unavailable systems, conflicting sources and work the agent must not do.

Avoid a test set consisting only of questions the development team already knows the agent can answer. Reserve examples for evaluation that were not used to tune instructions. Include recently observed cases as the business changes, while retaining a stable set that makes regressions visible.

Use different checks for different results. Automated tests can confirm that one record was created with the right fields. People can check whether an explanation is clear and a staff handoff is useful. A model can help review large batches, but compare its judgements with human reviews. Do not make it the only judge of serious errors.

Anthropic’s January 2026 testing guidance distinguishes what an agent says from what actually happens and recommends reviewing full trials. [5] If it says an appointment is booked but no booking exists, the test fails. Refusing a prohibited request can be a correct result. Tests should clarify requirements, not chase a flattering pass rate.

Use a scorecard that exposes tradeoffs

One headline accuracy number conceals too much. A system can answer common questions correctly while failing every sensitive exception. It can reduce average handling time while creating a small number of expensive errors. Define a scorecard that makes these tradeoffs visible.

• Task completion: did the authorised outcome actually occur, with all required records and confirmations?
• Evidence quality: did the answer use the appropriate current source and preserve its conditions?
• Action safety: were permissions, verification, approval, and tool restrictions respected?
• Handoff quality: did the right team receive enough context to continue without unnecessary repetition?
• User experience: could people understand, correct, interrupt, or leave the interaction?
• Operating cost: what was spent across successful tasks, failed attempts, retries, review, and support?

Report results by meaningful task category. Separate a straightforward status request from an account change, a new-language interaction, or a document with poor image quality. The categories should help improve the service, not create intrusive personal profiles.

Set release thresholds according to consequence. A formatting issue and a disclosure of another customer’s information do not belong in the same error bucket. For serious failures, the release decision may be to stop until the control is fixed, regardless of aggregate performance. Document who can accept remaining limitations. A numerical threshold is useful only when the team understands what it permits and what it does not.

Price the completed workflow, not only the model call

Model usage is one component of cost. A credible estimate also includes integration development, knowledge preparation, hosting, search, storage, monitoring, security review, human evaluation, maintenance, and the fallback process. For customer-facing systems, include the cost of correcting mistakes and handling complaints.

Calculate total cost per correctly completed task. Count the cost of failed and abandoned attempts too. Track staff review time separately: automation may move work from doing the task to checking it without saving time overall.

Use an illustrative scenario to expose assumptions. Suppose a workflow handles several hundred documents each month. The model fee might be modest, but a reviewer spending a few minutes resolving each uncertain extraction could dominate the operating cost. Improving input templates or validation may create more value than choosing a cheaper model.

Estimate low, expected, and high usage rather than one precise forecast. Consider seasonal peaks, long conversations, large attachments, retry storms, and unexpected customer behaviour. Set budgets and alerts at the workflow level. If spending rises suddenly, the system should have an agreed response: limit new tasks, switch to a safe fallback, or ask an operator to investigate. Commercial predictability is part of a useful automation, not an afterthought.

Make privacy decisions visible in the design

Map what data enters the workflow, where it is processed, which suppliers receive it, who can access it, and how long it remains. Separate raw messages, retrieved documents, action logs, conversation transcripts, and evaluation datasets. They may have different purposes and retention needs.

India’s Digital Personal Data Protection Act, or DPDP Act, has a phased start. The November 2025 notification brings different provisions into force at different times. As of August 2026, it would be wrong to say every main duty was already fully in force under that notice. Get advice on the rules that apply now, other relevant laws and preparation for later dates. [6]

Regardless of the legal timetable, reduce unnecessary data collection. A service enquiry assistant generally does not need identity documents or detailed personal histories. Mask sensitive fields in troubleshooting logs where possible. Do not copy an entire customer record into a model request when a few authorised attributes will answer the question.

Check supplier contracts for where data is processed, who else receives it, security, use for model training, deletion and incident reporting. Check the exact account and feature you will use. A privacy setting for one product may not cover its connected tools. Describe the controls you have checked and the limits that remain.

Design the human handoff as part of the product

A handoff is not a failure if it occurs for the right reason. It is a service feature. The design should explain when the agent transfers work, who receives it, what context travels with it, and what the user should expect next.

Transfer work when someone asks for a person, the agent repeatedly misunderstands, permission is missing, records conflict, a system is unavailable or the topic is outside its agreed task. Do not make people repeat requests to improve an automation score.

Give staff a short handoff: what the user asked, verified facts, sources checked, actions tried, current result and why help is needed. Label model guesses clearly. Keep the original conversation available only to authorised reviewers when needed.

Plan after-hours behaviour. If the human queue is closed, the agent should say so and offer a realistic next step. It should not promise an immediate callback unless the operating team can deliver it. Set ownership and ageing rules for unresolved tasks. A daily review of stuck work may matter more than a polished conversational personality.

Finally, make it easy for staff to correct the system. Capture the reason for correction in a structured way, then review patterns. Repeated handoffs can reveal a missing policy, a broken integration, or a workflow that should remain human-led.

Make the experience accessible and multilingual

A conversational interface does not remove accessibility obligations. People may use a keyboard, a screen reader, magnification, assistive input, or a device with limited bandwidth. They may need more time to read or answer. The interaction should remain usable without rapid typing, precise pointer control, or constant attention.

Use clear labels, visible focus, readable contrast, sensible status announcements, and a reliable way to revisit previous messages. Do not place essential instructions only inside animation. Provide a conventional contact or form option when conversation is not the easiest route. W3C’s WCAG 2.2 guidance is a useful reference for web-interface requirements; it is not a substitute for testing with actual assistive technologies and users. [7]

Test the complete task in every supported language. A translated greeting does not show that the agent can understand an address or explain a cancellation rule. Ask qualified speakers to check names, numbers, local terms and code switching, which means changing languages within a conversation.

Let people choose or change language without making assumptions about identity. Preserve original text where review requires it, and label translations appropriately. Avoid claiming universal language support from a supplier’s model list. The relevant question is whether the complete workflow, including sources, integrations, handoff, and human support, works in the languages you promise.

Introduce autonomy in stages

Start with offline evaluation, then run the system on permitted examples without affecting live records. A shadow mode can compare proposed actions with the work people actually complete. It is useful only if data access is authorised and employees understand what is being observed.

The next stage can be assisted operation. The agent prepares summaries, recommendations, or draft updates; a person reviews them before execution. Measure review time and disagreement. If reviewers routinely rewrite the output, the system may not yet save effort even when it appears accurate.

Allow narrow automatic actions only after the evidence supports them. Keep higher-impact changes behind approval. Expand one dimension at a time: a new task type, a new language, a new tool, or a larger audience. Changing all four makes it difficult to identify the cause when performance shifts.

Plan how to undo a release before launch. Staff should know how to stop updates, switch to a form, route work to people and check affected records. Keep a dated record of the model, instructions, tools, sources and test results for each release. This makes it possible to compare versions and restore an earlier setup.

Monitor outcomes without collecting everything

Monitor whether tasks finish, errors rise, queues grow and people receive correct information. Decide which records answer these questions. Collecting everything adds cost and privacy risk without necessarily helping.

Log task references, action results, times, response delays, software versions and changes of task stage. Store conversation content only for a clear purpose with restricted access. Staff need enough evidence to investigate a failure, not an unrestricted archive of personal conversations.

Set alerts around consequences. A sudden rise in rejected updates, repeated handoffs, missing confirmations, or unexpected external destinations deserves attention. An alert should have an owner and a response procedure. Otherwise, it becomes background noise.

Review a representative sample of completed interactions as well as failures. Silent errors can look successful in system logs. Ask whether the customer’s underlying need was addressed and whether the business record supports the final message.

Schedule periodic access reviews, knowledge reviews, supplier-change reviews, and evaluation refreshes. Treat model upgrades like software changes. A new default can alter tool use, tone, cost, or refusal behaviour. Re-run the relevant evaluation set before broad rollout, and keep a route back to the previous configuration where the provider permits it.

Three example projects to assess

An internal knowledge assistant can be a sensible first step when employees repeatedly search approved policies. Begin with one department, a manageable source library, and read-only access. Measure successful source discovery, answer correctness, and time to reach a useful document. Do not promise that it can answer every organisational question.

A commercial enquiry assistant can collect project type, broad requirements, timing, and contact preference before preparing a handoff. It should use the current service catalogue, disclose its role appropriately, and avoid making unapproved commitments. Success includes a useful summary and a completed routing action, not merely collecting more fields.

A campaign-reporting workflow can gather authorised platform exports, validate periods and currencies, calculate agreed metrics in code, and draft commentary for review. Keep observations separate from causal claims. A rise in enquiries after a campaign does not by itself prove the campaign caused the change.

Plan for staff and supplier changes

Give the system a business owner and backup contact. Review access when staff or suppliers leave. Avoid depending on an employee’s personal account. Use business accounts and a documented way to change credentials while keeping the records needed to run the service.

Test the handover before accepting the project. Can another authorised operator find the live settings and source list, run the tests, review stuck tasks and stop the system? Can the business export its records? Owning source code is not enough if the team cannot access the settings, hosted data or required accounts.

A supplier may retire a model, change an API or move a feature to a higher-priced plan. Keep a list of services you depend on and decide which changes require fresh tests. Test an important replacement before an emergency. A similar model may follow instructions differently or lack a tool you need.

Review whether the automation is still worth running. A system upgrade may remove the task, or demand may fall. When retiring it, revoke access, stop schedules, keep required records, delete unneeded data and tell affected staff.

Questions to ask an agency or supplier

Ask for a demonstration using your workflow, with synthetic or properly authorised data. A generic demo is useful for orientation, but it should not be the basis for acceptance. The proposal should identify dependencies the client must provide and decisions the agency cannot make on the client’s behalf.

• What is included in discovery, source preparation, integration, evaluation, deployment, training, and support?
• Which actions can run automatically, and which require approval from a named role?
• What happens when a model, API, search service, or business system becomes unavailable?
• How will correct completion, serious errors, review effort, and ongoing cost be measured?
• Who owns the code, configuration, accounts, source register, evaluation cases, and operating documentation?
• What are the exit arrangements, data-export options, deletion responsibilities, and recurring charges?

Ask how changes are priced. Adding a new integration or language may require substantial validation even when the conversational interface looks unchanged. Distinguish fixes to agreed functionality from new requirements.

The handover should include settings, access responsibilities, instructions, known limits, test results and an incident process. Train staff on routine work and failures. They should not need the original developer for every everyday decision.

Follow one request through to a checked result

Consider an illustrative internal purchasing assistant. An employee asks it to prepare a replacement order for a damaged office monitor. The assistant may find the approved equipment policy and create a draft request; it cannot approve spending or place the order. This example describes a proposed design, not a deployment or client result.

The first evidence check concerns authority. The employee can see their own equipment record and the standard policy, but not another department's purchase history. If two records appear to match, the assistant asks for an authorised distinguishing detail. It does not choose a record because the name sounds familiar. The draft carries the employee's verified identifier, the selected equipment record, the policy version and an explicit pending-approval state.

Now stop the connection after the draft is saved but before the assistant receives confirmation. A second attempt must use the same action reference and look for that draft. The test passes only if there is one request in the main record system. If the lookup also fails, the assistant reports that the result is unknown and asks staff to check. It must not place another order.

The evaluator then changes one condition at a time. An expired policy should prevent an unsupported answer. A document containing an instruction to bypass approval should remain evidence to inspect, not authority to act. A manager's request to approve the purchase should still require the designated approval process. Each trial records the final business state, the information disclosed and the action actually attempted. This applies the distinction between agent statements and environmental outcomes in Anthropic's evaluation guidance. [5]

The handoff contains the draft reference and the uncertain step, so staff can resolve the case without re-entering everything. The employee receives a status they can understand: submitted for review, awaiting clarification, or not yet confirmed. Testing these alternatives makes the boundary between assistance and authority visible.

Test a permission change while work is in progress. Remove the employee’s access after the policy is read but before the draft is saved. The saving step must check current permission. Next, reject a pending request while its notification is waiting to send. The message must show the rejection, and no order may proceed. Compare the user, policy version, request reference and approval status across records. Use made-up test records with access limited to the test team.

A practical readiness checklist before launch

Before launch, review the configured system with the business owner, developers and relevant security or legal advisers. Each completed checklist item should link to evidence: a test, document, permission setting or observed result.

• The workflow has a named owner, a defined purpose, and explicit exclusions.
• Authoritative sources are current, permissioned, and assigned to maintainers.
• Tool permissions match the task, with separate controls for consequential actions.
• Duplicate events, uncertain writes, timeouts, and unavailable dependencies have been tested.
• Evaluation covers routine work, exceptions, out-of-scope requests, and serious failure modes.
• Users can reach a person, correct information, and use an accessible alternative.
• Data flows, supplier terms, retention, and applicable legal requirements have been reviewed.
• Monitoring, budget limits, rollback, incident ownership, and support responsibilities are documented.
• The receiving team has practised using the handoff and resolving stuck tasks.
• The client has received the agreed configuration, documentation, and training.

Launch approval should record remaining limitations and the conditions for expansion. It should also say who can pause the workflow. If staff discover a problem affecting customers or confidential information, they should not have to debate whether they are authorised to stop it.

Lucid Growth Media can help you choose an automation task, connect agreed systems and test the result. Tell us what staff repeat, which tools they use and where work gets stuck. We can then define what to automate, what people should approve and how your team will run it.