Headless CMS for AI

What's in this pack

This pack collects the five headless backends worth installing when you need an AI agent to read or mutate real business data — content, products, orders, users — without writing custom CRUD endpoints.

The split is intentional: Strapi for editorial content, Medusa / Vendure for product+order data, Directus / Hasura for arbitrary SQL surfaces. Most production systems pick one from each row depending on which use cases dominate.

Why headless matters for agents

Traditional CMSs ship HTML; agents do not consume HTML well. Headless CMSs ship typed JSON and GraphQL schemas. The difference compounds:

• Schema introspection. GraphQL endpoints are self-documenting. An agent can call __schema and discover what fields exist, what they return, and what arguments they accept. No manual API docs to keep in sync.
• Mutation safety. REST + GraphQL endpoints declare write operations explicitly with input types. Agents can validate before sending, and the server rejects malformed payloads at the transport layer rather than after a partial write.
• Permissions. Each tool here ships role-based access control. You can give the agent a scoped token that can only read certain content types or only mutate specific resources, with audit logs.
• Multi-language and i18n. Strapi and Directus have first-class locale support, which matters when the agent is generating or translating content.

These properties are why a headless CMS, even when overkill for the human content team, is often the right substrate for an agent-driven product.

Install in one command

# Install the entire pack
tokrepo install pack/headless-cms-for-ai

# Or pick a single backend
tokrepo install strapi
tokrepo install hasura

Each tool installs as a Docker compose snippet plus a Claude Code skill that knows the tool's API surface. The skill exposes typed methods like strapi.list_articles({ filters }) so the agent doesn't have to handcraft REST URLs.

Common pitfalls

• Schema drift between agent and server. When you add a content type in the admin UI, the agent's local schema cache goes stale. Re-introspect on every session start, or wire a webhook so the agent invalidates on content-type changes.
• N+1 queries from agents. Agents tend to fetch one record at a time. Use the bulk endpoints (Strapi's populate=*, Hasura's nested selections) and budget queries — set a per-agent rate limit.
• Public read tokens. It's tempting to give the agent a wide-open read token. Don't. Scope to specific collections; revoke on role change. Each of these tools has fine-grained permission UI.
• Mutation idempotency. Agents retry. If an agent retries a createOrder mutation after a network blip, you'll get duplicates. Use idempotency keys (Medusa supports them natively; for others, layer a request_id field).
• Backups. Headless CMSs centralize content; if the database is corrupted you lose a year of editorial work. Set up daily snapshots before you let the agent write to production.

Common misconceptions

• "Hasura and Directus are interchangeable." They overlap on "expose SQL as GraphQL" but differ in audience: Hasura is for engineers who want a thin GraphQL veneer over Postgres; Directus is for teams that also want a content admin UI. If you only need the API, use Hasura. If non-engineers will edit data, use Directus.
• "Strapi can replace Medusa for commerce." Strapi handles content beautifully but lacks order workflow, payment, and inventory primitives. Use Medusa or Vendure for those, then point Strapi at content adjacent to products (blog, marketing pages).
• "GraphQL is always better than REST for agents." Sometimes — schema introspection is great. But for simple list/get operations, REST endpoints are easier to cache and easier for the agent to compose with HTTP-level tools. All five tools speak both; pick per call.

Relationship to other packs

• Postgres for Agents is the data layer beneath Hasura and Directus.
• MCP Server Stack includes MCP wrappers around these CMSs so the agent can use them via MCP rather than raw HTTP.
• AI App Builders consume these GraphQL endpoints from the frontend side.