5 ways agentic CMS workflows fail (and why it isn't the AI)

The Content Model Was Never Designed to Be Read by Anything But a Person

Most content models in production today were designed for humans. A content author opens an entry, sees fields with names like "Body" and "Promo Block 2" and "Image (Left or Right)," and fills them in based on tribal knowledge about what each field is actually for.

It works because the human knows what "Promo Block 2" means on a Tuesday morning at this company. The field name doesn't have to carry that meaning. The person does.

Patrick, 2016: What's wrong with "Promo Block 2"?

A lot. But you wouldn't have listened.

Patrick, 2016: Try me.

In about eight years, an AI agent is going to read that field name. It's going to try to figure out what belongs there. The only thing it has to go on is the name. "Promo Block 2" tells it nothing — not what belongs there, not what tone the copy should take, not what audience it serves, not how it relates to "Promo Block 1."

Patrick, 2016: It doesn't have to. Mike knows what goes in there.

Mike leaves in 2020. By 2025 the only person who knows what "Promo Block 2" means is a contractor who started last month and is guessing based on what's in existing entries. The agent does the same thing, just faster and at higher volume.

The cost of an unclear field name used to be zero because the human reading it absorbed the gap. The cost of an unclear field name with an agent reading it is the quality of every piece of content that field touches — forever, at scale.

How to design against it

Treat field names, descriptions, and validation rules as prompts. Because they are. Run your content model through the same review you'd run a system prompt through. If a field name doesn't tell a stranger what belongs there, rewrite it. If two fields do similar things, collapse them or sharpen the distinction. The work is unglamorous and most teams skip it. That's exactly why fixing it produces an outsized return.

Governance Was Written as Policy When It Needed to Be Written as Enforcement

Every team I've watched stand up an agentic content workflow has a governance document. Three approvers. Legal review. The whole thing. The document says what's allowed, what isn't, who approves what, and what the escalation path looks like.

The document is the problem.

A policy document assumes volume and velocity that match human content production. An agent produces drafts at a rate the human review process was never built for. Policy that requires three approvers and a legal check works at 20 pieces a week. It collapses at 200. So teams either bottleneck at review and lose the speed they were chasing, or they quietly bypass the policy and lose the governance they were promised.

Both options end the same way: you don't have governance. You have a document that describes governance you used to have.

When I've worked on cross-functional governance for content lifecycles, the gains haven't come from writing a better policy. They've come from treating governance the way an engineering team treats code review. Most checks get automated. The humans focus on the ones that need judgment. The system carries the easy load so the people can carry the hard one.

How to design against it

Stop thinking of governance as a policy document. Start thinking of it as a code review. What can be enforced automatically? Brand voice rules, banned phrases, compliance checks, citation requirements. What genuinely needs a human? Strategic positioning, sensitive topics, brand-defining claims. Build the system so easy enforcement happens before a human ever sees the draft, and human review is reserved for the ten percent where judgment actually matters.

The Taxonomy Was Good Enough for Navigation, But Not Good Enough for Reasoning

I shipped a content taxonomy on the agency side in roughly 2017 that was structurally elegant. Site visitors could navigate it. Content authors could file new entries into it. SEO was happy.

It was not built for an agent to reason over.

Patrick, 2017: The taxonomy works. Visitors can navigate it, authors can file into it, SEO is happy. What's the problem?

In ten years, a system that doesn't navigate or file or care about SEO is going to try to reason over it.

Patrick, 2017: And?

Your categories aren't mutually exclusive. "Lifestyle" overlaps with "Adventure" overlaps with "Performance." You're resolving that blur with editorial judgment that lives entirely in your head. An author just knows where a piece belongs — and if they don't, they ask in a chat. That tacit knowledge doesn't transfer to an agent.

The agent reads the taxonomy literally. When labels overlap, it oscillates. When labels are fuzzy, it picks the wrong one with confidence. The site navigation looks fine. The agentic workflows produce subtly wrong outputs that compound over time.

Patrick, 2017: It's worked for two years.

That's the problem. It's worked because you've been there to make it work.

How to design against it

Audit your taxonomy for ambiguity. Pick ten content items and ask three people on your team independently where each one should be filed. If you don't get the same answer three times, your taxonomy is ambiguous — and your agent will inherit the ambiguity. Either tighten the labels or add disambiguation rules into the model itself. The work is closer to a thesaurus exercise than a content exercise. Content teams push back on it. Do it anyway.

There's No Escalation Path Because Nobody Thought One Was Needed

On the customer side at Arterra, I ran the technical governance of the digital solutions stack across intranet, B2B, and DTC channels. I learned something specific about escalation paths there: they only feel optional until they're not. The day something escalates, the absence of a path is the most expensive thing you own.

Most agentic content workflows are built without explicit escalation logic. The assumption is that if something goes wrong, a human will notice and intervene. This is fine when volume is low. It becomes a coverage problem when volume scales, because nobody is monitoring all outputs all of the time. The agent ships something it shouldn't have. The team finds out from a customer email, a compliance officer, or worse — a journalist.

The pattern I see consistently across the developer community: teams build the happy path first and promise themselves they'll add escalation logic later. They don't add it later. They add it after the first incident.

How to design against it

Build the escalation path before you build the workflow. Decide explicitly what triggers a hold, what triggers a human in the loop, what triggers a full stop. Decide who owns each level. Decide what the audit trail looks like. If you can't articulate what the agent does when it's uncertain, you don't have a workflow. You have a draft generator with a publishing button attached.

Nobody Owns the Workflow End to End — So Nobody Can Fix It When It Breaks

This is the one I see most often. And it's the one that looks least like an AI failure.

Patrick, 2016: Everyone owns it. Marketing ops, the engineer, the content director, IT.

That's the same as nobody owns it.

Patrick, 2016: That's harsh.

It's not harsh. It's operational. When the workflow breaks — and it will break — you need to know whose calendar opens up. Right now, you have four calendars that all stay closed because everyone assumes someone else is on it.

The workflow gets stood up by a marketing operations lead, with input from a CMS engineer, sign-off from a content director, and a security review from IT. Everyone touches it. Nobody owns it. So, when it breaks, the team spends two weeks figuring out who's responsible before anyone starts working on the actual problem.

I see the same pattern in miniature teaching postgrad students at Centennial College. Group projects where ownership is fuzzy fail the same way enterprise workflows fail — just on a six-week timeline instead of a six-quarter one. The mechanism is identical.

Patrick, 2016: Fine. So I name someone.

One person. Not a committee. Not a working group. One person who is accountable for the workflow's behavior, its outputs, and its evolution. They don't need to be the most technical person in the room. They need to be the one whose phone rings when something goes wrong.

Patrick, 2016: And if nobody wants the job?

Then you don't have a workflow. You have a distributed responsibility chart, which means you have nothing. Same outcome as "Promo Block 2," actually. Nobody wanted to own that field name either.

How to design against it

Name a single owner before you ship the workflow. That person is accountable for the workflow's behavior, its outputs, and its evolution. If no one will sign up for that, the workflow isn't ready to ship.