AI agents for business: which tasks to delegate
AI agents for business can help with workflows that involve interpreting text, choosing a next step and using several systems. Start with one process and define its result, permitted actions and acceptance checks. The scenarios and selection table below help you choose a pilot.
6 min read
Define the action first
A sales assistant is not a task specification. Reading an incoming request, finding the customer in a CRM and preparing a record with missing fields is specific enough to test. Choose a recurring action that a member of staff can verify against clear rules.
If the steps are fixed and the data is already structured, start with an integration or rules-based workflow. Add a model where the process needs to interpret free text, handle ambiguity or choose a suitable tool.
An agent can use tools and manage a sequence of actions. A chatbot can have those capabilities too; a conversational interface does not define the architecture. Discuss the permissions and result of the actual workflow.
Candidate workflows
The following are candidate scenarios, not a list of IOANN client deployments. Their value needs to be tested using your data and current workflow.
| Scenario | Possible system action | Human check |
|---|---|---|
| Incoming requests | Identify the topic, gather data and prepare a request | Routing, record completeness and ambiguous cases |
| Internal knowledge | Find a policy and prepare a sourced answer | Current version, access permissions and relevance |
| Moving data between systems | Match a record, populate fields and propose a change | Correct target record and no duplicate write |
| Drafting a customer reply | Gather request details and draft a reply | Commitments, terms and permission to send |
| Document processing | Extract fields and flag missing values | Source values and cases requiring manual review |
Select one process
Record how often each task occurs, where staff spend time and what an error causes. These observations support both the pilot decision and its evaluation. A feeling that something takes too long does not replace a baseline.
Prefer a task with sample inputs, an identifiable correct result and someone responsible for exceptions. If a required system is inaccessible or the documents are unreliable, address that dependency first.
| Check | What to record | When to defer |
|---|---|---|
| Result | One completed action and its acceptance rule | Stakeholders disagree about success |
| Data | Samples, source owner and permitted access | Sources cannot be checked or accessed |
| Alternative | Current process and an option without a model | A simple integration already solves the task |
| Failure | Consequences and a human handover path | The change is irreversible and cannot be reviewed beforehand |
| Baseline | Volume, time, errors and processing cost | There is no way to compare the pilot with current work |
Start with limited permissions
Separate reading data, preparing a change and executing it. An initial agent can prepare a record for a member of staff to approve. Sending messages, changing orders and financial actions require their own approval process.
An external document or email can contain text attempting to change model behaviour. Treat that content as data. Tool permissions, parameter validation and access to records belong in the application, outside the model's unrestricted decisions. OWASP describes prompt injection and excessive agency risks.
Before release, test duplicate events and cases where an action succeeds but its acknowledgement is lost. Retrying a model request and retrying a write can have different consequences.
Test the full user workflow
A plausible reply does not establish that the workflow completed. Check the target record, written fields, human handover and state after a failure. Include missing data, ambiguity and unavailable integrations in the evaluation.
Define the acceptable result for each example before testing. Track automatic completion, human handover and failure separately. This lets you compare models and establish which part of the workflow the system actually handles.
In our own product, Inner Voice, we defined evaluation scenarios in advance and identified a duplicate-reply risk during a review of notification failures. These are documented engineering examples, not measurements of savings at a client business. The retry article and case page describe the checks.
Measure cost per completed action
Include model calls, integrations, infrastructure, maintenance and manual review. Divide total workflow cost by actions that meet the agreed acceptance conditions. Failed attempts still consume resources, so their costs remain in the numerator.
Compare with the existing process on comparable tasks. Freed time can be useful when the team can put it to other work, but it does not automatically become cash savings. Account separately for development and transition costs.
What to prepare for a development discussion
Bring one process description and a few anonymised examples. Explain where staff currently work, which action must be completed and who checks the result. A list of systems helps establish available integrations.
Those inputs support a discussion of an option without AI, pilot scope and acceptance checks. Development cost and timing depend on data access, integrations and the first release scope; they are estimated after reviewing the task.