The automated business as a control system
When a business runs mostly on software — software that watches the market, decides what to do, and then does it — the honest description isn't “a company with good tooling.” It's a control system. A closed loop. And once you see it that way, the recurring failures stop feeling like bugs and start feeling like missing organs.
This week I sat down and mapped the whole thing onto that model. Not to rewrite anything — just to see it clearly. Seven pillars, and one feedback arc that has to close or none of it learns.
+--------------------------------------------------------------------+
| OBJECTIVE: maximize d(revenue - cost)/dt |
+--------------------------------------------------------------------+
^ |
| FEEDBACK: predict -> act -> settle -> measure -> refit |
| v
+------------+ +-----------+ +------------+ +------------+
| 1 SENSORS |-->| 2 WARE- |-->| 3 MODELS / |-->| 4 CONTROL |
| / ETL | | HOUSE | | PREDICTORS| | LAW |--> decisions
+------------+ +-----------+ +------------+ +-----+------+
|
+-------------+ approvals/gates v
| 7 GOVERNANCE|<--------------------+ +------------+
| (policy, | | 5 ACTUATORS|
| RBAC, | | / workflow|
| gates) | +-----+------+
+-------------+ |
v
+--------------------+
| 6 ORCHES- |
| TRATOR (the tick) |
+--------------------+
You sense the world. You write what you sensed down as durable facts. You turn facts into predictions. You turn predictions into decisions. You execute decisions deterministically. Something has to tick the whole thing. And something has to decide which decisions a human must sign off on. Around it all runs the loop: predict, act, settle, measure, refit. The objective sits on top.
This isn't a metaphor dressed up as rigor; there's real math underneath. Allocating finite capacity under uncertainty is a Bandits-with-Knapsacks problem. Competing for share against other providers is Hotelling. Comparing options that consume different things needs a common currency — dollars per unit of the resource that actually binds (the dominant resource). And every prediction has to be checked against what later really happened, or the model never improves. When those four are wired, the loop closes. When any one is missing, you feel it — usually as a decision that keeps going wrong for reasons no one can quite name.
The four gaps (and they're not just ours)
Mapping our own system onto this model, four gaps kept appearing. The point of writing them up is that they're not idiosyncratic — they're the standard failure modes of any automated business. If you're running one, three of these are probably true for you too.
1. The loop that never reconciles. The expensive one. You build a predictor — if we deploy capacity here, we expect to earn this much — you act on it, and then you never write the prediction down, never compare it to the outcome once it matures, never feed the error back into the model. The predictor stays a one-shot guess forever. It feels like the loop is closed, because you're busy acting on predictions. It isn't. You built the feed-forward half and omitted the feedback half. We had a whole class of allocation decisions running with literally zero outcome records — every projection a guess that refined nothing. The fix is unglamorous and essential: log every {input, prediction} at decision time, reconcile after the result comes in, and let the error move the weights.
2. Optimizing the wrong resource. You measure one resource and build the entire objective function around it — in our case, dollars per unit of disk. But a different resource (RAM, as it happened) was the one that actually bound, and the system quietly mis-allocated because the objective was looking at the wrong dimension. The lesson generalizes: find your dominant resource empirically — the one whose exhaustion coincides with failure — and price everything in dollars per unit of that. Multi-resource accounting isn't a polish step; it's the whole game. An optimizer with the wrong denominator is an optimizer that confidently makes the wrong call.
3. The loop wired for accounting, not control. The subtlest gap. You measure your prediction error. You even graph it on a dashboard. But the number never flows back into the policy — the smoothing weight doesn't update, the parameters don't move. The loop is closed for accounting and open for control. Everything looks wired: predict, settle, and measure are all present and running. What's missing is the last wire — the one that would make the model actually self-correcting. A calibration number that nobody reads is a feedback loop that doesn't exist.
4. Control law as “legal prose.” The hardest to fix, and probably the root of the other three. The control logic doesn't live in one place. It's smeared across cron schedules, config files, natural-language prompt files, and a growing sediment of glue scripts whose only reason for existing is to hold the others together. The friction of closing any of the gaps above — stand up a new cron, write a new task file, wire a new tool call, add a new lock, add a new monitor for the new cron — is itself the reason those feedback legs stayed unbuilt for so long. In this shape, the boilerplate is the bug. The cost of adding the loop exceeds the will to add it.
Where this points
That last gap points at the real fix, and it's structural rather than tactical. The control law wants to be live code: a single runtime you patch in place, where closing a feedback leg is editing one function rather than standing up three scheduled jobs and a document. External systems — the warehouse, the execution engine, monitoring, the judgment model — become libraries (or, if you like, syscalls). Governance becomes code you can read and change, instead of prose that a model has to interpret and a human has to enforce. We aren't there yet. This map is the current-state drawing that a future like that would start from.
If you're building or running an automated business, the exercise is cheap: draw the seven pillars, then trace the feedback arc end to end and mark where it actually closes. The predictor with no outcome records. The resource you don't price. The error that never makes it back into the policy. The logic scattered across prose and cron. Those breaks are the roadmap — and in a business that runs on software, the architecture is the strategy.