The panel, and what it costs
An admin panel is the defining feature of a content management system, and its largest liability: a second application in front of the content, with a login to attack, sessions to steal, forms that must mirror every field, and its own idea of the content that drifts from the templates. Loam removed it — not a minimal one, not a hidden one: none.
Your agent is the interface
What remains is the files, the rules for how they may change, and one gate through which changes arrive: the MCP, a protocol any assistant speaks. You connect your site once, from the assistant you already use. /admin on your domain holds no login form but an explanation written for agents: what this site is, how to connect, what the rules are. To set up a new assistant, you hand it that address.
Management in your own words
“Move the summer closure notice above the opening hours and make it less formal” is not a feature a panel offers. An agent works from what you mean: it finds the right file, makes the change and stages it as a draft for you to preview and publish. “Add an English version of the about page.” “Take the old vacancies page offline.” “What changed last week?” There is no editor to learn.
One truth
Your agent reads the same files the site renders. It does not guess where a title or a price lives, and no admin-side model can disagree with the page.
The panel's other jobs, as data
| Panel job | Loam answer |
|---|---|
| Explain the site | /admin, readable by any agent |
| List drafts, report refusals | the MCP, in plain language |
| Activity log | the journal |
| Map of the site | the machine views |
Panels need training and documentation, and go out of fashion. A conversation does not.