Deck: Choose the least complex operating pattern that can do the job safely—and prove it before adding autonomy.

CTA: Download the [Cortex Agent-or-Workflow Decision Card](../products/freebies/cortex-agent-or-workflow-decision-card-2026-09-21.md) before selecting a model, connector, or automation platform.

The first AI decision is not which model to buy

It is whether the job needs an agent at all.

That sounds obvious. It is not how most AI projects begin. Teams start with a demo, a platform catalogue, or a request to “add an agent” to a process that has not been described clearly enough to automate.

The result is predictable: more tools, more permissions, more latency, more places to debug, and no clean answer to the question that matters—did the work actually get better?

The better starting point is architectural classification. Is this a repeatable path with known inputs and approvals? Is it genuinely open-ended work where the system must decide what to do next? Or is the boundary still too unclear to automate safely?

“Agent” should not be a prestige label for a messy process. It should be a precise answer to a real operating problem.

What happened: workflows and agents are different operating patterns

Anthropic draws a useful distinction. A workflow uses predefined code paths to orchestrate language models and tools. An agent dynamically directs its own process and tool use.

That difference is practical, not semantic.

A workflow might take an incoming support request, classify it, retrieve the relevant policy, draft a response, and route the result to a reviewer. The path is known. The handoffs can be tested. The stop condition can be written down.

An agent might investigate an unfamiliar customer problem, choose which systems to inspect, decide which tools to call, gather evidence, and determine when it has enough information to recommend a next step. The path changes with the case.

Neither pattern is automatically better. The mistake is choosing the more flexible one before the work has earned that flexibility.

Why it matters: complexity is an operating cost

Agents can be valuable when the number and order of steps cannot be predicted in advance. They can select tools, adapt to changing information, and continue through a task that does not fit a fixed path.

But that flexibility has a bill. It can increase cost, latency, debugging difficulty, and the chance that an error compounds across several decisions. The more consequential the action, the more expensive an unclear boundary becomes.

Anthropic’s guidance is blunt: start with the simplest solution that works, and add complexity only when it demonstrably improves the outcome. That is good advice for a small business even if the team never uses Anthropic’s products.

Microsoft’s 2026 Work Trend Index points to the organizational version of the same problem. As AI and agents take on more execution, leaders have to redesign work and decide what humans and AI do. The opportunity is not created by assigning “agent” to every task. It is created by making the division of labor explicit.

The architecture choice is therefore an operating-model decision. It determines who owns the result, what permissions are needed, what evidence survives each run, and how a human intervenes when the case falls outside the expected path.

The practical test: classify the work before you configure the stack

Run these five questions against the proposed use case:

1. Are the steps repeatable and known in advance? If yes, that is a workflow signal. 2. Can you list the required inputs, tools, and decision points now? If yes, start with a workflow. 3. Do exceptions require judgment across changing information? If yes, an agent may be justified. 4. Must every run be predictable and easy to audit? If yes, prefer a workflow or a human-led process. 5. Would flexible tool selection materially improve the result? If no, do not pay for it.

Do not turn this into a procurement score. The point is to expose the assumption hiding inside the word “agent,” then make the smallest defensible architecture choice.

Choose a workflow when:

  • the trigger and desired output are clear;
  • the path can be decomposed into named steps;
  • consistency and reviewability matter more than exploration;
  • a reviewer can define what good looks like.

Your first proof should include three normal cases and two boundary cases. Compare output quality, review time, correction work, and exceptions against the current process. If the workflow cannot beat the current process after review and correction, it has not earned a wider rollout.

Choose an agent when:

  • the task is open-ended enough that a fixed path would break frequently;
  • the system must select or sequence tools dynamically;
  • the value of flexibility is greater than the cost of additional control;
  • you can cap permissions, retain evidence, and test out-of-scope behavior.

Your first proof should be narrow: one normal case, one unfamiliar case, explicit tool limits, a named reviewer, retained evidence, and a stop condition. If you cannot explain how the system fails safely, you are still designing the use case—not releasing an agent.

Choose human-led work when:

  • the boundary is unclear;
  • the cost of a wrong action is high and no qualified reviewer is available;
  • the work is too infrequent to justify a maintained system;
  • you cannot describe the fallback when the system is uncertain.

“Do not automate yet” is a valid architecture decision. It is often more disciplined than launching a system whose owner, proof metric, and recovery path exist only in a slide deck.

The opinionated take: earn autonomy in stages

Most teams should start one level simpler than their first instinct.

If the use case looks like an agent, first ask whether a workflow can handle the high-volume path while routing genuinely unusual cases to a person. That design often creates a better learning loop: the team sees which exceptions repeat, which inputs are missing, and where flexibility would actually pay for itself.

Autonomy should be earned by evidence, not granted by ambition.

Before release, write down six things:

  • the recommended pattern: workflow, agent, or human-led;
  • the human reviewer;
  • the stop trigger;
  • the evidence retained per run;
  • the proof metric;
  • the manual fallback.

If any of those fields is blank, the system is not ready for more complexity. Narrow it, hold it, or keep the work human-led until the missing control exists. Complexity is not progress when nobody can explain who owns the outcome after the run goes wrong.

The takeaway for operators

Do not buy an agent because the task sounds important. Do not reject an agent because a workflow is easier to explain. Choose the smallest operating pattern that can produce useful work with a clear owner and a safe recovery path.

Classify the job first. Prove the workflow where the path is repeatable. Introduce agent flexibility only where fixed steps genuinely fail. Keep high-impact actions behind explicit human gates.

The best first AI use case is not the one with the most autonomy. It is the one that can show, in a small and honest test, why its chosen architecture deserves to exist—and what would make you narrow or stop it.

Sources

  • [Anthropic, “Building effective agents”](https://www.anthropic.com/engineering/building-effective-agents)
  • [Microsoft Work Trend Index 2026: Agents, human agency, and opportunity](https://www.microsoft.com/en-us/worklab/work-trend-index/agents-human-agency-and-the-opportunity-for-every-organization)