Workflow Never Dies: The Rise of Descriptive Runbooks

I want to make a claim that sounds stubborn on purpose:

Workflow never dies.

The reason is simple: workflow and agent are not opposites, they are a spectrum. Andrej Karpathy described this as a continuum from tooling to autonomy. I see the same thing in practice. A workflow can be a strict checklist, or it can be a soft intent that an agent fills in. The slider moves as models get stronger. The spectrum does not disappear.

This post has two halves. The first half argues why workflows keep coming back, even as agents improve. The second half argues for a new kind of workflow: descriptive, human-written runbooks that are easier to author than drag-and-drop node graphs.

The spectrum, not the fight

Most debates treat workflow and agent as competing philosophies:

• Workflow is rigid and deterministic.
• Agent is flexible and autonomous.

But in practice, they stack. When models are weak, we add more steps. When models are strong, we remove steps and let them infer. The shape is a spectrum, not a cliff. You can feel it when you adjust prompts or tool rules. A runbook that has 20 explicit steps today might become a 3-step intent tomorrow. It is still a workflow; it is just a higher level of abstraction.

So when people ask, "Will agents kill workflows?" I think they are asking the wrong question. The right question is: How does the workflow change when agents are better?

Good workflows are frozen thinking patterns

Some workflows are just automation. Others are a record of how humans think when the stakes are high.

Think about the patterns we already use:

• "Let's think step by step"
• CodeAct style loops (plan, act, observe, revise)
• Planner plus todo list

These are not mere recipes. They are abstractions of human reasoning. We only write them down because they work.

As models train on human traces, those abstractions become priors inside the agent. The model learns that "step by step" is a good default, that a plan should precede action, that a todo list reduces omissions. Over time, the best workflows are no longer bolted on. They are absorbed.

That is why workflow never dies. It mutates. It goes from explicit steps to implicit habits.

The spiral effect: better agents create new workflows

Now flip the arrow. When agents improve, humans use them as building blocks to create new workflows. This is a spiral: models absorb workflows, humans invent new ones on top, and the cycle repeats.

A simple example is almost boring: "Every day, have an agent check my email and summarize what needs a reply." That is a workflow. It is not a drag-and-drop graph, but it is still a sequence of intent, schedule, and verification.

This matters because the demand for workflow does not go away. It just moves up the abstraction ladder. People want outcomes, and they will keep organizing steps to reach them, even if the steps are written in plain language.

Why classic workflow tools feel heavy

Traditional workflow software made a bet: if you make automation visual and modular, more people will use it. Hence the drag-and-drop nodes, connectors, and long configuration panels.

It worked for power users, but it also created friction:

• You have to learn a UI grammar before you can express intent.
• You have to decide tools and data formats up front.
• Small changes require rewiring nodes and revalidating every edge.
• The work feels like systems design, not problem solving.

The problem is not that graphs are bad. The problem is that graphs force you to think like the system. Most people want to think like a human: "Do this, then that, then check for exceptions." That gap makes classic workflow tools feel heavy.

The new workflow is descriptive

What does a next-generation workflow look like?

It looks like a runbook. A plain-language sequence of steps that reads like an operating manual. The human writes the intention, the agent executes the details.

Pylon calls these "Runbooks" for support agents, and it is a good mental model. The runbook is a list of actions, not a diagram. It reads like:

• Step 1: detect the issue and gather context
• Step 2: search the knowledge base for a match
• Step 3: draft a response, then ask for confirmation

The agent does the rest: tool selection, retrieval, follow-ups, and edge cases.

Here is the Pylon runbook visual that captures the idea:

The core value is not the UI. It is the language. Anyone who can write a checklist can author a workflow. The interface becomes a text editor, not a wiring board.

Descriptive workflows lower the real cost

The biggest cost of workflow is not compute. It is adoption cost. Descriptive workflows lower that in three ways:

• Faster authoring. Writing steps is a familiar skill; dragging nodes is not.
• Lower configuration debt. You can adjust wording without refactoring a graph.
• Better transfer. A runbook can be copied, read, and critiqued like any document.

This makes workflows feel less like infrastructure and more like documentation. It invites iteration. People can propose edits, leave comments, and evolve the process without a tooling specialist.

The runbook is a policy, not a diagram

I think of the runbook as a policy spec. It is not a fixed graph. It is a set of constraints on an agent:

• Do not send replies without approval.
• If a step fails, ask a human and log the context.
• Use the internal knowledge base before browsing the web.

Those are not nodes. They are rules. An agent can translate them into actions. This matters because real work is messy. You want a spec that says what must be true, not just what happens on the happy path.

This is where descriptive workflows shine. You can express:

• conditional branches ("If the customer is enterprise, escalate")
• safety gates ("Ask before billing changes")
• fallback plans ("If no data, request more context")

All of that fits in plain language. The agent interprets it at runtime.

Why this matters for product design

If workflow becomes descriptive, product priorities shift:

• The text editor becomes the core interface.
• Versioning and diffing become first-class features.
• Debugging becomes narrative: what step failed, what context was missing.
• Sharing becomes cultural: runbooks are read like playbooks.

This also changes who builds workflows. It is no longer only the ops engineer or the automation specialist. It is the team lead, the manager, the person closest to the problem. The workflow becomes part of the human system again.

The future is shorter, not longer

As agents improve, the runbooks will get shorter. The steps become higher-level. Instead of 20 lines, you might have 5 lines that encode intention, constraints, and checkpoints.

That does not eliminate workflow. It makes workflow more semantic. A sentence like "Triage daily issues, reply to anything that blocks revenue, and summarize the rest" is still a workflow. It is just compressed.

So yes, workflow never dies. It ascends. It shifts from nodes to narratives, from graphs to runbooks, from explicit logic to descriptive policy.

Closing thought

Workflow is the human habit of turning intention into repeatable action. Agents do not erase that habit, they amplify it. The winners will be the products that make workflow feel like writing, not wiring.