Ett CMS har traditionellt varit byggt för människor. En redaktör loggar in, hittar rätt sida, ändrar innehållet och publicerar.

Nu börjar en annan typ av användare ställa krav på samma system: AI-agenter och automatiserade verktyg.

I WordPress syns den utvecklingen tydligt genom Abilities API. Med WordPress 7.1 blir det enklare för externa system att upptäcka vilka funktioner en webbplats kan erbjuda, förstå vilka indata de kräver och använda dem under definierade behörigheter.

Det betyder inte att WordPress plötsligt kan överlåtas till en AI-agent. Men det säger något viktigt om vart CMS är på väg.

Ett CMS behöver snart beskriva vad det kan göra

Ett vanligt API gör det möjligt för andra system att läsa eller ändra data. Abilities API försöker lösa en annan del av problemet.

En funktion kan registreras som en så kallad ability med bland annat:

  • ett tydligt namn och en beskrivning
  • definierade indata och utdata
  • en funktion som ska köras
  • regler för vem eller vad som får använda den

Det skapar ett gemensamt lager där WordPress, plugins och andra komponenter kan beskriva sina funktioner på ett mer standardiserat sätt.

För en människa kan en knapp med texten “Skapa utkast” vara ganska självklar. Ett externt system behöver något mer exakt. Det behöver kunna förstå att funktionen finns, vad den kräver och vilket resultat den ger.

Det är den typen av struktur Abilities API bygger för.

WordPress 7.1 gör grunden mer användbar

Abilities API introducerades redan i WordPress 6.9. Det nya i 7.1 är framför allt att infrastrukturen börjar bli mer praktiskt användbar för externa klienter.

WordPress utvecklar bland annat stöd för:

  • bättre filtrering och upptäckt av registrerade abilities
  • tydligare och mer portabla scheman för indata och utdata
  • validering när en funktion används
  • möjlighet att följa hur abilities anropas
  • en gemensam markering för funktioner som är avsedda att exponeras externt

Den sista punkten är särskilt intressant.

En ability kan markeras som publik för externa klienter, exempelvis REST API, MCP-adaptrar och AI-agenter. Det betyder inte att vem som helst automatiskt får köra funktionen. Behörighetskontrollen finns fortfarande kvar.

Det är en viktig skillnad.

Att en AI-agent kan upptäcka att en funktion finns är inte samma sak som att agenten har rätt att använda den.

Från innehåll till handling

Mycket av diskussionen om AI och webb har hittills handlat om innehåll.

Kan AI förstå sidan?
Kan innehållet citeras?
Syns företaget i ett AI-svar?

Det är frågor jag redan har skrivit om inom AI-synlighet och agentisk webbläsning.

Ett agentiskt CMS tar frågan ett steg längre.

AI behöver inte bara kunna förstå vad som finns på webbplatsen. Den kan också behöva utföra definierade uppgifter i systemet bakom den.

WordPress har även en officiell MCP Adapter som kan översätta registrerade abilities till verktyg som MCP-kompatibla AI-klienter kan upptäcka och använda.

Där börjar CMS:et gå från en plats där AI läser information till ett system där AI potentiellt kan delta i arbetsflödet.

Det jag faktiskt skulle vilja ha hjälp med

Det är lätt att göra den här utvecklingen mer science fiction än den behöver vara.

Jag är mindre intresserad av en AI som på egen hand bygger en hel webbplats. Det jag ser större värde i är stöd i konkreta arbetsmoment där det fortfarande finns tydliga ramar och mänskligt ansvar.

Tre exempel ligger nära till hands.

Stöd i innehållsarbetet

En agent skulle kunna hjälpa till att hitta innehåll som blivit gammalt, identifiera sidor som saknar viktiga delar eller skapa ett första utkast utifrån en definierad struktur.

Det intressanta är inte att generera mer text.

Det intressanta är om systemet känner till webbplatsens innehållsmodell, tonalitet, sidtyper och redaktionella regler och kan arbeta inom dem.

Stöd i SEO-arbetet

SEO innehåller många återkommande kontroller.

En agent skulle exempelvis kunna identifiera sidor som saknar metabeskrivning, upptäcka svag internlänkning, jämföra rubrikstruktur eller hitta innehåll som konkurrerar om samma ämne.

Men även här behövs ramar.

Att ett verktyg kan upptäcka ett problem betyder inte att det automatiskt ska skriva om en viktig landningssida eller ändra en URL.

Bra automation behöver förstå skillnaden mellan att rekommendera, förbereda och faktiskt genomföra en förändring.

Strukturera bättre landningssidor

Här blir kopplingen mellan CMS och AI extra intressant.

Om CMS:et redan känner till tillåtna block, sidtyper, innehållsfält och designregler skulle en agent kunna hjälpa till att sätta ihop ett första förslag till landningssida.

Inte genom att skapa vad som helst.

Utan genom att arbeta med den struktur som redan finns:

  1. välj rätt sidtyp
  2. föreslå informationsordning
  3. använd tillåtna block
  4. skapa utkast till innehåll
  5. föreslå relevanta interna länkar
  6. kontrollera grundläggande SEO och tillgänglighet
  7. lämna sidan som utkast för granskning

Det är betydligt mer intressant än en tom prompt som säger “bygg en landningssida”.

WordPress 7.1 gör inte allt detta åt dig

Det här behöver vara tydligt.

WordPress 7.1 levereras inte med en AI-agent som automatiskt sköter innehåll, SEO och landningssidor.

Abilities API är infrastruktur.

De inbyggda abilities som finns i WordPress är fortfarande begränsade, och mer avancerade arbetsflöden kräver att funktioner registreras av WordPress själv, plugins eller egenutvecklade lösningar.

MCP Adapter är på samma sätt en brygga. Den skapar en standardiserad väg mellan WordPress-funktioner och AI-klienter, men den bestämmer inte vilka funktioner som ska finnas eller vad en agent ska få göra.

Det är därför jag tycker utvecklingen är intressant.

WordPress försöker inte lösa hela AI-frågan med en stor knapp i admin. Plattformen bygger i stället delar som andra kan använda för att skapa kontrollerade arbetsflöden.

Behörighet blir viktigare när AI får verktyg

När ett system går från att bara läsa information till att kunna utföra handlingar förändras riskbilden.

Det räcker inte längre att fråga om AI:n ger ett bra svar.

Man behöver också fråga:

  • vilka funktioner kan agenten upptäcka?
  • vilka funktioner får den köra?
  • vilken användare eller roll sker det som?
  • vilka förändringar kräver mänskligt godkännande?
  • går det att följa vad agenten har gjort?
  • går en förändring att återställa?

WordPress betonar själv att exponering inte är samma sak som auktorisation. En publikt upptäckbar ability kan fortfarande ha en behörighetskontroll som avgör om den får köras.

Det är en sund princip även utanför WordPress.

AI-agenter bör få minsta möjliga behörighet för uppgiften de ska lösa.

Framtidens CMS handlar inte bara om bättre redigering

När jag skrev om WordPress 7.0 var en av slutsatserna att WordPress blir mer av en plattform än ett rent publiceringsverktyg.

Abilities API gör den utvecklingen tydligare.

Ett framtida CMS behöver sannolikt klara flera typer av användare samtidigt:

  • besökaren som läser webbplatsen
  • redaktören som arbetar i gränssnittet
  • utvecklaren som integrerar andra system
  • sökmotorn som försöker förstå innehållet
  • AI-agenten som vill upptäcka och använda definierade funktioner

Det förändrar inte grunden för en bra webbplats.

Struktur, tydlighet, innehåll, tillgänglighet, säkerhet och ett genomtänkt redaktionellt arbetssätt blir snarare ännu viktigare.

Skillnaden är att samma struktur behöver fungera för fler än personen framför skärmen.

Vad bör företag göra nu?

För de flesta företag är svaret inte att börja bygga MCP-servrar eller ge AI-agenter tillgång till WordPress i morgon.

Jag skulle börja betydligt enklare.

1. Strukturera innehållet bättre

Tydliga sidtyper, fält, taxonomier och block gör innehållet lättare att arbeta med för både människor och system.

2. Bestäm vad som får automatiseras

Skilj mellan sådant en AI får analysera, föreslå, skapa som utkast och faktiskt publicera eller ändra.

3. Se över redaktionella regler

Om en människa inte kan förklara vad en bra tjänstesida ska innehålla kommer en AI-agent inte lösa problemet på ett tillförlitligt sätt.

4. Börja med stöd, inte autonomi

Innehåll, SEO och strukturering av landningssidor är bra exempel på områden där AI kan minska manuellt arbete utan att behöva få sista ordet.

5. Följ utvecklingen, men bygg inte för hypen

Abilities API, MCP och agentiska gränssnitt är fortfarande under snabb utveckling.

Det viktiga just nu är inte att implementera allt nytt.

Det viktiga är att bygga webbplatser och CMS-lösningar med tillräckligt tydlig struktur för att kunna dra nytta av utvecklingen när den faktiskt skapar värde.

Det här är den intressanta förändringen

AI i CMS behöver inte betyda en knapp som skriver en artikel åt dig.

Den större förändringen är att CMS:et börjar kunna beskriva sina funktioner på ett sätt som andra system kan förstå och använda under kontrollerade former.

För mig är det där WordPress utveckling blir riktigt intressant.

Inte när AI ersätter redaktören, SEO-arbetet eller webbstrategin.

Utan när den kan avlasta delar av arbetet utan att vi behöver släppa kontrollen över struktur, kvalitet och publicering.

Det är en betydligt rimligare väg mot ett mer agentiskt CMS.

Källor

  • WordPress 7.1 Field Guide, Make WordPress Core
  • Abilities API, WordPress Developer Resources
  • Abilities API improvements in WordPress 7.1, Make WordPress Core
  • A unified public exposure flag for Abilities in WordPress 7.1, Make WordPress Core
  • From Abilities to AI Agents: Introducing the WordPress MCP Adapter, WordPress Developer Blog