Innholdsmodellen din er en prompt.

Deklarer femten blokktyper for en artikkelkropp, og en forfatter kan lovlig bruke én av dem femten ganger på rad. En vegg av prose validerer. Skjemaet har ingenting å si om det, fordi ingenting er galt — monotoni er et gyldig dokument i et blokkbasert CMS på samme måte som en funksjon på tusen linjer er gyldig C. Det er feilmodusen du arver når forfatteren er en agent, og det er den interessante halvdelen av dette innlegget. Start med halvdelen som virket.

Hvorfor erstatte et markdown-felt med typede blokker?

Fordi forfatteren er blitt en annen. Standard innholdsmodell for en artikkel er ett felt som holder en markdown-streng. Alternativet er en ordnet liste med typede blokker — en ingress, et uttrekkssitat, en infoboks, en kodeblokk, et sett med hovedpunkter — hver med deklarerte felter og sin egen validering. Bytt den ene mot den andre, og frontenden merker det knapt. Det som skriver inn i den, merker det umiddelbart.

Den vanlige begrunnelsen for strukturert innhold handler om utdata: du vil rendre den samme artikkelen til web, til e-post, til en app, til trykk, og en markdown-streng baker inn antakelser om HTML. Den begrunnelsen er reell, og det er ikke den jeg fremmer. Saken jeg bryr meg om, er inndatasiden. Når det som setter sammen en artikkel slutter å være en person med en teksteditor og blir en prosess som holder et verktøyskjema, slutter innholdsmodellen å være lagring og begynner å være instruksjoner. Jeg har gjort det argumentet om grensesnitt før; dette er det samme skiftet som ankommer innholdslaget, der det er atskillig mindre abstrakt.

Hva lar en markdown-streng en forfatter gjøre, egentlig?

Hva som helst. John Gruber slapp Markdown i 2004 som en måte for et menneske å skrive noe som til slutt skulle bli HTML, og den definerende egenskapen er ettergivenhet — syntaks som ikke går opp, degraderer til bokstavelig tekst i stedet for å feile. En markdown-kolonne godtar en tom streng, en roman, seks rå <div>-er, og et uttrekkssitat forfalsket av et blockquote. Alt sammen er gyldig, fordi kolonnen ikke har noen mening.

Den ettergivenheten er en fordel når et menneske skriver og en redaktør leser. Den er en risiko når forfatteren er en prosess som gjør nøyaktig det den siste tingen den leste antydet, og ingen mennesker ser resultatet før det lander i en database.

// ett felt, én streng, alt går
{ "body": "## Hvorfor vi gjorde det\n\nDe fleste B2B-plattformer vokser gjennom oppkjøp…" }

// en ordnet liste med typede blokker
{ "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 betyr formen på kroppen mer når forfatteren er en agent?

Fordi skjemaet er den eneste briefen forfatteren garantert leser. En menneskelig skribent plukker opp husstil fra en stilguide, en redaktør og tre år med lesing av publikasjonen. En agent får innholdsmodellen — feltnavn, typer og beskrivelser — lastet inn i konteksten sin, og ikke stort mer. Det som ikke er i skjemaet, er ikke i briefen.

Når du først godtar det, slutter felt-description å være dokumentasjon og blir teksten med høyest gjennomslag i hele systemet. De nyttige er ikke beskrivelser av data. De er redaksjonelle regler, skrevet der forfatteren ikke kan unngå å møte dem.

Et eksempel. Si at du deklarerer to like blokktyper: én for nøkkel/verdi-rader der nøkkelen er et kort symbol, en annen for rader der nøkkelen er en hel frase. En beskrivelse som sier rader med nøkkel og verdi er et bortkastet felt. En beskrivelse som sier at symbolvarianten er riktig når nøkkelen er en totegns merkelapp mot én eller to linjer, at fraseformen er riktig når verdien går opp i et kort avsnitt, og at hvis verdiene går forbi fire linjer bør du ikke bruke noen av dem — brødtekst med mellomtitler, eller en ekte tabell — er et avsnitt med redaksjonelt skjønn som sitter inne i et JSON-skjema. Det er forskjellen på en forfatter som vet når blokken skal brukes, og en forfatter som bruker den fordi den sto på lista.

Det finnes et mindre tilfelle jeg liker bedre, fordi regelen det koder, ikke er skrevet ned noe annet sted. Gi skjemaet både en title og en display_title, og legg regelen på den andre: sett den når tittelen går forbi rundt femti tegn. Det feltet finnes fordi en tittel nå har to lesere. Langformen må bære spørsmålet noen ville skrevet inn eller stilt en assistent; kortformen må sitte under en tittelbjelke uten å brekke til tre linjer. Det er ikke en stilnotis i et dokument noen vedlikeholder. Det er et felt.

Hva kan en typet kropp håndheve som en stilguide ikke kan?

Fire ting, og de er verdt å skille, fordi bare én av dem handler om validering. Et skjema gjør en klasse av feil strukturelt umulig, gir hver innholdsenhet en stabil adresse, flytter renderingsbeslutninger ut av hendene på forfatteren, og bærer sine egne instruksjoner. En stilguide kan bare be pent.

• Strukturell umulighetEt pull_quote uten quote er ikke et dårlig formatert uttrekkssitat. Det feiler validering og når aldri databasen. Feilklassen forsvinner i stedet for å bli fanget i gjennomgang — noe som betyr mest for feilene ingen gjennomgår, som en stats-blokk med to verdier der layouten venter tre.
• Hver blokk har en adresseBlokker bærer en stabil key — intro, costs, faq. Det gjør redigering til en patch i stedet for en omskriving: en agent som retter en pris i én seksjon sender den blokken alene, ikke hele artikkelen, og kan ikke stilltiende miste et avsnitt den glemte å ta med i nysendingen.
• Rendering avgjøres et annet stedForfatteren velger callout med tone warn. Den velger ikke en farge, en ramme, et ikon eller en bredde. Presentasjon bor i rendereren, der en designbeslutning kan endres én gang i stedet for å bli tatt opp på nytt i hver artikkel som tilfeldigvis inneholder en advarsel.
• Instruksjonen reiser med feltetEn beskrivelse festet til et felt ankommer forfatterens kontekst hver eneste gang, i samme nyttelast som det den beskriver. En wiki-side om tone of voice ankommer aldri.

Hva et skjema ikke kan håndheve

Smak, som er den delen jeg åpnet med. En kropp som består utelukkende av prose-blokker er gyldig, og det er modellens standardvalg: gitt en liste over blokktyper og et poeng som skal fremmes, vil en språkmodell gripe etter den mest generelle beholderen som finnes, og fortsette å gripe etter den. Typesystemer har aldri kunnet fortelle deg at et korrekt program er et kjedelig et.

Løsningen er ikke et strengere skjema, og jeg vil være tydelig på det, fordi instinktet er å legge til en begrensning. Du kan ikke uttrykke bruk uttrekkssitatet når setningen gjør mer arbeid enn avsnittet rundt den i JSON Schema, og en regel som ikke mer enn tre påfølgende prose-blokker produserer en forfatter som setter inn en skillelinje hvert tredje avsnitt for å tilfredsstille den. Goodhart gjelder for innholdsmodeller. Det som faktisk virker, er å skrive kravet om uttrykksfullhet inn i instruksjonene agenten kjører under, og så lese resultatet.

Det andre et skjema ikke kan sjekke, er om noe i det er sant. En stats-blokk deklarerer tre strenger. Den deklarerer ikke tre fakta. En strukturert kropp gjør et oppdiktet tall bedre formatert, mer fremtredende og mer sannsynlig å bli sitert tilbake av noe som leser det senere. Struktur hever prisen på en hallusinasjon i stedet for å senke den.

Hvordan lærer agenten egentlig formen?

Ved å hente den. Blokktypene er definert på samlingen, og agenten leser dem slik den leser alt annet — et kall som returnerer innholdsmodellen som data. Selve skriveverktøyet tar et ganske ugjennomsiktig data-objekt, og serveren validerer det som kommer inn mot samlingen. Så briefen når forfatteren som en nyttelast den slår opp under kjøring, ikke som en type deklarert i verktøyets signatur.

Det finnes bare to steder et skjema kan bo, og valget betyr mer enn det ser ut til.

Legg det i verktøyets inputSchema, og det er deklarert én gang, i katalogen, der hver kaller ser det før den gjør et kall. Modellen kan ikke skrive uten å ha fått vist formen. Legg det i data som returneres av et leseverktøy, og det kan endres uten å deploye noe, det kan versjoneres sammen med innholdet, og — den avgjørende faktoren — det kan være forskjellig per tenant.

Den siste avgjør saken for en driftet plattform. Ett endepunkt betjener mange organisasjoner, og samlingene deres er ikke de samme. Du kan ikke bake én tenants innholdsmodell inn i en verktøysignatur som alle tenanter leser. Kostnaden er reell og verdt å navngi: ingenting tvinger modellen til å hente samlingen før den skriver. En forfatter som hopper over oppslaget, gjetter, og det eneste som står mellom en gjetning og databasen er validering på serversiden. Noe som er et argument for å validere strengt, og mot å behandle verktøybeskrivelsen 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 innholdsmodellen din er låst ved byggetid, ble det andre alternativet bedre med revisjonen 2026-07-28, og det er verdt å vite. SEP-2106, i 2026-07-28-MCP-spesifikasjonen, løfter verktøyenes inputSchema og outputSchema til full JSON Schema 2020-12: inndataskjemaer beholder rotkravet om type: "object", men tillater nå komposisjon gjennom oneOf, anyOf og allOf, pluss betingelser og $ref/$defs. En diskriminert union som den over lar seg uttrykke i en verktøysignatur, noe som betyr at en server med én tenant kan legge hele formen i katalogen og la protokollen bære den. Det er ikke byttehandelen vi står i, men det er den bedre når du kan ta den.

Hvordan står dette seg mot Portable Text, Contentful Rich Text og Strapi dynamic zones?

Ingen her har funnet opp strukturert innhold. Blokker er gammelt nytt i headless CMS-verdenen; det nye er hvem som har nytte av dem. Hver av de modne implementasjonene gjør en annen avveining, og avveiningene leses annerledes når forfatteren din er en maskin.

Sanitys Portable Text kom først og har eldet best. Den modellerer rik tekst som en liste med blokker med stiler og markdefinisjoner, eksplisitt designet for å serialiseres til et hvilket som helst menneskelesbart format i stedet for å anta HTML, og den tillater vilkårlige egendefinerte objekter i rotlista. Det er et genuint godt laget format og verdt å lese før du designer ditt eget — Sanity er en innholdsplattform, så innholdsmodellen er produktet der på en måte den ikke er noe annet sted på denne lista.

Contentful Rich Text lagrer et nøstet JSON-dokumenttre som du går gjennom for å rendre. Det støtter innebygde oppføringer og ressurser skikkelig, noe markdown ikke kan. Kostnadene er et rendererbibliotek, en egendefinert renderer for hver innebygde type, og nyttelaster betydelig større enn tilsvarende markdown. For en generator er dybden den kronglete delen: en flat liste med typede blokker er enklere å produsere korrekt enn et tre, fordi forfatteren aldri må holde en nøstingsposisjon i hodet.

Strapi dynamic zones ligger nærmest modellen beskrevet her — et deklarert sett komponenter forfatteren velger fra, returnert som strukturert JSON. Kostnaden dukker opp i uthenting snarere enn i skriving: Strapi 5 fjernet den delte populeringsstrategien, så du deklarerer populering per komponent med on-fragmenter i stedet for å lene deg på populate=*.

Payload lagrer Lexical-editortilstand som JSON, med blokker som lever som noder som bærer et fields-objekt, og gir deg konvertere for å komme til HTML.

Så hvorfor skulle du bruke Munins CMS i stedet?

Ikke for redigeringsopplevelsen. Munin leveres uten visuell sidebygger, uten WYSIWYG-editor for rik tekst og uten plugin-markedsplass. De fire produktene er bygd rundt akkurat det, og hvis en menneskelig redaktør som sitter i en nettleser hele dagen er sentrum for innholdsdriften din, er ett av dem det riktige kjøpet, og jeg ville ikke prøvd å snakke deg fra det.

Bruk Munin når det du egentlig vil vite, er hvilken artikkel som lukket avtalen.

Et headless CMS holder dokumenter. Det har ingen mening om hvem som leste dem, fordi menneskene ligger i et annet system med en annen idé om hva en person er, og koblingen mellom dem er en integrasjon noen vedlikeholder. Munins CMS er én av seks moduler på én Postgres, så artikkelen, den besøkende som leste den, samtalen de åpnet to dager senere, og avtalen som kom ut av det, er rader i den samme databasen mot én kontaktoppføring, med radnivåsikkerhet som bærer tenancy — som er hele det arkitektoniske veddemålet. Spørsmålene som normalt er et dataprosjekt, er spørringer: hva noen leste før de tok kontakt, hvilket stykke support stadig sender, hvilket tema som produserer samtaler som konverterer.

Den andre halvdelen er at de samme 200+ MCP-verktøyene som skrev artikkelen kan gjøre alt rundt den. Én agent skriver utkastet, genererer forsidebildet (via Munin Media-verktøyene), sjekker hva den forrige tjente inn, finner kontaktene som leste den, og legger igjen en oppfølging i en gjennomgangskø for at et menneske skal godkjenne eller drepe den. Ingen orkestrering mellom de stegene, fordi det ikke er noe å orkestrere — det er ett endepunkt over ett skjema, og verktøykatalogen er flaten. Det er ikke noe du skrur på et headless CMS med tre integrasjoner og en scheduler. Det er det du får når CMS-et aldri var et separat produkt. Hvordan den runden kjører i praksis — les hylla, verifiser, skriv utkast inn i skjemaet, forsidebilde, stopp — er skrevet opp steg for steg.

Og det er MIT hele veien — ingen enterprise/-katalog som holder på funksjonene du faktisk ville trengt. Hele greia kjører på din egen maskinvare rett fra repoet, eller på Munin Cloud i EU hvis du heller ikke vil kjøre den i det hele tatt. Exiten er en sekvens av verktøykall, og hver modul har en tilsvarende eksport. Vi vil heller at du skal kunne dra.

Hva det koster

• 01Hver blokktype er for alltid. Femten typer er femten renderere, femten valideringsveier og femten tilfeller hver framtidige migrasjon må håndtere. Å legge til én er en skjemaendring på fem minutter og en permanent forpliktelse, som er det samme regnestykket som å legge til en offentlig API-metode.
• 02Differ blir verre. En markdown-kropp differ som brødtekst i hvilket som helst verktøy skrevet de siste førti årene. En blokkliste differ som JSON — en retting på ett ord dukker opp som en endret linje inne i en sitert streng, og en omrokkering dukker opp som en omskriving. Stabile blokknøkler og versjonering per oppføring gjør gjennomgangen til å leve med, og det er fortsatt verre enn git diff på en tekstfil.
• 03Mennesker er tregere i det. Ingen har noen gang skrevet raskere i en strukturert editor enn i en ren tekstfil. Hvis de fleste av forfatterne dine er mennesker og de fleste artiklene dine er vanlige essays, er en markdown-kolonne med en god stilguide den korrekte tekniske beslutningen, og du bør ikke lese resten av denne lista som et argument mot det.
• 04Skjemaet blir taket. Når den riktige formen for en tanke ikke står på lista, griper forfatteren etter prose, og tanken kommer ut flatere enn den burde ha gjort. En markdown-streng har ikke noe tak — den lar en skribent finne opp en form på stedet. Den friheten er nøyaktig det du gir fra deg, og det er kostnaden jeg legger merke til oftest.

Se på formen på den regningen, da. Hver linje på den betales én gang, i det øyeblikket du deklarerer en type eller kobler opp en renderer, og ingenting av det gjentar seg per artikkel. Den løpende kostnaden sitter på den andre siden av byttehandelen.

En markdown-kolonne gir deg nøyaktig én redaksjonell kontroll som kjører på hvert eneste stykke, og det er et menneske som leser stykket. Det virker, og det er det riktige svaret for et team av menneskelige skribenter. Det slutter å virke i det øyeblikket artikkelproduksjonen automatiseres, fordi «en god stilguide» da er et dokument ingen i loopen åpner — forfatteren er en prosess, og en prosess leser nyttelasten den fikk overlevert. Skjemaet er den eneste briefen som ankommer sammen med arbeidet, hver eneste gang, uansett om noen husket å sende den eller ikke.

Så de fire kostnadene over er endelige, tellbare og stort sett engangs. Alternativets kostnad er et gjennomgangssteg du må bemanne for alltid, på hver artikkel, i det volumet du nå publiserer. Det er regnestykket som avgjorde det her, og det er regnestykket verdt å kjøre før du avgjør det for deg selv.

Ofte stilte spørsmål

Bør jeg lagre markdown eller strukturerte blokker i CMS-et mitt? Lagre markdown hvis forfatterne dine er mennesker og utdataene dine er ett nettsted. Lagre strukturerte blokker hvis du rendrer til mer enn én flate, eller hvis noe annet enn en person setter sammen kroppen. Det avgjørende spørsmålet er ikke hvordan innholdet vises — det er hvem eller hva som skriver det, og om noen leser resultatet før det publiseres.

Hva er Portable Text, og hvordan skiller det seg fra Markdown? Portable Text er Sanitys åpne format for rik tekst som en liste med typede blokker, hver med en stil og et sett markdefinisjoner, og det tillater vilkårlige egendefinerte objekter i lista. Markdown er en ren tekst-syntaks fra 2004 som antar en eventuell konvertering til HTML. Det ene er data du spør mot og transformerer; det andre er en streng du parser.

Kan en AI-agent skrive pålitelig inn i en strukturert innholdsmodell? Ja for struktur, nei for skjønn. Skjemavalidering hindrer pålitelig feilformede blokker, manglende påkrevde felter og feil typer, så de feilene slutter å nå produksjon. Det hindrer ikke monotoni, dårlig seksjonsrekkefølge eller oppdiktede tall, fordi ingen av dem er typefeil. Struktur er et gulv under kvaliteten, ikke en erstatning for gjennomgang.

Hvordan oppdager en AI-agent innholdsmodellen til et CMS? Enten er formen deklarert i verktøysignaturen modellen ser før den kaller noe som helst, eller så returneres den som data fra et leseverktøy modellen må huske å kalle. Flerleieplattformer skyves mot det andre, fordi ulike kunder har ulike samlinger og én signatur ikke kan beskrive dem alle. Byttehandelen er at ingenting tvinger fram et oppslag, så serveren må validere strengt.

Hva er et agentisk CMS? Et som en AI-agent kan betjene direkte, ikke et med en AI-skriveassistent skrudd inn i editoren. I praksis betyr det at hver handling er et verktøy agenten kan kalle, at innholdsmodellen er oppdagbar, og at skrivinger lander i en gjennomgåelig tilstand i stedet for å gå rett ut. Munin eksponerer mer enn 200 slike verktøy på ett endepunkt og holder hver oppføring versjonert, så en publisering kan rulles tilbake.

Kan et CMS fortelle meg hvilken artikkel som skapte en kunde? Bare hvis innholdet og kunden bor i den samme databasen. Et headless CMS holder dokumenter og vet ingenting om lesere, så å svare på det betyr en integrasjon mellom CMS-et, analyseverktøyet og CRM-et. Munin kjører innhold, analyse, samtaler og CRM som seks moduler på én Postgres mot én kontaktoppføring, noe som gjør det til en spørring.

Er et blokkbasert CMS verdt det for et lite team? Bare hvis agenten står for skrivingen. For et toperson-team som publiserer en håndfull innlegg for hånd, koster et markdown-felt mindre å bygge, mindre å rendre og mindre å redigere. Økonomien snur når artikkelproduksjonen automatiseres, for da er skjemaet den eneste redaksjonelle kontrollen du har som kjører på hvert eneste stykke.

Hvordan hindrer du at en agent bruker den samme blokktypen til alt? Ikke med skjemaet — en vegg av brødtekst er gyldig innhold. Det må håndteres i instruksjonene agenten kjører under, formulert som et krav om å bruke typespekteret uttrykksfullt, og deretter sjekkes ved å lese resultatet. Det finnes ingen måte å kode dette som en begrensning som ikke produserer dårligere skriving enn den hindrer.

Blokktypene denne artikkelen er skrevet i, er deklarert på selve samlingen, lesbare i repoet eller ved å kalle cms_list_collections mot en egen organisasjon.

Stilguiden din er et forslag. Innholdsmodellen din er prompten.