A player piano is a beautiful machine and a useless musician. Feed it a perforated roll and it reproduces a performance flawlessly, the same way every time, forever.
But walk in with a request it has no roll for. Or ask it to follow a singer who is half a beat behind tonight. It does the one thing it can. It plays the roll anyway. It cannot hear the room. It was never built to.
Most "AI automation" is a player piano. A workflow engine sits at the centre holding the roll. It calls a model the way the piano triggers a note: when the script says to, in the slot the script defines.
That engine is sturdy, legible, and very good at what it was cut to do. It also cannot improvise. And go-to-market is nothing but improvisation. Every prospect is a different room. Every reply is a singer off the beat.
There is a law that says why this fails, and it is worth knowing by name.
Only variety can absorb variety
In 1956 the cyberneticist W. Ross Ashby stated what became the Law of Requisite Variety. To control a system, a regulator must command at least as many responses as the system can present situations. A controller with five moves loses the moment the world plays a sixth.
His collaborator Roger Conant later put the sharp end on it. Every good regulator of a system must contain a model of that system. To regulate something well, you have to understand it well enough to be a model of it.
Hold the two parts of an AI system against that law.
A workflow is a low-variety regulator by design. Its value is that it does the same defined thing every time. That is what makes it reliable on the structured path and brittle off it. It holds no model of the buyer. It holds a list of branches someone drew on a Tuesday.
The instant the situation is not on the list, the workflow has no move. So it does the player-piano thing and runs the branch regardless.
A frontier reasoning model is the opposite kind of object. It is the highest-variety regulator we can currently put in a machine: a vast learned model of how people, businesses and language behave. It has requisite variety to spare.
By Ashby and Conant both, the reasoner is the thing that should hold the centre. So put it there. Let it govern. Let the workflow become what it was always good at being: a tool the reasoner reaches for. A script, a connector, a deterministic hand it chooses when to use.
You do not hand the piano roll the concert. You hand the pianist a metronome, and let them decide when to glance at it.
This is the whole architectural choice, and the industry mostly has it upside down. The question is not "which workflow tool should orchestrate our AI?" It is "what is the highest-variety intelligence we can put at the centre, and is everything else properly demoted to something it calls?"
The roll yellows
There is a second reason, slower and crueller.
A workflow stack is a frozen snapshot of last quarter's assumptions. A piano roll punched once. The market it was cut for keeps moving. Channels change their terms. Buyers change their habits. The message that landed in March is stale by June. The roll does not move with them.
This is software entropy. It is the same idea the second law of thermodynamics hands us. An ordered arrangement decays toward disorder unless energy is continuously spent against it.
Every brittle branch is a thing that will rot, and someone has to keep pouring in maintenance to hold the line. Teams that live this discover that most of their automation budget goes not on building, but on keeping the old rolls from tearing.
A reasoner at the centre spends that energy differently, and far less of it. It does not store ten thousand frozen rules to defend against the drift. It re-derives the right move from current context each time it runs.
You maintain a living body of context and a thin layer of governance around the intelligence. Not a sprawling flowchart that ages the moment it is drawn. The intelligence adapts. The scaffolding stays small.
That is the structural reason a decision-at-the-centre system ages well, and a workflow-at-the-centre system ages into a maintenance tax.
You can read the pattern in public
You do not have to take the architecture on trust. The most capable agentic tools being shipped are built this way, and built openly enough to read the shape of.
The pattern is consistent across the leading systems. A reasoning model holds the centre. The deterministic parts, the tools and connectors and scripts, are demoted to capabilities the model calls. The brain is decoupled from the hands, and each hand is a stable thing the brain reaches for.
And tellingly, the teams building these tools show enough to make the shape legible and keep the implementation to themselves. The design is public. The build is not. We take the same stance, for the same reason.
Enough of ours to judge it
Our engine, Fulcrum, is built on that principle. It follows the published best practice rather than inventing a private orchestration framework. A frontier reasoner sits at the core.
Around it: an operating contract that fixes voice and the hard "never" rules. A set of versioned, reusable skills. Deterministic, always-on gates that do not relax. A thin governance wrapper. And one durable, structured body of context the system queries rather than guesses against.
Every workflow tool, whether a CRM, a sender or a scraper, enters through a single port as a constrained, swappable capability the intelligence calls. The unit of work is the decision, not the task.
That is the shape. How those decisions are instrumented, graded and trusted with more autonomy over time is the part we keep. The same way the public analogues keep their internals.
The point a founder should take is simpler than the architecture. Put the low-variety thing in charge, and you have placed a hard ceiling on how much intelligence your system is ever allowed to apply, no matter how good the model it calls. Put the high-variety thing in charge, and you let it apply all of it.
We learned this the long way. On the road of trying to make the workflow the master, and the separate road of trying to own the model outright. Both conclusions arrived with receipts.
A player piano will never hear the room. Hire the pianist, and hand it the metronome.
The operating question is not "which tool should run our go-to-market?" It is: "what is the most capable mind we can put at the centre, and have we demoted everything else to something it picks up only when it chooses?" Founder-led. Not founder-limited.