Most companies in 2026 have set up at least a handful of AI automations. Document processing, email triage, meeting summaries, simple data extraction from forms and reports. These work, they’re not hard to configure, and they provide visible value quickly. The organization sees the output and wants more.
The problem is that “more” means something different than they expect.
flowchart TD
A[Take action] --> B[Evaluate result]
B --> C{Decide next step}
C -->|Looks fine| A
C --> F1[Error propagation]
C --> F2[Ambiguous input]
C --> F3[Wrong-context output]
F1 --> E{Escalation protocol}
F2 --> E
F3 --> E
E -->|Owner + data scope + audit trail| R[Resolved safely]
E -->|Missing any| X[Invisible failure]
class R good
class X bad
classDef good fill:#163a26,stroke:#44cc77,color:#d7ffe6;
classDef bad fill:#3a1620,stroke:#ff5555,color:#ffd9d9;
classDef warn fill:#3a2e16,stroke:#ffaa33,color:#ffe9c7;
classDef accent fill:#15233b,stroke:#4488ff,color:#dce9ff;
What the First Phase Looks Like
The first phase of enterprise AI automation tends to be narrow and deterministic: take this input, run it through an AI model, produce this output. Document summarization is a common example. You provide a contract, you get a structured summary. The inputs and outputs are defined. If the output is detectably wrong, a human catches it in the review step. The failure mode is bounded.
This phase is achievable with off-the-shelf tools — most organizations have done it. The ROI is real. Even moderate productivity improvement on high-volume document work compounds quickly when the underlying volume is significant.
What the Second Phase Actually Is
The second phase is agentic: instead of a single prompt-output loop, the AI takes an action, evaluates the result, and decides what to do next. Greg Isenberg’s recent coverage of Hermes Agent — the MCP-powered desktop agent that lets AI handle multi-step workflows across applications — generated nearly 100,000 views in a week. The interest reflects a real market demand: organizations that have built the first round of automations and are ready to go further.
At the enterprise level, an agentic automation might look like this: research competitive intelligence from a defined source list → identify the five most relevant items based on defined criteria → draft structured summaries for each → log the completed batch → notify the appropriate team. Each step involves AI judgment. The agent is deciding what counts as “relevant,” how to structure the summary, and when the batch is complete.
The difference from the first phase is substantial.
Non-determinism compounds. In a single prompt-output automation, an error is isolated. In a multi-step agentic workflow, a mistake in step two propagates through steps three, four, and five before anyone reviews the output. The final result reflects compounding errors rather than a single detectable failure.
Failure modes are harder to anticipate. Deterministic automation fails in predictable ways. Agentic automation can fail in novel ways — the agent encounters an unexpected state, interprets ambiguous input in an unintended direction, or produces output that is technically correct from its perspective but contextually wrong. Designing for these failure modes requires thinking through the edge cases before they occur, not after.
Audit requirements are more complex. In regulated industries, the question of how a particular output was produced becomes harder to answer when it was produced by an agent running five sequential decisions with dynamic inputs. Most organizations haven’t built the logging infrastructure to reconstruct that trail. Most discover this need after the first audit question, not before.
The Sequencing Question
The most common mistake in enterprise AI automation is moving to agentic workflows before the foundational operating model is in place. Not the technical foundation — the organizational one.
That organizational foundation includes: explicit ownership for each automation (someone is responsible for monitoring outputs and responding to failures, and that person is named), defined escalation paths for when an automation produces output outside expected parameters, and logging that makes it possible to understand what the agent did and why.
None of this is technically complicated. It’s the organizational discipline that gets skipped when teams are moving fast and everything appears to be working. The teams that skip it and jump directly to agentic workflows tend to accumulate invisible failures — outputs that look fine until they don’t, and by that point the root cause is difficult to isolate.
The sequencing that works: establish ownership and monitoring discipline with the first-phase automations, then extend into agentic workflows once the operating model is proven. The first-phase automations are where you learn what your monitoring and escalation infrastructure actually needs to look like. The second phase is where you find out whether you built it correctly.
What Leadership Needs to Decide
Before an organization extends into agentic automation at scale, three decisions need explicit answers at the leadership level:
Who owns each automation as a function? If the answer is “whoever built it” or “the engineering team,” you don’t have ownership — you have distributed accountability, which is no accountability. A specific function or individual needs to be responsible for ongoing monitoring and response.
What data does this automation have access to, and is that scope appropriate? Agentic systems routinely access more data than single-step automations to complete multi-step tasks. The scope of that access needs to be intentionally defined, not defaulted to whatever the system can reach.
What is the escalation protocol when an automation produces unexpected output? Who is notified? On what timeline? What’s the remediation path? If the answer is “whoever notices it,” you don’t have a protocol — you have the assumption that someone will catch it.
These decisions don’t require a governance project. They require a few hours of structured decision-making with someone who has seen what happens when they’re skipped.
AI automation strategy is one of the engagements I work on directly with clients — both in designing first-phase automations correctly and in building the organizational model that supports moving to the next phase without accumulating the failures that tend to come from skipping that step.
