FluentCMS v2: a headless CMS where agents are the operator

The README calls v2 pre-alpha, and that governs everything else

The status banner at the top of the repository is the first thing to read and the thing that decides whether this project is usable today. It says: status pre-alpha, v2 is a rewrite from scratch in progress on this branch, and nothing runs yet. The default branch is `v2`. The previous version lives on the `dev` branch and receives security fixes only, and the README states there is no migration path from v1 to v2.

That last sentence is the one that matters most for a decision. A team with an existing FluentCMS deployment is not looking at an upgrade, it is looking at a reimplementation that would have to be migrated by hand to a different architecture. A team starting fresh can read the design documents without inheriting a sunk cost.

The release history reinforces the picture. The published tags are v0.0.3, described as a first attempt to publish to NuGet, then v0.0.4 and v0.0.5, with the newest release dated 2024-12-16. The last push to the tree was on 2026-10-20, so the code is moving even though no release has been cut from the v2 branch. Anyone evaluating this needs to distinguish between the activity of the repository and the availability of a usable artefact, and the two are not the same here.

The site itself is at fluentcms.com, and the project identifies itself as an ASP.NET Core Blazor content management system.

MCP tools instead of admin screens, with forms as the fallback

The central design decision is that the agent does the work by default, and people write the rules and review what matters. Concretely, agents operate the CMS through MCP, the Model Context Protocol, and every capability is a tool before it is a screen. Forms exist as the fallback for people who want to click rather than prompt.

The consequence for a reader evaluating the project is that the admin UI and the agent interface are not two parallel frontends over the same domain, they are one capability set with two consumers. The first milestone in the roadmap makes this explicit: M1 Governance core is to be operated by external agents only. The full admin UI is scheduled later, in M2 Built-in agent and full admin, alongside roles, scheduled and triggered tasks on the owner's model key, email and webhook notifications, and OAuth for hosted assistants.

The stack follows the same bias. The project uses the official C# MCP SDK for the agent surface, Microsoft.Extensions.AI for model access, Blazor for the admin UI, and EF Core with PostgreSQL for production and SQLite for development. The architecture decision records listed under `docs/adr/README.md` cover .NET 10, branching, solution structure, persistence, admin UI, MCP server, model access, identity, search and jobs, and the component set.

There is no built-in renderer, theme or page builder, because delivery is headless: frontends read a delivery API. That is a clean separation for teams that already have a frontend stack, and it means the CMS ships no opinion about what a page looks like.

The rule book compiles into checks, and unchecked rules stay advisory

The governance story has three parts, and the second one is the interesting engineering claim. Rules are written in plain language and compiled into checks that block violations. A rule that cannot be checked is labelled advisory and is shown as such.

That distinction between a checkable rule and an advisory one is what keeps the system honest. A rules engine that silently accepts unenforceable rules produces a false sense of governance, and the design here says out loud when it cannot enforce something. The README states the boundary of agent authority in the same breath: agents never approve or publish by judgment, only checks can auto-publish, and only where a routing rule allows it.

Risk routing is what turns the rule book into a workflow. Four outcomes for a change set are described there. Routine sets pass on checks, risky sets wait for a person, large sets are sampled, and a set is published and reverted atomically. Sampling for large sets is a deliberate trade: reviewing every line of a bulk edit does not scale, so the system accepts statistical inspection instead of pretending to be exhaustive.

The review desk is listed as part of M1, which is where the human involvement is designed to happen. A team reading this repository is really reading a specification of a governance workflow, and the question to ask is how much of it is implemented against the roadmap.

Typed entities, provenance, and no copied facts

Two content principles in the README are worth separating, because they solve different problems.

The first is that facts live once. Prices, dates, names and limits are typed entities with a source and an owner, and content references them rather than storing a copy. The failure mode this prevents is a landing page that says one price and a support article that says another, with no obvious place to fix the inconsistency. Under this model there is a single record to correct, and correcting it changes every reference. The cost is that content becomes a graph of references rather than a document, and the delivery API has to resolve those references for consumers.

The second is provenance on every published item: whether AI was involved, who reviewed it, and where the facts came from. The audit log is part of M1, so this is intended to be recorded, not just described. Combined with the change set model, which carries a diff, the agent's rationale and its sources, the system gives you both the what and the why of every published change.

The change set deserves a second look. The README says every change is a change set, and that these are grouped edits rather than individual item saves. For a human reviewer this is the difference between reviewing a coherent batch and reviewing a stream of unrelated diffs. Atomic publish and revert means a batch either lands as a unit or does not.

Self-hosted on .NET 10, with one external dependency

The stack section is short and specific: .NET 10, EF Core with PostgreSQL for production and SQLite for development, Blazor for the admin UI, the official C# MCP SDK, and Microsoft.Extensions.AI for model access. Self-hosted and MIT licensed, with no required external service other than a model provider, according to the same section.

That last clause is the real dependency, and it deserves attention. Everything else runs on your own infrastructure, but an agent-driven CMS needs a model to drive the agent, so there is a provider to choose, keys to manage and per-run cost to consider. The M2 milestone mentions scheduled and triggered tasks on the owner's model key, which is the point where usage becomes a standing expense rather than an occasional one.

The repository layout backs up the .NET 10 and modern tooling story. There is a `FluentCMS.slnx` solution file, `global.json`, `nuget.config`, `Directory.Build.props` and `Directory.Packages.props` for central package management, `src/` and `tests/` for code, and a `docs/` directory holding the requirements set. The requirements set is unusually complete for a project at this stage: a decision record, vision and principles, personas and scenarios, a feature list, functional and non-functional requirements, a glossary, and an explicit out of scope document.

Documentation is present for contributing and for security policy, and the community links include a Discord and an announcement issue explaining what v2 is and why the restart happened. There is also a `CODE_OF_CONDUCT.md` and a `.config/` directory.

Where FluentCMS v2 is the wrong choice today

The primary limitation is not subtle: the project says it does not run. There is no install command in the documentation, no deployment guide, and no published package for the v2 branch, so there is nothing to install and no way to evaluate the behaviour of the governance model beyond reading the specification. The README's own instruction for interested people is to read the announcement issue about the restart, which is a call for contributors rather than a call for users.

The second limitation follows from the architecture. With agents as the primary operator and the admin UI deferred to M2, a team whose editors are not comfortable with agent workflows and cannot wait for a UI has no ergonomic path. Forms are the documented fallback, but the scope of what forms can cover is not spelled out, and the full admin surface, roles and notifications are all M2 items.

The third is a governance maturity gap. Everything interesting about this design is a promise in the roadmap: the rule book, risk routing, the review desk, the audit log, the delivery API, generated forms, media and sign-in are M1 scope, while multi-language, multi-site and a public plugin SDK are M3. A framework where the plugin SDK is a scale-out milestone is not yet a platform others can build on.

There is also an unresolved tension in the agent model worth naming. The rule book is written in plain language by people, and compiled into checks. A natural language rule is a statement of intent, and compiling it into a check requires deciding what the check must be. The project handles the case where that is impossible by marking the rule advisory, but the README does not describe who resolves the gap between the intent and the check, or how often a rule set drifts from its compiled form.

How this differs from a conventional CMS and from v1

A conventional CMS treats the editor as the primary user and exposes screens for creating, editing and publishing. FluentCMS v2 inverts that: the operator is an agent acting through a tool protocol, and the human role shifts to writing rules and reviewing change sets. The practical difference is not cosmetic. In a conventional CMS, a human produces content directly and the audit log records what they did. Here, the agent proposes, checks gate the proposal, and the review desk is where a person decides, with the diff and the rationale presented for that decision rather than the raw edit.

The other difference is delivery. There is no built-in renderer, theme or page builder, and frontends read a delivery API. A team that wants a CMS to also be the website, with templates and a page builder included, will find nothing of the sort here. The gain is that the CMS does not fight the frontend stack it sits next to.

Against the previous version of FluentCMS, the difference is a rewrite rather than an evolution. The v1 code lives on the `dev` branch and gets security fixes only, and the README is explicit that there is no migration path. So the honest comparison for an existing user is between staying on a maintained-but-frozen v1 and starting a v2 project that you build largely from the specification, with the option of contributing upstream if the design appeals to you.

Editorial conclusion

Adopt FluentCMS v2 only if you are willing to build on a pre-alpha branch, because the README states that nothing runs yet and that there is no migration path from v1. Do not adopt it for a production site, and do not plan a v1 to v2 move, since the previous version on the `dev` branch takes security fixes only. If you want to evaluate it, the concrete first step is to read `docs/adr/README.md` for the .NET 10 and PostgreSQL decisions, then check the M1 Governance core milestone to see which of the promised pieces, MCP server, rule book, change sets, delivery API, are actually present in `src/` on the `v2` branch.

Frequently asked questions

Official sources

1. fluentcms/FluentCMS on GitHub
2. License: MIT
3. Project website
4. README
5. Releases