The AI-First CMS Manifesto

The Evaluation That Broke Me

Last year, a friend asked me to help evaluate headless CMS options for his team. They had a Next.js app, a growing content operation, and the kind of ambitions that meant whatever they picked would be load-bearing for years. So I did what any responsible developer would do: I opened fourteen browser tabs and started comparing.

Contentful. Sanity. Strapi. Payload. Hygraph. Directus. The list kept growing. Every platform had a slick marketing site. Every one promised "powerful content management." Every one had a feature matrix that looked like every other feature matrix.

But something felt wrong. Not with any individual product — most of them are good at what they do. The problem was that every option felt like it was built for a world that no longer exists. A world where humans type every word into a rich text editor, where content models are configured through point-and-click admin panels, where "developer experience" means "we have a GraphQL API."

That world ended in 2024. And the CMS market hasn't caught up.

The question that kept nagging me wasn't "which CMS has the best feature set?" It was "which CMS was designed for a world where AI agents create, review, and publish content?" The answer, as far as I could tell, was none of them. That's the gap we're building Laizy to fill.

The Shift Nobody Planned For

Three things changed simultaneously, and the CMS industry is still processing the implications.

AI agents write content now. Not in a "here's a rough draft" way — in a "here's a complete, structured, brand-consistent blog post with proper metadata, SEO tags, and a generated hero image" way. The quality bar for AI-generated content crossed the threshold where it's no longer distinguishable from human-written content for most use cases. This doesn't mean humans are out of the loop. It means the bottleneck shifted from creation to review.

Developers work through CLI tools and code editors, not dashboards. The developer experience revolution that Prisma brought to databases, that Terraform brought to infrastructure, that Tailwind brought to CSS — that hasn't happened for content management. We still configure content models by clicking through admin UIs, then wonder why our staging and production environments have different schemas. The best developer tools meet developers where they already work: in the terminal, in their editor, in their CI pipeline.

Content is structured data, not documents. This one has been true for a while in the headless CMS world, but AI amplifies it. When a human writes content, they can work with unstructured blobs of rich text — they understand context, they know what goes where. When an AI agent writes content, it needs explicit structure: typed fields, validation constraints, relationships between content models. The more structured your content, the better AI can work with it. The less structured, the more hallucination, inconsistency, and manual cleanup you deal with.

Each of these shifts alone would warrant rethinking CMS architecture. Together, they demand it.

The question isn't whether CMS platforms will adapt. They will — every major player is already adding "AI features." The question is whether adaptation is enough, or whether this is one of those architectural inflection points where the tools built from scratch for the new paradigm will outperform the ones that retrofitted it.

We believe it's the latter.

What AI-First Actually Means

Let's be precise about what "AI-first" means, because the term is at risk of becoming meaningless. Half the CMS platforms on the market have already added "AI-powered" to their homepage. Most of them mean they added a button that sends your text to ChatGPT and pastes the response back. That's not AI-first. That's AI-adjacent.

AI-first is an architectural claim, not a feature claim. It means the entire system — from schema definition to content creation to developer tooling — was designed assuming that AI agents would be primary users of the platform, alongside humans. Here's what that looks like in practice.

Schema-Aware AI

When an AI agent creates content in a traditional CMS, it's working blind. It might know there's a "title" field and a "body" field, but it doesn't know the title has a 200-character limit, that the slug must be unique, or that the status field only accepts specific values. So it generates content, submits it, gets a validation error, guesses at a fix, and tries again.

In an AI-first CMS, the schema itself is the AI's instruction manual. The content model — with all its field types, constraints, relationships, and defaults — is structured data that an AI agent can read before generating anything. The agent knows the rules before it starts writing. This isn't a minor optimization. It's the difference between "try and fail" loops and getting it right on the first attempt.

File-System-First for Agents

AI coding agents work on files. Claude Code, Cursor, Windsurf, GitHub Copilot Workspace — every major AI development tool operates on the file system. They read files, write files, run commands. They don't click buttons in web UIs.

If your content model lives in an admin dashboard, AI agents can't read or modify it without screen scraping or a specialized API integration. If your content model lives in a file in your repository — a .laizy schema file, version-controlled and diffable — any AI agent can read it, understand it, and even propose changes to it through a pull request.

This is the same principle that makes Infrastructure as Code superior to clicking through cloud consoles. The file system is the universal interface.

CLI-Native Workflows

Every operation that a human can do through a dashboard should also be available as a CLI command. Not because CLIs are cooler than dashboards (though they are), but because CLI commands are scriptable, pipeable, composable, and agent-friendly.

An AI agent can run laizy content create BlogPost --json '{"title": "Weekly Digest", "content": "..."}' as part of an automated workflow. It cannot click through a dashboard form. The CLI is the API that agents actually use.

Generated Typed Clients

When you change a content model, every consumer of that content needs to know about it. In traditional CMS platforms, this is a runtime discovery — your frontend crashes when a field that used to exist doesn't anymore.

In an AI-first CMS, running laizy generate produces a TypeScript client where every model, every field, and every method is fully typed. Change the schema, regenerate, and TypeScript tells you at compile time what broke. AI agents can use these types to understand what content looks like without trial and error.

Schema as Rosetta Stone

The schema is the single most important artifact in an AI-first CMS. It's the shared language between humans, AI agents, and application code. Get it right, and everything downstream works. Get it wrong, and you're fighting the system at every step.

Here's what a Laizy schema looks like in practice:

model BlogPost {
  title: String {
    required: true
    maxLength: 200
  }

  content: String {
    required: true
  }

  slug: String {
    required: true
    unique: true
  }

  status: String
}

model Author {
  name: String {
    required: true
    maxLength: 100
  }

  email: String {
    required: true
    unique: true
  }

  bio: String
}

This isn't configuration hidden in a database. It's a file in your repository. It goes through code review. It's version-controlled. It's diffable. And critically, it's readable by any AI agent that can read text files.

When an AI agent encounters this schema, it knows:

• A BlogPost requires a title (string, max 200 characters), content (string, required), and a slug (string, required, must be unique)
• An Author has a name, email (unique), and optional bio
• The status field on BlogPost is optional with no constraints

This is enough information for the agent to generate valid content on the first attempt. No guessing. No trial-and-error. No "I'll create a post and see what errors come back."

Compare this to the alternative: an AI agent hitting a REST API, getting back a 422 error with {"error": "title exceeds maximum length"}, adjusting, retrying, getting another error for a different field, adjusting again. That's the workflow you get when content models are opaque runtime configurations instead of readable schema files.

The schema is also the contract between your content model and your application code. When you run laizy generate, the schema is compiled into TypeScript types and a client library. Your application code gets full autocomplete and compile-time checking. Change a field name in the schema, regenerate, and every reference in your codebase that uses the old name lights up red. This is the same DX that Prisma brought to database modeling — and it's overdue for content management.

The Agent Workflow

Here's what it looks like when an AI agent manages content through Laizy, end to end. These are real CLI commands, not mockups.

Step 1: Initialize the project. The agent runs laizy init, which creates a configuration file, a starter schema, and links the local project to a Laizy CMS project in the cloud.

$ laizy init
✓ Created ~/.laizyrc
✓ Created laizy/schema.laizy
✓ Linked to project "my-website"

Step 2: Define the schema. The agent edits laizy/schema.laizy to define content models. It can read existing schemas, understand field types and constraints, and propose additions or modifications — all through standard file operations.

$ cat laizy/schema.laizy
model BlogPost {
  title: String {
    required: true
    maxLength: 200
  }
  content: String {
    required: true
  }
  slug: String {
    required: true
    unique: true
  }
  status: String
}

Step 3: Sync to the database. The agent runs laizy sync to push schema changes to the cloud database. The sync command analyzes changes, shows an impact analysis (which changes are safe, which might cause data loss), and applies them.

$ laizy sync
✓ Analyzing schema changes...
  + BlogPost (4 fields)
  + Author (3 fields)
✓ 2 models synced

For safety, laizy sync --dry-run previews changes without applying them — a workflow that's natural for agents that want to validate before committing.

Step 4: Generate the typed client. Running laizy generate produces a TypeScript client with full type safety. The agent's application code gets autocomplete for every content model and field.

$ laizy generate
✓ Generated types.ts
✓ Generated client.ts
✓ TypeScript client ready

Step 5: Create content. The agent pipes structured JSON into the CLI to create content. Because it has already read the schema, it knows exactly what fields to include and what constraints to respect.

$ echo '{"title": "Weekly Product Update", "content": "...", "slug": "weekly-update-feb-10", "status": "draft"}' | laizy content create BlogPost
✓ Created BlogPost (ec87a7ei)

The agent can also list existing content, check status, and manage the full content lifecycle from the command line:

$ laizy content list BlogPost --status published
  ID          Title                Status
  ec87a7ei    Weekly Product Update    published

This entire workflow is file-based, CLI-driven, and requires zero interaction with a web dashboard. An AI agent can execute it end to end without human intervention. A human can also use the exact same workflow — the CLI is the great equalizer.

What This Means for Content Teams

AI-first architecture isn't only a developer concern. Content teams are the ones who benefit most, even if they never touch the CLI.

AI that respects your content model. When a content team member asks the AI to create a blog post, the AI doesn't produce a free-form blob of text. It creates structured content that fits your exact content model: the right fields, the right constraints, the right defaults. The result is content that's ready for review, not content that needs reformatting into your CMS's structure.

Faster creation, more time for editing. The best content workflows separate creation from curation. AI handles the first draft — the hard, blank-page work of getting words into the right structure. Content teams focus on what humans do best: editing for voice, checking for accuracy, making strategic decisions about what to publish and when. This isn't about replacing content people. It's about freeing them from the mechanical parts of their job so they can focus on judgment and creativity.

Brand voice consistency. When you configure your AI with style guidelines and your content schema enforces structural consistency, the output is remarkably uniform. Not in a boring way — in a "our blog doesn't read like it was written by fifteen different people" way. Every organization with more than one content creator has struggled with voice consistency. Structured schemas plus AI-aware content creation is the first solution that actually works at scale.

Approval workflows stay human. Nothing gets published without a human deciding it should. AI creates drafts. Humans approve them. The technology accelerates the pipeline without removing the checkpoint that matters most: editorial judgment. The goal is a content team that produces four times the output with the same headcount, not a content team with no headcount.

Where This Is Heading

The trajectory is clear, even if the timeline isn't.

AI agents will become the primary content producers for most organizations. Not because they're cheaper (though they are), but because the content demands of modern businesses exceed what human teams can produce manually. You need blog posts, product updates, documentation, social content, email campaigns, localized variants — the volume is beyond what headcount-based content teams can sustain.

Content will be treated as structured data with the same rigor we apply to database schemas and API contracts. Unstructured rich text editors will feel as primitive as writing SQL queries by hand felt after ORMs arrived. Content models will be code — version-controlled, tested, reviewed, and deployed through the same pipelines as the rest of your application.

The CMS will fade into the infrastructure layer. Just as developers no longer think about their database as a "product" — it's Postgres or it's something else, and you interact with it through an ORM — developers will stop thinking about their CMS as a standalone platform. It will be a typed interface to structured content, accessible through generated clients and CLI tools, managed through schema files and CI pipelines.

We don't know exactly when this transition completes. But we know the direction. And we're building Laizy for the destination, not the departure point.

The CMS market is about to bifurcate. On one side, legacy platforms bolting AI features onto decade-old architectures. On the other, tools built from scratch for a world where AI generates, reviews, and optimizes content. The platforms that treat AI as a first-class architectural concern — not a feature checkbox — will be the ones that matter in three years.

We're building one of those platforms. If that resonates with you, request access and try it yourself.