The New Automation Lifecycle

Purpose

The existence of agentic workflows has changed the way that network engineering teams can go from manual processes to useful automation. They enable faster, easier ways to build automated workflows, among other benefits.

But agentic workflows do not replace deterministic automation. In most cases, they should be used as a step toward deterministic workflows. Many engineering teams are getting this wrong today—either by trying to force AI into all workflows, or designing systems where LLMs are unnecessarily involved in decision making that should be deterministic.

This post describes:

• How and when to use both agentic and deterministic workflows, and how they harmonize together to improve the automation development lifecycle for engineering teams.
• The foundational systems needed to be successful in a world of deterministic and agentic workflows.

Definitions

Deterministic workflows follow prescribed logic, including individual steps with predefined inputs and outputs. Executions take the same predictable path, with explicit controls, retries, and auditability.

Agentic workflows let an LLM participate in runtime decision-making. The model can interpret ambiguous instructions and inputs, choose tools, decide the next step, and handle exceptions using context.

Figure 1. Deterministic execution follows a prescribed path; agentic execution makes bounded decisions at runtime.

How Did We Get Here?

I find it helpful to give context on what led us here because things have moved so quickly.

Prior to LLMs, all workflows were deterministic.

The New Automation Development Lifecycle

Previous model

1. Evaluate manual processes and identify flows to convert to deterministic workflows (effort reduction, risk reduction, simplicity to develop).
2. Document the flow in manual steps.
3. Execute the manual process to gain confidence in steps, inputs and outputs, and consistency so development effort is not wasted.
4. Create a deterministic workflow shell.
5. Automate individual steps over time.
6. Arrive at a fully deterministic workflow.

This model often left a long gap between identifying the opportunity and delivering meaningful automation.

Emerging model

1. Identify a valuable flow and document its manual steps.
2. Use an agentic skill or workflow to automate ambiguous or poorly specified portions.
3. Measure value, failure modes, execution frequency, and repeatability.
4. Replace proven steps individually with deterministic implementations.
5. Arrive at a deterministic workflow when the economics and risk justify it.

Many automation opportunities will now begin as agentic workflows before becoming deterministic.

Workflow path: Manual process → Agentic-assisted workflow → Hybrid workflow → Deterministic workflow. The hybrid stage matters: retain agentic judgment where it is valuable, while deterministic orchestration governs validation, approvals, and production changes.

Operating Principles

• Agentic workflows are a good intermediate solution for many flows.
• Agentic workflows are often a poor long-term solution for stable, frequent, or consequential flows.
• Do not design new systems around an AI workflow layer when it is unnecessary or difficult to migrate away from. That creates an avoidable dependency on LLMs and their ongoing cost.
• Keep the AI decision surface narrow. AI may classify, recommend, investigate, or draft; deterministic controls should validate, authorize, and execute consequential changes.
• Do not force determinism where ambiguity is inherent and risk is low. Instead, make agent actions observable, bounded, and reversible.
• Convert a step to deterministic when its inputs, decision criteria, tools, and exception paths are sufficiently understood and stable.

Value and Tradeoffs

For network engineering, agentic workflows are promising for request intake, ticket triage, investigation, runbook discovery, change-plan drafting, and incident summarization. Changes to production infrastructure should normally remain behind deterministic validation, authorization, approval, and execution controls.

Preparing the Organization for AI-Enabled Workflows

Align on a platform vision

Engineering teams should be able to self-serve the creation and modification of the business logic they own while operating within centralized controls. A successful platform provides:

• Rapid workflow creation and iteration
• Step-level auditability, including execution time and outcome
• Cost visibility for model and tool usage
• Guardrails, governance, and complex permission support
• Connectors to engineering and operations systems
• Centralized execution, scheduling, and triggers
• Shared identity, secrets, approvals, and policy enforcement

Continue identifying workflow opportunities

Use the established process: prioritize high-value work, reduce operational risk, and centralize workflows that should not remain tribal knowledge.

Evaluate agentic candidates deliberately

For each agentic candidate, assess:

• Cost per execution and expected frequency
• Effectiveness and quality of outcomes
• Operational risk and reversibility
• Failure modes and required human review
• Difficulty of converting all or part of the workflow to deterministic steps

Convert what has become understood

The platform should make it easy to replace a single agentic step with a deterministic step without rebuilding the entire workflow or changing its interface to users and upstream systems.

Platform Requirements

The foundational requirement is that the workflow system recognize both the workflow as a whole and its logical steps.

Non-negotiable: Every workflow—including an agentic workflow—must expose a durable, step-level execution graph.

Each step should record, as appropriate:

• Step ID, start and end timestamps, result, and retry history
• Actor and model/version used
• Input and output references
• Tools called and permissions used
• Cost or token metrics
• Approval and audit context

For example, a workflow that reads a Jira ticket, posts a comment, and changes its status must surface those as separate steps. Otherwise, it becomes an opaque agentic blob: individual steps cannot be measured, governed, or migrated to deterministic implementations without replacing the entire workflow.

The platform should also provide:

• One execution record and audit model across agentic and deterministic work
• Composable agentic and deterministic steps in the same workflow
• Shared identity, secrets, permissions, approvals, and triggers
• Step-by-step replacement without changing the workflow’s external contract
• Clear portability so the agent layer does not become a proprietary execution dependency

An Architectural Question to Resolve

It is possible to operate separate platforms for deterministic and agentic workflows. The costs are meaningful: teams must learn two systems, operational records can fragment, and migrating a proven agentic step can require a cross-platform redesign.

The preferred direction is usually a common control plane: one model for identity, policy, triggers, execution history, approvals, and observability, with both deterministic and agentic steps composable in a workflow. Separate tools may still be justified when the deterministic platform has specialized capabilities that the agentic platform cannot safely or economically provide. In that case, the production deterministic system should remain the system of record for consequential execution.

Illustrative Examples

Preferred direction: Use the agent where understanding is still needed, and deterministic code where a stable, consequential action can be safely standardized.