← Back to Blog

What happens when your CMS has readers that are not people?

Ask Refined Element is a small Xperience by Kentico knowledge pack published from one structured content model to people, crawlers, apps, and AI agents. Two premium answers can also be bought by an agent over Lightning through HTTP 402.
What happens when your CMS has readers that are not people?

For most of the web, a CMS has one job: put useful pages in front of people.

That is still the job. It is just no longer the whole job.

A useful piece of consulting knowledge may now be read by a person on a website, pulled into an application, summarized by a crawler, or requested by an AI agent working for someone else. Those readers do not all want a web page. And if the same answer has to be recreated for each of them, the CMS has stopped being a source of truth and become a filing cabinet with six sets of copies.

That was the question behind Ask Refined Element: can I take a small, real body of Xperience by Kentico knowledge and make it available to different kinds of readers without building a separate product for each one?

The answer is yes, with one important caveat about the parts of the platform that still need to catch up.

Start with a small body of work

Ask Refined Element is deliberately small. It contains eighteen items drawn from work I had already done: Kentico upgrade guidance, agent-ready CMS practices, Sentinel health-scan material, checklists, and a few descriptions of the services behind them.

I did not set out to build a giant knowledge base. I wanted to test a more practical proposition: take material that already has value, put it into a structured model, and see how far one source can travel.

The content is authored in Xperience by Kentico once. From there, it appears through several delivery surfaces:

  • a human-readable page at Ask Refined Element
  • llms.txt and structured metadata for AI discovery
  • a public JSON API for applications
  • a headless GraphQL surface for structured queries
  • an MCP server for agents that prefer typed tools over scraping pages
  • a paid API path for two deeper playbooks

That list can sound like architecture for architecture's sake. It is not. Each surface is just a different way to read the same underlying content.

A browser gets a page. An application gets JSON. An agent gets a tool. None of them should require a second editorial workflow.

The reader changes the product

The most interesting reader here is the agent.

An agent does not need a navigation menu or a webinar registration form. It needs a way to ask a bounded question, understand what is available, and retrieve a useful answer in a format it can work with. MCP is a good fit for that. The Ask Refined Element MCP server lets an agent search the pack and retrieve an item without pretending to be a person in a browser.

That changes the shape of a consulting site a little.

It does not make the website obsolete. People still need context, judgment, proof of work, and a reason to trust the person behind the material. But it creates another path into the expertise: a machine-readable one for work that begins inside someone else's agent workflow.

This is the part I think more CMS teams should take seriously. The question is no longer only, "Can we publish this page?" It is also, "Can a machine find, understand, and use the knowledge we have already published?"

A paid answer without a shopping cart

Two items in the pack are not free: an upgrade-risk triage playbook and an agent-ready CMS checklist.

When an agent requests one of them, the API returns HTTP 402, Payment Required, with a Lightning invoice. The agent can pay 100 sats, then retry with the resulting proof of payment. If the proof checks out, the API returns the content.

There is no account creation, checkout form, or human in the loop. The first end-to-end retrieval worked: an agent requested a playbook, received a 402 challenge, paid it through the free, open-source Lightning Enable MCP, retried, and received the answer.

It was only 100 sats. That is the point.

I am not claiming that agents are about to replace consulting relationships with ten-cent purchases. Most valuable work is still contextual and collaborative. But very small payments are useful for a different category of thing: a concise answer, a checklist, a diagnostic, or a narrow playbook that an agent needs right now. They're also useful as anti-spam — trivial for a legitimate agent, expensive at scale.

The web has had a 402 Payment Required status code for decades. L402 gives it a practical flow for this kind of exchange: request, price, pay, prove payment, receive the resource. For a small machine-to-machine purchase, it is a cleaner fit than forcing an agent through a consumer checkout.

Lightning Enable is the Refined Element product that provides the payment plumbing here. Ask Refined Element is a practical test of what that plumbing looks like when it is attached to real consulting knowledge rather than a demo endpoint.

The important caveat

Building this also exposed a gap worth saying plainly.

The headless content channel is the most natural place for structured, agent-readable knowledge. But the Management API preview and KentiCopilot tooling that made the earlier agent-assisted site work possible do not yet author that headless content type directly. They work with pages and reusable content.

That meant I could not honestly say that an agent authored every part of this system through the same management surface. I used a targeted conversion step to put validated content into the headless channel, then kept the paid material out of GraphQL so a broad read key could not bypass the paywall.

That is not a reason to abandon the approach. It is a useful boundary: the delivery model works, but agent operations need to reach the headless model cleanly before the workflow is truly end to end.

It is also a good reminder that an "agent-ready" CMS is not a badge you add to a product page. It is a set of operational choices about what content is structured, what can be queried, what can be changed safely, and what should remain protected.

One source, more than one reader

The point of Ask Refined Element is not that eighteen pieces of content make a knowledge empire.

The point is that the same small body of work can serve different readers without being rewritten into six separate systems. The CMS manages the material. The site explains it to people. The API and MCP server make it useful to software and agents. L402 makes a small paid exchange possible when the answer is worth more than a free lookup.

That feels like a more realistic next step for an established CMS than a dramatic reinvention. Start with a useful slice of what you already know. Structure it well. Give it more than one way out.

The browser is still a reader. It is just no longer the only one.