Why we built agent access into the core, not as an add-on

Titre : Why we built agent access into the core, not as an add-on

Catégorie : Engineering

Corps

A lot of "AI-ready" SaaS tooling means a chatbot widget bolted onto the admin panel. We took a different approach: a real MCP (Model Context Protocol) server, the open standard now under the Linux Foundation, exposing what the application can actually do — not a natural-language wrapper around a support ticket form.

The design constraint we cared about most: an agent should never have more power than a careless human admin. That's why every write goes through the same three-step pipeline a human editor would use — validate the proposed change, preview exactly what it changes, then explicitly publish. An agent can draft ten pages in one pass; none of them go live until the publish step runs, and every step is logged.

The same mechanism that lets an agent propose a new blog post also lets it propose an entirely new admin dashboard module — describe it in plain language, and a working form/table screen exists, bound to real data, without anyone hand-building a UI for it.

This wasn't a feature we added late. It shaped how the content and admin layers are structured from the start — which is the only way "agent-native" means anything more than a marketing line.

CTA de fin

Read the full breakdown in AI & Agents (MCP).