From Pattern to Plan - The Genesis of a Domain-Agnostic Workflow System

August 1, 2026

Some ideas don’t arrive in a moment — they form over decades. The idea of thinking about workflows in a domain-agnostic way — as plans made of individual steps, independent of what the task is actually about — is one of them. To understand why, I have to go back about fifteen years.

Fifteen years ago: agencies and a pattern

Back then I was writing WPF-based solutions for advertising and communications agencies — applications that modeled the various states and sequences of actions. And these applications didn’t stay on screen: over protocols like MQTT and OPC UA, they also drove hardware, so that multimedia effects could be composed together — image, sound, light, and physical actuators as a coordinated interplay. And the more of these systems I built, the clearer one thing became: they repeat themselves. Not in detail, but in structure.

The pattern was always the same: the application starts in a kind of idle state — a screensaver, if you will. Then one or more actions are executed. And afterward, the system returns to its idle state and waits for the next trigger.

When something repeats structurally, you shouldn’t keep reprogramming it — you should build it properly once. So I implemented a plugin system: the structure — idle state, trigger, actions, return — was fixed, while the concrete actions were interchangeable building blocks: play a video, switch a lighting scene, drive an actuator over MQTT or OPC UA. And the whole thing could be assembled through configuration instead of code.

About seven or eight years ago: publishers, industry, and an intermediate format

A few years later I found myself — this time for the publishing industry — working on a seemingly quite different problem: importing messages from a variety of channels. The task: accept data from the most diverse sources, transform it into a unified intermediate format, and then store it somewhere — in a database, in a file, wherever.

Alongside that — in an entirely different setting, classical industry with logistics and production — came ETL ingestion pipelines: data imports from CSV files and Excel sheets, which exist there in abundance — item masters, bills of materials, stock levels, delivery data from partners. And every time, the same steps: define the import schema, i.e. determine which column maps to which target field and in what format the values arrive; validate and clean the data; and store the result, structured, in a database. The difference between any two imports was almost never in the mechanics — only in the schema. In the what, not the how.

Sounds different from the agency applications? It isn’t. It’s the same pattern again: a trigger (a new message arrives, a file is delivered), a chain of actions (extract, transform, validate, store), and afterward the system waits again for the next trigger. What I built here were, at their core, ETL pipelines — and the earlier insight held unchanged: the structure is always the same, only the building blocks change.

Three years ago: AI arrives

When AI had its breakthrough moment about three years ago, the next step was obvious to me: I started integrating AI into exactly these workflows. Concretely, that meant: transforming text into the intermediate format, translating it, enriching it with metadata, or extracting metadata directly from the text — and, of course, storing the result back in the database. Tasks that used to require bespoke logic or manual work became AI steps. But the pattern itself didn’t change: AI simply became another building block in the familiar chain — trigger, actions, store, wait.

Yet in the process, an old problem became all the more obvious: with every project, I was reinventing the wheel. The same patterns, implemented again and again, always slightly differently — but never solved once, for good.

The consequence: the domain-agnostic plan

Out of this realization came the thought that has stayed with me ever since: why not build a domain-agnostic system — one that isn’t built for advertising agencies, nor for publishing or industrial pipelines, nor for AI text processing, but for the pattern underneath all of them?

A system that treats any task as a plan: broken down into individual steps that are executed automatically. The structure — trigger, actions, return to idle — built cleanly once; the concrete building blocks interchangeable and combinable into ever-new workflows through configuration. Whether a step reads data from a file, enriches a text via AI, or writes a result to a database is irrelevant to the system itself — it only knows the plan.

This isn’t the idea of a single moment, but the consequence of fifteen years in which the same pattern kept appearing to me in ever-new disguises. At some point you stop reinventing the wheel — and build the axle instead.