AI Agent or Fixed Workflow? A Business Decision Table

Use fixed rules when the valid steps and conditions can be specified in advance. Add an AI step when interpretation is useful but the surrounding process should remain predictable. Consider an agent when the next action genuinely depends on what it discovers, and you can still bound and verify its work.

This is a task-selection reference for business owners, reviewed September 14, 2026. The eight examples below are proposed design choices, not findings from a deployment study. They help identify where autonomy adds value and where it merely introduces another source of uncertainty.

In a rules-only process, software follows explicit conditions: validate a required field, calculate a known fee or route a record according to a documented status. The value is consistency. Using a model to rediscover a fixed rule on every run can add variation without improving the result.

An AI-assisted workflow keeps the sequence in code but uses a model at a specific point. For example, it might draft a reply from an approved knowledge base, then require a reviewer to approve it. The model interprets information; it does not choose every action the process can take.

An agent chooses steps or tools based on what it finds. Anthropic’s engineering guidance distinguishes predefined workflows from systems where a model dynamically directs its process. That distinction concerns control of the work, not whether the product’s marketing calls it an agent.

Start with the least complex form that can meet the requirement. These rows describe plausible starting designs. A business with different constraints may reasonably choose another design, provided it can explain what extra autonomy accomplishes and how the consequences are controlled.

The table uses task uncertainty and acceptance evidence rather than a maturity score. Do not total the rows into a readiness percentage. A single consequential weakness, such as an inability to verify a financial change, can matter more than several easy tasks that work well.

Uncertainty about the input is not the same as uncertainty about the process. A document can contain unfamiliar wording while the required output fields remain fixed. In that case, extraction plus validation may be sufficient. The model does not need freedom to email the customer or edit the source system.

By contrast, a software defect may require inspecting several possible causes before a fix can be chosen. The sequence cannot always be usefully written as a fixed list. An agent can help with that exploration, while tests and a constrained editing scope still bound the result.

Write the uncertainty in plain language. “We do not know which file contains the defect” is actionable. “We need agentic transformation” does not explain a design choice. Our transformation sequencing guide addresses when to introduce the selected workflow into a business.

A model that understands a customer request does not automatically have authority to execute it. Separate interpretation, recommendation and action. The system might identify that a refund request meets a documented category while a deterministic check or authorised person decides whether money can move.

This separation allows useful automation without handing every consequence to the model. A research agent can assemble evidence while a purchase still requires approval. A drafting workflow can prepare a customer message while the final recipient and send action remain explicit.

Define what happens when evidence is missing or contradictory. The correct output may be an unresolved case with a reason, not a best guess. Our approval-gate framework explains how to place these boundaries around consequential actions.

Choose representative examples, including awkward ones, and write the acceptance test before implementation. For a question-classification workflow, include ambiguous wording and requests outside the supported scope. Count correct routing and useful escalation, rather than only the proportion of requests that receive an automated answer.

Compare the added complexity with the accepted work it enables. Record maintenance, review effort and failure handling as well as model usage. If a fixed workflow handles the task reliably, adding autonomous planning should have a specific benefit that survives this comparison.

For AI transformation projects, the first deliverable can be a task map rather than an agent. It should identify known rules, interpretation needs, action authority and verification. This makes the implementation decision concrete enough to challenge before the business depends on it.

The agent-versus-workflow cost calculator provides a separate economic comparison after the required control structure is understood.

As-of date. September 14, 2026. Sources reviewed for this article; the article is dated September 13, 2026.

Method. Eight original task examples classified using predefined workflow versus dynamic agent control. Categories are editorial recommendations; no deployment outcomes, population estimates or success rates were measured.

Sources. Anthropic: building effective agents.

Limits. Not a universal prescription. Real authority, data sensitivity, reversibility and acceptance tests can change the appropriate design.

The three forms in the first section are confused in both directions: autonomy where a rule would do, and a rule where the task needed discovery. The illustrative designs below are each a plausible proposal that picked the wrong form. They are design examples, like the eight in the table, not deployment findings.

Each design is corrected by the same question the evaluation section asks: what does the extra autonomy accomplish, and how would we know the result is right?

The evaluation section says the first deliverable can be a task map rather than an agent. The map is a table with one row per task and four columns: the known rules, the interpretation the task needs, the action authority involved, and the verification available. The columns are the three forms of automation and the acceptance check, laid side by side so the design falls out of the row rather than out of a preference.

An illustrative map for a customer-enquiry process has four rows. Reject an incomplete form: known rules are the required fields; no interpretation; no action beyond a validation message; verification is a test set of forms. Classify the enquiry: no fixed rule; interpretation of free text; no action; verification is a labelled sample including ambiguous wording and out-of-scope requests. Draft a reply from the approved knowledge base: the sequence is fixed; the model interprets and drafts; the send action stays with a reviewer; verification is reviewer acceptance. Investigate why an order did not ship: the sequence cannot be written in advance; the model needs to discover which system holds the cause; read-only access to each system; verification is a confirmed cause and a bounded set of actions proposed, not taken.

Read down the columns and the design appears: a rule, an AI step inside a fixed workflow, an AI step with a human send, and a bounded agent with read-only authority. Where a row cannot be filled, especially the verification column, the honest output is an unresolved case with a reason, which the authority section asks for. The map is also what a vendor proposal can be checked against: a proposal that adds autonomy to a row whose unknown column is empty is adding uncertainty, not value.

Write the four-column map for the process you are most tempted to automate. The rows that need an agent are likely to be few and specific, and the rest are often cheaper and more reliable as rules with a model at one point.