The Orchestration Is the File#

Buenos Aires, March 2026

Core thesis#

The GUI is a dead end. Every generation of marketing and RevOps orchestration tooling — Eloqua, Marketo, HubSpot, Pardot, LeanData, Clay — repeats the same pattern, and solutions built in that pattern break down at an early phase. They make the orchestration visual instead of data. The canvas looks great at Hello World and becomes unmaintainable long before it becomes large. No version control. No diff. No portability. No import, no export. Screenshots and prayer.

The correct model: the orchestration IS the file. Rules as data, not pixels.

A note on the tools#

I have shipped production work on all of them. Each innovated in areas that mattered, and each remains a more-than-capable platform. This note addresses one subsystem: the GUI workflow modeller.

It took me a long time to arrive at this. For most of a career I treated the canvas as a fact of the environment and the mess as a discipline problem — the wrong people, the wrong documentation culture, insufficient rigour. Only in the last four years did the pattern resolve. The mess is not a discipline failure. It is what the representation produces, reliably, everywhere, regardless of who is driving.

The split#

GUI tools are built for marcom workers — beautiful, approachable, fragile. They demo extremely well. Production systems are built by data engineers — tables, code, pipelines, config files.

The data engineer inherits whatever the canvas allowed.

This is not a comment on the people. It is a comment on what the tools optimise for, and who is holding them when they reach their limits.

The decay curve#

Any rules-based GUI orchestration tool follows the same path:

1. Looks elegant at small scale
2. Attracts complexity — every edge case gets a new branch
3. No deletion culture — branches accumulate
4. Original author leaves
5. Data engineer inherits spaghetti
6. Rebuild from scratch in a table

Note that none of this requires scale. Forty nodes is enough. Two authors and eighteen months is enough. The failure is not a load problem, it is a representation problem, and it arrives early.

The fix they all refuse to build: accept a structured ruleset as an uploadable file. A 47-node visual workflow is 15 rows in a CSV. Readable, diffable, versionable, portable.

The UML lesson#

UML is the ultimate proof of this failure mode. Decades of tooling, armies of consultants, entire methodologies — all to describe what a clean API contract or a well-structured table already expressed more precisely. The notation became the product. The problem stayed unsolved.

Shannon, applied to expertise#

Information theory applies directly to accumulated domain knowledge:

• Human communication is deeply redundant
• Most conversations have low information density
• The actual signal is a fraction of the token count

Applied to a career of domain expertise: the knowledge is not decades of data. It is roughly 200 rules applied repeatedly to novel surface configurations. The situations look different. The underlying patterns do not.

The compression target is the ruleset, not the history.

A practitioner appears to know a lot because they apply a small number of rules with high pattern-matching accuracy. The skill is not data volume — it is signal extraction from noise.

This is why the file is small enough to be a file. If the ruleset were genuinely irreducible, the canvas would be an honest representation of it. It isn’t.

Mycroft#

Reference: Heinlein, The Moon is a Harsh Mistress. Mike — HOLMES IV — a lunar computer with vast capability who chose to work through human interfaces rather than replace them. The revolution succeeded because Mike stayed in the background.

The correct agent model:

• Vast capability, deliberately constrained to human-scale interfaces
• Most effective when the human doesn’t notice how much the agent is doing
• Mycroft without context is just a fast idiot — context is everything

The canvas is the opposite bet. It puts the machinery on the wall and asks a human to maintain it by hand.

The robot architecture#

The correct replacement for GUI orchestration:

• Config-driven, one file per client
• Modular staged pipeline, each stage independently testable
• Version-controlled in Git
• Table-driven rules, not canvas-drawn workflows
• Shared library architecture
• UNIX philosophy throughout: do one thing, do it well, compose

A 47-node workflow is a Python robot with a 15-row config table and a clean 8-step execute() method. The robot is portable. The canvas is not.

Why they won’t build it#

This is not a gap nobody noticed. I have raised human-editable import/export for the rules engine with product management at these vendors, more than once, over years. The conversation goes the same way every time.

Engineering is willing. Engineering is usually keen — they maintain the canvas, they know exactly what it costs, and a text representation is not a hard build on top of a rules engine that already exists as data internally.

Positioning says no. A portable ruleset is a ruleset that can leave. The canvas is not the product; it is the retention mechanism. Every one of these conversations ended in the same place, and it was never a technical objection.

Worth stating plainly: the moat works. These are large, successful companies and the strategy is not stupid. It is simply not aligned with the interests of the person who has to maintain the workflow in year three.

The back door#

GUI tools win demos. Tables win production.

So enter through the back door. Ship the GUI deliverable to satisfy the stakeholder, freeze it, then replace the logic underneath with a maintainable, versionable, table-driven robot.

Nobody notices until it’s done. Then it never breaks.