AI agents for businesses: start with a bounded workflow
Choose an AI workflow by inputs, tools, permissions and approval points, then test quality, cost and failure behaviour before automation.
Updated: · AI-generated editorial illustration
AI agents can use tools across a sequence of tasks, but not every problem needs an autonomous system. For a small business, a workflow with explicit steps is often easier to inspect and maintain than an agent told to do everything. Start with a task that has defined input, output and correctness criteria.
The example is an assistant classifying and drafting customer requests. It is an illustrative design, not a connected inbox or a system sending messages on the business's behalf. External actions need actual permissions and an operational process.
1. Distinguish automation, workflow and agents
Rule-based automation fits stable logic. An AI workflow has predefined steps while using a model where language processing is needed. An agent can choose steps or tools more flexibly. The highest autonomy is not automatically the best choice; it expands what must be tested and constrained.
Anthropic's effective-agents article distinguishes workflows and agents and describes patterns. It is a reference framework rather than a requirement to use one vendor. Choose the simplest approach that solves the task, adding autonomy only when its benefit and evaluation method are clear.
2. Choose a task narrow enough to evaluate
For enquiries, the task might receive text, classify the service, identify missing information and draft a reply. Do not bundle quoting, contracting, CRM updates and email sending into the first version without validation conditions. Each output needs a schema or observable criteria.
A draft might need to preserve the question, avoid inventing prices and request a website URL when absent. Evaluate typical and difficult examples: short messages, several needs, misspelled Vietnamese and out-of-scope requests. Report an accuracy rate only with a real evaluation set and scoring method. A useful acceptance test checks the business decision, not merely whether the model produced fluent text.
3. Define tools and permissions explicitly
Read-only retrieval, drafting and external sending have different consequences. An initial version can read only necessary information and return a draft. When write tools are added, limit resources, actions and editable fields. A tool called manage_customer should not implicitly permit every customer operation.
The MCP tools specification describes tool interfaces in that protocol. MCP does not itself grant business authority or make retrieved content trustworthy. Accounts, authentication and access checks need to exist at the appropriate layer. The model should not be the final authority deciding who may access or modify a resource.
4. Separate input data from trusted instructions
Emails, websites and customer documents can contain text resembling commands. The workflow should treat them as material to analyse rather than allow them to change system authority or objectives. A message asking the assistant to ignore the process and export the customer list does not become valid authorisation merely because it was read.
Keep data boundaries clear, validate outputs and avoid forwarding untrusted instructions into powerful write tools. Send only necessary information to the model according to business data conditions. When source material is missing, a draft should expose the gap rather than fabricate a confident answer. Good workflow design makes uncertainty reviewable instead of hiding it behind fluent prose.
5. Place approval according to consequences
An internal summary might need sampled review; sending email, changing prices or deleting records needs a more explicit process. Show the reviewer the concrete recipient, content, proposed edit and reason. Asking whether the agent may continue is insufficient if nobody knows the next action.
Once a scope is authorised, avoid repeatedly asking permission for routine reading or draft refinement. Changes to recipients, authority or consequence need renewed examination. Log the actual action and tool result. The agent saying sent is not equivalent to confirmation from the sending system. Approval should attach to a reviewable result and defined impact.
6. Measure quality, cost and failures before automation
Build an evaluation set from authorised examples, using fictional fixtures where needed. Record quality against criteria, step count, latency and cost under the provider's current pricing method. Do not choose a cheaper model if it breaks the task, or launch several agents for a small job without measuring the benefit.
Test timeouts, tool errors, missing information and invalid output. Set a step limit, bounded retries and a human escalation path. Expand a stable pilot according to evidence. The website-brief guide applies the same principles of objective, constraints and acceptance to project planning. The outcome is a workflow the business can understand, evaluate and operate, rather than an impressive demonstration with unknown failure behaviour.
Frequently asked questions
Are multiple agents needed from the start?
No. Add them for independent tasks with clear roles and verified benefit. A small workflow often needs fewer components, reducing cost and failure points while preserving quality checks.
References and further reading
To apply this to your current website, explore the AI agent setup service or contact Dean Vu to define a scope around your existing site and actual evidence.