Draft. Notes more than essay. Refining in public, after.

We have an agentic-BPMN extension running in production with a top-five European pharmaceutical company. The earlier piece on this site, Agentic BPMN workflows, describes the design: BPMN 2.0 diagrams with an extension that marks certain tasks as agentic, certain lanes as agent-occupied, with a reflection loop for low-confidence outputs. It works. The production deployment has been running for years.

Building it taught us something we didn’t see going in: BPMN is enough to design with, but it is not enough to run with.

BPMN gives the shape of a workflow — tasks, gateways, lanes, sequence flows. What it does not give is the answer to the question an agent has to ask continuously at runtime: what should I do next, and what am I allowed to do? That answer needs more than a diagram. It needs a live work-graph the agent can read from and write to — where state is observable, dependencies are explicit, history is replayable, and the next unblocked piece of work can be returned by a single query.

We have been quietly building that layer underneath the BPMN engine for a while without naming it. Watching what Steve Yegge has been doing with Beads in the coding-agent world clarified what we have been building. It is the same problem in a different domain.

What Beads is, briefly

Beads is an issue tracker designed for AI agents to use as their work memory. CLI-first, JSON everywhere, hash-based identifiers (so several agents creating issues concurrently do not collide), version-controlled storage on Dolt — a SQL database with git-like branching and merging — and a bd ready command that returns the work items that are unblocked given the current state of the dependency graph.

The category being prototyped here is not really issue tracker. It is work-graph for agent runtimes. Beads is one implementation, optimised for coding workflows. The architectural choices that interest us — content-addressed identity, version-controlled history, dependency-aware ready queue, primitives for multi-agent coordination — are general. They are not specific to coding agents.

A pharma planning agent has the same problem. So does a BPMN-driven decision-support agent. So does any agent that operates on a non-trivial multi-step process where the work outlives a single chat session.

What BPMN gives, and what it does not

BPMN gives the design-time representation:

• The shape of the workflow — what tasks exist, in what order, with what conditional branches.
• The lanes — who or what is responsible (human, agent, system).
• The intent — readable by other humans, machine-interpretable enough to drive execution.

BPMN does not give:

• The state — which instance of the diagram is at which task, what has been decided, what is blocked.
• The history — what was tried, what was decided, what was reversed, what evidence was attached, what comments were left.
• The coordination primitives at runtime — how concurrent agents avoid stepping on each other, how human approvals gate machine work, how rollback behaves when something downstream fails.
• The agent’s working memory — the things the agent learned mid-task that do not fit cleanly into the input or output contract of the next task.

A workflow engine handles some of this. Camunda, Activiti, others. They were designed in an era when the actor at a lane was either a human at a UI or a deterministic service. Agents are different. They are non-deterministic. They learn during execution. They produce side-information — notes, hypotheses, flags — that does not fit the input/output contract of a BPMN task. And they need to be coordinated across sessions that may span days.

The primitives a runtime work-graph needs

What has been emerging in our own work, and what Beads is sketching in the coding domain, looks like this:

Content-addressed identity. Each unit of work has an identifier that is a hash of its content, not a sequential number assigned by a central authority. This sounds small. It is not. The moment several agents are creating work items concurrently across distributed sessions, sequential IDs become an impossibility. Content addressing dissolves the problem.

Explicit dependencies, machine-readable. Not the BPMN sequence-flow sense — but the runtime equivalent: this work cannot proceed until that decision is made, that approval is given, that input is provided. An agent should be able to ask “what is ready?” and get back the unblocked subset of the graph. Beads calls this bd ready. Operations researchers call it the ready queue. The name does not matter; the primitive does.

Version-controlled history. Not append-only logs — actual version-controlled state, where the work-graph can be branched, an alternative tried, the result merged back if useful, the branch discarded if not. The git mental model, applied to work-graphs. That is what Dolt buys Beads. In the planning domain, it is what would let an operator ask “what if we had routed batch 17 differently three weeks ago?” and get an answer that is an actual replayable state, not a guess.

Agent-readable, human-readable. The same data structure has to be queryable by an agent through a JSON API and inspectable by a human through a UI. Not two parallel systems. The same source of truth for both consumers. This aligns with the architectural commitment we have stated elsewhere — headless, API-first, agent-mediated UI — but the work-graph is the place where that commitment becomes load-bearing rather than aspirational.

Domain-appropriate types. Here the coding-domain choices stop transferring. Beads’ core types are issues, dependencies, labels, formulas, molecules. For coding work, those are right. For planning work, they are not. A planning work-graph needs constraints, scenarios, approvals, batch lots, regulatory checkpoints, supersedure relationships when a plan is replaced mid-execution. The domain types matter. The architecture underneath them is what is transferable.

Why this matters in regulated industries

Most current discussion of agent observability frames it as a developer-experience problem. “I want to see what my agent did, so I can debug it.” That framing is correct as far as it goes. It misses the more important user.

For a pharma operator running an agent system in production planning, the question is not how do I debug. It is how do I prove. When the regulator asks why a maintenance window landed on a particular date, or what evidence supported skipping an additional batch test, the operator has to produce a coherent answer that involves the agent system without sounding evasive.

A chat log is not that answer. A work-graph with versioned history, explicit dependencies, and recorded approvals is. Why did the agent do X? Because Y was unblocked, Z was approved, and the recorded constraints supported it.

This is what turns the runtime work-graph from a UX feature into a compliance feature. In our experience, the compliance value carries far more conviction than the developer-experience value with regulated-industry buyers. Operators do not pay for cleaner debug views. They pay for the ability to defend a decision to an auditor.

What we have built, what is still ahead

Our current Aipokit Studio architecture has a partial version of this. The agentic-BPMN extension carries enough state per instance to drive execution, and the agent runtime keeps a working memory that survives session boundaries. What is missing — what Beads’ design points toward — is the version-controlled work-graph as a first-class layer, with the dependency-aware ready queue exposed as a primitive the agent can call rather than as a derived view computed elsewhere.

The right move is not to adopt Beads. The domain types are wrong. But the architectural pattern — content-addressed identity, version-controlled history, dependency-aware queries, agent-readable through JSON, human-readable through a UI — is the next major piece of work for Aipokit Studio. It is already implicit in what we have built. Making it explicit, naming it, and exposing it as a clean API is the lift.

Internally we have been calling it the runtime BPMN. That name will probably change. The thing it points at will not.

---

Open questions for the polish pass — to refine later:

• Title — too long? Better candidate: “What we needed before we knew we needed it.” Or just “The runtime work-graph.”
• Octapharma naming — currently using the “top-five European pharmaceutical company” fallback. Swap in the named version once the formal sign-off lands.
• Credit to Beads/Yegge — present level feels right (one named reference, structural framing, no fawning), but worth checking once the field grows.
• “Runtime BPMN” — claim the term, or yield to whatever the field eventually settles on? Probably yield. Re-examine before publishing.
• Companion artifact — per the publishing-rhythm rule, every quarterly anchor essay ships with a referenceable diagram. The natural one here is a four-quadrant map: (design-time vs runtime) × (human-readable vs agent-readable). Worth drafting separately in /decks of the brand repo.
• Length — currently ~1500 words. If this gets promoted from Journal to a YawningHero quarterly essay, target ~3000 with case detail from the production deployment.