Chapter 6 — Process as Data

Of all the failed escapes catalogued in Part I, Business Process Management deserves the most sympathy, because it came the closest to being right. The idea at its core — draw the process, and let the drawing execute — was a correct diagnosis wearing the wrong decade. The BPM pioneers understood something the page-builders never did: that an enterprise is not a pile of records but a set of processes, and that the process, not the screen, is the real unit of the product. They even understood that the process description should be executable, which puts them, in hindsight, two-thirds of the way to the thesis of this book.

What failed was not the idea. What failed was the residence. The process model lived in an annex — a suite purchased separately, administered separately, integrated over whatever pipe the vendors could agree on. The diagram knew nothing of the pages where users actually touched the process; those belonged to a different system, usually a different budget. It knew nothing of the data the process was about, beyond the fragments passed to it at each step. And it knew nothing of intelligence, because there was no intelligence to know — the smartest thing in a 2005 BPM suite was a rules engine, and we saw in chapter 2 how far the rules engine's vocabulary reached. So the executable diagram executed a skeleton while the living process — the judgment calls, the exceptions, the actual work — flowed around it through the channels work always finds.

I once stood in a conference room in front of a swim-lane diagram of a client's order-to-cash process. It was laminated — laminated, mind you, a commitment to permanence normally reserved for restaurant menus — and it hung on the wall the way a portrait of a founder hangs on a wall, honored and consulted about equally often. The process it depicted was being conducted at that very moment, three floors down, over email. Nobody in the building considered this a contradiction. The diagram was the description; the email was the behavior; and by then I knew the law that governed their relationship: second descriptions always lose.

This chapter is about what it takes to make the first description win — to make the process itself an object in the same governed graph as everything else the previous two chapters put there, so that there is nothing for the behavior to drift away from.

A process is an object

Start from the ground. The previous chapters established that the product's structure lives as typed, governed objects on one graph, and that the interface is a projection of those objects rather than a second codebase. The claim of this chapter is the natural next step, and I want to make it precisely: a process is a typed object in the same graph as the pages that trigger it and the knowledge that informs it.

Not a pointer to a process running elsewhere. Not an export of a diagram maintained elsewhere. The definition itself — the steps, the branching gateways, the waits and timers, the places where a human must approve before the flow may continue — is data, with an identity, a version, and a governance state, sitting beside the page objects and the knowledge objects in one store. Here is the shape, in the worked example's terms, trimmed to essentials:

{
  "@id": "urn:uuid:6f2d8c1e-…",
  "schemaRef": "schema:workflow",
  "orgId": "org_meridian",
  "state": "active",
  "data": {
    "name": "Claims intake",
    "nodes": [
      { "id": "collect", "kind": "form", "formRef": "urn:uuid:…" },
      { "id": "triage", "kind": "agent",
        "goal": "Assess claim completeness and score risk",
        "skills": ["Claims triage doctrine"],
        "allowedTools": ["score_risk", "knowledge_search"],
        "minConfidence": 0.8,
        "executorId": "hosted" },
      { "id": "review", "kind": "human_gate", "assignee": "role:adjuster" },
      { "id": "seal", "kind": "seal", "connectorRef": "urn:uuid:…" }
    ],
    "edges": ["collect → triage", "triage → review", "review → seal"]
  }
}

Every consequence the graph conferred on pages in chapter 4 now applies to processes, automatically, because a process is just another citizen. The definition can be diffed, so a change to the process is reviewable before it lands. It can be versioned, so last quarter's claims flow is retrievable when the auditor asks what the rules were in March. It can be addressed by a permission, so "the agent may edit triage thresholds but not payment steps" is an enforceable sentence rather than a hope. And it can be read — by the runtime that executes it, by the human who governs it, and by the machine intelligence that Part I spent two chapters locking out of the building.

And there is a second object, easy to miss and just as important: the run. Every execution of a process is itself data — this claim, this customer, entered the flow at 9:04, took the incomplete-documents branch, waited two days at the human gate, sealed at 11:31 Thursday. In the worked example these are called Runs, and they are durable objects with their own lifecycle: they can be inspected mid-flight, queued for human attention, advanced, restarted. The definition says what the process is; the runs say what it did, instance by instance. Keep that pairing in mind — chapter 8 will make heavy use of it.

One engine, two disciplines

Here the industry's current map will mislead you, so let me redraw it. As I write, process automation and AI agents are sold as different product categories, by different vendors, at different conference booths. The workflow engine is mature, deterministic, and slightly unfashionable. The agent framework is new, probabilistic, and slightly unaccountable. Enterprises are encouraged to buy both and to wire them together, which is to say: to build the annex again, twice, facing itself.

The vendor-neutral claim is that this split is an accident of product history, not a fact about processes. A real business process interleaves the two disciplines constantly. Collecting a claim form is deterministic. Judging whether the attached photographs actually show hail damage is not. Routing above a threshold to a senior adjuster is deterministic. Drafting the customer explanation is not. If the deterministic spine and the judgment calls live in separate systems, then the process — the real one, the one the business would describe — exists in neither, and you are back to the laminated diagram. The two disciplines are facets of one model, and they belong in one governed definition.

Concretely, a process substrate needs both vocabularies. From the deterministic tradition, the constructs BPM spent two decades refining: forms, parallel and inclusive and event-based gateways, waits and timers, iteration over collections, compensation steps for unwinding what a failed flow already did, subprocesses, and human gates. From the agentic tradition: nodes that carry a goal rather than a procedure, with declared tools, declared doctrine, and — when the work warrants a team rather than a worker — an orchestration pattern for multiple agents within the node: a single agent, a pipeline of specialists, a supervisor delegating to workers, a swarm.

The worked example, Closure, ships exactly this: one workflow engine with two authoring facets — it calls them Process and Agentic — over a single definition. Not two engines with a bridge; one graph in which a form node, a gateway, an agent team, and a human gate are peers. The claims flow above, drawn honestly:

collect (form)
   │
   ▼
triage (agent team: supervisor + 2 specialists)
   │
   ├── confidence ≥ 0.8 ──────────────┐
   ▼                                  ▼
review (human gate: adjuster)      review (flagged, senior queue)
   │                                  │
   └────────────┬─────────────────────┘
                ▼
seal (write case to system of record)

One run. One audit trail. The deterministic steps and the agent's judgment and the human's approval are entries in the same record, because they were always parts of the same process — the map just finally matches the territory.

It is worth pausing on the unglamorous constructs in that deterministic vocabulary, because they are where process maturity actually lives. Compensation — the declared steps for unwinding what a half-finished flow has already done — is an admission, written into the definition, that processes fail midway and that the failure path deserves the same rigor as the happy one. Timers and event-based gateways admit that the world does not answer promptly. Human gates admit that some judgments should not be delegated at any confidence. An agent framework alone has none of this vocabulary, which is much of why the demos of chapter 2 stall on the way to production: the exciting half of the process model was built before the boring half, and it is the boring half that the compliance department reads first.

Pluggable brains

Now the part of the design I find genuinely elegant, and one of the two places in this chapter where something strange happens. An agent node in a governed process declares what must be done — the goal, the permitted tools, the doctrine, the confidence threshold below which a human must be consulted. It does not hard-wire who does the reasoning. That is a separate, declared choice: the node names an executor, and the executor is pluggable. The worked example ships three:

The principle is worth stating in vendor-neutral form because any team building toward this paradigm will need it: the graph is the contract; the brain is pluggable. Governance, evidence, and audit attach to the node, not to the intelligence that happens to serve it. Whichever executor does the thinking, the run records the same pause, the same tool calls, the same outcome, the same escalation if confidence fell short. Swap the brain and the accountability does not move an inch.

The external executor is the diplomatic one. Enterprises have already built agents — on LangGraph, on cloud agent services, on frameworks with braver names — and a paradigm that demanded their abandonment would be ignored, correctly. Instead the run pauses, posts the task to a registered webhook with a signed payload — the goal, the doctrine, the allowed tools, a snapshot of the run's data — and waits. The outside framework does its reasoning on its own infrastructure and answers back with a summary, a confidence, and its results, and the governed run absorbs the work and moves on. The enterprise's existing agent estate stops being a fourth building on the street from chapter 2 and becomes a set of brains-for-hire, employed by processes that carry the accountability.

The ide executor is the strange one, and I want to dwell on it, because I know of no precedent. When a run reaches an agent node configured this way, it pauses in a state that means, literally, waiting for a programmer's editor. Somewhere, a developer's IDE — the same AI-assisted editor they use all day — picks up the task over a standard protocol, reasons about it with full local context, does the work, and submits the result back into the run, which verifies it, records it, and proceeds. Consider what has been inverted. For seventy years the developer's tools stood outside and above the running system: you worked on the application, from a privileged position it could not see, and shipped the result down to it. Here, a governed business process — the same object that collects forms and routes claims — reaches out and employs a programmer's editor as one of its workers. The IDE is, for the duration of that task, a process citizen: assigned, supervised, auditable, and expected to meet the node's contract like anyone else. The application is not being operated on. It is doing the hiring. What this means for the craft of authorship is chapter 12's question; what matters here is the machinery — and the machinery ships.

Loops with budgets, not hopes

Chapter 2 left a wound deliberately open: guardrails-by-prompt, the practice of constraining an agent by asking it nicely in its instructions, and the discovery — universal, expensive — that a prompt is weighed, not enforced. A process substrate can close that wound structurally, and this is the second place the design earns its keep.

In the worked example, a decision node can carry a loop: do the work, verify it, and if verification fails, repair and try again — under an explicit budget of attempts. The load-bearing word is verify, and the load-bearing fact is where verification lives. The checks are deterministic tools named in the process definition — does the output parse against the declared schema, does the page pass the contrast rule, does the total reconcile — not instructions folded into the agent's prompt. The agent may be probabilistic; the acceptance test is not. Verification is part of the process definition, not a hope expressed in a prompt. And the budget converts a failure mode into a policy: an agent that cannot satisfy its verifier within its allotted attempts does not try forever, and does not slip unverified work into the flow. It stops, and the run escalates to the gate the definition already provides. Do, verify, repair, within limits, with evidence — which is, one notices, precisely the discipline a good human team applies to its own work, now written down where the process lives and enforced whether or not anyone remembered to be disciplined that day.

Three doors, one room

A brief note that belongs to this chapter's argument, though the previous chapter owns its full development. Once the process is an object, the question "is this a form, a chat, or an autonomous agent?" changes meaning. Those are not three processes; they are three projections of one process object. The same claims-intake definition can be walked as a form wizard by a customer on the website, conducted as a conversation by an assistant, or executed straight through by an agent with a human gate where the policy demands one — three doors into one room. Change the room and every door now opens onto the change; there is no second copy of the journey to fall out of date. The interface argument of the previous chapter and the process argument of this one are the same argument, made about different objects on the same graph.

Sealing, or the modesty clause

There remains the question of where the process's results end up, and the answer is a deliberate act of architectural modesty. A claims process eventually produces facts the enterprise must keep: a case, a payment, a customer record amended. The paradigm does not propose that the product graph become the keeper of those facts. It proposes the opposite: the process completes by sealing — writing its durable results into the systems of record the enterprise already trusts and audits. The CRM keeps the customer. The ITSM platform keeps the case. The forms platform keeps the submission. In the worked example, sealing is a first-class node kind, connectors are vaulted per environment, and the whole posture is explicit: the graph governs the journey; the systems of record keep the conclusions. The graph does not compete to be the system of record — it composes them, and makes what lands in them better-structured for having passed through a governed process on the way.

I want to be honest about why this matters, because it is as much strategy as architecture. Systems of record are where enterprise trust actually lives — decades of it, encoded in retention policies, audit relationships, and the institutional memory of the compliance department. A paradigm that asked enterprises to migrate those systems into a new graph would be proposing the largest rewrite in the history of rewrites, on behalf of a book arguing that rewrites are the disease. Sealing dissolves the demand. Adopt the substrate for what changes weekly — the journeys, the pages, the judgment — and let what must be permanent stay exactly where the auditors already know to find it. The last application, whatever else it is, should not begin its life by asking you to abandon your ledgers.

The point

A process is a typed object on the same graph as the pages that trigger it and the knowledge that informs it — and every execution of it is an object too, addressable, versioned, and auditable like anything else on the substrate. The deterministic discipline of BPM and the agentic discipline of AI are facets of one process model, not two products to be wired together; a single definition can carry forms, gateways, agent teams, and human gates through one run with one audit trail. Agent nodes declare goals and contracts while the reasoning brain stays pluggable — hosted, an external framework, or, most strangely, a developer's IDE employed by the run as a governed worker. Where agents act, verification is deterministic tooling inside the definition with explicit repair budgets — structure, not a hope expressed in a prompt. And the process ends in modesty: it seals its durable results into the systems of record the enterprise already trusts, composing them rather than replacing them.