Agent, Automation, or Ordinary Software?

Not every process needs an agent. Many do not need AI at all.

The right question is not, “Could a model do this?” A capable model can participate in almost any information workflow. The right question is, “What is the least complicated system that can complete this job reliably under its actual variability?”

That question produces three broad answers: ordinary software, deterministic automation, or an agentic system.

Start with variability

Ordinary software is strongest when the user is making decisions and the application needs to store state, enforce rules, calculate, organize, and present information.

Deterministic automation is strongest when the path is known: when this event happens, validate these fields, transform this data, update that system, and notify this person.

An agent becomes relevant when the path varies and selecting the next useful action requires interpreting context.

| Condition | Ordinary software | Automation | Agent | | --- | --- | --- | --- | | Path through the work | Chosen by user | Predetermined | Selected from context | | Inputs | Structured | Structured or normalized | Variable and partly unstructured | | Rules | Explicit | Explicit | Mix of rules and judgment | | Failure handling | User resolves | Programmed branches | Interprets, retries, or escalates within bounds | | Best evidence | Correct state and calculations | Correct execution | Verified task completion |

These categories can coexist. A strong agentic product still uses ordinary software for state and interface and deterministic code for rules, calculations, permissions, and irreversible actions.

Use code for what code knows

If a value must equal the sum of approved line items, calculate it. Do not ask a language model.

If a request must be rejected when a required field is absent, validate it. Do not ask a language model whether the request “seems complete.”

If an action is authorized only for one role, enforce the permission in the tool. Do not tell the model to remember the policy.

Models are valuable where the input cannot be fully anticipated: interpreting a request, classifying an unusual document, comparing evidence, planning across several available tools, or drafting a context-sensitive response. The deterministic system should surround that judgment.

The agent test

An agent is a reasonable candidate when all of these are true:

The job has a clear outcome.
The path to the outcome varies meaningfully.
A competent person can judge whether the outcome is correct.
The required tools can be exposed through narrow contracts.
The system can observe the state needed to verify completion.
Failure can be stopped, reversed, or escalated.

If the job has no clear outcome, an agent has no stable target. If the tools are broad, the risk comes from access rather than intelligence. If completion cannot be observed, the agent’s confidence becomes the only evidence, and that is not enough.

Examples

Monthly reporting package

The calculations, period selection, entity hierarchy, and formatting should be deterministic. A model may help explain material movement, compare narrative context, and draft commentary. An agent may coordinate missing inputs and route exceptions if the process spans several people and systems.

The final system is mostly reporting software and automation, with model-assisted interpretation where language and context vary.

Incoming customer request

If the request maps to five known categories, classify it with rules or a small model and route it. If resolving it requires searching account history, reading policy, choosing among tools, preparing an action, and escalating unusual cases, a bounded agent may be useful.

The authority should follow the risk. Reading context may be automatic. Issuing a credit may require approval. Closing the case should require verification that the underlying action succeeded.

Document extraction

Extraction from variable documents may require a model. Cross-field validation, totals, required fields, and downstream mappings should be code. Review routing should follow explicit confidence and business rules. An “agent” is unnecessary unless the process requires choosing among several follow-up actions based on the extracted evidence.

Autonomy is not the goal

Teams sometimes measure progress by removing humans from the loop. That is a poor universal objective.

The objective is a better operating result. A ten-second approval may be the cheapest control in the system. A person may be essential where policy is ambiguous, the consequence is material, or the organization wants accountability to remain explicit.

Anthropic’s guidance on trustworthy agents emphasizes that autonomy introduces risk because agents act with less oversight and can misread intent or be manipulated through prompt injection. The response is not to avoid agents. It is to bound tools, access, and action based on the work.

A useful architecture pattern

For many operational systems, the clean shape is:

Application state records the case and current step.
Rules validate permissions, required data, and irreversible actions.
Model judgment interprets variable material or proposes a next action.
Tools expose narrow reads and writes.
Verification checks the resulting system state.
Review handles exceptions and consequential decisions.
Evaluation measures the task across representative cases.

This pattern is less magical than an autonomous assistant. That is a strength. Each layer can be inspected, tested, and changed without pretending the model is the application.

Choose the boring answer when it works

The strongest engineering decision may be a form, a database table, and three explicit rules. It may be a queue and a worker. It may be a search index with good filters. It may be an agent.

Choosing the smallest adequate mechanism has several benefits: lower cost, lower latency, easier testing, clearer failure, and fewer surprises when the model changes.

Use AI where variability requires learned judgment. Use an agent where that judgment must choose and verify a sequence of actions. Use ordinary software everywhere else.

That is not a retreat from advanced capability. It is how advanced capability becomes dependable.

Design the handoff before the happy path

The clearest sign of a mature system is not how confidently it begins. It is how well it behaves when the work stops matching expectations.

Suppose an operational agent is asked to prepare a customer renewal package. It gathers account history, checks current terms, summarizes open support issues, and drafts a recommended path. Halfway through, it discovers that the contract in the document store conflicts with a date in the CRM.

A weak implementation chooses one source, continues, and presents a polished answer. A safer implementation recognizes that the conflict changes the job. It records both values, identifies the source of each, pauses the consequential recommendation, and routes a small, legible question to the account owner. When the person resolves the conflict, the system resumes from durable state rather than starting again.

That handoff needs product design. The reviewer should see:

what the system was trying to accomplish;
what has already been read or changed;
the exact evidence behind the conflict;
the narrow decision needed from the person;
what will happen after approval;
how to reject or revise the proposed action.

If the human review surface is an afterthought, the supposed safety mechanism becomes another source of work. People receive vague approval requests, reconstruct context from logs, and eventually approve by habit. A nominal human in the loop is not the same as useful human control.

Think in authority levels

Autonomy is easier to reason about as a ladder than a switch.

At the first level, the system observes and organizes. It may classify requests, collect relevant records, or explain what changed. At the second, it proposes an action but cannot execute it. At the third, it can act on reversible, low-consequence steps and asks for approval elsewhere. At the fourth, it completes a bounded workflow independently while producing a record for review. Some work should never move beyond the first or second level.

Authority can differ by tool, customer, amount, data type, and confidence. An agent may be allowed to create a draft record but not publish it, schedule an internal follow-up but not contact a customer, or issue a refund below a policy threshold but escalate an unusual pattern. This is usually more useful than assigning one autonomy level to the entire product.

The level should be earned through evidence. Start with observation. Compare proposals with expert decisions. Measure correction patterns. Allow reversible actions. Review failures. Expand authority only where the cost of failure, quality of verification, and recovery path support it.

This also creates a better adoption path. Teams can learn where the system helps without being asked to trust everything at once. Operators often have good reasons for caution: they know the exceptions hidden by a clean process diagram. A staged authority model treats that knowledge as part of the design rather than resistance to be overcome.

The selection rule

Use ordinary software for known states and exact rules. Use automation to connect repeatable work across systems. Use an agent when a bounded job contains meaningful variability that can still be observed and evaluated. Combine them when the workflow requires all three.

The goal is not to make the architecture sound advanced. It is to leave the people responsible for the outcome with a system they can understand when the normal case stops being normal.