Start with the job, not the label

A business rarely begins with a clean technical category. It begins with a complaint: staff copy information between systems, reports take a day to prepare, customers wait for an answer, or payments are followed up inconsistently. Calling the answer “AI” too early hides the useful engineering questions. What information enters the process? Which decisions are genuinely variable? Which actions must always follow the same rule? Who is responsible when the result is wrong?

Normal automation and AI agents solve different parts of that picture. Automation is strongest when inputs, rules and valid state transitions can be described clearly. Agents become interesting when the task requires interpretation, relevant context or flexible coordination across tools. A dependable system often uses both, with the boundary made visible rather than blended into one prompt.

What normal automation does well

Conventional software is exceptionally good at repeatable work. A database can enforce uniqueness. A rules engine can calculate an account status. An integration can copy an approved field from one system to another. A scheduler can trigger a reminder. An authorization service can decide whether a person may view or change a record. None of these tasks becomes better because a language model is inserted into the path.

Deterministic code is easier to test exhaustively, faster to run and simpler to explain after an incident. It can preserve invariants such as “a refund may not exceed the captured payment” or “only a finance approver can release this transaction.” It also gives engineers a stable place to handle retries, idempotency, reconciliation and rollback. These are not secondary concerns. They are what turn a successful demo into dependable business software.

  • Calculations, validation and required field checks
  • Identity, roles, permissions and access boundaries
  • Known workflow transitions and service-level timers
  • API synchronisation with explicit data contracts
  • Payments, bookings and other side effects that must not be repeated
  • Audit records and retention rules

Where an agent may earn its place

Some work cannot be reduced to a short list of stable rules without losing the value of human judgement. A support request may describe the same issue in many ways. A sales enquiry may need relevant details gathered from an email, CRM record and previous conversation. A finance follow-up may require a different tone because the customer has already disputed an invoice. In these cases, the system needs to interpret meaning and assemble the context that changes the next useful step.

That does not give an agent unlimited authority. The agent can classify a request, find relevant records, prepare a structured summary or draft a message. Normal software still decides which records are accessible, whether the proposed transition is valid and whether approval is required. The agent adds flexible reasoning inside a dependable application boundary.

A payment follow-up example

Consider the question “Who has not paid this month?” The calculation should not be left to a model. Application code should identify the account scope, invoice dates, payment status, agreed grace periods and any formally recorded payment plan. Those facts should produce a traceable list. If the list is wrong, the team needs to see which source or rule caused the error.

An agent can help after that list exists. It can review previous communication, identify a dispute or promise that changes the follow-up, and prepare a suitable draft. It can explain why it selected a particular template and surface cases where context is incomplete. A person or policy can approve external communication. After approval, a deterministic command sends the message once and records the action in the CRM.

payment state → deterministic overdue list → context review → draft proposal → approval → idempotent send → audit event

The failure modes are different

Automation usually fails because an input is missing, a contract changed, a dependency is unavailable or an unhandled branch reached the workflow. These failures can often be detected with schema validation, monitoring, retries and reconciliation. Agent behaviour adds another class of uncertainty: the output can be plausible but wrong, context can be irrelevant, a tool can be selected poorly or a generated explanation can overstate what the evidence supports.

The control system should reflect those differences. Deterministic components need unit, integration and state-transition tests. Agent components need representative task datasets, retrieval evaluation, structured-output validation, policy checks and review of errors by category. End-to-end tests still matter because a correct model response can produce a bad operational outcome when combined with stale state or a poorly designed tool.

A practical decision framework

Before adding an agent, write down the current task and ask how a competent person performs it. Separate the steps that are always the same from the steps where a person interprets incomplete or changing information. Then identify the consequence of a wrong answer. Low-risk preparation and summarisation may tolerate a different control level from payments, contractual communication or changes to customer records.

An agent is a stronger candidate when the task has meaningful variation, useful context is available, tools can be bounded and quality can be measured. It is a weaker candidate when the rule is already known, the data is too poor to support the decision, no one can define a good result or the only justification is that an AI demonstration would look impressive.

  • Can the rule be written clearly and tested with examples?
  • Does meaning or changing context alter the correct next step?
  • What information is required, and may the system access it?
  • What is the cost of a wrong classification, draft or action?
  • Where should a person review, correct or take over?
  • What evidence would show the new system is better than the current process?

Keep authority outside the model

A useful architecture treats model output as a proposal, not an authority. The application supplies a bounded task and relevant context. The model returns a structured result. Policy code validates the requested operation, current identity, resource scope and approval requirement. A tool or domain service performs the action and emits an audit event. This pattern makes it possible to replace the model without moving business rules or permissions into a new prompt.

It also makes observation clearer. The team can distinguish a retrieval failure from a reasoning failure, a policy rejection from a tool outage and an approval delay from an execution error. Those categories lead to different fixes. Without boundaries, every problem is described as “the agent got it wrong,” which is too vague to improve the system.

Measure the whole workflow

Model accuracy is only one measure. The business cares whether work finishes sooner, whether staff correct fewer mistakes, whether customers receive appropriate answers and whether exceptions become easier to see. A system that produces excellent drafts but adds a slow approval queue may not improve the operation. An automation that saves time but silently duplicates records is not successful either.

Establish a baseline before changing the process. Record volume, handling time, common failure categories, rework and the decisions people find hardest. During a pilot, compare the same measures and review errors in context. Include cost per completed task, not only cost per model call, because integration, human review and incident handling are part of the product.

Use draft mode before action mode

A sensible first release often observes or prepares work without taking external action. The system can create an overdue list, classify requests or draft follow-ups while the existing process remains authoritative. Reviewers then compare the output with what they would have done, identify missing context and build an error dataset from real cases.

Only after the team understands quality and failure should it consider low-risk automatic actions. Even then, authority can be graduated by action type, confidence, customer segment, value or environment. A successful pilot is not an argument for removing all approval. It is evidence for changing a specific boundary with known risk.

The useful answer is usually a system

The choice is rarely “automation or agent” for an entire product. A dependable application combines a data model, interfaces, integrations, rules, permissions, observation and selected reasoning. Normal software gives the operation stable ground. Agents help where meaning, context and tool coordination make rigid rules inadequate.

That is why “not everything needs AI” is an engineering principle rather than a conservative slogan. Removing an unnecessary model call can improve speed, privacy, cost and reliability. Adding a well-bounded agent can make previously awkward work practical. The job is to put each technique where it earns its place and to make the boundary understandable to the people responsible for the outcome.