Inside the Magnolia agents: An open, extensible architecture

"Extensible" shows up in a lot of AI product marketing, ours included. It's worth being specific about what it actually means for the Magnolia Agentic AI platform, because the answer determines whether you can trust the platform with real, differentiated workflows instead of just the ones we shipped out of the box.

For us, it means: if a customer or partner needs a tool the platform doesn't have — a check specific to a regulated industry, an integration with an internal system, a workflow that only makes sense for one team — they can build it and register it, using the same registry and the same security model that Magnolia DXP's own tools use. Nothing about that requires forking the product or waiting for a Magnolia DXP release.

Everything the agents do, they do through tools. Tools are defined declaratively in YAML and executed in Java, and they're exposed to the platform as a unified set of capabilities. The third-party large language model behind the agents picks the right one based on the description in that YAML configuration — which is also why writing a clear tool description matters as much as writing the tool itself.

Anything can be a tool: a REST endpoint, an AI task, a native command, or another MCP server. The Magnolia agents’ own toolset is a useful illustration of the range this covers — from tools that, for example, surface stale pages, search your content semantically, prioritize what to fix for SEO, combine SEO checks with analytics, optimize metadata, translate content, and even jump you straight into the right Magnolia DXP app — with more on the way.

Ten tools ship today; the registry is built to keep growing past that — content-idea generation and image generation are on the upcoming roadmap — including tools you write yourself.

Every tool execution passes through three layers of security before it runs, and all three have to pass:

Every tool execution is audit-logged end-to-end.

Underneath the conversation, the agent runs a simple loop, not a black box: think, decide, act, observe, and repeat, up to a hard ceiling of ten iterations to prevent runaway loops.

Thoughts and tool calls stream back in real time, so a user watching the agents work sees their reasoning, not just waiting. A typical multi-step request — "show me which pages are failing this month" — plays out as exactly this loop: think, call an analytics tool, observe the result, refine, call an SEO audit tool on the pages that came back, and answer.

Not every agent needs to think the same amount. A modelId swap in YAML — no code change — lets you choose a reasoning-capable model for an orchestrator that has to plan multi-step work, and a fast, lightweight model for an agent that's mostly doing lookups.

With a reasoning-capable model selected, the LLM call can include a hidden planning phase before any tool gets called: deciding which tools to call, in what order, with what arguments, and self-correcting mid-thought before committing to an action. That means better tool selection on ambiguous requests, fewer wasted loop iterations, and stronger recovery when a tool returns something unexpected. It also costs more per turn — reach for it on complex, multi-step orchestration, and skip it for simple lookups. Model choice is resolved through the same Unified Model Registry described in The Magnolia Agentic AI platform: An open framework for agentic content operations, so you can swap providers later without touching agents' code.

Conversation history is deliberately simple and deliberately volatile. Each session is scoped to exactly one user and one Agentic Chat — nobody sees anyone else's conversation. Messages live in an in-memory, append-only log, which means fast reads with no database round-trip on every turn.

Two guarantees sit on top of that log. When the context window fills up, a token-budget compressor prunes old turns based on real token usage reported by the model, not a guess. And sessions have a time-to-live and a per-user cap, so old or excess sessions simply drop — restart-safe by design. Conversation IDs are crypto-random UUIDs, so there's no session pinning and no enumeration risk.

The Model Context Protocol (MCP) turns the tool registry into a two-way bridge rather than a system that only talks to itself.

Magnolia DXP can connect out to external MCP servers — analytics platforms, search tools, IDE integrations — and any tools they expose auto-appear in the registry without per-tool YAML configuration. The same three-layer security applies to those external tools, and you can filter which external servers and tools a given agent is allowed to see with include MCP Servers, exclude MCP Servers, and exclude MCP Tool Patterns.

It also works the other way: Magnolia DXP's own tasks and tools can be exposed to external MCP clients — a coding assistant, an IDE, an automation pipeline — with scoped authentication so each client only sees what its role permits, governed and audit-logged by the same registry. That's the same open standard underneath the Magnolia MCP Developer's Server, a related but distinct product built for developers working directly on Magnolia DXP projects — think of it as the same architectural philosophy applied to the IDE rather than the content workflow. If you're curious how AI is also changing how developers build on Magnolia DXP, rather than how the Magnolia Agentic AI platform operates once it's live, our earlier piece on teaching an AI how to build on Magnolia DXP is a related, if separate, thread worth a look.

Several of the agents’ tools — Context Search most directly, but also anything doing retrieval-augmented generation (RAG) — depend on Magnolia's vector database. It's what lets the agents search by meaning rather than exact keyword match, and what keeps that search permission-aware: results are filtered against a user's actual read access before anything is returned, which matters as much for AI agents as it does for a human editor.

Your agents can be declared in YAML for straightforward tasks or backed by Java for custom business logic. The third-party AI models powering them are your choice, bring-your-own-key, resolved through the registry. Your own MCP servers can be connected as additional agents, with the same governance applied across all of them. When deployed, customers should configure disclosure controls to inform users that they're interacting with an AI agent, consistent with Article 50.1 of the EU AI Act. Magnolia supports configurable disclosure labels and transparent indicators to help meet this obligation — see the EU AI Act statement for implementation guidance.