5 måter agentiske CMS-arbeidsflyter mislykkes på (og hvorfor det ikke er AI-en)

10. juni 2026

AI-en får skylden for den delen som ikke var dens feil.

Når agentiske CMS-arbeidsflyter feiler i produksjon, ser feilen ut som et AI-problem. Det er den nesten aldri.

Det er et innholdsmodellproblem. Et styringsproblem. Et taksonomiproblem. Et eskaleringsproblem. Et eierskapsproblem. Agenten er det somavslører gapet, ikke det som skapte det. Teamene som lykkes med agentiske innholdsarbeidsflyter er ikke de med bedre modeller. Det er de som fikset driftsmodellen før de koblet til agenten.

Jeg har jobbet med innholdssystemer fra alle stoler i rommet – byråbygging, plattformstyring på merkevaresiden, og nå leder jeg kunnskaps- og utdanningsprogrammer hos Optimizely. Jeg har også brukt tre år på å undervise i programvarelivssyklus og AI til studenter på masternivå.

Jeg har sett alle disse fem feilene skje. Jeg har forårsaket noen av dem selv.

Her er mine tanker om de fem feilmodusene og noen samtaler med mitt tidligere jeg om hva jeg burde ha gjort bedre. Han fortjente å høre dem før.

1

Innholdsmodellen ble aldri designet for å leses av noe annet enn en person

De fleste innholdsmodeller i produksjon i dag ble designet for mennesker. En innholdsforfatter åpner en oppføring, ser felt med navn som "Brødtekst" og "Promo Block 2" og "Bilde (venstre eller høyre)", og fyller dem ut basert på stammekunnskap om hva hvert felt faktisk er til for.

Det fungerer fordi mennesket vet hva "Promo Block 2" betyr på en tirsdag morgen i dette selskapet. Feltnavnet trenger ikke å ha den betydningen. Personen gjør det.

Patrick, 2016: Hva er galt med "Promo Block 2"?

Mye. Men du ville ikke ha lyttet.

Patrick, 2016: Prøv meg.

Om omtrent åtte år kommer en AI-agent til å lese det feltnavnet. Den kommer til å prøve å finne ut hva som hører hjemme der. Det eneste den må stå på er navnet. «Promo Block 2» forteller den ingenting – ikke hva som hører hjemme der, ikke hvilken tone teksten skal ha, ikke hvilket publikum den tjener, ikke hvordan den forholder seg til «Promo Block 1».

Patrick, 2016: Det trenger den ikke. Mike vet hva som skal inn der.

Mike slutter i 2020. Innen 2025 er den eneste personen som vet hva «Promo Block 2» betyr en entreprenør som startet forrige måned og gjetter basert på hva som står i eksisterende oppføringer. Agenten gjør det samme, bare raskere og med høyere volum.

Kostnaden for et uklart feltnavn pleide å være null fordi mennesket som leste det absorberte gapet. Kostnaden for et uklart feltnavn med en agent som leser det er kvaliteten på hvert innholdsstykke det feltet berører – for alltid, i stor skala.

Hvordan designe mot det

Behandle feltnavn, beskrivelser og valideringsregler som ledetekster. Fordi det er de. Kjør innholdsmodellen din gjennom den samme gjennomgangen som du ville kjørt en systemledetekst gjennom. Hvis et feltnavn ikke forteller en fremmed hva som hører hjemme der, skriv det på nytt. Hvis to felt gjør lignende ting, skjul dem eller skjerp skillet. Arbeidet er lite glamorøst, og de fleste team hopper over det. Det er nettopp derfor det å fikse det gir en overdimensjonert avkastning.

2

Styring ble skrevet som policy da den måtte skrives som håndheving

Hvert team jeg har sett sette opp en agentisk innholdsflyt har et styringsdokument. Tre godkjennere. Juridisk gjennomgang. Hele greia. Dokumentet sier hva som er tillatt, hva som ikke er det, hvem som godkjenner hva, og hvordan eskaleringsveien ser ut.

Dokumentet er problemet.

Et policydokument forutsetter volum og hastighet som samsvarer med menneskelig innholdsproduksjon. En agent produserer utkast med en hastighet den menneskelige gjennomgangsprosessen aldri ble bygget for. Policy som krever tre godkjennere og en juridisk sjekk fungerer med 20 stykker i uken. Den kollapser ved 200. Så teamene får enten flaskehals ved gjennomgang og mister hastigheten de jaktet på, eller de omgår stille policyen og mister styringen de ble lovet.

Begge alternativene ender på samme måte: du har ikke styring. Du har et dokument som beskriver styringen du pleide å ha.

Når jeg har jobbet med tverrfunksjonell styring for innholdslivssykluser, har ikke gevinstene kommet fra å skrive en bedre policy. De har kommet fra å behandle styring slik et ingeniørteam behandler kodegjennomgang. De fleste kontroller blir automatiserte. Menneskene fokuserer på de som trenger vurdering. Systemet bærer den enkle byrden, slik at folket kan bære den vanskelige.

Hvordan designe mot det

Slutt å tenke på styring som et policydokument. Begynn å tenke på det som en kodegjennomgang. Hva kan håndheves automatisk? Regler for merkevarestemmer, forbudte fraser, samsvarskontroller, siteringskrav. Hva trenger virkelig et menneske? Strategisk posisjonering, sensitive emner, merkedefinerende påstander. Bygg systemet slik at enkel håndheving skjer før et menneske i det hele tatt ser utkastet, og menneskelig gjennomgang er reservert for de ti prosentene der vurdering faktisk betyr noe.

3

Taksonomien var god nok for navigering, men ikke god nok for resonnering

Jeg lanserte en innholdstaksonomi på byråsiden omtrent i 2017 som var strukturelt elegant. Besøkende kunne navigere i den. Innholdsforfattere kunne legge inn nye innlegg i den. SEO var fornøyd.

Den var ikke bygget for at en agent skulle kunne resonnere over den.

Patrick, 2017: Taksonomien fungerer. Besøkende kan navigere i den, forfattere kan legge inn innlegg i den, SEO er fornøyd. Hva er problemet?

Om ti år vil et system som ikke navigerer, arkiverer eller bryr seg om SEO, prøve å resonnere over det.

Patrick, 2017: Og?

Kategoriene dine utelukker ikke hverandre. «Livsstil» overlapper med «Eventyr» og «Ytelse». Du løser opp i den uskarpheten med redaksjonell vurdering som lever utelukkende i hodet ditt. En forfatter vet bare hvor et verk hører hjemme – og hvis de ikke gjør det, spør de i en chat. Den tause kunnskapen overføres ikke til en agent.

Agenten leser taksonomien bokstavelig. Når etiketter overlapper, oscillerer den. Når etiketter er uklare, velger den feil med selvtillit. Nettstedsnavigasjonen ser fin ut. Agentarbeidsflytene produserer subtilt feil utdata som forverres over tid.

Patrick, 2017: Det har fungert i to år.

Det er problemet. Det har fungert fordi du har vært der for å få det til å fungere.

Hvordan designe mot det

Gjennomgå taksonomien din for tvetydighet. Velg ti innholdselementer og spør tre personer i teamet ditt uavhengig av hverandre hvor hvert enkelt skal arkiveres. Hvis du ikke får det samme svaret tre ganger, er taksonomien din tvetydig – og agenten din vil arve tvetydigheten. Enten stramme inn etikettene eller legg til flertydighetsregler i selve modellen. Arbeidet er nærmere en synonymordbokøvelse enn en innholdsøvelse. Innholdsteamene protesterer. Gjør det uansett.

4

Det finnes ingen eskaleringsvei fordi ingen trodde at en var nødvendig

På kundesiden hos Arterra ledet jeg den tekniske styringen av den digitale løsningsstakken på tvers av intranett, B2B og DTC-kanaler. Jeg lærte noe spesifikt om eskaleringsveier der: de føles bare valgfrie inntil de ikke er det. Den dagen noe eskalerer, er fraværet av en vei det dyreste du eier.

De fleste arbeidsflyter for agentinnhold er bygget uten eksplisitt eskaleringslogikk. Antagelsen er at hvis noe går galt, vil et menneske legge merke til det og gripe inn. Dette er greit når volumet er lavt. Det blir et dekningsproblem når volumet skaleres, fordi ingen overvåker alle utdata hele tiden. Agenten sender noe den ikke burde ha sendt. Teamet finner det ut fra en e-post fra kunden, en compliance-ansvarlig eller verre – en journalist.

Mønsteret jeg ser konsekvent på tvers av utviklermiljøet: team bygger den lykkelige stien først og lover seg selv at de skal legge til eskaleringslogikk senere. De legger den ikke til senere. De legger den til etter den første hendelsen.

Hvordan designe mot den

Bygg eskaleringsstien før du bygger arbeidsflyten. Bestem eksplisitt hva som utløser en hold, hva som utløser et menneske i løkken, hva som utløser et punktum. Bestem hvem som eier hvert nivå. Bestem hvordan revisjonssporet ser ut. Hvis du ikke kan formulere hva agenten gjør når det er usikkert, har du ikke en arbeidsflyt. Du har en utkastgenerator med en publiseringsknapp tilknyttet.

5

Ingen eier arbeidsflyten fra ende til ende – så ingen kan fikse den når den svikter

Dette er den jeg ser oftest. Og det er den som ser minst ut som en AI-feil.

Patrick, 2016: Alle eier den. Markedsføringsoperasjoner, ingeniører, innholdsdirektører, IT.

Det er det samme som at ingen eier den.

Patrick, 2016: Det er hardt.

Det er ikke hardt. Det er operativt. Når arbeidsflyten svikter – og den vil svikte – må du vite hvis kalender som åpnes. Akkurat nå har du fire kalendere som alle forblir lukket fordi alle antar at noen andre er med på den.

Arbeidsflyten blir organisert av en leder for markedsføringsdrift, med innspill fra en CMS-ingeniør, godkjenning fra en innholdsdirektør og en sikkerhetsgjennomgang fra IT. Alle berører den. Ingen eier den. Så når den går i stykker, bruker teamet to uker på å finne ut hvem som er ansvarlig før noen begynner å jobbe med det faktiske problemet.

Jeg ser det samme mønsteret i miniatyrundervisning av studenter på masternivå ved Centennial College. Gruppeprosjekter der eierskap er uklart, mislykkes på samme måte som arbeidsflyter i bedriften mislykkes – bare på en tidslinje på seks uker i stedet for en på seks kvartaler. Mekanismen er identisk.

Patrick, 2016: Greit. Så jeg navngir noen.

Én person. Ikke en komité. Ikke en arbeidsgruppe. Én person som er ansvarlig for arbeidsflytens oppførsel, resultater og utvikling. De trenger ikke å være den mest tekniske personen i rommet. De må være den som får telefonen til å ringer når noe går galt.

Patrick, 2016: Og hvis ingen vil ha jobben?

Da har du ikke en arbeidsflyt. Du har et distribuert ansvarsdiagram, som betyr at du ikke har noe. Samme resultat som «Promo Block 2», faktisk. Ingen ville eie det feltnavnet heller.

Hvordan designe mot det

Nevn én enkelt eier før du sender arbeidsflyten. Den personen er ansvarlig for arbeidsflytens oppførsel, dens resultater og dens utvikling. Hvis ingen vil registrere seg for det, er ikke arbeidsflyten klar til å sendes.

Hva alt dette betyr

De fem feilmodusene handler egentlig ikke om AI.

De handler om innholdsdrift. Innholdsmodellering, styring, taksonomi, eskalering og eierskap var alltid avgjørende for om et innholdssystem fungerte. En agent introduserer ikke disse problemene. En agentavslører dem – raskere, med høyere volum, med mindre tilgivelse for tvetydighet enn noe menneskelig team noen gang har krevd.

Dette er gode nyheter. Det betyr at arbeidet med å få agentiske CMS-arbeidsflyter til å lykkes er arbeid de fleste innholdsteam allerede vet hvordan de skal gjøre. Det er ikke ny vitenskap. Det er den lite glamorøse driftsdisiplinen som alltid var der, nå synliggjort av et system som ikke bærer taus kunnskap slik et menneskelig team gjør.

Hvis du bygger opp en agentisk innholdsarbeidsflyt akkurat nå, fiks disse fem tingene før du kobler til agenten.

Agenten vil være den enkle delen.

Vil du se hvordan Optimizely håndterer dette i praksis?