When an automation should become an agent

Answer: An automation should graduate to an agent when the method has stabilized but the inputs never do — when a workflow needs judgment on a case-by-case basis, exceptions keep multiplying, or the rules governing it change faster than anyone can maintain them. Until that signal appears, deterministic automation is cheaper, faster, and easier to audit, and staying on it is the right call, not a consolation prize.

Why isn’t “it would be nice if this were smarter” a real signal?

Because it isn’t specific, and everything looks smarter in a demo. The signal we actually look for is narrower: rules stop covering the cases that show up, and the team maintaining the workflow is spending more time writing new exceptions than the workflow saves by existing. If deterministic rules still handle 95% of your cases correctly, deterministic rules are still the right architecture for that workflow, and we say so even when an agent would be the easier thing to sell.

What does “the inputs never stabilize” actually look like in practice?

It looks like a rule engine that keeps growing a new branch every few weeks because a customer, a vendor, or a regulation introduced a case nobody wrote a rule for. A support-ticket router with 40 if/then branches that still misroutes a meaningful share of tickets isn’t under-engineered — it’s evidence the underlying task requires judgment the branches can’t encode. That’s the actual promotion signal: not that an agent would be more impressive, but that the deterministic version has hit a structural ceiling no amount of additional rules will fix.

What actually changes when a workflow gets promoted?

4 specific upgrades, not a rebuild from zero. The working brief that described the automation becomes a written specification an agent can be evaluated against. The person who used to eyeball whether the output looked right becomes a graded evaluation set, the same discipline described in how we evaluate agents before they meet customers. The informal “someone checks this occasionally” becomes a defined escalation rule with an owner. And the ad-hoc process becomes a governed runtime with logging and a cost ceiling, so what the system does in production is visible, not assumed.

Because most of what made the automation work — the logs, the edge cases already discovered, the instrumentation — carries forward, promotion typically ships in weeks, not months. It’s mostly upgrade, not invention.

What’s the actual cost of promoting something too early?

An agent is harder to audit than a rule engine, costs real money per run rather than a fixed compute cost, and introduces a class of failure — being confidently wrong — that a deterministic system structurally cannot produce. A rule engine either matches a case or it doesn’t; it doesn’t invent a plausible-sounding wrong answer. Promoting a workflow before the inputs actually demand judgment trades a cheap, predictable system for an expensive, harder-to-audit one, in exchange for a capability the workflow didn’t need yet.

Who should be making this call, and when?

Whoever owns the automation’s monitoring, because they’re the one who can actually see the exception rate climbing before it becomes a visible problem. The decision shouldn’t wait for a workflow to be embarrassingly broken before someone asks whether it needs to be rebuilt as an agent — the signal is visible in the monitoring data well before that point, if someone is looking at the exception queue instead of just the uptime dashboard.

This is the exact handoff we run between our automation and agentic engineering lines: a workflow that outgrows deterministic rules moves over carrying its specification, its logs, and its instrumentation, not starting from a blank page.