Every content management system in wide use was designed around the same picture: a person sitting in an admin panel, typing. The dashboard, the rich text editor, the media picker, the publish button — each one exists because a human needed a place to click.
That picture is changing faster than the tooling underneath it. Teams are now running agents that draft, revise, translate, schedule and publish content, often on their own infrastructure and often unattended. The operator of the content platform is no longer only a person. It is increasingly a piece of software with credentials.
We built ApexCMS for that operator.
The assumption underneath every CMS
The category solved a real problem. Headless content platforms decoupled content from presentation, exposed a delivery API, and let front-end teams build in whatever framework they preferred. That was the right move, and it is why the category won.
But the decoupling stopped at delivery. Reading content through an API became a first-class capability. Almost everything else — defining what a content type is, changing its fields, approving a draft, managing who can publish — stayed behind the admin panel, where only a person could reach it. Some systems go further and disable structural changes in production entirely, on the reasonable assumption that a human with a deploy pipeline is the only thing that should be reshaping a content model.
That assumption is what breaks. If an agent can read content but cannot create a content type, cannot upload the image it just generated, cannot move an entry from draft to published under a policy, then it is not operating your content platform. It is filling in a form that a human still has to finish.
The design principle we settled on is short enough to state in one line, and everything else follows from it:
If the admin panel can do something the API cannot, an agent cannot do that thing.
So the admin panel is not a privileged surface in ApexCMS. It is a client of the same API everything else uses. There is no operation available to a person that is unavailable to a credentialed agent, because there is no second, richer, internal interface for the panel to call.
What agent-first means in practice
Consider the full publication cycle, not just the writing step. A piece of content has to be modeled, drafted, illustrated, reviewed, published, and eventually revised. Agent-first means an agent can carry every one of those steps, and hand off to a human at whichever point you choose.
Modeling. Content types and their fields are defined at runtime, through the API, without a code deploy or a restart. An agent that needs to publish a new kind of thing — a changelog entry, a location page, a product FAQ — can create the structure for it and then populate it. The model is data, not a file in a repository.
Drafting and media. Entries are created through the same API, with their media, as one coherent operation. An agent that produces an article and an accompanying image does not need a human to attach one to the other.
Review. Draft and published are distinct states, and moving between them is a specific action with its own permission. This is the hinge of the whole design, and we will come back to it.
Revision. Every change is versioned and every version is restorable. An agent editing content it published last week is a normal operation rather than a risk, because the previous state is still there.
Each of those is an ordinary API call rather than a special integration, which is what makes the whole cycle available to something other than a person. What that looks like in practice is worth walking through concretely, and we do that below.
Why the stack is what it is
ApexCMS is built on Elixir. That is a commercial decision more than an aesthetic one, and it comes down to what agent-driven publishing does to a system's load profile.
Human editing is steady and shallow: a handful of people, a few operations each, spread across a working day. Agent-driven publishing is bursty and deep. An agent wakes up, opens many operations at once, holds several of them for a while — a batch of entries, a set of uploads, a series of model calls — and then goes quiet. Multiply that by every tenant on the deployment and by every agent each of them runs.
That is the workload the BEAM, the runtime Elixir sits on, was built for. Three things follow from it that a buyer can actually feel:
- Background work needs no extra infrastructure. Long-running jobs, scheduled execution and concurrent processing are properties of the runtime, not services you provision alongside it. There is no separate queue, no cache tier, no worker fleet to run and pay for. For a self-hosted product, that is the difference between one server and five.
- Failures stay local. A misbehaving integration, a slow external call, an extension that throws — these are isolated by the runtime rather than shared by the process. One tenant's bad afternoon is not everyone's outage.
- Concurrency is not a tuning exercise. The capacity is there by default rather than something you reach by configuring pools and workers correctly.
Underneath, content lives in PostgreSQL, with each customer's data isolated from every other customer's at the database level rather than by a filter in application code. Two reasons, both commercial. Isolation that the database enforces is a much easier thing to stand behind than isolation that depends on every query being written correctly. And a Postgres database is something an operator can back up, inspect, export and leave with — the content is yours in a form you can actually take somewhere else.
The administration interface is React. It exists because people still need to read, review and correct what the system holds, and reviewing is a visual task. Being agent-first does not mean removing the human interface. It means not privileging it.
Running the agent on your own server
Nothing in this design requires a hosted automation product, and the setup we build toward is deliberately ordinary: a small VPS, an agent runtime installed on it, and one API credential scoped to a role you define. That is the entire installation.
Two open-source runtimes fit this shape today. OpenClaw is an agent framework built for exactly this — self-hosted, tool-using, connected to the apps a team already uses. Hermes Agent, from Nous Research, takes a similar position with persistent memory across sessions and scheduled automations built in. Both run continuously on a modest server rather than for the length of one conversation, and both reach you through Telegram, Slack, Discord or email. The practical consequence is that the interface to your content platform becomes a message or a time of day, instead of someone remembering to log in.
The full cycle, end to end
Take a company publishing service pages across a set of locations.
- The trigger. Someone sends a message — "we've opened in Fort Myers, put the page together" — or the agent simply reaches a scheduled task on its own.
- Structure. The agent reads the existing content model through the API. If the type it needs does not exist yet, it creates it. That is a runtime operation, not a deployment, so nothing is waiting on an engineer.
- Drafting. It writes the entry, produces or selects the imagery, uploads the media and attaches it — one continuous sequence, with nobody stitching the pieces together afterwards.
- The stop. It goes no further, because the credential it holds can create and edit but cannot publish.
- Review. A person opens the admin, reads what was produced, fixes a line, and publishes.
- Distribution. The same agent triggers the front-end rebuild, and the page is live.
Every step there is an API call against the same contract the administration panel uses. No scripting layer, no headless browser driving a dashboard, no integration written specially for the occasion.
Note where the recurring part lives: with the agent, not with the CMS. That is deliberate. The runtime already knows how to run work on a cadence, retry it and remember what it did last time. Rebuilding that inside the content platform would mean operating a worse copy of something you are already running.
Why your own server
Three reasons, all commercial rather than ideological.
- The credentials and the content stay on infrastructure you control. Your content API key, your model provider key, and every draft before anyone approves it — none of that transits a third party's account.
- The cost is a server, not a seat or a run. Automation priced per execution penalises precisely the workload this is good at: high volume, low individual value, running unattended.
- It is yours to keep. The agent, the context it has accumulated, and the platform it operates are all things you can back up and move. That matters more the longer the arrangement runs.
There is an obvious objection to all of this: an agent on your own server, holding your own credentials, sounds like more exposure rather than less. It is not, and the reason is the subject of the next section.
Autonomy is only sellable if it is reversible
This is the part that decides whether any of this is usable in a real business.
Giving software the ability to publish is not interesting on its own. It is interesting only alongside a credible answer to three questions a client will ask, in this order: what is it allowed to do, who approves what it produces, and what happens when it gets something wrong.
ApexCMS answers those structurally rather than by convention.
Scope. Permissions are role-based and granular, and publishing is its own permission, separate from creating and editing. An agent can be given the ability to produce drafts and nothing else. That is a genuinely useful configuration: full automation of the expensive part, with a human keeping the last step.
Approval. Because draft and published are real, distinct states rather than a flag someone remembers to check, the review step is enforced by the system rather than by process discipline. Content does not reach the public because nobody stopped it.
Reversal. Every version is retained and any version can be restored. There is no scenario where the previous state of a page is gone.
Accountability. Actions are attributable. When something appears on the site, the record of who or what put it there, and when, is part of the data rather than something reconstructed from logs afterwards.
Taken together, that is the actual product argument. Not "an agent can publish for you" — plenty of things can be made to publish. It is that an agent can publish for you inside a boundary you set, with a review gate you control and an undo that always exists.
How it fits an Astro or Next.js front end
ApexCMS does not render your site, and has no opinion about what does. It publishes content over HTTP against a described, versioned contract, and anything that can make an HTTP request is a valid client.
Astro. The natural fit is a build-time fetch: content is pulled when the site builds and ships as static HTML, which is what you want for marketing sites, service pages and anything read far more often than it changes. The publishing step and the rebuild are two operations, and in an agent-first setup the same agent that publishes can trigger the rebuild — no separate automation to maintain between them.
Next.js. Content can be fetched per request in server components, or rendered statically and refreshed on demand when something changes. Both patterns work against the same API, and the choice is a caching decision on your side rather than a constraint from ours.
Anything else. SvelteKit, Nuxt, a mobile app, a digital signage screen, another back-end service that needs the same copy — all of them consume the same contract. The API is described in a machine-readable specification, which matters more than it used to: it is also how an agent discovers what operations exist rather than being told in a prompt.
The point is that the front end stays a decision you make on its own merits. Choosing this platform does not commit you to a rendering framework, and switching your front end later does not touch your content.
Where this fits
The clearest cases we see are these.
An agency or operator running many sites. Multiple clients or brands on one deployment, each fully isolated, each with its own content model and its own users. One system to run and update instead of a fleet of separate installations.
A team with more content to produce than people to produce it. An agent drafts continuously against a defined structure; a person reviews and releases. The economics change because the expensive step is automated and the accountable step is not.
Content that must feed more than one destination. A website, an app, an internal tool and a partner integration all reading the same content, where copying it between systems is the actual problem.
Ongoing work rather than a launch. Sites where content keeps changing after go-live — locations, catalogues, documentation, listings — and where the cost is not building it once but keeping it current for years.
Organisations that need to hold their own data. Self-hosted on infrastructure you control, with the content in a database you can back up and export. For some clients this is a preference. For others, in regulated sectors, it is the requirement that decides the vendor.
Where it is not the right tool
A brochure site of eight pages that changes twice a year does not need a content platform at all. Markdown files in the repository are faster to build, cheaper to run and easier to reason about, and we have recommended exactly that to clients who arrived asking for a CMS.
If what you want is a system that also owns how the site looks — themes a designer can rework, layouts changed without anyone opening application code — then headless is the wrong shape, and that is worth saying plainly rather than selling around. ApexCMS publishes content and holds no opinion about presentation. That is a feature right up until the moment that opinion is the thing you were buying.
And if you have no interest in automating content production, the agent-first argument is simply not a reason to choose this. It would work. It just would not be why.
Agent-first is a bet about where publishing is going, not a claim that everyone is there yet. We built it because we think the operator of a content platform is changing, and a system designed for a person clicking a button will keep meeting that operator at the edge of what its API was ever meant to do.
If any of this describes a problem you have, we are happy to talk it through — including telling you when the answer is something simpler.