Multi‑tenant CMS — the content backbone for every Delectable surface.
CMS is the cross-platform content management module that powers the admin surface, tenant branding, and content delivery for every Delectable product. One service, deployed to GCP for Delectable customers and Azure for Earley Information Science customers; tenants are isolated by configuration, not by fork.
The agentic surfaces — not a page builder, a control plane
Every other CMS is a fancy WYSIWYG. Ours is a structured control plane for agentic experiences — templates declare slots, slots bind to agent contracts, and agents resolve content in real time against tenant rules and the knowledge graph. The screens below show that model in production.
Templates aren’t pages — they’re experience blueprints. Each template defines Libraries (shared shells), Templates (page/screen/placement contracts), Variants (rollout treatments + A/B), and Slots (where content, components, and agent panels resolve). The Agent Chat dropdown in Live Preview lets operators preview how the agent populates this surface in‑context against a sample shopper.
Placements are the bridge between an agent panel and a template slot. Each placement carries the surface (web, app, in‑store, agent console), bid floor, creative constraints, and targeting defaults — so a sponsored slot in a chat‑agent response and a sponsored slot on the home page share the same governance, attribution, and creative pipeline. Same record, different surface.
Versioned content browser. Git‑like branching, semantic tagging, status filters — all backed by the content‑addressable storage layer.
Schema editor for content models. Define fields, semantic tokens, and validation. Tenants extend a shared base library or fork their own.
What CMS gives you
Tenant resolution & branding
Domain → tenant mapping in via_tenant_domains. Brand colors, logos, fonts, and custom CSS in via_tenant_branding. TenantMiddleware caches resolution for 5 min and injects CSS variables into every page render.
Content authoring
Author once, publish to web, app, in-store kiosk, voice. The schema is semantic-token aware so AI agents and humans see consistent vocabulary.
Feature flags & entitlements
Per-tenant module access via via_tenant_features. Turn on Ads, Social, IA, PIM, or Governance independently per tenant. Enforced via fastapi_permissions dependencies.
Document & knowledge intake
SCHEMA-aware document ingestion with auto-classification, entity extraction, and indexing into the Memgraph knowledge graph. Source of truth for the “Ask” assistant on every console.
Shared chrome contract
One header partial, tenant-themed, with global search + Ask drawer + environment + version badges. Every Delectable admin surface inherits the same affordances.
Content-API for agents
All content is queryable via the agent tool surface. The Delectable AI agent grounds product, recipe, and dietary content through the same CMS that powers the admin UI.
AI‑first content architecture
The headline is “multi‑tenant CMS,” but the moat is the underlying structure: every piece of content is typed, semantically tokenized, agent‑callable, and version‑controlled like code. Six concepts compound into the differentiation.
Information architecture
Every surface declares its type — not its layout. Surface types: retail_media_slot, commerce_page, agent_console, site_page, chat_shell. The surface type drives which slots, rules, workflows, and agent contracts are valid — so you can’t accidentally bind a creative to an unsupported context.
Schema‑aware taxonomy
Content fields are tagged with semantic tokens drawn from schema.org and our domain vocabulary (Food HyperGraph attributes, dietary flags, mission states). Operators see token chips next to fields; agents query by token, not by display string.
Knowledge‑graph ontology
Tagged content is projected into Memgraph as typed nodes with relationships to products, ingredients, dietary attributes, and shopper missions. The Eagle AI agent grounds in this graph — meaning content authored in CMS becomes queryable structure, not just rendered text.
Tenant‑scoped metadata
Every content item carries tenant‑scoped metadata: source, author, evaluation scores, drift flags, governance tags, last‑reviewed timestamp. Agents use it for retrieval ranking and refusal reasoning; humans use it for review queues. Same source of truth.
Smarkdown — semantic markdown
Authors write in markdown; the runtime parses it into a structured AST where blocks carry semantic types (recipe step, dietary callout, sponsored slot, agent prompt) and inline tokens link to graph entities. Markdown that an agent can reason about, not just render. Forward‑looking work; the AST shape is wired for the next migration.
Content‑addressable storage
Live in production today (migration 002_content_addressable_storage). Every content blob is keyed by SHA‑256, every commit references parent commit + blob hash, every branch is a named ref to a commit. Git for content. Diffs, branches, merges, audit trails — all native.
Once content is typed, tokenized, graph‑projected, and content‑addressed, an LLM stops being a creative wildcard and becomes a composer of verified facts. Hallucination drops not because we “prompt better” but because there’s less left for the LLM to invent. Every other piece of the platform (Eagle AI agent, Ads, Social) inherits this discipline through CMS — which is why CMS is the multiplier, not just another module.
How tenants are configured
A tenant is a JSON config file in infrastructure/src/infrastructure/customers/<slug>.json. Registering a tenant creates the org row, applies branding, grants module entitlements, and (for full customers) bootstraps the per-tenant database schema. For investor or partner portals the registration uses --skip-schema.
{ "customer": { name, display_name, org_type, subscription_tier, metadata{...} }, "entitlements": { "modules": [ { "module": "ads", "entitled": true }, { "module": "social", "entitled": true }, { "module": "cms", "entitled": true } ] }, "tenant": { "slug": "florida-funders", "branding": { app_name, colors{...}, fonts, logos }, "email_domains": ["floridafunders.com"], "features": { "investor.florida_funders": true } } }
$ cd ~/code/infrastructure $ python -m infrastructure.customers.register florida-funders.json --skip-schema
Architecture
domain → slug
port 8093
via_tenant_branding
per request
via_tenant_features
fastapi_permissions
/ads, /social, /cms, ...
consistent chrome
CMS is the multiplier under every other module.
Every console you see in this library — ads, social, eagle AI, pim, governance — renders through CMS’s tenant resolver. That’s how a single line in a JSON config grants a new investor or partner access to exactly the right surfaces with their own branding.