AI agent, automation or ordinary software: what do you actually need?

The labels can hide the real engineering decision

Teams are often encouraged to “build an agent” before anyone has described the work precisely. Yet many useful business systems need a mixture of ordinary software, deterministic automation and a carefully bounded AI-assisted step. Choosing the most fashionable label first can add uncertainty, cost and operational risk without improving the outcome.

Begin with the process: what starts it, which information is available, what decision or output is required, which actions may occur and who remains accountable. Then choose the least complex approach that can handle the variable parts of the work.

The categories in this article are practical rather than absolute. Products use the terms differently, and real systems combine techniques. The important distinction is how much behaviour is explicitly defined, how variable the input is and how much freedom the system has to choose actions.

Use ordinary software for explicit rules and dependable state

Ordinary software is the right foundation when inputs are structured, rules are known and the same condition should produce the same result. Calculations, permissions, record updates, validation, scheduling, form workflows and most core business state benefit from predictable behaviour.

For example, a system that checks whether required onboarding fields are complete does not need a language model if the requirements can be represented as rules. A pricing calculation should not be generated from prose when it can be implemented and tested directly. Authentication and access control should remain explicit even if an AI feature sits elsewhere in the product.

Deterministic software is easier to test exhaustively, explain and monitor for these jobs. It is not a less ambitious choice. It creates the reliable boundaries within which more variable assistance can operate.

Use deterministic automation to connect known steps

Automation coordinates repeatable actions across time or systems: when a form is submitted, create a record, notify an owner and schedule a reminder. The path is defined in advance, even if it contains conditions and retry behaviour.

This approach is well suited to moving structured data between systems, applying business rules, generating standard documents from known fields and triggering approved communications. The difficult engineering is often not the visual flow builder; it is permissions, duplicate events, unavailable dependencies, error recovery and visibility when a step fails.

Use an automation platform when it provides suitable connectors and the workflow can be operated safely there. Use custom software when the logic, scale, user experience or control requirements justify it. Either way, document the owner and fallback rather than creating a chain that nobody notices until it stops.

Use an AI-assisted step for bounded interpretation or drafting

AI models can help when a narrow step involves variable language or other unstructured input. Examples include proposing a category for an enquiry, extracting draft actions from approved meeting notes, retrieving relevant internal material or preparing a first response for review.

The surrounding workflow should still define the allowed inputs, output structure, permissions, review point and exception route. Wherever possible, ordinary software should validate required fields and permitted actions. The model's job should be narrow enough that a person or another control can evaluate the result.

Do not use a fluent answer as proof that the source was correct or the task was completed. Show provenance where useful, surface missing information and prevent the assisted step from quietly acquiring broader permissions.

• The input varies in language or format.
• The desired output is bounded and reviewable.
• A reasonable fallback exists when the model is uncertain.
• The workflow can tolerate variation before approval.
• The information and vendor are approved for the purpose.

Use an agent only when choosing among actions creates real value

An agent generally has some ability to plan, select tools or decide which step comes next. That flexibility can help when the route cannot be fully defined in advance—for example, investigating an operational issue across several approved sources and proposing a next action.

Flexibility also expands the behaviour that must be controlled. Define which tools the agent may use, which records it may read, whether it may write, spending or action limits, stopping conditions and the situations that require approval. Treat every tool as a permissioned capability rather than giving broad access for convenience.

An agent is a poor substitute for an undefined process. If people cannot agree on the goal, acceptable sources or escalation path, additional autonomy will make the ambiguity harder to observe. Start with assistance or a fixed workflow, learn from real exceptions and only add freedom where repeated evidence shows that predetermined routing is the actual constraint.

Use this decision tree

First ask whether the required behaviour can be expressed as stable rules. If yes, use ordinary software. If several known actions need to be coordinated, add deterministic automation. If a bounded step must interpret variable language or prepare a draft, add AI assistance inside that defined workflow.

Only consider an agent when the system must choose among multiple permitted routes, that choice cannot be represented reliably with ordinary rules, and the value justifies stronger monitoring and controls. Even then, retain deterministic boundaries around identity, permissions, validation and consequential effects.

1. Can the task be defined as rules over structured inputs? Use ordinary software.
2. Does it connect a known sequence of systems or events? Use automation.
3. Does one bounded step require interpretation or drafting? Add AI assistance.
4. Must the system select among several permitted actions? Evaluate an agent.
5. Can a simpler design produce the same useful outcome? Prefer the simpler design.

A practical workflow is usually hybrid

Consider an enquiry workflow. Ordinary software receives the form, validates required fields and stores the record. An AI-assisted step proposes a category and response using an approved knowledge source. Deterministic rules route low-confidence or sensitive categories to a specialist. A person reviews the source, classification and draft. After approval, automation sends the response and records the event.

There is no need for a general agent in that design. If later evidence shows that reviewers repeatedly research several internal systems and choose among variable next steps, a tightly permissioned agent might assist that investigation. The case should be made from observed work, not from the desire to use agent technology.

Compare operating qualities, not demo quality

For each design, compare reliability, explainability, latency, cost, information handling, testability and the effort required to operate it. A flexible system may handle more variations but cost more to evaluate and supervise. A deterministic workflow may be narrower but easier to trust and maintain.

Test representative inputs and difficult cases. Record corrections, exceptions and tool failures. Confirm that the system can be paused and that external actions cannot exceed their permissions. Review vendor behaviour and costs over time rather than assuming the first configuration will remain suitable.

This material is general implementation information and not legal, privacy, cyber-security or regulatory advice. Controls and professional review should be matched to the organisation and consequences involved.

Build the least complex system that does the work well

A reliable product does not earn extra value for containing an agent. Value comes from improving the work while keeping responsibility and operating cost clear. Ordinary software, automation and AI are complementary tools, not a ladder of sophistication.

Map the process, isolate the variable step and add autonomy only where it solves an observed constraint. That approach may sound less dramatic than an autonomous-everything promise, but it creates a stronger path from demonstration to dependable operation.