5 sätt som agentiska CMS-arbetsflöden misslyckas (och varför det inte är AI:n)

10 juni 2026

AI:n får skulden för den del som inte var dess fel.

När agentiska CMS-arbetsflöden misslyckas i produktionen ser felet ut som ett AI-problem. Det är det nästan aldrig.

Det är ett problem med innehållsmodellen. Ett styrningsproblem. Ett taxonomiproblem. Ett eskaleringsproblem. Ett ägarskapsproblem. Agenten är den sak somexponerar gapet, inte den sak som skapade det. De team som lyckas med agentiska innehållsarbetsflöden är inte de som har bättre modeller. De är de som fixade driftsmodellen innan de kopplade in agenten.

Jag har arbetat med innehållssystem från varje stol i rummet – byråbyggen, varumärkesbaserad plattformsstyrning och leder nu kunskaps- och utbildningsprogram på Optimizely. Jag har också tillbringat tre år med att undervisa doktorander i mjukvarulivscykel och AI.

Jag har sett alla dessa fem misslyckanden hända. Jag har själv orsakat några av dem.

Här är mina tankar om de fem misslyckandena och några samtal med mitt tidigare jag om vad jag borde ha gjort bättre. Han förtjänade att höra dem tidigare.

1

Innehållsmodellen designades aldrig för att läsas av något annat än en person

De flesta innehållsmodeller i produktion idag designades för människor. En innehållsförfattare öppnar en post, ser fält med namn som "Brödtext" och "Promo Block 2" och "Bild (vänster eller höger)" och fyller i dem baserat på stamkunskap om vad varje fält faktiskt är till för.

Det fungerar eftersom människan vet vad "Promo Block 2" betyder en tisdagsmorgon på det här företaget. Fältnamnet behöver inte ha den betydelsen. Personen gör det.

Patrick, 2016: Vad är det för fel med "Promo Block 2"?

Mycket. Men du skulle inte ha lyssnat.

Patrick, 2016: Testa mig.

Om ungefär åtta år kommer en AI-agent att läsa det fältnamnet. Den kommer att försöka lista ut vad som hör hemma där. Det enda den behöver vara med är namnet. "Promo Block 2" säger ingenting – inte vad som hör hemma där, inte vilken ton texten ska ha, inte vilken publik den betjänar, inte hur den relaterar till "Promo Block 1".

Patrick, 2016: Det behöver den inte. Mike vet vad som ska finnas där.

Mike slutar 2020. År 2025 är den enda personen som vet vad "Promo Block 2" betyder en entreprenör som började förra månaden och gissar baserat på vad som finns i befintliga poster. Agenten gör samma sak, bara snabbare och med högre volym.

Kostnaden för ett oklart fältnamn brukade vara noll eftersom den mänskliga läsningen absorberade luckan. Kostnaden för ett oklart fältnamn med en agent som läser det är kvaliteten på varje innehållsdel som fältet berör – för alltid, i stor skala.

Hur man designar mot det

Behandla fältnamn, beskrivningar och valideringsregler som prompter. För det är de. Kör din innehållsmodell genom samma granskning som du skulle köra en systemprompt igenom. Om ett fältnamn inte berättar för en främling vad som hör hemma där, skriv om det. Om två fält gör liknande saker, komprimera dem eller skärp skillnaden. Arbetet är oglamoröst och de flesta team hoppar över det. Det är just därför det ger en oproportionerlig avkastning att åtgärda det.

2

Styrning skrevs som policy när den behövde skrivas som verkställighet

Varje team jag har sett skapa ett agentiskt innehållsarbetsflöde har ett styrningsdokument. Tre godkännare. Juridisk granskning. Hela grejen. Dokumentet säger vad som är tillåtet, vad som inte är det, vem som godkänner vad och hur eskaleringsvägen ser ut.

Dokumentet är problemet.

Ett policydokument antar volym och hastighet som matchar mänsklig innehållsproduktion. En agent producerar utkast i en takt som den mänskliga granskningsprocessen aldrig byggdes för. Policy som kräver tre godkännare och en juridisk kontroll fungerar vid 20 stycken i veckan. Den kollapsar vid 200. Så teamen antingen får en flaskhals vid granskningen och förlorar den hastighet de jagade, eller så kringgår de tyst policyn och förlorar den styrning de utlovades.

Båda alternativen slutar på samma sätt: du har ingen styrning. Du har ett dokument som beskriver den styrning du brukade ha.

När jag har arbetat med tvärfunktionell styrning för innehållslivscykler har vinsterna inte kommit från att skriva en bättre policy. De har kommit från att behandla styrning på samma sätt som ett ingenjörsteam behandlar kodgranskning. De flesta kontroller automatiseras. Människorna fokuserar på de som behöver bedömning. Systemet bär den lätta bördan så att människorna kan bära den svåra.

Hur man designar mot det

Sluta tänka på styrning som ett policydokument. Börja tänka på det som en kodgranskning. Vad kan tillämpas automatiskt? Regler för varumärkesröst, förbjudna fraser, efterlevnadskontroller, citeringskrav. Vad behöver verkligen en människa? Strategisk positionering, känsliga ämnen, varumärkesdefinierande påståenden. Bygg systemet så att enkel tillämpning sker innan en människa ens ser utkastet, och mänsklig granskning är reserverad för de tio procent där bedömning faktiskt spelar roll.

3

Taxonomin var tillräckligt bra för navigering, men inte tillräckligt bra för resonemang

Jag lanserade en innehålls-taxonomi på byråsidan ungefär 2017 som var strukturellt elegant. Webbplatsbesökare kunde navigera i den. Innehållsförfattare kunde lägga in nya inlägg i den. SEO var nöjd.

Den var inte byggd för att en agent skulle kunna resonera över den.

Patrick, 2017: Taxonomin fungerar. Besökare kan navigera i den, författare kan lägga in inlägg i den, SEO är nöjd. Vad är problemet?

Om tio år kommer ett system som inte navigerar, arkiverar eller bryr sig om SEO att försöka resonera kring det.

Patrick, 2017: Och?

Dina kategorier utesluter inte varandra. "Livsstil" överlappar med "Äventyr" överlappar med "Prestanda". Du löser den suddiga bedömningen med redaktionellt omdöme som lever helt i ditt huvud. En författarevetvar en text hör hemma – och om de inte gör det frågar de i en chatt. Den tysta kunskapen överförs inte till en agent.

Agenten läser taxonomin bokstavligt. När etiketter överlappar varandra oscillerar den. När etiketter är suddiga väljer den fel med säkerhet. Webbplatsnavigeringen ser bra ut. Agenternas arbetsflöden producerar subtilt felaktiga resultat som förvärras över tid.

Patrick, 2017: Det har fungerat i två år.

Det är problemet. Det har fungerat eftersom du har varit där för att få det att fungera.

Hur man designar mot det

Granska din taxonomi för tvetydighet. Välj tio innehållsobjekt och fråga tre personer i ditt team oberoende av varandra var var och en ska arkiveras. Om du inte får samma svar tre gånger är din taxonomi tvetydig – och din agent kommer att ärva tvetydigheten. Antingen skärp etiketterna eller lägg till regler för disambiguering i själva modellen. Arbetet är närmare en synonymordbokövning än en innehållsövning. Innehållsteamen motsätter sig det. Gör det ändå.

4

Det finns ingen eskaleringsväg eftersom ingen trodde att en behövdes

På kundsidan på Arterra skötte jag den tekniska styrningen av den digitala lösningsstacken över intranät, B2B och DTC-kanaler. Jag lärde mig något specifikt om eskaleringsvägar där: de känns bara valfria tills de inte är det. Den dagen något eskalerar är avsaknaden av en väg det dyraste du äger.

De flesta agentiska innehållsarbetsflöden är byggda utan explicit eskaleringslogik. Antagandet är att om något går fel kommer en människa att märka det och ingripa. Detta är okej när volymen är låg. Det blir ett täckningsproblem när volymen skalas, eftersom ingen övervakar alla utdata hela tiden. Agenten skickar något den inte borde ha gjort. Teamet får reda på det via ett kundmejl, en compliance officer eller värre – en journalist.

Mönstret jag ser konsekvent i utvecklarcommunityn: team bygger den lyckliga vägen först och lovar sig själva att de ska lägga till eskaleringslogik senare. De lägger inte till den senare. De lägger till den efter den första incidenten.

Hur man designar mot den

Bygg eskaleringsvägen innan du bygger arbetsflödet. Bestäm explicit vad som utlöser en spärr, vad som utlöser en människa i loopen, vad som utlöser en punkt. Bestäm vem som äger varje nivå. Bestäm hur revisionsspåret ser ut. Om du inte kan formulera vad agenten gör när det är osäkert, har du inget arbetsflöde. Du har en utkastgenerator med en publiceringsknapp bifogad.

5

Ingen äger arbetsflödet från början till slut – så ingen kan fixa det när det går sönder

Det här är det jag ser oftast. Och det är det som minst liknar ett AI-misslyckande.

Patrick, 2016: Alla äger det. Marknadsföringsansvariga, ingenjören, innehållscheferna, IT.

Det är samma sak som att ingen äger det.

Patrick, 2016: Det är hårt.

Det är inte hårt. Det är operativt. När arbetsflödet går sönder – och det kommer att gå sönder – måste du veta vems kalender som öppnas. Just nu har du fyra kalendrar som alla förblir stängda eftersom alla antar att någon annan är med i dem.

Arbetsflödet ställs upp av en marknadschef, med input från en CMS-ingenjör, godkännande från en innehållschef och en säkerhetsgranskning från IT. Alla rör vid det. Ingen äger det. Så när det går sönder lägger teamet två veckor på att lista ut vem som är ansvarig innan någon börjar arbeta med det faktiska problemet.

Jag ser samma mönster i miniatyrundervisning av doktorander på Centennial College. Gruppprojekt där ägarskapet är oklart misslyckas på samma sätt som företagsarbetsflöden misslyckas – bara på en sexveckors tidslinje istället för en sexkvartals. Mekanismen är identisk.

Patrick, 2016: Bra. Så jag utser någon.

En person. Inte en kommitté. Inte en arbetsgrupp. En person som är ansvarig för arbetsflödets beteende, dess resultat och dess utveckling. De behöver inte vara den mest tekniska personen i rummet. De måste vara de vars telefon ringer när något går fel.

Patrick, 2016: Och om ingen vill ha jobbet?

Då har du inget arbetsflöde. Du har ett distribuerat ansvarsschema, vilket innebär att du inte har någonting. Samma resultat som "Promo Block 2", faktiskt. Ingen ville äga det fältnamnet heller.

Hur man designar mot det

Utnämn en enda ägare innan du levererar arbetsflödet. Den personen är ansvarig för arbetsflödets beteende, dess resultat och dess utveckling. Om ingen vill registrera sig för det är arbetsflödet inte redo att levereras.

Vad allt detta leder till

De fem fellägena handlar egentligen inte om AI.

De handlar om innehållsdrift. Innehållsmodellering, styrning, taxonomi, eskalering och ägarskap var alltid avgörande faktorer för om ett innehållssystem fungerade. En agent introducerar inte dessa problem. En agentavslöjar dem – snabbare, med högre volym, med mindre förlåtelse för tvetydighet än något mänskligt team någonsin krävt.

Detta är goda nyheter. Det betyder att arbetet med att få agentiska CMS-arbetsflöden att lyckas är ett arbete som de flesta innehållsteam redan vet hur man gör. Det är inte ny vetenskap. Det är den oglamorösa operativa disciplinen som alltid funnits där, nu synliggjord av ett system som inte bär tyst kunskap på samma sätt som ett mänskligt team gör.

Om du bygger upp ett agentiskt innehållsarbetsflöde just nu, fixa dessa fem saker innan du ansluter agenten.

Agenten kommer att vara den enkla delen.

Vill du se hur Optimizely hanterar detta i praktiken?