IWHWI
IWHWI: AI framework to manage your Directus content via MCP.
Headless CMS platforms like Directus expose collections and fields, while Strapi or Contentful expose content types and fields - but each with its own conventions, its own SDK and its own limitations. The result: your content model is locked into a single tool, your automations must be rebuilt with every migration, and industrialisation remains a manual effort.
IWHWI (Interface Web Headless with Intelligence) is our proprietary Clean Architecture framework that solves this problem. It introduces an abstraction layer above the CMS: Content Types - composed of Nodes (structural building blocks) and Fields (business fields) - are modelled in the business domain, independently of the CMS adapter used. Directus, which does not natively have the Content Type concept (unlike Strapi or Contentful), is the first adapter implemented - the most complex case. Other CMS platforms, which already have this concept, will follow.
Thanks to the MCP protocol (Model Context Protocol), an AI assistant can create structures, synchronise data, translate content and drive the entire lifecycle - all from a conversation. Discover below the architecture, key concepts and concrete capabilities of this framework.
Clean Architecture and CMS abstraction
IWHWI is built on a Clean Architecture with four layers: Domain (entities, nodes, fields), Infrastructure (CMS adapters, data sources), Interface (MCP server, AI commands) and Usecase (facades, services). The business domain is fully decoupled from the CMS: the Directus adapter implements a generic interface (ICmsAdapter) that other CMS platforms can implement.
Content Types: an abstraction above the CMS
Headless CMS platforms like Strapi or Contentful natively include the Content Type concept. Directus, however, only handles individual collections and fields - with no abstraction layer. That is why IWHWI was designed starting from Directus, the lowest-level case, by introducing Content Types composed of Nodes (structural building blocks) and Fields (business fields). For example, the "categories" Content Type is defined in IWHWI with 4 Nodes (1 init, 2 lang, 1 supp) plus additional fields. Under Directus, this definition is automatically translated into 3 collections (categories, categories_base, categories_seo) with all required relations. The Supp Node is not a separate collection: it adds a field group directly within the main collection. This abstraction, designed for the most complex case, will be even simpler to adapt to CMS platforms that already have this concept.
Node system
- Init Node: main collection (identifiers, status, metadata).
- Lang Node: collections linked to the languages Content Type (translated content per language).
- Flag Node: collections linked to the countries Content Type (per-country configurations).
- Supp Node: field groups added to the main collection (images, settings).
Migration from traditional CMS
Thanks to this abstraction layer, IWHWI can also serve as a migration bridge between traditional CMS platforms and modern headless CMS. The goal: retrieve structured content from an existing site - WordPress, Joomla + Seblod, Joomla + K2, Joomla + FlexiContent or Drupal + CCK - map it to IWHWI Content Types, then push it to the target headless CMS (Directus, Strapi, Contentful...). All these systems store content types with custom fields, accessible via their REST APIs or databases. IWHWI will be tested on these migration scenarios to validate this approach.
Fields in three layers
Fields are managed independently of the CMS across three levels: Types (base interface definitions), Generics (reusable business fields) and Specifics (node-specific fields). Each field is a separate file, imported and composed within nodes.
Layered architecture and node system
IWHWI follows a four-layer Domain-Driven Design architecture. The Domain layer defines business entities: typed fields (generic and specific), nodes (Init, Lang, Supp, Flag) and content types (pages, blocks, categories, etc.). Each content type is declared declaratively, with its nodes and fields.
This approach keeps the business model independent of the technical infrastructure.
The Infrastructure layer handles storage, synchronisation and external adapters. Data is organised in versioned folders (aXXXX), each containing three spaces: default (frozen reference), directus (current CMS state) and ia (AI-generated content). Registry files maintain the mapping between local IDs and Directus UUIDs.
This system enables full version tracking and traceability of every change.
MCP integration and AI-driven control
The MCP (Model Context Protocol) lets an AI assistant (Claude, GPT) run actions on external systems. IWHWI implements an MCP server that exposes all its commands as AI tools: creating Directus structures, managing sources, synchronisation, translation, inspecting fields and relations.
AI doesn't just suggest: it runs operations directly on your CMS.
MCP commands cover the full lifecycle: structure (create/remove collections and fields), source (create, update, delete items), sync (sync Directus → local), translate (translate automatically), local (manage translation files), util (inspect fields, relations, items). Each command is documented and typed.
The AI assistant has full, secure control over your Directus instance.
By choosing IWHWI for your content management, you benefit from:
- a framework designed to industrialise Directus content management,
- native integration with AI via the MCP protocol,
- a versioned, reproducible workflow (source/sync) compatible with Git,
- multilingual automatic translation and TypeScript type generation,
- a migration bridge to retrieve content from traditional CMS platforms (WordPress, Joomla + Seblod/K2/FlexiContent, Drupal + CCK) into a modern headless CMS.
IWHWI turns content management into an automated, reliable process driven by artificial intelligence. Contact us for a demo.