Din indholdsmodel er en prompt.

Erklær femten bloktyper til en artikeltekst, og en forfatter må lovligt bruge én af dem femten gange i træk. En mur af prose validerer. Skemaet har intet at sige om det, fordi der ikke er noget galt — monotoni er et gyldigt dokument i et blokbaseret CMS på samme måde som en funktion på tusind linjer er gyldig C. Det er den fejltilstand, du arver, når forfatteren er en agent, og det er den interessante halvdel af dette indlæg. Start med den halvdel, der virkede.

Hvorfor erstatte et markdown-felt med typede blokke?

Fordi forfatteren er blevet en anden. Standardindholdsmodellen for en artikel er ét felt, der holder en markdown-streng. Alternativet er et ordnet array af typede blokke — en manchet, et citatudtræk, en infoboks, en kodeblok, et sæt hovedpointer — hver med erklærede felter og sin egen validering. Byt den ene ud med den anden, og frontenden opdager det knap nok. Det, der skriver ind i den, opdager det øjeblikkeligt.

Den gængse begrundelse for struktureret indhold handler om output: du vil rendere den samme artikel til web, til e-mail, til en app, til tryk, og en markdown-streng bager antagelser om HTML ind. Den begrundelse er reel, og det er ikke den, jeg fremfører. Den sag, jeg går op i, er inputsiden. Når det, der sætter en artikel sammen, holder op med at være en person med en teksteditor og bliver en proces, der holder et værktøjsskema, holder indholdsmodellen op med at være lagring og begynder at være instruktioner. Jeg har ført det argument om grænseflader før; dette er det samme skift, når det når indholdslaget, hvor det er betydeligt mindre abstrakt.

Hvad lader en markdown-streng egentlig en forfatter gøre?

Hvad som helst. John Gruber udgav Markdown i 2004 som en måde, hvorpå et menneske kunne skrive noget, der til sidst ville ende som HTML, og dens definerende egenskab er eftergivenhed — syntaks, der ikke går op, falder tilbage til bogstavelig tekst i stedet for at fejle. En markdown-kolonne accepterer en tom streng, en roman, seks rå <div>'er og et citatudtræk forfalsket med et blockquote. Det hele er gyldigt, fordi kolonnen ikke har nogen mening.

Den eftergivenhed er en fordel, når et menneske skriver, og en redaktør læser. Den er en risiko, når forfatteren er en proces, der gør præcis det, som det sidste, den læste, antydede, og intet menneske ser resultatet, før det lander i en database.

// ét felt, én streng, alt er tilladt
{ "body": "## Hvorfor vi gjorde det\n\nDe fleste B2B-platforme vokser gennem opkøb…" }

// et ordnet array af typede blokke
{ "body": [
    { "key": "lead",  "type": "lead",  "props": { "text": "…" } },
    { "key": "why",   "type": "prose", "props": { "markdown": "## Hvorfor…" } },
    { "key": "quote", "type": "pull_quote",
      "props": { "quote": "…", "source": "…" } },
    { "key": "costs", "type": "editorial_list",
      "props": { "items": ["01 | …", "02 | …"] } }
] }

Hvorfor betyder tekstens form mere, når forfatteren er en agent?

Fordi skemaet er den eneste brief, forfatteren med sikkerhed læser. En menneskelig skribent samler husstilen op fra en stilguide, en redaktør og tre års læsning af udgivelsen. En agent får indholdsmodellen — feltnavne, typer og beskrivelser — læsset ind i sin kontekst, og ikke ret meget mere. Det, der ikke står i skemaet, står ikke i briefen.

Når du først accepterer det, holder feltets description op med at være dokumentation og bliver den tekst i systemet, der har størst gennemslag. De brugbare er ikke beskrivelser af data. De er redaktionelle regler, skrevet dér hvor forfatteren ikke kan undgå at møde dem.

Et eksempel. Lad os sige, at du erklærer to ensartede bloktyper: én til nøgle/værdi-rækker, hvor nøglen er et kort symbol, og en anden til rækker, hvor nøglen er en hel sætning. En beskrivelse, der siger rækker med nøgle og værdi, er et spildt felt. En beskrivelse, der siger, at symbolvarianten er rigtig, når nøglen er en totegns etiket over for én eller to linjer, at sætningsvarianten er rigtig, når værdien strækker sig til et kort afsnit, og at hvis værdierne løber forbi fire linjer, skal du ikke bruge nogen af dem — brødtekst med mellemrubrikker, eller en rigtig tabel — er et afsnit redaktionelt skøn, der sidder inde i et JSON-skema. Det er forskellen på en forfatter, der ved hvornår blokken skal bruges, og en forfatter, der bruger den, fordi den stod på listen.

Der er et mindre tilfælde, jeg holder mere af, fordi den regel, det koder, ikke står skrevet nogen andre steder. Giv skemaet både en title og en display_title, og læg reglen på den anden: sæt den, når titlen løber forbi omkring halvtreds tegn. Det felt findes, fordi en titel nu har to læsere. Langformen skal bære det spørgsmål, nogen ville skrive ind eller stille en assistent; kortformen skal sidde under en titelbjælke uden at brydes over tre linjer. Det er ikke en stilnote i et dokument, som nogen vedligeholder. Det er et felt.

Hvad kan en typet tekst håndhæve, som en stilguide ikke kan?

Fire ting, og de er værd at holde adskilt, fordi kun én af dem handler om validering. Et skema gør en hel fejlklasse strukturelt umulig, giver hver indholdsenhed en stabil adresse, flytter renderingsbeslutninger ud af hænderne på forfatteren og bærer sine egne instruktioner. En stilguide kan kun bede pænt.

• Strukturel umulighedEt pull_quote uden quote er ikke et dårligt formateret citatudtræk. Det fejler valideringen og når aldrig databasen. Fejlklassen forsvinder i stedet for at blive fanget i gennemgangen — hvilket betyder mest for de fejl, ingen gennemgår, som en stats-blok med to værdier, hvor layoutet venter tre.
• Hver blok har en adresseBlokke bærer en stabil key — intro, costs, faq. Det gør redigering til en patch i stedet for en omskrivning: en agent, der retter en pris i ét afsnit, sender den blok alene, ikke hele artiklen, og kan ikke stiltiende tabe et afsnit, den glemte at have med i gensendelsen.
• Rendering afgøres et andet stedForfatteren vælger callout med tonen warn. Den vælger ikke en farve, en ramme, et ikon eller en bredde. Præsentationen bor i rendereren, hvor en designbeslutning kan ændres én gang i stedet for at blive taget op igen i hver eneste artikel, der tilfældigvis indeholder en advarsel.
• Instruktionen rejser med feltetEn beskrivelse, der er hæftet på et felt, ankommer i forfatterens kontekst hver eneste gang, i samme nyttelast som det, den beskriver. En wiki-side om tone of voice ankommer aldrig.

Hvad et skema ikke kan håndhæve

Smag, som er det, jeg åbnede med. En tekst, der udelukkende består af prose-blokke, er gyldig, og det er modellens standardvalg: givet en liste over bloktyper og en pointe, der skal føres, vil en sprogmodel gribe efter den mest generelle beholder, der findes, og blive ved med at gribe efter den. Typesystemer har aldrig kunnet fortælle dig, at et korrekt program er et kedeligt program.

Løsningen er ikke et strengere skema, og det vil jeg gerne være tydelig omkring, fordi instinktet er at tilføje en begrænsning. Du kan ikke udtrykke brug citatudtrækket, når sætningen gør mere arbejde end afsnittet omkring den i JSON Schema, og en regel som højst tre prose-blokke i træk producerer en forfatter, der indsætter en skillelinje hvert tredje afsnit for at tilfredsstille den. Goodhart gælder også for indholdsmodeller. Det, der faktisk virker, er at skrive kravet om udtryksfuldhed ind i de instruktioner, agenten kører under, og derefter læse resultatet.

Det andet, et skema ikke kan tjekke, er, om noget i det er sandt. En stats-blok erklærer tre strenge. Den erklærer ikke tre fakta. En struktureret tekst gør et opdigtet tal bedre formateret, mere fremtrædende og mere sandsynligt at blive citeret tilbage af noget, der læser det senere. Struktur hæver prisen på en hallucination i stedet for at sænke den.

Hvordan lærer agenten egentlig formen?

Ved at hente den. Bloktyperne er defineret på samlingen, og agenten læser dem, som den læser alt andet — et kald, der returnerer indholdsmodellen som data. Selve skriveværktøjet tager et ret uigennemsigtigt data-objekt, og serveren validerer det, der kommer ind, op mod samlingen. Briefen når altså forfatteren som en nyttelast, den slår op ved kørselstid, ikke som en type erklæret i værktøjets signatur.

Der er kun to steder, et skema kan bo, og valget betyder mere, end det ser ud til.

Læg det i værktøjets inputSchema, og det er erklæret én gang, i kataloget, hvor enhver kalder ser det, før den foretager et kald. Modellen kan ikke skrive uden at have fået formen vist. Læg det i data, der returneres af et læseværktøj, og det kan ændres uden at deploye noget, det kan versioneres sammen med indholdet, og — den afgørende faktor — det kan være forskelligt per tenant.

Det sidste afgør sagen for en hostet platform. Ét endpoint betjener mange organisationer, og deres samlinger er ikke de samme. Du kan ikke bage én tenants indholdsmodel ind i en værktøjssignatur, som alle tenants læser. Omkostningen er reel og værd at sætte navn på: intet tvinger modellen til at hente samlingen, før den skriver. En forfatter, der springer opslaget over, gætter, og det eneste, der står mellem et gæt og databasen, er validering på serversiden. Hvilket er et argument for at validere strengt, og imod at behandle værktøjsbeskrivelsen, som om den var kontrakten.

{
  "type": "object",
  "properties": {
    "body": { "type": "array", "items": { "$ref": "#/$defs/block" } }
  },
  "$defs": {
    "block": {
      "oneOf": [
        { "$ref": "#/$defs/lead" },
        { "$ref": "#/$defs/prose" },
        { "$ref": "#/$defs/pull_quote" }
      ]
    },
    "pull_quote": {
      "type": "object",
      "required": ["type", "props"],
      "properties": {
        "type": { "const": "pull_quote" },
        "props": {
          "type": "object",
          "required": ["quote"],
          "properties": {
            "quote":  { "type": "string" },
            "source": { "type": "string" }
          }
        }
      }
    }
  }
}

Hvis din indholdsmodel er fastlåst ved byggetid, blev den anden mulighed bedre med revisionen 2026-07-28, og det er værd at vide. SEP-2106, i 2026-07-28-MCP-specifikationen, løfter værktøjernes inputSchema og outputSchema til fuldt JSON Schema 2020-12: inputskemaer beholder rodkravet type: "object", men tillader nu komposition gennem oneOf, anyOf og allOf samt betingelser og $ref/$defs. En diskrimineret union som den ovenfor kan udtrykkes i en værktøjssignatur, hvilket betyder, at en server med én enkelt tenant kan lægge hele formen i kataloget og lade protokollen bære den. Det er ikke den handel, vi står i, men det er den bedre, når du kan tage den.

Hvordan står det her sig over for Portable Text, Contentful Rich Text og Strapi dynamic zones?

Ingen her har opfundet struktureret indhold. Blokke er ingen nyhed i headless CMS-verdenen; det nye er, hvem der har gavn af dem. Hver af de modne implementeringer laver en anden afvejning, og afvejningerne læses anderledes, når din forfatter er en maskine.

Sanitys Portable Text kom først og er ældet bedst. Det modellerer rig tekst som et array af blokke med stilarter og markdefinitioner, udtrykkeligt designet til at blive serialiseret til et hvilket som helst menneskelæsbart format frem for at antage HTML, og det tillader vilkårlige egne objekter i rod-arrayet. Det er et gennemført velskabt format og værd at læse, før du designer dit eget — Sanity er en indholdsplatform, så indholdsmodellen er produktet dér på en måde, den ikke er nogen andre steder på denne liste.

Contentful Rich Text gemmer et indlejret JSON-dokumenttræ, som du går igennem for at rendere. Det understøtter indlejrede poster og aktiver ordentligt, hvilket markdown ikke kan. Omkostningerne er et rendererbibliotek, en egen renderer til hver indlejret type, og nyttelaster betydeligt større end tilsvarende markdown. For en generator er dybden den besværlige del: et fladt array af typede blokke er lettere at producere korrekt end et træ, fordi forfatteren aldrig skal holde en indlejringsposition i hovedet.

Strapi dynamic zones ligger tættest på den model, der beskrives her — et erklæret sæt komponenter, som forfatteren vælger fra, returneret som struktureret JSON. Omkostningen dukker op i hentningen frem for i skrivningen: Strapi 5 fjernede den delte populeringsstrategi, så du erklærer populering per komponent med on-fragmenter i stedet for at læne dig op ad populate=*.

Payload gemmer Lexical-editorens tilstand som JSON, med blokke der lever som noder, der bærer et fields-objekt, og giver dig konvertere til at komme til HTML.

Så hvorfor skulle du bruge Munins CMS i stedet?

Ikke for redigeringsoplevelsen. Munin leveres uden visuel sidebygger, uden WYSIWYG-editor til rig tekst og uden plugin-markedsplads. De fire produkter er bygget omkring præcis det, og hvis en menneskelig redaktør, der sidder i en browser hele dagen, er centrum for din indholdsdrift, er et af dem det rigtige køb, og jeg ville ikke forsøge at tale dig fra det.

Brug Munin, når det, du faktisk vil vide, er hvilken artikel der lukkede handlen.

Et headless CMS holder dokumenter. Det har ingen mening om, hvem der læste dem, fordi menneskene ligger i et andet system med en anden idé om, hvad en person er, og forbindelsen mellem dem er en integration, som nogen vedligeholder. Munins CMS er ét af seks moduler på én Postgres, så artiklen, den besøgende der læste den, den samtale de åbnede to dage senere, og den handel der kom ud af det, er rækker i den samme database op mod én kontaktpost, med row-level security der bærer tenancy — hvilket er hele det arkitektoniske væddemål. De spørgsmål, der normalt er et dataprojekt, er forespørgsler: hvad nogen læste, før de tog kontakt, hvilket stykke supporten bliver ved med at sende, hvilket emne der producerer samtaler, som konverterer.

Den anden halvdel er, at de samme 200-plus MCP-værktøjer, der skrev artiklen, kan gøre alt rundt om den. Én agent skriver udkastet, genererer forsidebilledet (via Munin Media-værktøjerne), tjekker hvad den forrige tjente ind, finder de kontakter der læste den, og efterlader en opfølgning i en gennemgangskø, så et menneske kan godkende eller aflive den. Ingen orkestrering mellem de trin, fordi der ikke er noget at orkestrere — det er ét endpoint over ét skema, og værktøjskataloget er fladen. Det er ikke noget, du skruer på et headless CMS med tre integrationer og en planlægger. Det er, hvad du får, når CMS'et aldrig var et separat produkt. Hvordan den runde kører i praksis — læs hylden, verificér, skriv udkast ind i skemaet, forside, stop — er beskrevet trin for trin.

Og det er MIT hele vejen — ingen enterprise/-mappe, der holder på de funktioner, du faktisk ville få brug for. Det hele kører på din egen hardware direkte fra repoet, eller på Munin Cloud i EU, hvis du hellere vil slippe for at køre det overhovedet. Udgangen er en sekvens af værktøjskald, og hvert modul har en tilsvarende eksport. Vi vil hellere, at du kan gå.

Hvad det koster

• 01Hver bloktype er for altid. Femten typer er femten renderere, femten valideringsveje og femten tilfælde, som enhver fremtidig migrering skal håndtere. At tilføje én er en skemaændring på fem minutter og en permanent forpligtelse, hvilket er det samme regnestykke som at tilføje en offentlig API-metode.
• 02Diffs bliver værre. En markdown-tekst differ som brødtekst i et hvilket som helst værktøj skrevet inden for de sidste fyrre år. Et blok-array differ som JSON — en rettelse på ét ord dukker op som en ændret linje inde i en citeret streng, og en omrokering dukker op som en omskrivning. Stabile bloknøgler og versionering per post gør gennemgangen til at leve med, og den er stadig værre end git diff på en tekstfil.
• 03Mennesker er langsommere i det. Ingen har nogensinde skrevet hurtigere i en struktureret editor end i en almindelig tekstfil. Hvis de fleste af dine forfattere er mennesker, og de fleste af dine artikler er almindelige essays, er en markdown-kolonne med en god stilguide den korrekte tekniske beslutning, og du skal ikke læse resten af denne liste som et argument imod den.
• 04Skemaet bliver loftet. Når den rigtige form for en tanke ikke står på listen, griber forfatteren efter prose, og tanken kommer ud fladere, end den burde have gjort. En markdown-streng har intet loft — den lader en skribent opfinde en form på stedet. Den frihed er præcis det, du giver afkald på, og det er den omkostning, jeg lægger mærke til oftest.

Se dog på formen på den regning. Hver linje på den betales én gang, i det øjeblik du erklærer en type eller kobler en renderer op, og intet af det gentager sig per artikel. Den løbende omkostning sidder på den anden side af handlen.

En markdown-kolonne giver dig præcis én redaktionel kontrol, der kører på hvert eneste stykke, og det er et menneske, der læser stykket. Det virker, og det er det rigtige svar for et hold af menneskelige skribenter. Det holder op med at virke i det øjeblik, artikelproduktionen automatiseres, fordi «en god stilguide» så er et dokument, ingen i loopet åbner — forfatteren er en proces, og en proces læser den nyttelast, den fik udleveret. Skemaet er den eneste brief, der ankommer sammen med arbejdet, hver eneste gang, uanset om nogen huskede at sende den eller ej.

Så de fire omkostninger ovenfor er endelige, optællelige og overvejende engængs. Alternativets omkostning er et gennemgangstrin, du skal bemande for altid, på hver artikel, i den mængde du nu publicerer. Det er det regnestykke, der afgjorde det her, og det er det regnestykke, der er værd at lave, før du afgør det for dig selv.

Ofte stillede spørgsmål

Skal jeg gemme markdown eller strukturerede blokke i mit CMS? Gem markdown, hvis dine forfattere er mennesker, og dit output er ét website. Gem strukturerede blokke, hvis du renderer til mere end én flade, eller hvis noget andet end en person sætter teksten sammen. Det afgørende spørgsmål er ikke, hvordan indholdet vises — det er, hvem eller hvad der skriver det, og om nogen læser resultatet, før det publiceres.

Hvad er Portable Text, og hvordan adskiller det sig fra Markdown? Portable Text er Sanitys åbne format til rig tekst som et array af typede blokke, hver med en stil og et sæt markdefinitioner, og det tillader vilkårlige egne objekter i arrayet. Markdown er en ren tekst-syntaks fra 2004, der forudsætter en konvertering til HTML på et tidspunkt. Det ene er data, du forespørger på og transformerer; det andet er en streng, du parser.

Kan en AI-agent skrive pålideligt ind i en struktureret indholdsmodel? Ja for struktur, nej for skøn. Skemavalidering forhindrer pålideligt fejlformede blokke, manglende påkrævede felter og forkerte typer, så de fejl holder op med at nå produktion. Den forhindrer ikke monotoni, dårlig afsnitsrækkefølge eller opfundne tal, fordi ingen af dem er typefejl. Struktur er et gulv under kvaliteten, ikke en erstatning for gennemgang.

Hvordan opdager en AI-agent et CMS's indholdsmodel? Enten er formen erklæret i den værktøjssignatur, modellen ser, før den kalder noget som helst, eller også returneres den som data af et læseværktøj, som modellen skal huske at kalde. Multi-tenant-platforme skubbes mod det sidste, fordi forskellige kunder har forskellige samlinger, og én signatur ikke kan beskrive dem alle. Handlen er, at intet fremtvinger et opslag, så serveren er nødt til at validere strengt.

Hvad er et agentisk CMS? Et, som en AI-agent kan betjene direkte, frem for et med en AI-skriveassistent skruet ind i editoren. I praksis betyder det, at hver handling er et værktøj, agenten kan kalde, at indholdsmodellen kan opdages, og at skrivninger lander i en gennemgåelig tilstand i stedet for at gå direkte live. Munin eksponerer mere end 200 sådanne værktøjer på ét endpoint og holder hver post versioneret, så en publicering kan rulles tilbage.

Kan et CMS fortælle mig, hvilken artikel der skabte en kunde? Kun hvis indholdet og kunden bor i den samme database. Et headless CMS holder dokumenter og ved intet om læsere, så at svare på det betyder en integration mellem CMS'et, analyseværktøjet og CRM'et. Munin kører indhold, analyse, samtaler og CRM som seks moduler på én Postgres op mod én kontaktpost, hvilket gør det til en forespørgsel.

Er et blokbaseret CMS det værd for et lille hold? Kun hvis agenten står for skrivningen. For et tomandshold, der publicerer en håndfuld indlæg i hånden, koster et markdown-felt mindre at bygge, mindre at rendere og mindre at redigere. Økonomien vender, når artikelproduktionen automatiseres, for så er skemaet den eneste redaktionelle kontrol, du har, der kører på hvert eneste stykke.

Hvordan forhindrer man en agent i at bruge den samme bloktype til alt? Ikke med skemaet — en mur af brødtekst er gyldigt indhold. Det skal håndteres i de instruktioner, agenten kører under, formuleret som et krav om at bruge typespektret udtryksfuldt, og derefter tjekkes ved at læse resultatet. Der findes ingen måde at kode det her som en begrænsning, der ikke producerer dårligere skrivning, end den forhindrer.

De bloktyper, denne artikel er skrevet i, er erklæret på selve samlingen, læsbare i repoet eller ved at kalde cms_list_collections mod din egen organisation.

Din stilguide er et forslag. Din indholdsmodel er prompten.