Agentic Workflow Anti-Patterns: Orchestration Mistakes

Agentic workflow anti-patterns are the specific orchestration mistakes that turn a clean agent demo into a production outage. The model is rarely the problem in 2026 — capability is good enough. What takes the workflow down is hidden state, race conditions, un-bounded loops, over-broad tool scope, missing idempotency, blocking calls inside the loop, naïve retry, and a single-threaded orchestrator that becomes the bottleneck under real traffic.

This is a contrarian essay because the dominant agentic-workflow narrative in 2026 still emphasizes capability — newer models, longer context, deeper reasoning. None of that prevents the eight anti-patterns below. We have seen each of them in production at client engagements; we have written the incident postmortems; we have shipped the corrective patterns. The pattern repeats often enough that the value of cataloging it explicitly outweighs the risk of being seen as the team pointing out the obvious.

For each anti-pattern you will see the diagnostic signal (how to recognize it before it becomes an incident), a severity ranking (how badly it usually fails when it does fail), and the corrective pattern (what to ship instead). The companion resilience audit at the 70-point checklist grades a workflow against the positive-statement counterpart of each anti-pattern.

Every agentic workflow that takes down a production weekend started as a clean demo. The engineer wired three steps together in a notebook, fed it a canonical input, watched the model do something impressive, and shipped it behind a webhook. Three weeks later the first incident lands — a tool call hangs, a retry loop runs forever, a Slack channel fills with duplicates, and someone manually kills the process. The fix is never "use a better model." The fix is the orchestration layer that was never built.

This is the contrarian framing the rest of the essay rests on: capability rarely takes a workflow down in 2026. Orchestration does. Every anti-pattern below is a failure of orchestration — of how the agent is wired into the surrounding system, not of how the model reasons. Treating the agent layer as production infrastructure rather than a clever script is the only honest way past the prototype phase.

The eight anti-patterns are ranked by severity in the chart below — severity being the typical blast radius and recovery cost when the anti-pattern fails in production, not how common it is. Common and severe is the worst quadrant; that is where Sections 02 and 03 sit.

Hidden state is the orchestration anti-pattern with the highest blast radius and the lowest visibility before it fires. The agent reads or writes a piece of state that is not part of the workflow's declared inputs and outputs — a global variable, a module-level cache, a singleton client, a stale row in an external system. The state leaks across runs. When something triggers a retry, the agent does not see the input it thinks it sees, the result is non-deterministic, and the blast radius depends on which side-effects the hidden state was secretly controlling.

Diagnostic signal

The first symptom is almost always a retry that produces a different result than the original attempt against the same declared input. If your replay harness re-runs a captured trace and the agent makes a different decision, hidden state is the usual culprit. Other signals: workflow outputs that depend on the order of recent runs; agents that "work fine" in isolation but produce wrong answers under concurrency; behavior that flips after a process restart.

Severity

S0. Hidden state is the most expensive anti-pattern to debug because it is invisible by definition. Incident timelines on the engagements we have seen routinely stretch past 48 hours, with multiple false fixes deployed before someone notices the global-variable cache or the singleton client.

Corrective pattern

Every input the agent reads must be declared and captured in the trace; every output it writes must be declared and idempotent. No module-level mutable state. No singleton clients that hold per-tenant context. No reads from external systems without the specific row identifier appearing in the trace. The agent function should be a pure function of its declared inputs and the captured tool responses — if you cannot replay it deterministically, you have hidden state, even if you have not found it yet.

The race-condition anti-pattern appears the first time a workflow ships into a multi-tenant environment, or the first time two instances of the same workflow run concurrently against the same downstream resource. Each agent reads a resource, computes a new value, writes it back — and if two agents do this at the same time on the same resource, the second write silently overwrites the first. No error is raised; the data is simply wrong.

Diagnostic signal

Read–modify–write patterns against a shared database row, a shared file, a shared external resource, or a shared in-memory cache. Counts or aggregates that are slightly wrong in ways that do not show up in single-user tests. Customer-facing artifacts (briefings, invoices, communications) that occasionally reference the wrong tenant's data when traffic spikes.

Severity

S1. Race conditions are typically less catastrophic than hidden state because they tend to corrupt data within a narrow scope rather than triggering broad retry storms. They are equally hard to debug — the failure rate scales with concurrency, so the anti-pattern is invisible at demo scale and obvious at production scale. The cost ladder is data corruption first, customer incident second, audit-trail repair third.

Corrective pattern

Three options, in order of cost. First, optimistic concurrency control: every write includes the version of the row it expected to be updating, and the database rejects the write if the version has changed. Cheap, requires support in the storage layer. Second, pessimistic locking with a row-level or advisory-lock acquired before the read–modify–write block. Higher overhead, simpler reasoning. Third, redesign the workflow to eliminate the shared mutable state — use an append-only log instead of an in-place update, or partition the workflow by tenant so concurrent runs never touch the same row. The third option is the most resilient and the most work.

The un-bounded-loop anti-pattern shows up in two flavors. Flavor one: a tool call hangs and the agent waits forever — no wall-clock bound on the call, no bound on the stage, no bound on the workflow. Flavor two: the agent loops on a decision it cannot resolve — "try harder, the result still isn't right" — burning tokens on each iteration. Both flavors terminate either at the credit-card limit or when a human kills the process. Neither is a failure mode; both are spend incidents.

Diagnostic signal

A workflow that has been running for longer than its expected p99 duration with no explicit timeout. Tool calls without a stated timeout in the call site. A loop in the agent code with no maximum-iteration bound. Token-spend graphs with a long flat tail on the right side — agents that ran significantly longer than the median.

Severity

S0 for spend; S1 for outage. An un-bounded loop is the fastest way to burn a month of LLM budget in a single workflow run, and the spend incident is recoverable only by killing the process — no rollback exists. The outage severity is lower because most organizations notice the spend long before downstream effects propagate.

Corrective pattern

Three bounds, nested. End-to-end workflow timeout (typically 5–30 minutes depending on workflow class) terminates the whole run. Per-stage timeout (matched to p99 + 25–50% buffer) catches stuck stages before they consume the workflow budget. Per-tool timeout (shorter still, matched to each tool's latency profile) catches individual stuck calls. On top of the wall-clock bounds, a token-and-cost budget at the workflow level — total LLM spend and total tool spend capped, with the workflow terminated and the spend incident logged when the budget is consumed.

Tool-scope anti-patterns are the easiest mistake to make and the most dangerous when they fail. The pattern: an engineer wires a broad credential into an agent — a database connection with full read-write, an API key with admin scope, a filesystem handle rooted at the project base — because the agent "might need it." The agent gets a hallucinated tool argument exactly once, executes a destructive action against a production resource, and the team owns an incident with no rollback path. This is not theoretical; we have seen it.

Diagnostic signal

Count the tools wired into each agent. Count the distinct permissions those tools cumulatively expose. If the answer to either is "more than the agent strictly needs to complete its declared task," the anti-pattern is present. Other signals: a single agent that can both read and mutate the same sensitive resource; tool definitions with credentials passed in from the top of the workflow rather than scoped at the tool layer; absence of a least-privilege review for new tools.

Severity

S0. Tool over-broad scope is the only anti-pattern in this list that can produce a single-shot catastrophic incident — a destructive action against production data that has no rollback. Every other anti-pattern produces gradual or recoverable failures. This one can be terminal.

Corrective pattern: scoped vs broad tools

The matrix below contrasts scoped tool design against broad tool design across four dimensions. The right column is what most teams ship by default; the left column is what production agents should ship instead.

The corrective discipline is procedural: every new tool added to an agent goes through a least-privilege review before it ships. Three questions. What single capability does this tool expose? What is the smallest resource scope the credential needs? What is the blast radius if the agent calls this tool with the wrong arguments? If you cannot answer all three crisply, the tool is not ready for production. For broader background on the full resilience layer that scoped tools sit inside, see the 70-point resilience audit; for the subagent design discipline that frequently sits under agent toolsets, see the Claude Code custom-subagent guide.

Three more anti-patterns share a common shape: each is a mechanical mistake in how the agent is wired to the surrounding runtime, each shows up reliably in audits, and each has a well-understood corrective pattern that most teams skip because it adds friction before the first demo. The grid below summarizes each one — diagnostic signal, severity, corrective pattern — so you can grade your workflows in a single pass.

None of these three is exotic. None requires a new framework. Each is a well-documented engineering pattern lifted from traditional distributed-systems practice — idempotency from the payment-processing world, async-everywhere from high-throughput web servers, exponential backoff from every retry library shipped this decade. The reason they keep getting skipped in agent workflows is that the agent layer is often built by engineers approaching distributed systems for the first time, via the agentic-AI on-ramp. The contrarian takeaway is that agent reliability is mostly a distributed-systems problem wearing a new outfit; treating it as such is the fastest path past these three anti-patterns.

The final anti-pattern surfaces only at scale. The first seven are workflow-level mistakes — they fail in a single workflow run. This one is a system-level mistake — it fails when many workflow runs share the same orchestrator. The pattern: a single-process scheduler hands work to agents, holds the in-memory state of each in-flight workflow, and coordinates the retry, compensation, and observability paths. It works fine at 10 concurrent workflows, slows at 100, falls off a cliff at 1,000. The orchestrator becomes the bottleneck.

Diagnostic signal

Workflow start latency that climbs as concurrency climbs. Memory growth on the orchestrator process that tracks workflow count rather than per-workflow size. Restart-induced incidents where in-flight workflows are lost because state lived in memory. Time-to-first-step that lengthens during traffic spikes even though the agents themselves are not loaded.

Severity

S2 for most teams. The orchestrator bottleneck is a scaling cliff rather than a single-incident catastrophe — workflows degrade gracefully at first and the team usually has weeks of warning before the cliff. Severity climbs into S1 territory for teams running customer-facing real-time agent workflows where latency is a contract, not a preference.

Severity ranking across orchestrator architectures

The chart below ranks four common orchestrator architectures by the typical scaling ceiling we observe before the bottleneck anti-pattern forces a re-architecture. Severity is the cost of hitting the ceiling without warning — the longer the re-architecture, the worse the surprise.

The corrective pattern is architectural and the longest of the eight to ship. Move workflow state into durable storage so restarts do not lose in-flight runs. Move workflow execution into a worker pool so orchestrator capacity is decoupled from in-flight workflow count. Adopt a durable-execution platform (Temporal, Restate, Inngest, Vercel Workflow DevKit, or similar) so retry, compensation, and timeout primitives live in the platform rather than in scattered application code. Partition workflows by tenant so concurrent runs scale horizontally rather than competing for shared orchestrator attention. The full migration is typically a quarter of senior engineering time on a workflow that already exists; planning for it before the cliff hits is the difference between controlled re-architecture and emergency re-architecture.

For teams approaching this re-architecture for the first time, our AI transformation engagements cover the durable-execution adoption playbook alongside the seven workflow-level anti-patterns above. The architectural move is well-trodden by 2026; the trick is sequencing it against the team's current incident pressure rather than attempting a clean-room rebuild.