The CMS chose your editorial workflow before anyone drew a template. Artificial intelligence (AI) is now making the same kind of quiet choice about how work and learning get done, and the durable skill is noticing it.
Somewhere in your operation there is a shared document that knows more than your software does. It holds the real run of show and the real dates. Next to it there is a person whose sign-off is the actual gate, whatever the status dropdown claims to be doing.
Most teams I have worked with have some version of both, plus a status label that everyone has quietly agreed means something other than what it says. “Pending review” means the photo desk has it. “Draft” means it published once and came back down.
It is tempting to read all of that as sloppiness, or as a discipline problem that a new policy will tidy up. I would read it as measurement. Every one of those workarounds was built by a competent person under deadline pressure, and it survived because it works. That makes it evidence. Each one marks a spot where the way your organisation actually gets work done is pressing against the way your tools assumed you would.
Here is the part worth sitting with in 2026. Your tools make those decisions constantly, most of them before you ever log in, and the newest tool in the building makes more of them and hides them better. When you drop an AI assistant into how your team writes and teaches, it arrives with an opinion about how that work should flow, the same way your content system did. The difference is speed and confidence. The CMS at least made you click through its assumptions. A model will just quietly do the thing its defaults point at, and thank you for the chance.
Every tool ships with an opinion
Think about moving into a rented flat with someone else’s kitchen. The cutlery drawer is across the room from the dishwasher, because whoever laid it out cooked differently than you do. You do not rip out the cabinets. You put a jar of forks on the counter next to the dishwasher and get on with your life. Six months later that jar is invisible to you, but it is still an accurate record of a disagreement between the room and the cook.
Software is laid out by someone too. WordPress has a strong assumption underneath it: a person writes something, another person with more authority looks at it, then it becomes public. The roles are shaped around that path. Most enterprise content systems carry a version of the same assumption, usually with more steps and a heavier approval chain. That default is a sensible one, and it fits an enormous number of organisations.
It just is not universal. And when your organisation runs a different shape, the gap does not announce itself as an architecture problem. It shows up on the counter instead: a spreadsheet, a Slack channel, one editor who is the real approval step, a naming convention nobody wrote down. AI tools do the same thing on a shorter clock. Ask a model to help run an editorial process and it will happily assume a house style and a definition of “done,” and it will be wrong in the exact places your operation is unusual, which are the places that matter most.
canada.com had no reporters
In 2011 and 2012 I ran WordPress VIP environments through Postmedia’s network migration, moving eleven newspapers onto one parent theme, the National Post and the Montreal Gazette among them. I also worked on the portal architecture and child theme build for canada.com. That site is the clearest example I have of a workflow decision made on purpose, before anyone drew a template.
Every Postmedia daily ran a newsroom model, and the system was a good fit for it. A contributor files, a section editor reviews, and a publisher sits above them. The software enforces the path. Roles map to real desks. Status changes correspond to something that actually happens in a building.
canada.com had no editorial staff of its own. No reporters or assignment editors, and no city desks either. It gathered coverage from the eleven regional papers and presented it under a national domain. The people working on it decided what a national audience should see from a day’s output across eleven markets, and in what order.
That is not a newsroom. It is a portal, and the two want different systems. Forcing canada.com into the newsroom model would have produced roles nobody occupied and approval steps that guarded nothing. It would have worked in the sense that pages would have published. It would also have generated its own jar of forks inside a month.
Naming it as a portal settled a run of decisions that would otherwise have been argued one at a time for a year: what the roles were for, and what a status actually meant.
The hard problem was taxonomy, and the fix was upstream
Eleven newspapers meant eleven section structures, none of them consistent with the others. One paper’s Life section overlapped another paper’s Arts and a third paper’s Entertainment. Each structure reflected a real newsroom with real desks and decades of local habit.
The obvious move is to reconcile it in the front end: write template logic that knows the eleven vocabularies and maps them at display time. That approach ships quickly and then costs forever, because every new template inherits the mapping problem, and the mapping lives in whichever developer’s head last touched it.
We normalised categories at ingestion instead. Content arrived from a paper, got mapped into the portal’s own taxonomy on the way in, and everything downstream saw one clean vocabulary. Templates got simpler. Editors curating the front page worked with terms that meant one thing.
Notice that this is the same decision as before, several layers down. A newsroom’s taxonomy describes its own desks, so it belongs to the paper. A portal’s taxonomy describes an audience it is presenting to, so it belongs to the portal, and content has to be translated into it at the border. Get the model right and the technical choice mostly falls out of it. That last line is the one I would tape to the wall before letting any AI tool near a process, because a model is very good at producing a confident answer on top of a muddled model, and it will hand you eleven vocabularies dressed up as one and sound sure about it.
All of this ran on the same VIP parent theme as every Postmedia paper. Shared infrastructure applied equally across the network. What differed was posture. canada.com and the National Post sat on one platform and looked nothing like each other, which was the point. The architecture held from launch until Postmedia retired the canada.com brand in 2014, a business decision rather than a technical one. Three years in production is a reasonable test of whether the model was right.
There is more detail in the canada.com case study, and the network-wide picture is in the Postmedia VIP migration write-up.
Working out what your tools assume
You probably do not run a newspaper network or a national portal, and the software in question might be an AI assistant rather than a content system. The method still transfers, and you can do all of it yourself in an afternoon without a developer in the room.
Start with the workarounds, because they are already an audit somebody else did for free. Write down every place your team keeps information outside the tool, every status whose label has drifted from its meaning, and every approval that happens in conversation rather than in software. Do not fix anything yet. Just list it, and for each item write one sentence about what it is compensating for.
Then write the sentence your tool believes. Two lines, plain language: who makes a thing, and who decides it goes out. For a stock WordPress install that sentence is roughly “an author writes a post and an editor approves it.” For an AI writing assistant it is closer to “the model drafts and a human skims before it ships,” which is a decision about where judgment lives, made by a vendor you never met. Now write the sentence your organisation actually runs. If your real answer is “five contributors submit, one person schedules everything, and legal reads anything about the hospital,” you have just found a genuine mismatch and a specific one.
Compare the two sentences and check your list. The workarounds will cluster in exactly the places where the sentences disagree. That clustering is the useful output, because it tells you which single gap to close first, and it usually turns out to be smaller than the plugin catalogue or the AI roadmap implies. Sometimes it is one custom role. Often it is just renaming a status so the label and the meaning agree again, or deciding out loud which parts of the work a model is allowed to settle and which parts a person still owns.
This matters more with AI than it ever did with a CMS, because the failure is quieter. A content system that assumes the wrong workflow annoys people until they build a workaround. A model that assumes the wrong workflow produces plausible output that nobody builds a workaround for, because nothing looked broken. The same trap shows up in classrooms, where the tool quietly decides what counts as learning. I wrote about the two ways teaching with AI goes wrong, and both of them start right here, with a default nobody chose on purpose.
Occasionally the exercise shows the system is fine and the room has simply never been shown what it can already do. That is a teaching job, and I wrote up what two days of it looks like in a newsroom curriculum.
I am not arguing that every organisation needs custom architecture, or that AI belongs nowhere near your process. Most operations fit the defaults well, and that is fine. I am arguing that the decision has already been made on your behalf, by a content system years ago and by a model this quarter, and it is worth a couple of hours to find out what it was before you spend money or trust changing something else.
Do the two-sentence exercise on your own operation this week, and run it on whatever AI you have let in as well as the CMS you have run for years. If the sentences disagree badly enough that the workarounds have become load-bearing, that is the point where outside help earns its keep, and it is the kind of work I do with publishers.
Leave a reply