Enterprise process automation in 2026: the fail-safe layer no vendor talks about.

1. The 2026 shift: reliability over capability

For five years the EPA story was about capability. Could the agent read a PDF, drive a SAP GUI, fill an Oracle Forms screen, hand a row to Excel, escalate to a human, sign a JWT? By 2026 the answer to all of those is yes, from at least four serious vendors. The buying conversation has moved.

Adam Glaser, Appian's VP of product, summarized the shift this way at Appian World 2026: building agents is no longer the hard part; keeping them accurate, auditable, and useful on live business workflows is. The 40% Gartner forecast (40% of enterprise applications will embed task-specific AI agents by end of 2026, up from less than 5% in 2025) only matters if the embedded agents stay reliable past the demo. The platforms whose 2025 pilots are now in production all share the same property. They have a fail-safe layer. The platforms whose 2025 pilots stalled at the first quarterly review do not.

The fail-safe layer is the part nobody puts on a feature page, because it sounds like the absence of capability rather than the presence of one. A lot of vendor copy talks about scale, intelligence, orchestration, and self-healing. Almost none of it shows the SQL query that decides when a stuck workflow gets killed, or the substring list that decides whether an error is transient. The system property that decides whether an EPA program survives is the system property most marketing pages refuse to surface.

2. Three failure modes that kill EPA programs

The post-mortems on stalled EPA programs land on the same three failure modes, in roughly the same order.

One: every flake becomes a ticket. The bots get built, the workflows ship, and the failure layer does not. A 503 from the target system, a VPN reconnect that drops the session, a window-focus loss while a user moves the mouse, all of these mark the workflow failed. Each one creates an ops ticket that turns out to be transient and self-resolved within a minute. By month two, ops is spending 30 percent of its time triaging tickets that did not need triage. The platform looks unreliable; the underlying infrastructure is fine.

Two: the retry layer corrupts data. Ops asks for retries and the platform adds them. Now the 503 self-heals. So does the validation error: the bot resubmits the same bad input five times before failing, and downstream systems record five duplicate rows. Or the permission-denied error retries until the lockout policy locks the service account, taking down every other workflow using it. Retrying everything is worse than retrying nothing, because the failures it does not heal it amplifies.

Three: the dashboard goes red and stays red. Both of the above get fixed. The classifier exists; retries respect it; the failure rate drops 95 percent. Then the target system goes down for a Sunday-night maintenance window, the cron-scheduled workflow fires every minute against the dead endpoint, and by Monday morning the dashboard has 1,440 identical red rows. The team learns to ignore the dashboard. The next real incident, two weeks later, sits in the noise for six hours before someone notices. The fail-safe layer is incomplete unless it knows when to stop.

3. What the fail-safe layer actually contains

Three primitives, one for each of the three failure modes above. None of them are exotic. All of them have to be code-reviewable, in the path of every execution, with constants the buyer can read before signing.

Primitive A: an error classifier. Every error message that comes off an executed step gets categorized into one of a small fixed set: infrastructure (transient, retry), workflow logic (deterministic, do not retry), unknown (be conservative, do not retry). The classifier is the boundary between modes one and two above. Without it, you either retry everything or retry nothing.

Primitive B: a retry policy bound to the category. Infrastructure errors get a bounded retry: a small number of attempts, exponential backoff with a hard ceiling, then permanent failure. Workflow logic errors get zero retries. The constants are the system property a buyer should grep for: how many retries, what initial delay, what max delay, what multiplier. Vendors that decline to publish those numbers are publishing a marketing claim, not a system property.

Primitive C: consecutive-failure auto-cancel. A background pattern check runs against the execution history. If the same workflow has failed N times with the same error in the last M minutes, the next scheduled tick is skipped and the schedule itself is marked auto-cancelled until a human acks. This is the only primitive that prevents mode three. Without it, every prolonged target-system outage trains your team to ignore the dashboard.

4. Reading the actual code: classifier and retry config

The Mediar executor is open source. The reliability primitives are in two files inside github.com/mediar-ai/terminator: the retry config and classifier at crates/executor/src/config/retry.rs, and the dispatch handler at crates/executor/src/services/execution_handler.rs. The first 44 lines of retry.rs are the entire retry policy. The defaults are worth reading directly.

// crates/executor/src/config/retry.rs (lines 5-44)
#[derive(Debug, Clone, Serialize, Deserialize)]
pub struct RetryConfig {
    pub max_infrastructure_retries: u32,
    pub initial_delay_secs: u64,
    pub max_delay_secs: u64,
    pub backoff_multiplier: f64,
    pub enabled: bool,
}

impl Default for RetryConfig {
    fn default() -> Self {
        Self {
            max_infrastructure_retries: 3,
            initial_delay_secs: 30,   // first retry after 30s
            max_delay_secs: 600,      // cap at 10 minutes
            backoff_multiplier: 2.0,  // double each time
            enabled: true,
        }
    }
}

From crates/executor/src/config/retry.rs, lines 5 to 44. Three retries, 30s initial delay, 600s ceiling, double each time. Configurable per deployment, not hard-coded; this file is the default a fresh install ships with.

The next 120 lines are the classifier itself. Two named substring lists, in priority order. Anything that matches the infrastructure list returns Infrastructure. Anything that does not match infra but matches the workflow-logic list returns WorkflowLogic. Anything that matches neither falls through to Unknown, and the conservative default is to not retry the unknown. The conservatism is deliberate: an infrastructure pattern the classifier missed costs you one extra failed run; a logic pattern the classifier incorrectly retries can corrupt downstream data.

// crates/executor/src/config/retry.rs (lines 46-164)
#[derive(Debug, Clone, PartialEq)]
pub enum ErrorCategory {
    /// Infrastructure failure (VM down, network issue, MCP unreachable)
    /// These SHOULD be retried automatically
    Infrastructure,

    /// Workflow logic failure (step failed, validation error, business logic)
    /// These SHOULD NOT be retried automatically
    WorkflowLogic,

    /// Unknown/ambiguous error
    Unknown,
}

pub fn classify_error(error_message: &str) -> ErrorCategory {
    let error_lower = error_message.to_lowercase();

    let infrastructure_patterns = [
        "connection refused", "connection reset", "connection timeout",
        "503 service", "504 gateway timeout",
        "mcp service unavailable", "mcp connection failed",
        "vm is down", "machine not responding", "health check failed",
        "could not resolve host", "deadline exceeded",
        "out of memory", "resource temporarily unavailable",
        // (full list: 30+ patterns)
    ];

    let workflow_logic_patterns = [
        "validation failed", "invalid input", "missing required",
        "record not found", "permission denied", "unauthorized",
        "step failed", "assertion failed", "condition not met",
        "file not found", "parse error",
        // (full list: 18 patterns)
    ];

    for pattern in &infrastructure_patterns {
        if error_lower.contains(pattern) {
            return ErrorCategory::Infrastructure;
        }
    }
    for pattern in &workflow_logic_patterns {
        if error_lower.contains(pattern) {
            return ErrorCategory::WorkflowLogic;
        }
    }

    // Conservative default: do not retry the unknown
    ErrorCategory::Unknown
}

Excerpt from lines 46 to 164. The full file lists roughly 30 infrastructure substrings and 18 workflow-logic substrings. Run grep -c '"' crates/executor/src/config/retry.rs on the open-source repo to count the live patterns yourself.

5. The auto-cancel rule, in one SQL query

The third primitive (consecutive-failure auto-cancel) is one SQL query inside the queue processor. Before the executor claims an execution off the queue, if the trigger source is the cron scheduler, it asks the database one question: did this workflow already fail at least 3 times in the last 10 minutes with the same exact error message? If yes, the execution is auto-cancelled with the reason “Auto-cancelled due to consecutive failures”. The next scheduled tick is also cancelled.

// crates/executor/src/db/queries.rs (line 358)
// 3 identical errors within 10 minutes -> kill the cron schedule
SELECT COUNT(*) as count
FROM (
    SELECT error_message
    FROM workflow_executions
    WHERE workflow_id = $1
      AND status = 'failed'
      AND completed_at > NOW() - INTERVAL '10 minutes'
    ORDER BY completed_at DESC
    LIMIT 3
) recent_failures
WHERE error_message IS NOT NULL
GROUP BY error_message
HAVING COUNT(*) >= 3;

From crates/executor/src/db/queries.rs, line 358. Manual and web-triggered executions skip the check; the user is at the keyboard and can decide what to do. Cron-triggered executions, which run unattended, get the auto-cancel.

The threshold (3 inside 10 minutes) is intentionally tight. Two identical failures inside 10 minutes can still be coincidence; three is unambiguous evidence that the target system is unreachable, the credentials have rotated, or the schedule itself has gone wrong. Continuing to fire is worse than stopping. Past that bar, the next firing is silenced and a single alert is raised. Every EPA platform should have something like this; the platforms whose alerts are unreadable do not.

6. The buyer's view: what to ask, before signing

A short list of questions worth asking any 2026 EPA vendor. None of these are gotchas. All of them have an honest answer. The pattern is that the vendors with strong fail-safe layers have answers in minutes; the vendors without one route the question through three layers of sales engineering and come back with a deflection.

Mediar publishes the answers to all four under AGPL-3.0 in the Terminator repository because we believe the only reliability claim worth making is one a customer can grep. The same approach is available to any vendor that wants to make it; that none of the large incumbents have is itself a piece of information for the 2026 buyer.

Frequently asked questions