If your team copies data between tools, you may need an integration. If it reads messages to assign categories, a workflow with an AI step may be enough. If each case requires investigation and a different sequence of queries, an agent is worth evaluating. I would establish that distinction before choosing a platform or requesting a quote.
Workflow, AI workflow or agent: what are you buying?
In a workflow, code defines the route. It can include branches, approvals and model calls without handing over control of the process. In an agent, the model chooses some of the next steps and tools based on what it finds. Anthropic's engineering guide to agents uses this distinction and recommends starting with the simplest solution that works.
Natural language input does not require autonomy. Classifying a message, extracting fields and queuing the result can all follow predefined steps. The useful question is whether the system needs to choose the route, rather than just interpret text.
Choose according to the business process
| Situation | First option to evaluate | What to check |
|---|---|---|
| Structured data and known rules | Workflow without AI | Handling of duplicates, missing fields and connection failures. |
| Variable text, fixed categories and actions | Workflow with AI classification or extraction | Errors by category and a review path for missing information. |
| Investigation requiring different queries for each case | Bounded agent inside a workflow | Whether tool selection improves resolution over a fixed route. |
| Changes to orders, payments or customer commitments | Execution controlled by rules and approvals | Who authorises it, which permissions apply and how repeats are prevented. |
| No process owner or definition of success | Clarify the process before automating | Who handles exceptions and recognises correctly completed work. |
Workflows also need maintenance. Agents can still end in human review. I would compare both on the same tasks, against the same acceptance criteria, including the time staff spend correcting their output.
A hypothetical example: from sales enquiry to CRM
Imagine a business receiving questions about products, delivery and availability. This is a proposed design, not a reported client outcome.
- Workflow: receive the enquiry, check for an existing record and assign an identifier. A rule determines the channel and team allowed to handle it.
- AI step: extract the product and reason for contact. Code validates the fields; unknown categories or conflicting data go to review. The guide to classifying buyer messages with AI covers this stage.
- Agent, if needed: investigate an exception by choosing whether to query the catalogue or order status through authorised read tools. Limit queries and elapsed time; hand the case to a person if no evidence is found.
- Closing workflow: validate the proposal, obtain any required approval and save the confirmed action to the CRM. Retrying the same job must not create a second opportunity.
If a fixed lookup and classification resolve the enquiries, I would leave out the third step. Generated text must not confirm stock or commercial terms without a valid source and the corresponding permissions.
Pilot checks that support a go or no-go decision
Before building, I would agree on what counts as a resolved task and prepare representative examples with expected outcomes reviewed by the team. Include common requests, missing information, contradictions and tool failures. Keep some cases separate from those used to tune prompts.
- Outcome: measure tasks accepted by the process owner, broken down by type. A fluent response does not prove that the work was completed correctly.
- Intervention: record escalations, corrections and review minutes. A growing manual queue is a reason to revisit scope.
- Boundaries: test malicious instructions inside messages or documents, access to another customer's data and actions outside permissions. Enforce restrictions in tools as well as prompts.
- Recovery: simulate a timeout after a write, invalid output and an unavailable provider. Check that work is retained and a retry does not repeat an external effect.
- Decision: set thresholds by task type before seeing the results, name an approver and provide a route back to manual work.
I would start the pilot without sending replies or changing systems: staff compare its proposals with actual work. Enable only the actions that meet the agreed criteria afterwards. There is no universal accuracy percentage that authorises every business process.
Compare running costs and maintenance
Separate build costs, operations and changes. Building includes system integration, permissions and evaluation preparation. Operations include models, tools, infrastructure, retries, human review and incident handling. Changes include maintaining rules, connectors, prompts and evaluations as the business evolves.
To compare options, I would divide the total operating cost for a period by the tasks accepted during that period. Failed attempts and review work remain in the cost; unresolved tasks do not count as completed. Track resolution time and the pending queue too. Without that context, a low cost per model call tells you little.
Write down who maintains the workflow, reviews exceptions and approves changes. Each change to a prompt, model, tool or rule should be testable and reversible. Use the software and automation quote checklist to prepare comparable proposals.
Production controls and operational evidence
I would separate intake, interpretation, proposal, validation and execution. Each job needs a visible state, limited permissions, a retry budget and a review path. Record minimised inputs, sources, versions, calls, approvals and outcomes under defined access and retention rules. Good prompts help; prompts for repetitive business processes do not replace those controls.
The Adslyfy case shows execution states, attempts and evidence through sanitised screenshots. It illustrates the operational visibility I look for when building systems, rather than claiming results from AI agents.
What to bring to an initial technical discussion
To assess a custom automation and applied AI project, I would prepare this brief:
- One specific process, its tools and the people doing the work today.
- Approximate volume and anonymised examples of normal tasks and exceptions.
- Allowed actions, actions requiring approval and the consequences of an error.
- Acceptance criteria, available review time and a pilot owner.
- Possible system access and maintenance constraints.
With that information, I can assess where a workflow is sufficient, where AI fits and what we would need to demonstrate before allowing more autonomy. If you are weighing that decision, tell me about the process you want to automate.