Every enterprise we talk to wants AI in its content operations. Almost none of them are in a position to replatform to get it, and they should not have to. The estates are established: Magnolia running a decade of structured content, AEM carrying the brand, a records system nobody is allowed to touch. The question that matters is how agentic capability arrives at the estate you already run.
This week we made our answer public. The Magnolia Author MCP is an open-source connector, released under Apache 2.0 on GitHub, that lets an AI agent operate a Magnolia author instance the way an author does. It grew out of client work, and this post is about what that work taught us.
What an agentic surface is
The Model Context Protocol has settled the plumbing question. A CMS's capabilities are exposed as typed tools that any MCP-compatible client can call: Claude, Claude Code, Cursor, or a custom host inside your own stack. The agent does not screen-scrape AdminCentral and it does not need your source code. Our connector discovers page templates, component definitions and dialog field schemas from the running instance over Magnolia's REST APIs, writes real structured content, verifies how the page renders, and stops where your governance says it stops.
That last clause is the part that makes the rest usable, and it is where most of our lessons live.
What delivery taught us
The content model is the agent's API. The single strongest predictor of whether an agent authors well on an established CMS is the discipline of the content model underneath it. Structured templates with typed fields give the agent a contract to write into, and its output arrives shaped, validated and reviewable. Freeform rich-text soup gives it room to improvise, and it will. Estates with clean models get value in the first week. Estates without them get a content-modelling conversation first, and that conversation was overdue anyway.
Discover at runtime, assume nothing. Early versions of this kind of tooling hardcode component knowledge and break against every real estate. The connector reads templates, components and dialog schemas from the instance itself, which is why it works against any Magnolia 6.x author without touching your modules. On a legacy estate, the implementation is the documentation, and the agent should read it the same way a new developer would.
Agents draft. Humans publish. In client operation we exclude publish and delete from the agent's toolset entirely, at the tool level rather than by instruction. The agent can build a hundred pages of migration content overnight. Every one of them waits at the same review gate an author's work does. Structural guard rails beat behavioural promises: dry-run deletes with subtree snapshots, an audit log on every mutating call, and explicit confirmation before any write to an instance flagged as production. If a control depends on the agent choosing to respect it, it is not a control.
Verification closes the loop. Writing content is half the job. The connector checks how the page renders after it writes, which catches the class of error that structured writes alone miss: the component that landed in the wrong area, the image reference that resolves to nothing. An agent that can see its own output corrects most of its mistakes before a human ever reviews them.
Start where the work is structured, voluminous and checkable. Bulk builds from a structured brief. Updates that touch two hundred pages consistently. Migration loading with editorial approval in batches. Hygiene passes across an estate that no one would ever fund manually. That is where the hours are, and it is work that is easy to review because it is repetitive by nature. Single-page craft stays with your authors, who now spend their time on it.
Publishing from the tools people already use
An MCP client does not have to be a developer tool. The same connector that answers to Claude Code will answer to a chat assistant in Microsoft Teams or Slack, and that is how we run part of our own content operations through Noice Assistant: a message in a channel becomes drafted pages waiting at the review gate. Nothing about the pattern is Magnolia-specific either. Any CMS, DXP or DAM with a management API can sit behind the same conversation, and the assistant becomes the one interface across all of them. For a content team this is the difference between adopting AI and installing it. The request happens where work already happens, nobody learns a new interface, and the governance stays where it was.
The estate you have is the asset
There is a version of the AI conversation that treats an established CMS as the obstacle. Our experience is the opposite. A decade of structured content is the grounding an agentic system needs, and the governance culture around an established estate, with its roles, workflows and review habits, is the control framework the AI era is now scrambling to invent. Adding an agentic surface to a well-run estate is a smaller, safer step than replatforming into a system with neither.
The connector is free, open source, and works with any MCP-compatible client against any Magnolia 6.x author instance. If your estate is AEM, Sitecore or something older, the pattern transfers wherever a management API exists, and content migration remains the on-ramp when the model underneath needs work first.
If you want to see what an agentic surface would do on your estate, talk to us. A scoping call and a look at your content model will tell us both more than a slide deck.
