The process was carrying the rules
We used to enforce governance by making software annoying. That worked right up until people could route around the software entirely.
For decades, the answer to “how do we get better at doing work” was improve the process. Take ten people, a pile of steps, and six handoffs to get one thing done. So you mapped it and made it better. Kill some steps, move people around, automate the repetitive parts. Hammer and Champy built the “re-engineering” movement on that in the 1990s and I still think their diagnosis holds up. Find the big processes, find where they hurt, streamline, automate, measure, repeat.
AI is starting to break this.
What I keep landing on is that putting a process into software was never only about speed. You were making decisions about how the work should happen and then freezing them. The CRM says “your company has six stages for customer acquisition.” The ERP says “these are the steps for how an order gets entered and processed.” The expense system says “these purchases need approval.” The dashboard says this is how conversion gets calculated.
That software stored somebody’s idea of how the company works, and the idea got a vote on every piece of work that touched it afterward. It kept enforcing an ideal state long after the state stopped being ideal.
Sometimes that’s useful and sometimes it’s maddening. Anyone who’s worked inside a big company knows what happens next. People get tired of the “perfect process” because it isn’t perfect anymore, and they route around it. They export to Excel, keep another spreadsheet, send it over email instead, build a little internal tool, go ask an analyst for a different report. The official system doesn’t quite fit the work they’re actually trying to do, and AI makes routing around it massively easier.
It also makes it more tempting. I’m not on an enterprise sales team (just my own), but I’ve been on a few, and finding the information was never the hard part. Every customer is different, and you get one deck. One deck that has to talk to everybody equally, which means it talks to nobody in particular. Point an AI at the CRM, the ERP, email, Slack and the support system, let it transform all of that freely, and the deck stops having to be one deck. MCP is what makes that practical, because systems can hand over their information directly instead of through screens somebody designed years ago. The official system was built to serve everybody at once, and now nobody has to settle for that.
Which raises the question this whole note is about. If every prep is bespoke, who decides what that deck is allowed to promise?
Nobody decided that number
I worked at a company where people routed around the official tool. Maybe more than once.
The dashboard everybody used got built because an engineer had some free time and was sick of being asked to write the same queries every other day. He started from a template. Why did it look the way it looked? Because that’s what the template did. Why did the template do that? Nobody knew, and nobody asked. The data on it was genuinely interesting and it didn’t help anyone decide anything.
So the users asked for an export, because they wanted to do it themselves, which is what people always want. Product said no. An export means the user leaves the tool, and time in the tool was something somebody was measured on. Design disagreed with Product. Then nothing happened for a long time.
Then somebody added a chatbot.
Now anyone can ask their own question and get an answer shaped to that question, which is what the export was for in the first place. Different people get different results and most of the time that’s the point. Shadow spreadsheets on steroids. It’s also single player, one person and their question and their answer, and the results are inconsistent. Two people asking the same thing in different words don’t necessarily land in the same place.
The inconsistency is the obvious complaint. What happened to the method is the wild part. That old dashboard had a definition. An accidental definition, inherited from a template by a guy who wanted to be left alone, but it was visible and it was the same number for everybody. The chatbot’s answer turns up with no method attached at all, and nobody asks for one. Gospel moved from the process to the output.
Three kinds of friction
It’s easy to make fun of enterprise software and I’ve done plenty of it. But some of that friction was governance wearing a UI. A required field is annoying, and it might also be a decision the company made: you can’t call an opportunity qualified unless you know who the decision maker is. An approval step slows everything down, and it might also exist because nobody should be able to hand a customer a 40% discount on their own. A locked definition in a dashboard is frustrating, and at least everybody’s arguing about the same number.
Then go back to that dashboard. Governance didn’t block the export. Somebody’s engagement metric did. And the definition on the screen came from a template nobody had ever examined.
So there are at least three kinds of friction and from the outside they look identical. Rules that are load bearing. Accidents nobody ever revisited. Somebody else’s incentive. Most arguments about enterprise software treat all three as the same thing, which is nonsense, and the constraint never tells you which one it is. Tearing them all out is fast and satisfying. Working out which ones mattered is slow and nobody budgets for it.
So where do the rules live now?
Historically the governance hid inside the process. The software wouldn’t let you continue, the form required the field, the workflow required the approval, the dashboard contained the approved definition. When the path goes dynamic those controls have to live somewhere else, and they stop reading like instructions. First do this, then do this, then send it to Sarah. They start reading like boundaries. This is the outcome, these are the authoritative sources, these definitions can’t change, you can decide these, these ones need approval, these actions get recorded.
Some of that has an obvious home. Definitions belong in whatever the company treats as its semantic layer. Decision rights and access look like permissions and scopes. What happened looks like an audit log.
Intent, acceptable assumptions and stop conditions have no obvious home at all. Right now they live in a document somebody wrote, which isn’t a control. It’s a suggestion with good formatting. Everybody wants the magic layer that fixes this and I haven’t seen one.
Standardize less of the work and more of the truth
Maybe nobody needs to follow the same 17-step process. Maybe nobody needs to look at the same interface or produce the same report. One person works through a conversation with an AI, somebody else wants a dashboard, somebody else wants a spreadsheet, and that’s fine.
What the company has to agree on sits underneath all of that. As far as I can tell it comes down to six things.
Intent. What are we actually trying to accomplish?
Information. What does the company know, and which source wins?
Rules. What has to stay true. What revenue means, what counts as a customer, who owns it.
Authority. Who, or what, can decide and act, and what needs a human first?
Judgment. When should somebody stop, because the request doesn’t make sense?
Feedback. What happened, and what did we learn?
Those six aren’t a sequence, and that’s the point. The route between them can be different for every person and different next week. The path stops being the thing you design.
Writing them down is harder than it sounds. A person picks most of this up by being in the room, and nobody ever had to make it explicit. An agent has no room to be in. That’s the work nobody budgeted for, and it’s the part I’m least sure about.
The obvious objection
An explicit constraint layer is a process. Somebody owns it, a committee edits it, definitions drift after a reorg and nobody updates them, and three years later it’s the dashboard nobody trusts, except now it’s also telling agents what they’re allowed to do. I don’t think that’s avoidable and I’m not going to pretend it is.
What I’d argue is that an explicit constraint rots where you can see it. A rule buried in a required field rots silently, and the only symptom is that your best people quietly stop using the system. By the time that shows up you’re screwed, because every workaround they built on the way out is load bearing now too.
There are also places where this whole argument is wrong. If the path is the product you don’t want it dynamic. Clinical trials, financial reporting, anything that gets audited: there the 17 steps exist so you can prove afterward that the 17 steps happened. “People and agents found their own route” is the one thing you can’t say to a regulator.
AI doesn’t change human nature. People will still disagree, optimize for their own goals, build workarounds and keep information to themselves. It hands each person a lot more leverage and pretty soon it hands their agents the same thing, so alignment gets more important.
Before anybody tears down the constraints, somebody should work out which ones were load bearing. The future enterprise probably has far fewer rigid workflows and just as many rules. Instead of designing every step a person takes, you design the room they’re trusted to work in.
Know where this has to go, and not how?
Twenty minutes. Tell me where you want this company to be in two years and I’ll tell you what I’d go look at first.