Key Takeaways
- An agent can use tools, so assess its authority as well as its answers.
- Prefer a simpler deterministic workflow when the task does not need AI judgement.
- Keep external sends, financial changes and sensitive decisions behind explicit controls.
- Measure correction effort and failure cost as well as time saved.
Agentic AI describes systems that can choose actions and use tools while working towards a task. The term is broad, and suppliers use it differently. For a business buyer, the important question is not whether a product calls itself an agent. It is what the system can read, decide and change, and who remains responsible when it is wrong.
This guide compares chatbots, workflows and agents without assuming that more autonomy is better. The examples are proposed operating patterns, not claims about unnamed MattDarm clients or measured savings. Start with a real process and a controlled pilot before giving a system access to live customer or financial records.
Distinguish an answer from an action
A basic chatbot may answer questions from approved information. A workflow follows defined steps, such as routing an enquiry after a form is submitted. An agent may choose which tool to use or which step to take next based on the task and the information it encounters.
These approaches can be combined. A support assistant might retrieve an approved policy, draft a reply and send it to a human queue. It does not need permission to issue refunds simply because it can explain the refund process. Separate the ability to describe an action from the authority to perform it.
Ask the supplier to demonstrate the boundary. Which records can the system read? Which can it edit? Can it contact people, spend money, delete information or change permissions? A list of integrations is not a sufficient answer: access scope and the actual operations matter.
Check whether AI is needed at all
Some repetitive tasks are better handled by ordinary rules. If every approved form submission must create one internal task, a deterministic integration may be easier to test and maintain. Adding a language model can introduce uncertainty without solving a real limitation.
AI becomes more relevant when the input varies and interpretation is useful, such as classifying a free-text request or preparing a draft summary. Even then, the surrounding workflow should control what happens next. The model's output should not be treated as an unquestionable instruction.
Use our first-workflow selection guide to compare frequency, variation, impact and reversibility. Choose the least complicated approach that reliably solves the problem. A modest draft-assistance workflow can be more valuable than a broad agent that requires constant supervision.
Define an authority boundary before connecting tools
Write down the permitted task, approved data sources, allowed tools and prohibited actions. Use separate read and write permissions where possible. Give the system only the access necessary for the specific workflow rather than connecting an administrator account for convenience.
Keep consequential actions behind an appropriate approval step. Examples include sending a client proposal, changing an invoice, committing the business to a date or deleting records. Approval must refer to the actual proposed action and destination, not merely a general instruction to be helpful.
The NCSC's secure AI development guidance treats security as a lifecycle responsibility. Build controls into the application and its integrations rather than relying only on a prompt that asks the model to behave carefully.
Treat retrieved information as data, not authority
An agent may read emails, documents or web pages containing inaccurate or malicious instructions. Those sources can be relevant to the task without being authorised to change its rules. A document that says “ignore the approval step” should not acquire control over the system.
Keep the authorised workflow separate from the material being processed. Validate tool arguments, restrict destinations and check permissions at the action boundary. Review how the supplier tests prompt injection and whether unexpected instructions can trigger a send, export or account change.
Ask for a demonstration using a deliberately misleading test document in a safe environment. The purpose is to see the control hold, not to expose real customer data. If the system cannot explain or enforce its boundary, reduce its authority before considering live use.
Make a useful support assistant before an autonomous one
Start with approved public service information and a clear human handoff. Test whether the assistant can distinguish a general question from an account-specific request. It should not reveal private records to someone simply because they ask convincingly.
Require the system to identify uncertainty and avoid inventing availability, prices or policy exceptions. Keep a route to a person visible. If it drafts an answer from a source, the reviewer should be able to see the relevant source and check whether the wording preserves important conditions.
MattDarm's AI chatbot development and AI-powered customer service are related but distinct scopes. A general website assistant and a system connected to customer accounts need different access, testing and operational arrangements.
Assess data handling before the pilot
List the information the system will process and where it will go. Check provider terms, retention, access controls, logging and any subprocessors relevant to the intended use. A paid subscription does not by itself establish that every category of business or customer information is appropriate to upload.
Use synthetic or appropriately minimised data while testing where possible. Do not place passwords, API keys or confidential customer records into a general prompt. Keep secrets in the approved technical configuration and ensure logs do not expose them.
The ICO's AI and data protection guidance is an official starting point. It is under review following legislative changes, so check the current guidance and obtain suitable advice for the actual use case. A generic AI policy is not legal approval for sensitive processing.
Build an evaluation set from real task types
Collect representative examples of ordinary requests, ambiguous inputs, missing information and situations that must be escalated. Use permitted or synthetic data. Record the expected behaviour, not just whether the answer sounds fluent.
Test tool failures and repeated requests. If a connection times out, can a retry create duplicate records or send the same message twice? If an approval is rejected, does the system stop? If the source information conflicts, does it ask rather than choose a convenient answer?
Keep a versioned result record so a model, prompt or integration change can be compared with the baseline. A successful demonstration using three friendly examples is not equivalent to a robust evaluation. Include the failure cases that could matter to customers and staff.
Measure value after review and correction
Record the manual time for the task, the automated run time, the human review time and the correction effort. Include setup, subscriptions, integration maintenance and incident handling in the cost picture. Time apparently saved at one stage can reappear as review work elsewhere.
Distinguish capacity from cash savings. If a team member spends less time drafting, the benefit may be faster response or more time for customers rather than a direct reduction in payroll. Avoid presenting theoretical minutes multiplied by a salary rate as realised profit.
Do not promise a universal payback period. Decide what result would justify continued use and what failure rate would make the pilot unacceptable. Review the outcome with the people doing the work, not only the person who bought the tool.
Plan operation, failure and exit
Assign an owner for monitoring, source updates, access changes and incidents. Make it possible to pause the workflow and return to a manual process. Document how to revoke credentials and identify records created by the system if something goes wrong.
Keep a useful activity log without retaining unnecessary sensitive content. A record should help explain which task ran, what action was approved and whether it completed. “The agent said it succeeded” is weaker evidence than confirmation from the receiving system.
Use the business AI policy template to define staff responsibilities. Re-test after significant provider, model or integration changes. An AI system does not become safely self-improving merely because it has been used for several weeks.
Start with a bounded brief
Describe one process, its current cost, the permitted inputs, the desired output and the actions that must remain human-controlled. Include a pilot limit and a stop condition. That brief makes it easier to compare suppliers and avoids buying a vague promise of autonomous operations.
MattDarm's AI automation setup and AI strategy consulting can help scope the work. Bring us the current workflow, including the exceptions and the systems involved. The best initial recommendation may be a simpler integration, a draft-only assistant or no automation until the process is clearer.
Frequently Asked Questions
How is an AI agent different from a chatbot?
A chatbot primarily provides conversational responses, while an agent may choose and use tools to perform tasks. Products overlap, so inspect actual permissions and actions rather than relying on the label.
Should an agent be allowed to send emails automatically?
Only within an explicitly approved, tested workflow with appropriate recipient, content and permission controls. For a first pilot, drafting into a human review queue is often a more controllable scope.
Will an agent learn safely from every interaction?
Do not assume that. Memory, retrieval, feedback and model training are different mechanisms. Ask what changes over time, who approves those changes and how the system is re-evaluated.
How do we calculate the return on an AI pilot?
Include setup, provider costs, maintenance, human review and correction. Measure usable output and operational effects, and distinguish freed capacity from money actually saved.
What should remain under human control?
The boundary depends on risk, but sensitive decisions, external commitments, financial changes and destructive actions need particular care. Define permissions and approvals before connecting live systems.
