Inside the Magnolia Agent: 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 Agent, 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 Agent 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 Agent does, it does through tools. Tools are defined declaratively in YAML and executed in Java, and they're exposed to the Agent as a unified set of capabilities. The large language model behind the Agent 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 Agent's own tool set 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 with 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.

The agent loop: Think, act, observe, repeat

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 Agent work sees it 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 Agent: an open framework for agentic content operations, so you can swap providers later without touching agent code.

Conversation history is deliberately simple and deliberately volatile. Each session is scoped to exactly one user and one agent — 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) is what 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 includeMcpServers, excludeMcpServers, and excludeMcpToolPatterns.

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 Agent 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 Agent's tools — context_search most directly, but also anything doing retrieval-augmented generation — depend on Magnolia's vector database. It's what lets the Agent 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 an AI agent as it does for a human editor.

The Magnolia Agent is generally available today.

Your tools can be declared in YAML for straightforward tasks, or backed by Java for custom business logic. Your models are your choice, bring-your-own-key, resolved through the registry. Your own MCP servers can be connected as additional tools, with the same governance applied throughout.