A decision framework for separating deterministic workflows, AI-assisted steps, and genuinely agentic work.
Three different systems often share one label
“Agent” has become a convenient name for almost any software that calls a model. That blurs important engineering choices. A deterministic automation follows an explicit path: when an invoice is approved, create an accounting entry and notify the owner. An AI-assisted workflow uses a model for one bounded judgment, such as classifying the invoice or extracting irregular fields. An agent chooses among actions, observes results, and adapts its next step toward a goal.
These are not maturity levels where every workflow should eventually become agentic. They are different control structures. The more freedom a system has to plan and act, the harder it becomes to predict cost, timing, and failure behavior. That trade can be worthwhile when paths genuinely vary, but it is wasteful when a normal state machine already expresses the work.
Prefer determinism when the business already knows the path
Traditional automation is easier to test, replay, audit, and explain. It is the right default for fixed approvals, calculations, record synchronization, scheduled jobs, and compliance checks with explicit rules. Adding a model to those steps introduces probabilistic output without necessarily adding information. It can also hide a process problem behind apparently flexible behavior.
- Choose rules or code when the same valid inputs should always produce the same action.
- Choose an AI-assisted step when language, documents, or fuzzy categories prevent reliable fixed rules.
- Consider an agent when the sequence of useful actions changes based on intermediate observations.
- Keep a human decision when consequences are high and neither evidence nor policy supports delegation.
Agentic behavior earns its place on variable paths
An agent becomes useful when it must inspect a situation, choose a tool, interpret the observation, and decide what to do next. Investigating a service incident, assembling research across heterogeneous sources, or resolving an account exception can have this shape. Even then, the goal should be narrower than “handle operations.” A bounded goal makes it possible to define available tools, maximum effort, and a finish condition.
Start by drawing the possible action loop. List what the agent can read, what it can change, and which observations can be trusted. Separate reversible actions, such as drafting a message, from consequential ones, such as changing a price or revoking access. A capable model does not remove the need for domain authorization. The tool layer should enforce policy even if the model asks for something outside its remit.
Design the control surfaces before the happy path
- Constrain the tools
Expose narrow, schema-validated operations instead of general database, browser, or shell access. Check authorization inside each tool.
- Set effort budgets
Limit turns, elapsed time, model spend, retrieved context, and repeated actions so a confused loop ends predictably.
- Create approval boundaries
Require explicit confirmation for irreversible, external, financial, security-sensitive, or customer-visible actions.
- Preserve a legible trace
Record goals, tool requests, tool results, decisions, and final status with appropriate redaction and retention controls.
- Define recovery
Make partial work idempotent where possible, and provide operators with retry, resume, cancel, and rollback paths.
Use a portfolio of control styles
The strongest design is often hybrid. A deterministic workflow owns state transitions and policy, a model interprets an unstructured input, and a small agent loop gathers missing context before returning a proposed action for approval. Each component does the work it can express well. The system remains observable because state and authority do not live only inside a conversation transcript.
When comparing options, measure the complete operating burden: exception handling, evaluation, latency, review effort, and the cost of a wrong action. A simple automation that covers most cases and routes exceptions to people may outperform a sophisticated agent in both reliability and value. The right question is not whether a workflow can use an agent. It is whether adaptive planning creates enough benefit to justify the additional uncertainty.