Console and API share one record

If your public API drifts from the editor UI, you do not have a platform. You have two backends.

That statement becomes even more important when AI agents join the system.

Humans use the Console. Applications use the API. Agents use MCP. They should still operate one backend.

Different interfaces. One backend.

This article is about one system of record — not a feature note that “Console data is also available via API.” For the category, see /blog/what-is-ai-era-backend-platform. For how agents operate that backend, see /blog/operate-luno-from-mcp.

The problem with separate representations

Many stacks grow an “admin CMS” and a “developer API” that slowly diverge. Schemas fork. Publish meaning forks. Permissions fork. Validation forks.

Console
   ↓
CMS database

Public API
   ↓
Separate API model
   ↓
Sync / transformation
   ↓
Frontend

When agents arrive, they often write yet another client against whatever is convenient — and the fragmentation accelerates.

If the API drifts, you have two backends

An API is not a second backend

An API-first slogan is not enough. “Everything is available through an API” can still hide a second representation.

API parity is not enough. State parity matters.

What must stay shared is the underlying state: data, content, schema, forms, media, publishing state, revisions, relationships, and configuration — not merely “the same database row” in a narrow sense.

Console does not create something that the API later copies. Different interfaces refer to and operate the same backend state.

One system of record

Console
   │
   ▼
┌─────────────────────┐
│   Shared Backend    │
│   Same data         │
│   Same schema       │
│   Same state        │
│   Same rules        │
└─────────────────────┘
   ▲          ▲
   │          │
  API        MCP
   │          │
Application  AI Agent

The interface changes. The backend does not.

A platform is not just an API around a database. It needs a consistent data model, shared state, shared authorization semantics, lifecycle, publishing, and operational meaning.

Console is an interface, not the backend

Console is not merely an admin dashboard bolted on top. It is one interface to the backend — optimized for humans to inspect, create, edit, publish, configure, and manage.

Console → Human interface
API     → Application interface
MCP     → Agent interface

API is an interface, not a second backend

Applications should consume the backend itself — not a exported copy of a CMS. Read published state through the public API because that state lives on the same record editors and agents already operate.

The frontend does not consume a copy of the backend. It consumes the backend itself.

MCP is an interface, not an agent backend

Do not invent a third world for agents:

Wrong
Console → Human Backend
API → Application Backend
MCP → Agent Backend

Right
             LUNO Backend
                  │
       ┌──────────┼──────────┐
       │          │          │
    Console      API        MCP
       │          │          │
     Human    Application   Agent

MCP is another interface, not another backend.

Interface drift becomes backend fragmentation. When Console supports A, API supports B, and MCP supports C, you get three interfaces and three realities.

One backend, three operators

In the AI era, agents are another class of backend operator.

                 One Backend
                     │
       ┌─────────────┼─────────────┐
       │             │             │
     Human       Application      Agent
       │             │             │
    Console         API           MCP

Rough roles:

Human: inspect / configure / approve / manage
Application: read / submit / display / integrate
Agent: discover / create / modify / operate / verify

Same backend does not mean same authority.

Authentication, authorization, approval, and production governance remain separate concerns. One source of truth without one giant permission model. See /blog/agent-autonomy-without-production-authority.

Why one system of record matters more in the AI era

When humans, applications, and agents all mutate shared state, separate backends create synchronization, conflicts, stale data, duplicated state, and inconsistent permissions.

The more operators a backend has, the more important a single source of truth becomes.

Concrete example: an AI agent creates content

Suppose an agent creates a blog post over MCP.

Agent creates
       ↓
Same record
       ↓
Human reviews in Console
       ↓
Publish updates state
       ↓
API serves published state
       ↓
Website renders

No synchronization job is required to copy the agent’s content into a separate CMS. Publishing state is part of the same system of record: draft → published → API-visible.

Same state, different authority

Interfaces can expose different surfaces of the same backend. That is normal. What must not fork is the underlying record and its rules.

*Application-facing Public API is oriented to consuming published state; write and management paths use authenticated admin/agent surfaces. The point is shared backend semantics — not identical UI chrome on every interface.

Why this matters for applications

If Console publish and API visibility disagree, your frontend inherits two truths. If an agent writes to a shadow store, humans inherit another. One system of record keeps the application on the same lifecycle as editors and agents.

Where LUNO fits

This is how LUNO is designed.

Human
  → Console

Application
  → REST / Public API

AI Agent
  → MCP

        ↓

   LUNO Backend

They are not three ways to access three systems. They are three ways to operate the same backend.

CMS history often started with a human editor and added an API later. Comparisons belong elsewhere — see /blog/luno-vs-wordpress-contentful. The design claim here is simpler: one system of record.

Why stop rebuilding that backend project by project is /blog/never-build-backends-again. How pricing should follow the same unit is /blog/pricing-without-seat-tax.

Conclusion

A backend should have one source of truth.

Humans may use the Console.
Applications may use the API.
Agents may use MCP.

The interface can change.
The authority can change.
The client can change.

The record should not.

One backend.
Different interfaces.
Different authority.
One system of record.

Different interfaces. One backend.

LUNO is Backend Platform for the AI Era. Next: how agents operate that backend — /blog/operate-luno-from-mcp — and how authority stays explicit — /blog/agent-autonomy-without-production-authority.