Forem: Tony Spiro

The Power of Headless CMS with AI Agents

Tony Spiro — Fri, 22 May 2026 17:28:35 +0000

What if your content could manage itself — publishing, optimizing, and adapting without constant human intervention? Discover how pairing headless CMS architecture with AI agents unlocks truly autonomous, scalable content operations built for the demands of modern digital experiences.

What Is a Headless CMS, and Why Does API-First Matter?

A headless CMS decouples content management from content presentation. Instead of rendering pages directly, it exposes content through APIs so developers can pull structured data into any frontend: a website, mobile app, smart display, voice assistant, or even an in-car interface.

This API-first model matters because it makes content a first-class, programmable resource. Editors define schemas, validation rules, and relationships once, and developers consume that content anywhere. The result is faster iteration, cleaner architecture, and freedom to adopt the best tools for each channel.

Structured content: clearly defined fields, types, and relationships
Omnichannel delivery: one source of truth feeds many surfaces
Composable architecture: best-of-breed tools instead of monolithic lock-in

Why AI Agents Need Structured, Programmable Content

AI agents, autonomous systems that reason, plan, and execute tasks, thrive on predictable inputs and outputs. A traditional CMS, where content lives buried inside HTML templates or proprietary page builders, is a nightmare for an agent to navigate.

A headless CMS, on the other hand, looks exactly like what an agent needs: typed schemas, documented endpoints, and machine-readable content. When an agent can introspect a content model, it knows what a "Product," "Article," or "Event" actually is. It understands which fields are required, which are optional, and how entries relate to each other. That clarity transforms content from a static asset into a programmable surface the agent can operate on.

Concrete Use Cases for AI Agents + Headless CMS

1. Creating and Updating Content Autonomously

Agents can draft blog posts, translate articles, refresh product descriptions, or rewrite metadata for SEO, then push those changes directly through the CMS API. With a structured schema, the agent knows exactly which fields to populate and which validation rules to respect.

2. Generating Media on Demand

Pair a headless CMS with image and video generation models, and agents can produce hero images, alternate crops, social previews, or localized variants automatically. The generated assets get uploaded, tagged, and linked to the right content entries, with no human file-shuffling required.

3. Automating Publishing Workflows

Agents can monitor drafts, run quality checks, request human approval when confidence is low, and schedule publication windows. They can even coordinate multi-step workflows: translate, review, optimize, publish, and notify stakeholders, all through API calls.

4. Multi-Channel Distribution

Once content lives in a headless CMS, agents can syndicate it intelligently. An agent might reformat a long-form article into a LinkedIn post, a newsletter blurb, and a push notification, each tuned to its channel and audience, while keeping the canonical version centralized.

Personalized landing pages generated per audience segment
Continuous content audits and automatic cleanup of outdated entries
Real-time localization across dozens of markets

Why the Combination Unlocks Scale

Individually, headless CMS platforms are powerful infrastructure, and AI agents are powerful actors. Combined, they enable something genuinely new: content operations that scale without scaling headcount linearly.

The headless CMS provides the structured "world" the agent can safely act within, with schemas as guardrails, APIs as levers, and version history as a safety net. The agent provides the cognition: judgment, generation, and coordination. Humans shift from executing repetitive tasks to defining strategy, setting policies, and reviewing edge cases.

This pairing also respects governance. Because every change flows through the CMS API, you get audit trails, role-based permissions, and rollback capabilities by default. Autonomy doesn't mean chaos; it means controlled, observable automation.

Looking Forward

We're heading toward a future where content teams operate more like product teams running an autonomous system. Editors will spend less time copy-pasting and more time tuning agent prompts, refining schemas, and shaping editorial strategy.

If you're building digital experiences today, the question isn't whether AI agents will touch your content stack; it's whether your stack is ready for them. A headless, API-first CMS is the foundation that makes the next decade of intelligent, autonomous content operations possible.

Originally published on Cosmic

Top 7 Enterprise Headless CMS Platforms in 2026

Tony Spiro — Thu, 21 May 2026 16:56:35 +0000

Enterprise CMS buying decisions are expensive to get wrong. You're choosing infrastructure that your content, engineering, and marketing teams will live in for years. The wrong call means migration pain, security debt, or a platform that can't keep up with how fast AI is changing software development.

This guide gives you an honest, side-by-side look at the top 7 enterprise headless CMS platforms in 2026, with real pricing where available and a clear-eyed take on what each platform is actually good at.

1. Cosmic

Best for: Enterprise teams that want AI agents, managed infrastructure, and full-stack automation without the DevOps overhead.

Cosmic (cosmicjs.com) is a managed headless CMS backed by Y Combinator (W19). It's built API-first, with a REST API delivering sub-100ms response times and a TypeScript SDK that makes content integration feel native in any JavaScript project.

The platform's defining differentiator in 2026 is its AI agent layer. Cosmic ships four distinct agent types:

Content Agents: Generate and manage CMS content, run bulk operations and migrations.
Code Agents: Connect to GitHub, work on isolated branches, write and ship code, open pull requests.
Computer Use Agents: Automate browser tasks visually, record demos, cross-post media, extract data.
Team Agents: Live in Slack, WhatsApp, and Telegram as actual teammates.

Workflows chain these agents together: a Content Agent writes copy, a Code Agent deploys it, a Computer Use Agent screenshots the preview, a Team Agent posts to Slack.

Other enterprise-grade features:

99.9% uptime SLA
256-bit SSL encryption
imgix CDN for global media delivery
MCP Server for AI tool integration
Agent Skills for Cursor, Claude Code, and GitHub Copilot
REST API + TypeScript SDK + CLI
Supports: Next.js, React, Vue, Nuxt, Astro, Remix, Svelte, Gatsby

"Cosmic is: us never having to ask a developer to change anything on the backend of our website." - Maximilian Wuhr, Co-Founder at FINN

Pricing:

Free: $0/month
Builder: $49/month
Team: $299/month
Business: $499/month
Enterprise: Custom

Additional users: $29/user/month.

2. Contentful

Best for: Large enterprises with established Contentful workflows and dedicated platform teams.

Contentful is one of the most widely deployed headless CMS platforms in the enterprise market. It has a mature ecosystem, a large partner network, and deep integrations with enterprise toolchains.

The tradeoffs: pricing at enterprise scale is significantly higher than most alternatives. AI capabilities are evolving but not as deeply native as Cosmic's agent layer.

Pricing: Paid tiers start at around $300/month. Enterprise pricing is custom.

3. Sanity

Best for: Teams that want maximum schema flexibility and are comfortable owning the editorial UI.

Sanity takes a highly code-centric approach. The content studio is fully customizable in React. Real-time collaboration on content is a standout feature. Steeper learning curve than most CMS platforms.

Pricing: Free tier available. Growth plan starts at $15/seat/month. Enterprise is custom.

4. Storyblok

Best for: Marketing-heavy enterprise teams that prioritize visual editing and component-based content modeling.

Storyblok's visual editor is genuinely excellent. Their FlowMotion feature adds CMS-native workflow automation. Note: FlowMotion automates processes inside the CMS. It does not extend to writing code, deploying to GitHub, or operating as a Slack teammate.

Pricing: Entry plan starts at $99/month. Enterprise is custom.

5. Hygraph

Best for: Content federation and complex multi-source data architectures.

Hygraph specializes in pulling data from multiple sources and unifying it behind a single content graph. Powerful for complex architectures, but may be more than most teams need.

Pricing: Professional plan starts at $299/month. Enterprise is custom.

6. Strapi

Best for: Teams that want full code-level control and are comfortable self-hosting.

Strapi is the leading open-source headless CMS. Self-hosted, fully customizable. The tradeoff: your team owns security patching, server maintenance, and upgrade cycles.

Pricing: Open-source is free to self-host. Strapi Cloud starts at $29/month. Enterprise is custom.

7. Prismic

Best for: Marketing and editorial teams that want a clean, opinionated writing experience.

Prismic's slice-based content modeling makes it fast to build page layouts. AI capabilities are not as mature as Cosmic's agent layer.

Pricing: Free tier available. Paid plans from $15/month. Enterprise is custom.

How to Choose

Building AI-native products where the CMS is infrastructure? Cosmic.
Large existing Contentful deployment with a dedicated platform team? Contentful.
Maximum schema flexibility with strong developer ownership? Sanity.
Visual editing and marketing team autonomy as the primary requirement? Storyblok.
Content federation across multiple enterprise data sources? Hygraph.
Full infrastructure control with engineering capacity to maintain it? Strapi.
Clean, opinionated editorial experience for a non-technical team? Prismic.

Start building free on Cosmic or book a demo to discuss Enterprise requirements.

Best Headless CMS for AI SaaS Backends in 2026

Tony Spiro — Wed, 20 May 2026 15:41:32 +0000

Building an AI SaaS product in 2026 means your content backend has to do more than store structured data. It needs to be fast enough for real-time API calls, secure enough that you're not patching CVEs on a Friday night, and smart enough to keep pace with an AI-augmented development workflow. This post breaks down what actually matters in a CMS for AI SaaS backends, and which platforms are worth your attention.

What AI SaaS Backends Actually Need from a CMS

When your product is AI-native, the CMS is not just a writing tool for a marketing blog. It's infrastructure. Here's what that means in practice:

Speed. Your frontend or API layer will call the CMS on every request or during build. Sub-100ms response times are not a nice-to-have. They determine whether your product feels fast.

Security you don't have to own. Self-hosting a CMS means your team owns every CVE, every patch cycle, every security audit. For a small AI SaaS team, that is a real cost.

Developer ergonomics. The SDK, the CLI, the REST API: they need to work the way your developers expect. Friction in the content layer slows shipping.

AI integration that is native, not bolted on. The CMS should be able to generate content, images, and video, run agents, and execute workflows without requiring a separate integration layer.

Framework flexibility. Next.js today, Astro tomorrow. The CMS should be invisible to the frontend.

Cosmic: Built for AI SaaS from the Ground Up

Cosmic is a managed headless CMS backed by Y Combinator (YC W19). It was built API-first, and the entire platform has been evolving toward AI-native infrastructure for the past two years.

Infrastructure and Security

Cosmic is fully managed SaaS. That means:

99.9% uptime SLA on paid plans
256-bit SSL encryption in transit and at rest
50M+ API requests/month infrastructure scale
150+ country CDN for global content delivery
imgix CDN for media, with real-time image transformation

No CVEs to patch. No server to maintain. No security audit you have to run yourself.

This is not a knock on open-source CMS platforms. It is a statement about what managed infrastructure means when your core team is building AI features, not patching web servers.

The API Layer

Cosmic's REST API is the product. Sub-100ms response times. Predictable, cacheable, built for high-frequency reads.

The TypeScript SDK is the recommended way to integrate from any JavaScript or TypeScript project:

import { createBucketClient } from '@cosmicjs/sdk';

const cosmic = createBucketClient({
  bucketSlug: 'your-bucket-slug',
  readKey: 'your-read-key',
});

const { objects } = await cosmic.objects
  .find({ type: 'posts' })
  .props(['title', 'slug', 'metadata'])
  .limit(10);

AI Agents Built In

Cosmic includes four types of AI agents that run directly inside your workspace:

Content Agents generate and manage CMS content, handle bulk operations, and run migrations. No separate integration required.
Code Agents connect to GitHub repositories, work on isolated branches, write and fix code, create pull requests, and deploy to production or preview. Your CMS can literally ship code.
Computer Use Agents automate browser tasks with visual AI: record demos, cross-post media, extract data from any webpage.
Team Agents live in Slack, WhatsApp, and Telegram as actual teammates. Schedule them, message them, have them report status, and execute workflows on your behalf.

These are not marketing features bolted on top of a legacy CMS architecture. They're first-class capabilities built into the platform.

MCP Server and Agent Skills

For AI SaaS developers using modern tooling:

MCP Server: Cosmic exposes a Model Context Protocol server so AI tools that speak MCP can interact directly with your content schema.
Agent Skills for Cursor, Claude Code, and GitHub Copilot: Your AI coding assistant understands your Cosmic content schema natively. No manual context-loading.

Framework Support

Cosmic works with every major frontend framework: Next.js, React, Vue, Nuxt, Astro, Remix, Svelte, Gatsby.

Pricing

Plan	Price	Key Limits
Free	$0/month	1 Bucket, 1,000 Objects
Builder	$49/month	2 Buckets, 5,000 Objects
Team	$299/month	3 Buckets, 20,000 Objects
Business	$499/month	5 Buckets, 50,000 Objects
Enterprise	Custom	Custom

No credit card required to start. Additional users are $29/user/month.

The Self-Hosted Open Source Option: What You're Actually Signing Up For

Several popular CMS platforms are open source and self-hosted by default. Strapi is the most prominent example. The appeal is clear: full control, no vendor lock-in, customize everything. For some teams and use cases, this is the right call.

But for an AI SaaS team in 2026, there is a real cost to consider:

Security patching is yours. This week (week of May 13, 2026), Strapi disclosed five CVEs: CVE-2025-64526, CVE-2026-22599, and others. This is not unusual for large open source projects. What it means in practice is that someone on your team owns the patch cycle, the upgrade testing, and the deployment coordination. If you're a three-person AI startup, that overhead is material.

Managed SaaS removes that overhead entirely. The tradeoff is less raw configuration control in exchange for not owning your own server security posture.

Evaluating a CMS for Your AI SaaS: A Quick Checklist

Before committing to a CMS as your AI SaaS backend, run through these questions:

[ ] Does it have a REST API with documented, predictable response times?
[ ] Is there a TypeScript SDK with active maintenance?
[ ] Is security patching handled by the vendor (managed) or by your team (self-hosted)?
[ ] Does it have a free tier to prototype without a credit card?
[ ] Does it support the frontend framework(s) you're using?
[ ] Do AI agents and workflow automation come included, or require separate services?
[ ] Is there a path to Enterprise with SLAs and dedicated support?

Cosmic checks every box on this list.

Get Started

Cosmic's free plan is genuinely free: no credit card, one bucket, one Team agent, 1,000 Objects. It's enough to build a real prototype.

Start building free or book a 30-minute intro call with Tony to see how Cosmic fits your AI SaaS architecture.

Cosmic's REST API, TypeScript SDK, and AI agent layer are designed specifically for developers building modern, AI-native applications.

Why Bun is Rewriting in Rust (And What It Means for JavaScript Developers)

Tony Spiro — Tue, 19 May 2026 16:44:38 +0000

Bun started as a bet that JavaScript tooling could be much faster. That bet paid off. Now, Bun is making another one: rewriting its runtime in Rust. Here's everything you need to know about why, where things stand, and what it means if you're building JavaScript applications today.

What Is Bun and Why It Matters

Bun is an all-in-one JavaScript toolkit. It combines a fast JavaScript runtime, a bundler, a package manager, a test runner, and a transpiler into a single binary. If you've been frustrated by Node.js startup times, slow npm runs, or juggling separate tools for bundling and testing, Bun was built for exactly those pain points.

The numbers are striking. According to benchmarks published on bun.sh, Bun handles 59,026 Express.js "hello world" HTTP requests per second on Linux x64, compared to 25,335 for Deno and 19,039 for Node.js. For WebSocket throughput, Bun clocks 2,536,227 messages per second against Deno's 1,320,525 and Node's 435,099. Bun also bundles 10,000 React components in 269ms. Rolldown completes the same job in 495ms. esbuild takes 572ms.

These aren't hypothetical gains. Companies including X (Twitter) and Midjourney run Bun in production. Tailwind's standalone CLI is compiled with Bun. Claude Code, Anthropic's AI coding assistant, ships as a Bun executable to millions of users.

Why Bun Was Originally Written in Zig

Bun's creator, Jarred Sumner, started the project in 2021. He was building a voxel game and got frustrated with Next.js hot reload times. He began porting a JSX and TypeScript transpiler from Go to Zig, a systems programming language that compiles to native binaries and offers fine-grained memory control without a garbage collector.

Zig was a pragmatic choice for a small team obsessed with performance. It gave Bun low-level control over memory layout and system calls, which directly contributed to the benchmark advantages the runtime is known for. Bun shipped its 1.0 release in September 2023 and its 1.2 release added built-in PostgreSQL, S3, and Redis clients.

But Zig is a young language with a small ecosystem. Finding contributors who know Zig well is harder than finding Rust developers. The Rust ecosystem, by contrast, is large, mature, and has become the dominant language for systems-level rewrites across the industry (see: the Linux kernel, Android, Firefox, and much of the cloud-native toolchain).

The Decision to Rewrite in Rust

The Rust rewrite is still described as experimental. Jarred Sumner announced the milestone on Hacker News in what became one of the more closely-watched threads in the JavaScript runtime community this year.

The core reasons for the rewrite come down to three things:

Contributor accessibility. Rust has a vastly larger developer community than Zig. More contributors means faster bug fixes, more platform support, and a healthier open-source ecosystem around Bun.

Maintainability at scale. Rust's ownership model and strong type system provide compile-time safety guarantees that help catch bugs before they reach users.

Long-term stability signals. Bun was acquired by Anthropic in late 2025. As Jarred wrote on the Bun blog, Claude Code ships as a Bun executable to millions of users. If Bun breaks, Claude Code breaks. That stakes profile demands a codebase that's as battle-hardened as possible.

Where the Rewrite Stands Today

The headline number: the Rust rewrite has achieved 99.8% test compatibility on Linux x64 glibc. This figure comes from Jarred Sumner's own announcement on Hacker News.

99.8% compatibility is a meaningful threshold. It means the Rust rewrite, running Bun's existing test suite, behaves identically to the Zig implementation in the overwhelming majority of cases. The 0.2% gap represents edge cases and platform-specific behaviors, not fundamental incompatibilities.

The rewrite is currently scoped to Linux x64 glibc. macOS, Windows, and ARM support come later. Bun's current stable release series (v1.3.x) continues to ship from the Zig codebase. The Rust rewrite is parallel, experimental work.

Performance Implications: Rust vs Zig

The most common question is whether Rust will be faster or slower than Zig. The honest answer: it depends, and the gap is smaller than most people assume.

Both Zig and Rust compile to native machine code. Neither has a garbage collector. Both allow the same class of low-level optimizations. The real performance benefits of the rewrite are likely to come from:

A larger contributor pool finding and fixing performance regressions faster
Rust's ecosystem of performance-focused crates like Rayon and Tokio
Memory safety eliminating a class of bugs that cause random slowdowns in production

What won't change: Bun's use of JavaScriptCore (WebKit's JavaScript engine) for actually executing your JavaScript code.

What Changes for JavaScript Developers Using Bun

For most JavaScript developers, the Rust rewrite won't require any changes to your code or workflow. Bun's explicit goal is 100% backward compatibility.

What you can expect to improve over time:

Fewer edge-case bugs, especially on non-Linux platforms
Faster patch releases from a more accessible codebase
Better cross-platform parity
Increased confidence for production adoption

Using Bun with Cosmic

If you're building with Bun today, integrating Cosmic is straightforward. Install the TypeScript SDK:

bun add @cosmicjs/sdk

Then initialize your client:

import { createBucketClient } from '@cosmicjs/sdk'

const cosmic = createBucketClient({
  bucketSlug: process.env.COSMIC_BUCKET_SLUG as string,
  readKey: process.env.COSMIC_READ_KEY as string,
})

const { objects } = await cosmic.objects.find({
  type: 'posts',
})

This runs identically on Bun, Node.js, and Deno. Cosmic's REST API and TypeScript SDK don't depend on any runtime-specific APIs.

What's Next

The timeline for the Rust rewrite becoming the default Bun binary is not publicly committed. The likely next steps are:

Closing the remaining 0.2% compatibility gap on Linux x64
Expanding platform coverage to macOS (both x64 and ARM)
Windows support
A public beta period before the Rust binary becomes the default release

The bigger context is Anthropic's acquisition. Bun now has institutional backing from one of the best-funded AI labs in the world. That financial and organizational support changes the risk calculus for anyone evaluating Bun for long-term production use.

The Bottom Line

Bun's Rust rewrite isn't a pivot or a panic. It's a deliberate maturity move by a team that has already proven it can execute. The 99.8% test compatibility milestone is real progress, the Anthropic acquisition provides genuine long-term stability, and the move to Rust opens Bun's development to a much larger contributor community.

For JavaScript developers: Bun was already fast. The Rust rewrite is about making it more reliable, more maintainable, and more accessible to contributors, while keeping the performance characteristics that made it worth paying attention to in the first place.

The runtime wars aren't over, but Bun just made a significant move.

Building your next Bun app? Cosmic's REST API and TypeScript SDK work seamlessly with any JavaScript runtime. Start free.

Cosmic AI Agents vs. Storyblok FlowMotion: Why CMS Automation Is Not Enough

Tony Spiro — Mon, 18 May 2026 16:29:39 +0000

Storyblok recently launched FlowMotion, a workflow automation and orchestration layer built directly into their CMS, powered by n8n under the hood. It's a genuine product advancement, and if your world begins and ends inside the CMS, it solves real problems: content governance, localization sync, compliance routing, launch coordination.

But there's a category question worth asking: Is CMS automation the same as having AI agents?

The honest answer is no. And the gap between the two matters enormously for teams building in 2026.

What Storyblok FlowMotion Actually Does

FlowMotion is an automation layer embedded in Storyblok. When something happens inside the CMS, a publish event, a translation update, an asset upload, a workflow fires. You can route content to legal review, sync regional variants, trigger notifications, and coordinate multi-market launches.

These are valuable capabilities. FlowMotion clearly solves a real operational pain for enterprise content teams managing global content pipelines.

But read the language carefully: "whenever something happens in Storyblok... FlowMotion activates your entire content ecosystem." The trigger is CMS-native. The automation scope is CMS-adjacent. FlowMotion keeps content operations in sync. That is its job.

What Cosmic AI Agents Actually Do

Cosmic agents are not automation rules attached to CMS events. They are autonomous AI teammates that operate across your entire stack.

Here's the concrete difference:

Content Agents

Generate and manage CMS content, run bulk operations and migrations, and discover content progressively. Yes, they do what FlowMotion does inside the CMS. But they're just the starting point.

Code Agents

Connect to your GitHub repositories, work on isolated branches, write and fix code, create pull requests, and deploy to production or preview environments. FlowMotion cannot write a single line of code. Cosmic agents can ship a feature.

Computer Use Agents

Automate browser tasks with visual AI. Record demo videos automatically. Cross-post media between platforms. Extract data from any website. These agents navigate the web the way a human would: visually, intelligently, across any surface.

Team Agents

Live in Slack, WhatsApp, and Telegram as actual team members. They receive messages, respond intelligently, execute tasks, and check in on their own schedule. Your content team can @ a Cosmic agent in Slack and get work done. FlowMotion has no channel presence.

The Workflow Difference

FlowMotion workflows are triggered by CMS events and route content through CMS-adjacent steps.

Cosmic Workflows chain any combination of agent types into a single automated process:

A Content Agent writes a new product page from a brief
A Code Agent deploys it to a feature branch and opens a PR
A Computer Use Agent screenshots the live preview and posts it to Slack
A Team Agent notifies the marketing channel and awaits approval

That is one Cosmic Workflow. It crosses four system boundaries. It involves content, code, a browser, and a messaging platform. No CMS automation layer can do this, because by definition, a CMS automation layer lives inside the CMS.

Workflows can be scheduled (hourly, daily, weekly, monthly on paid plans) or triggered via webhook, giving you full programmatic control.

Developer-Native Integrations FlowMotion Does Not Offer

Cosmic was built from the ground up for developers. The integrations reflect that:

REST API with sub-100ms response times. Not an afterthought. The API is the product.
TypeScript SDK (@cosmicjs/sdk): the official way to interact with Cosmic from any TypeScript or JavaScript project
CLI: Manage your Cosmic workspace from the terminal
MCP Server: Cosmic exposes an MCP (Model Context Protocol) server, which means AI tools that speak MCP can directly interact with your content
Agent Skills for Cursor, Claude Code, and GitHub Copilot

Two Different Categories

To be direct: Storyblok FlowMotion is a well-built CMS automation layer. If you're deep in the Storyblok ecosystem and need better content operations workflows, it likely delivers real value.

But if you're building with AI in 2026, the question is not "which CMS has better automation?"

The question is: Do you want a CMS that automates its own operations, or do you want AI agents that can do work across your entire business?

FlowMotion automates content operations inside a CMS. Cosmic agents write code, browse the web, generate images and video, post to Slack, deploy to GitHub, and manage content, as a team, across every system boundary that matters.

That is a different category of product.

Pricing

Cosmic starts free with no credit card required:

Free: $0/month — 1 Bucket, 2 Team members, 1,000 Objects
Builder: $49/month — 2 Buckets, 3 Team members, 5,000 Objects
Team: $299/month — 3 Buckets, 5 Team members, 20,000 Objects
Business: $499/month — 5 Buckets, 10 Team members, 50,000 Objects
Enterprise: Custom pricing

Additional users are $29/user/month.

Start building free with no credit card required, or book a demo with Tony to see Cosmic agents in action.

Claude Sonnet vs Opus for Coding: Which Model Should You Choose?

Tony Spiro — Mon, 18 May 2026 16:06:26 +0000

If you've spent any time building with the Anthropic API, you've faced the same question: Sonnet or Opus? For coding tasks specifically, the answer isn't "always use the smartest model." It depends on the task, your latency budget, and what you're paying per token. This guide breaks down the real-world tradeoffs between Claude Sonnet 4.6 and Claude Opus 4.7 for coding work, so you can make the right call every time.

The Quick Answer

Claude Sonnet 4.6: Best for the majority of coding tasks. Fast, cost-efficient, and handles most real-world code generation, debugging, and refactoring with high quality.

Claude Opus 4.7: Best for the hardest problems. Architecture decisions, complex multi-file reasoning, and tasks where a wrong answer costs you hours.

But that framing is too simple on its own. Let's go deeper.

Pricing: The Numbers You Need to Know

Before comparing capability, know what you're spending:

Claude Sonnet 4.6: $3 input / $15 output (per MTok)
Claude Opus 4.7: $5 input / $25 output (per MTok)

Opus costs roughly 1.67x more on input and output than Sonnet. On large codebases with high prompt volumes, that gap compounds fast. For agentic coding pipelines where the model is called dozens of times per task, Sonnet's cost advantage makes it the default for most steps. Reserve Opus for the decision nodes that matter.

What Each Model Is Good At (for Code)

Claude Sonnet 4.6: The Everyday Workhorse

Sonnet is where you'll live for most coding work. It handles:

Code generation from specs. Give Sonnet a clear function signature, a description of behavior, and edge cases to handle. It produces clean, idiomatic code across TypeScript, Python, Go, Rust, and most other mainstream languages.
Bug hunting and debugging. Paste in an error trace and the relevant code block. Sonnet is excellent at reading stack traces, identifying the root cause, and proposing a fix, often on the first pass.
Boilerplate and CRUD. REST API routes, database models, form validation, utility functions. Sonnet generates this at speed with minimal review needed.
Code review and refactoring. Ask Sonnet to review a pull request diff or suggest a cleaner implementation. It flags real issues, not just style nitpicks.
Unit test generation. Feed it a function, get back a test suite. Sonnet understands testing patterns (Jest, Pytest, Vitest, etc.) and generates meaningful test cases.

Claude Opus 4.7: When You Need the Heavy Lifter

Opus earns its price premium on tasks that require sustained, multi-step reasoning over large, complex contexts:

Complex architecture decisions. Tasks that require understanding tradeoffs across a system, not just code completion.
Large codebase comprehension. When you need to understand data flows across 50+ files, Opus maintains coherence across a longer context window more reliably.
Multi-step agentic coding tasks. Tasks where the model needs to plan edits across multiple files, maintain state about what it has already changed, and reason about dependencies.
Hard algorithmic problems. Competitive-programming-style problems, complex graph algorithms, optimization tasks where a subtly wrong solution is worse than no solution.
Security-critical code review. When reviewing authentication logic, cryptographic implementations, or input validation on a public-facing surface.

Speed and Latency

Sonnet is significantly faster. For interactive coding tools (autocomplete, inline suggestions, chat-based debugging in an IDE), latency is a real UX factor. Waiting 8 seconds for a response breaks flow in a way that waiting 2 seconds does not.

For batch processing (overnight analysis, CI-integrated code review, automated test generation), latency matters less. That's a valid use case for Opus if you need maximum accuracy.

A Practical Decision Framework

Default to Sonnet when:

The task is well-defined (clear input, clear expected output)
Speed or cost is a constraint
You're running many parallel calls in an agent pipeline
The task is generative (new code, boilerplate, tests)
You can validate output programmatically

Reach for Opus when:

The task requires judgment, not just generation
You're reasoning across a large, ambiguous codebase
A wrong answer has downstream consequences that are hard to catch
You're doing one-shot architecture or design work where iteration is expensive
The cost per call is small relative to the value of getting it right

The Hybrid Approach

The most effective production setups don't pick one model and commit. They route tasks:

Use Sonnet for planning, scaffolding, and code generation.
Pass the result to a validation step (run tests, linter, type checker).
If validation fails and the error requires reasoning (not just a syntax fix), escalate to Opus for diagnosis.
Use Opus for final review on security-sensitive or architecture-defining changes.

This is exactly the pattern Cosmic uses for our own AI agents. Cosmic's agent infrastructure runs on Claude, and Sonnet handles the high-volume content and code generation tasks while Opus is reserved for the decisions that require deeper judgment.

A Note on Context Windows

Both Sonnet 4.6 and Opus 4.7 support large context windows, so raw context length is rarely the deciding factor. The real difference is how effectively each model reasons within that context. Opus maintains more coherent reasoning over long, complex contexts, but for most coding tasks within a single file or module, Sonnet's context utilization is more than sufficient.

Conclusion

Sonnet is the right default for coding. It's fast, cost-efficient, and capable enough for the majority of real-world tasks. Opus is the right choice when the stakes are high and the reasoning is genuinely complex.

Using Opus everywhere is expensive and usually unnecessary. Using Sonnet everywhere means occasionally getting a suboptimal answer on the hard problems.

The teams shipping the best AI-assisted coding workflows treat model selection as a routing problem, not a binary choice. Start with Sonnet, validate your output, and escalate to Opus only when the task earns it.

Cosmic is an AI-powered headless CMS built for developers. Our platform uses Claude to power autonomous content and code agents that work directly in your workflow. Start building for free, no credit card required.

How to Build a React Blog with Next.js and Cosmic

Tony Spiro — Fri, 15 May 2026 15:37:50 +0000

Building a blog with React and Next.js is one of the most common use cases for modern web development. But where you store and manage your content matters just as much as the frontend you choose.

In this tutorial, you'll learn how to build a fast, production-ready React blog using the Next.js App Router and Cosmic as your headless CMS.

Want to skip ahead? Grab the free Simple React Blog template and deploy in minutes.

Why Use a Headless CMS for a React Blog?

Managing blog content directly in your codebase works fine for a handful of posts, but it breaks down fast. Markdown files scattered across a repo, no visual editing interface, and every content update requiring a developer and a deployment are all pain points that accumulate quickly.

A headless CMS solves this by separating your content layer from your presentation layer. You manage posts, authors, and categories in a structured dashboard. Your Next.js app fetches that content via the REST API at build time or on demand. Non-technical editors can publish without touching code, and developers stay focused on the frontend.

Cosmic gives you a clean API, a TypeScript SDK, a generous free tier, and zero infrastructure to manage.

Prerequisites

Before you start, you'll need:

Node.js 18 or later
A free Cosmic account
Basic familiarity with React and TypeScript

Step 1: Set Up Your Cosmic Bucket and Content Model

After signing up for a free Cosmic account, create a new bucket. You can start from the Simple React Blog template to get a pre-configured bucket with sample content and a ready-to-deploy Next.js app, or follow along manually.

Creating a Blog Posts Object Type

In your Cosmic dashboard, navigate to Object Types and create a new type called blog-posts. Add the following metafields:

Title - Text (built-in)
Slug - Text (built-in)
Cover Image - File (image)
Excerpt - Textarea
Content - Markdown
Published Date - Date
Author - Text

Once saved, create a few sample posts so you have content to query during development.

Get Your API Credentials

Go to Settings > API Keys in your bucket. You'll need:

Bucket Slug (e.g. my-blog-production)
Read Key (for public content fetching)

Save these as environment variables.

Step 2: Create a New Next.js App

npx create-next-app@latest my-blog --typescript --app
cd my-blog

Install the Cosmic SDK:

npm install @cosmicjs/sdk

Create a .env.local file:

COSMIC_BUCKET_SLUG=your-bucket-slug
COSMIC_READ_KEY=your-read-key

Step 3: Initialize the Cosmic Client

Create a shared Cosmic client at lib/cosmic.ts:

import { createBucketClient } from '@cosmicjs/sdk'

export const cosmic = createBucketClient({
  bucketSlug: process.env.COSMIC_BUCKET_SLUG as string,
  readKey: process.env.COSMIC_READ_KEY as string,
})

Step 4: Define Your TypeScript Types

// types/post.ts
export interface Post {
  id: string
  slug: string
  title: string
  metadata: {
    content: string
    excerpt: string
    cover_image: { imgix_url: string }
    published_date: string
    author: string
  }
}

Step 5: Fetch Posts from the Cosmic REST API

Fetch All Posts (Blog Index)

const { objects: posts } = await cosmic.objects
  .find({ type: 'blog-posts' })
  .props(['id', 'slug', 'title', 'metadata'])
  .depth(1)

Fetch a Single Post by Slug

const { object: post } = await cosmic.objects
  .findOne({ type: 'blog-posts', slug: params.slug })
  .props(['id', 'slug', 'title', 'metadata'])
  .depth(1)

Step 6: Build the Blog with Next.js App Router

Blog Index Page (`app/blog/page.tsx`)

import { cosmic } from '@/lib/cosmic'
import Link from 'next/link'

export default async function BlogPage() {
  const { objects: posts } = await cosmic.objects
    .find({ type: 'blog-posts' })
    .props(['id', 'slug', 'title', 'metadata'])

  return (
    <main>
      <h1>Blog</h1>
      {posts.map((post) => (
        <article key={post.id}>
          <Link href={`/blog/${post.slug}`}>
            <h2>{post.title}</h2>
          </Link>
          <p>{post.metadata.excerpt}</p>
        </article>
      ))}
    </main>
  )
}

Dynamic Post Page (`app/blog/[slug]/page.tsx`)

import { cosmic } from '@/lib/cosmic'
import { marked } from 'marked'

export async function generateStaticParams() {
  const { objects: posts } = await cosmic.objects
    .find({ type: 'blog-posts' })
    .props(['slug'])
  return posts.map((post) => ({ slug: post.slug }))
}

export default async function PostPage({ params }: { params: { slug: string } }) {
  const { object: post } = await cosmic.objects
    .findOne({ type: 'blog-posts', slug: params.slug })
    .props(['title', 'metadata'])

  const html = marked(post.metadata.content)

  return (
    <main>
      <h1>{post.title}</h1>
      <img src={`${post.metadata.cover_image.imgix_url}?w=1200&auto=format`} alt={post.title} />
      <div dangerouslySetInnerHTML={{ __html: html }} />
    </main>
  )
}

Step 7: Optimize Images with Imgix

Cosmic stores all media through Imgix, a powerful image CDN. Append transformation parameters directly to any media URL:

https://imgix.cosmicjs.com/your-image.jpg?w=800&auto=format&q=80&fit=crop

Common params:

w= sets width
auto=format serves WebP to supported browsers
q=80 reduces file size
fit=crop crops to exact dimensions

Step 8: Deploy to Vercel

Push your project to a GitHub repository
Go to vercel.com and import the repo
Add your environment variables under Settings > Environment Variables:
- COSMIC_BUCKET_SLUG
- COSMIC_READ_KEY
Click Deploy

Vercel will detect Next.js automatically, build your app, and give you a live URL in under a minute.

Enable On-Demand Revalidation (Optional)

// app/api/revalidate/route.ts
import { revalidatePath } from 'next/cache'
import { NextRequest } from 'next/server'

export async function POST(request: NextRequest) {
  revalidatePath('/blog')
  return Response.json({ revalidated: true })
}

Then configure a Cosmic webhook to call this endpoint whenever a post is published.

What You've Built

A Next.js App Router project with TypeScript
A Cosmic bucket with a structured content model
Server-side data fetching via the @cosmicjs/sdk
Static pre-rendering with generateStaticParams
Imgix-powered image optimization
Live on Vercel with optional on-demand revalidation

Your editors can log into the Cosmic dashboard and publish new posts without touching your codebase. Your readers get a fast, statically rendered experience. And your SEO improves because every post is pre-rendered HTML at build time.

Start with the Free Template

Don't want to build from scratch? The Simple React Blog template gives you everything in this tutorial, already wired up and ready to deploy with one click.

Get the free React blog template

Start building free

Have questions or want to talk through your project? Book a quick intro call with the Cosmic team.

MCP vs Agent Skills: What's the Difference and Which Do You Need?

Tony Spiro — Tue, 12 May 2026 22:12:48 +0000

Originally published at cosmicjs.com

Two terms keep coming up in every AI developer conversation right now: MCP (Model Context Protocol) and Agent Skills. They sound similar. They're not the same thing. Here's a clear breakdown of what each is, when to use which, and how Cosmic implements both.

What Is MCP?

MCP (Model Context Protocol) is an open protocol developed by Anthropic that lets AI models connect to external tools and data sources in a standardized way. Think of it as a universal adapter that allows an AI assistant like Claude to read files, query databases, call APIs, and interact with services, all through a consistent interface.

MCP runs as a server that your AI client connects to. Once connected, the AI can discover and use whatever tools the MCP server exposes.

Cosmic MCP Server: Cosmic ships a native MCP server that gives AI assistants direct access to your content. Claude, Cursor, and other MCP-compatible clients can read objects, query content types, fetch media, and understand your content model, all without you writing any integration code.

What Are Agent Skills?

Agent Skills are pre-built, reusable capabilities you can attach to AI coding assistants like Cursor, Claude Code, and GitHub Copilot. Where MCP gives an AI access to data, Agent Skills give an AI knowledge of how to do specific tasks in a specific codebase or platform.

CosmicAgent Skills teach your coding assistant how to work with Cosmic specifically: how to structure queries, how to use the TypeScript SDK, how to model content, and how to build features against the Cosmic REST API.

The Key Difference

MCP = data access. The AI can read and write to your Cosmic bucket in real time.
Agent Skills = task knowledge. The AI knows how to build with Cosmic correctly.

They are complementary, not competing.

When to Use MCP

Use the Cosmic MCP Server when:

You want Claude or another AI assistant to query your live content
You're using an AI chat interface and want it to have context about your bucket
You want AI to help you manage, audit, or restructure your content

# Add Cosmic MCP to your Claude config
npx @cosmicjs/mcp

When to Use Agent Skills

Use Cosmic Agent Skills when:

You're building features in Cursor, Claude Code, or Copilot
You want your coding assistant to generate correct Cosmic SDK code automatically
You want to avoid copy-pasting docs into every prompt

Using Both Together

The most powerful setup uses both. Your coding assistant has Agent Skills so it generates correct Cosmic code, and it has MCP access so it can query your actual live bucket while building. It can look up your real content types, check what fields exist, and generate code that matches your exact schema.

// Agent Skills ensure your assistant generates correct SDK usage
import { createBucketClient } from '@cosmicjs/sdk'

const cosmic = createBucketClient({
  bucketSlug: process.env.COSMIC_BUCKET_SLUG,
  readKey: process.env.COSMIC_READ_KEY
})

// MCP gives the assistant live access to your actual content types
const { objects } = await cosmic.objects
  .find({ type: 'your-actual-type-slug' }) // AI knows this from MCP
  .props('title,slug,metadata')
  .limit(10)

The Bottom Line

If you're building with AI assistants, you want both. MCP for live data access. Agent Skills for correct code generation. Cosmic ships both natively.

Start free with Cosmic and set up both in under 10 minutes.

Astro vs Next.js: Which Framework Should You Use in 2026?

Tony Spiro — Tue, 12 May 2026 22:12:26 +0000

Originally published at cosmicjs.com

Choosing between Astro and Next.js in 2026? Both are excellent frameworks, but they solve different problems. This guide breaks down the real tradeoffs so you can make the right call for your project.

The Short Answer

Use Astro when your site is content-heavy and you want maximum performance with minimal JavaScript. Use Next.js when you need a full-stack React application with dynamic data, auth, and API routes.

Both work seamlessly with Cosmic as your headless CMS.

What Astro Does Well

Zero JS by default, ships only what you need
Island architecture for selective hydration
Supports React, Vue, Svelte, and more in the same project
Best-in-class for static content sites, blogs, and marketing pages
Built-in content collections

What Next.js Does Well

Full-stack React with App Router and Server Components
API routes and server actions built in
ISR and on-demand revalidation
Largest ecosystem and community
Best for dynamic applications, dashboards, and e-commerce

Performance Comparison

Astro wins on raw page weight for content sites. No framework JavaScript ships by default. Next.js with proper server components is competitive, but requires more discipline to keep bundles lean.

When to Use Astro

Marketing sites and landing pages
Blogs and documentation
Content-heavy sites where SEO is the primary goal
Teams that want to mix component frameworks

When to Use Next.js

SaaS applications
E-commerce with dynamic inventory
Apps with complex auth flows
Teams already invested in the React ecosystem

Using Both with Cosmic

Cosmic's REST API and TypeScript SDK work identically in both frameworks. Here's how to fetch content in each:

Astro

import { createBucketClient } from '@cosmicjs/sdk'

const cosmic = createBucketClient({
  bucketSlug: process.env.COSMIC_BUCKET_SLUG,
  readKey: process.env.COSMIC_READ_KEY
})

const { objects } = await cosmic.objects
  .find({ type: 'blog-posts' })
  .props('title,slug,metadata')
  .limit(10)

Next.js App Router

import { createBucketClient } from '@cosmicjs/sdk'

const cosmic = createBucketClient({
  bucketSlug: process.env.COSMIC_BUCKET_SLUG,
  readKey: process.env.COSMIC_READ_KEY
})

export default async function BlogPage() {
  const { objects } = await cosmic.objects
    .find({ type: 'blog-posts' })
    .props('title,slug,metadata')
    .limit(10)

  return <div>{objects.map(post => <div key={post.slug}>{post.title}</div>)}</div>
}

Same SDK, same API, same content model. Switch frameworks without touching your content.

The Verdict

Astro and Next.js are not competitors in the traditional sense. They serve different primary use cases. The better question is: what are you building?

Content site with SEO focus? Astro. Full-stack application? Next.js. Both? Cosmic works with either.

Start free with Cosmic and build with whichever framework fits your project.

AI as Coordinator: Why SaaS Must Bundle or Die

Tony Spiro — Tue, 12 May 2026 16:03:23 +0000

For most of the last decade, the conventional wisdom in software was simple: use the best tool for every job. The CRM that wins on contact management. The CMS that wins on editor experience. The analytics platform that wins on dashboards. The best-of-breed stack, stitched together by integrations and held together by the humans navigating between them.

That era is over. I don't think this is coming. I think it has already happened. And I don't think most SaaS companies understand the implications yet.

The Unbundling Era Made Sense When Humans Were the Coordinators

The logic behind best-of-breed stacks was always human logic. A skilled operator could hold context across a dozen tools. A marketing manager could pull data from one platform, paste it into another, run a report from a third, and synthesize the whole picture in her head. The friction of context-switching was manageable because humans are actually pretty good at it. We pattern-match across interfaces. We tolerate inconsistency. We remember which export format a specific tool uses.

The integration layer was built for us. Zapier, Make, and dozens of custom webhooks exist because humans needed to connect tools they were already using. The business value was locked inside each individual product. The human was the orchestration layer.

So the market optimized for exactly that model. Single-purpose tools got sharper, deeper, and more opinionated. The pitch was always the same: we do one thing and we do it better than anyone. If you want the best email tool, use us. If you want the best CMS, use us. Mix and match as needed.

It was a good model. For a while.

Agents Don't Care About Dashboard Design

Here's what changes when AI agents become the coordinators of business operations: agents don't navigate between tools the way humans do. They don't have the cognitive flexibility to tolerate seams. They operate through APIs, CLIs, and MCPs, and every API boundary is a potential failure point: an authentication handoff that breaks, a data schema that doesn't translate cleanly, a rate limit that introduces latency, an error state that the agent doesn't know how to recover from.

Agents don't care about dashboard design. They don't appreciate a beautiful UI. The entire value proposition of the best-of-breed stack collapses when the end user is not a human.

An agent operating across 12 separate SaaS tools is not more capable than an agent operating in one unified system. It's more fragile. More likely to fail at a handoff. More likely to produce inconsistent output. More expensive to maintain. More difficult to debug.

The seams that humans could paper over with judgment and context-switching become hard failures when an agent hits them.

The New Moat Isn't UI. It's Vertical Integration.

This is where I think much of the software industry is getting it wrong. A lot of SaaS companies are responding to the AI moment by adding AI features. A copilot here. An AI-assisted editor there. An auto-summarize button on the dashboard. These features are fine, but they don't change the fundamental problem.

The companies that will win the next decade are not the ones that added AI on top of their existing product. They're the ones that rethought the product architecture entirely, with agents as the primary user.

The new moat is vertical integration. It's owning the full stack that an agent needs to do a job, in a single system, with a single data model, through a single API.

The single-product SaaS company with a great UI is not just at a disadvantage. It is structurally exposed.

From User Experience to Agent Experience

For the last decade, premium software competed on UX. Smoother onboarding. Cleaner dashboards. More intuitive editors. The best product was the one your team actually wanted to open in the morning.

That era produced real value. But it also produced an entire generation of software optimized for the wrong user.

The new benchmark is Agent Experience. AX. How well does your platform perform when the user is an AI agent making thousands of API calls, not a human clicking through a dashboard?

AX is not about aesthetics. It is about architecture. A high-AX platform has a unified data model, a clean and comprehensive API, minimal failure surfaces at integration boundaries, and built-in orchestration so agents don't need to reach outside the system to complete a workflow.

A vertically integrated platform is not just more convenient for agents. It is architecturally superior for them. Every seam an agent doesn't have to cross is a failure point eliminated, a latency reduced, a context preserved.

The logical endpoint of this architecture is a platform where agents don't just create content, they also measure its performance and act on what they learn. When the same system owns the content object and the pageview that came from it, the loop closes. Write, ship, measure, learn, all inside one platform, all accessible to your agents without a single third-party integration. That is what vertically integrated AX looks like in practice. We are building toward it.

UX won the last decade. AX wins the next one.

Who Loses

The companies most at risk are the ones whose entire value proposition was "we do one thing better than anyone."

Point solutions that relied on being the best-in-class editor, the best-in-class analytics view, or the best-in-class content modeling interface are going to find that the interface advantage no longer matters when agents are the users. An agent doesn't prefer your drag-and-drop UI. It calls your API.

The companies that built moats through beautiful interfaces are going to find that those moats are much shallower than they thought.

Who Wins

The companies that win will have a few characteristics in common.

First, they'll have a unified data model. Second, they'll expose a clean, comprehensive API as the primary interface. Third, they'll own the vertical. Fourth, they'll have built-in orchestration.

The Headless CMS Example

The headless CMS space is a useful lens here, because it's a sector that went through aggressive unbundling in the last five years and is now running directly into this problem.

The headless CMS companies that survive this shift will be the ones that extended beyond pure content APIs before the window closed.

Cosmic as the Model

I'm not writing this as an abstract observation. This is the exact bet we made at Cosmic.

Today, Cosmic is a single system that covers content management, media processing and delivery, AI agent infrastructure, workflow automation, and deployment. Our customers' agents can write a content draft, pull from the media library, run it through a publishing workflow, and deploy it, all through one API, in one system, with one data model.

When FINN, one of our customers, describes the value, Co-Founder Maximilian Wuhr puts it simply: "Cosmic is: us never having to ask a developer to change anything on the backend of our website."

The Window Is Shorter Than You Think

The companies that figure this out in the next 18 months will build the infrastructure their AI-native customers depend on. The companies that wait are betting that their existing moats hold longer than the market is moving.

Bundling isn't a retreat from the sophistication of the unbundled era. It's the appropriate response to the fact that the coordinator changed.

Bundle or die isn't hyperbole. It's the engineering reality of building for agents.

UX won the last decade. AX wins the next one.

If you're building for the agentic era and want to see what integrated depth actually looks like in production, start free at cosmicjs.com or book a 30-minute intro with Tony.

Tony Spiro is the CEO of Cosmic. He writes about building AI-native teams, headless CMS architecture, and the future of content infrastructure.

What Agent-Native Means for Your Content Infrastructure

Tony Spiro — Mon, 11 May 2026 21:41:02 +0000

"Agent-native" is being claimed by a lot of companies right now. Here's what it actually means at the content infrastructure layer — where agents read, write, and publish the content that everything else depends on.

Every Layer Is Being Redesigned

Every layer of the software stack is being redesigned for AI agents. The frontend layer, the code layer, the deployment layer. But there's one layer getting less attention — and it's the one agents depend on most: the content infrastructure layer. That's the CMS.

Here's what I think "agent-native" actually means at that layer, and why it matters.

Agents Need to Read, Write, and Publish Content

Let's start with the obvious: AI agents work with content. They generate it, organize it, update it, and publish it. The CMS is where that content lives. So if your CMS wasn't built for agents to interact with directly, your entire AI workflow has a bottleneck at the most important layer.

A traditional CMS was designed for a human editor sitting at a dashboard. An agent-native CMS is designed for agents — and humans — to operate it equally well.

For Cosmic, this meant four concrete things:

First: The API had to be simple enough for any AI agent to consume without special training. REST over HTTP, predictable URL patterns, JSON responses. Not a custom query language. Not a schema you need to introspect before you can use it.

Second: Agents needed to be first-class objects in the product. Not bolt-on integrations. Not webhooks you configure manually. Native AI agents — Team, Content, Code, Computer Use — that live in your workspace and operate on your content autonomously.

Third: The CMS had to connect to where developers already work. That's your IDE. So we built an MCP Server and Agent Skills for Cursor, Claude Code, and GitHub Copilot. Your AI coding tool can now read and write CMS content without leaving your editor.

Fourth: Agents needed to chain together. A Content Agent drafts an article. A Code Agent updates the front-end component. A Computer Use Agent cross-posts to social. A Team Agent notifies the editor in Slack. This is a workflow — and it needs to run on a schedule or a webhook trigger, without a human in the loop.

What This Unlocks for Teams in 2026

When your content infrastructure is genuinely agent-native, a few things become possible that weren't before.

Content velocity stops being a headcount problem. A single editor working with a team of content agents can produce, manage, and publish at a scale that previously required a full content department.

Developers get their time back. When agents handle the routine CMS work — bulk updates, content audits, migration tasks — developers can focus on the work that actually requires human judgment.

The feedback loop between content and code collapses. When your Content Agent and your Code Agent are in the same workflow, a content change can trigger a code update, a preview deployment, and a Slack notification in a single automated run.

This is not a future state. These are things teams are doing with Cosmic today.

The CMS Is the Critical Layer

Every AI agent that touches your product — regardless of what framework it's built in or which LLM it runs on — eventually needs to read or write content. That makes the CMS the most critical layer in an agent-native stack.

And it's the layer that will determine whether your agent workflows are fast, reliable, and actually useful, or slow, fragile, and constantly requiring human intervention.

Agent-native content infrastructure is not about adding an AI button to a dashboard. It's about rebuilding the CMS from the ground up for a world where agents and humans work on the same content, in the same system, at the same time.

That's what we're building at Cosmic.

I'm the CEO of Cosmic, an AI-powered headless CMS. I write about building AI-native teams and the future of content infrastructure.

Originally published on the Cosmic blog: https://www.cosmicjs.com/blog/agent-native-content-infrastructure

Why Cosmic Uses REST (and Why That's the Right Call in 2026)

Tony Spiro — Mon, 11 May 2026 21:37:22 +0000

Why Cosmic Uses REST (and Why That's the Right Call in 2026)

Every few years, a new API paradigm gets declared the future. GraphQL had its moment. And it's genuinely good — for certain use cases. But "good for certain use cases" and "better default for most teams" are different claims. REST is still the right default, and in 2026 there's a new reason it matters: AI agents.

Here's an honest breakdown of the tradeoffs, and why Cosmic is REST-first by design.

The Honest GraphQL vs REST Comparison

Let's be direct about where each one wins.

Where GraphQL excels

Precisely shaped responses. GraphQL lets clients request exactly the fields they need. On mobile or low-bandwidth environments, this can meaningfully reduce payload size.
Single endpoint for complex graphs. When your data has deeply nested relationships and you need to traverse them in a single request, GraphQL's query model can simplify client code.
Rapid iteration on the client side. Frontend teams can adjust what data they fetch without waiting for a backend API change.
Type-safe schema introspection. Tooling like Apollo DevTools and GraphQL Codegen is genuinely excellent for teams that invest in the ecosystem.

Where REST wins

Simplicity. A REST endpoint is a URL. Any HTTP client — curl, fetch, Postman, a Python script, an AI agent — can consume it without understanding a schema or learning a query language.
Cacheability. HTTP caching is built for REST. GET requests to a stable URL can be cached at the CDN layer with no additional tooling. GraphQL's POST-by-default convention makes this harder.
Debuggability. When something breaks, a REST API gives you a URL you can open in a browser, paste into Postman, or log directly. GraphQL errors can be harder to trace without dedicated tooling.
Ecosystem breadth. REST is universal. Every language, every framework, every tool speaks REST.
Operational simplicity. No query parser, no resolver overhead, no N+1 query problems to solve. For most content APIs, the queries are simple enough that REST's structure is a feature, not a limitation.

The honest verdict on GraphQL

GraphQL makes sense for complex, client-driven data fetching scenarios — large product catalogs with dozens of relationship types, mobile apps with strict bandwidth constraints, teams with mature frontend infrastructure. It's a real tool for real problems.

But most content APIs are not that complex. A blog post has a title, a body, some metadata, and maybe a category. A landing page has sections and a hero image. REST handles these cases cleanly, with less overhead and more cacheability.

Why 2026 Changes the Calculation: AI Agents

Here's the new variable: AI agents are now part of most content workflows. And REST is dramatically better suited for agent consumption than GraphQL.

REST endpoints are trivially parseable by LLMs

A REST endpoint is a URL with predictable structure: GET /objects?type=blog-posts&limit=10. An AI agent can construct this URL from a natural language instruction without understanding a schema. The response is JSON — structured, flat, predictable.

GraphQL requires the agent to understand the schema, construct a valid query document, and handle the query syntax correctly. That's more tokens, more failure modes, and more prompting complexity.

Caching matters for agent workflows

AI agents often make repeated, similar requests — checking content status, fetching object counts, reading metadata. CDN-cached REST responses make this cheap and fast. GraphQL's POST-by-default pattern bypasses CDN caching entirely, meaning every agent request hits your origin.

Direct URL-based queries are auditable

When an AI agent fetches content via a REST endpoint, the request is a plain URL you can log, inspect, and replay. This matters for debugging agent workflows and for understanding what your agents are actually doing.

The emerging standard: REST + structured JSON

Tools like Model Context Protocol (MCP) and the major LLM provider SDKs are all built around REST + JSON. The ecosystem is converging on REST as the lingua franca for agent-to-service communication — because it's the most universally parseable format.

Cosmic's REST API in Practice

Cosmic's REST API is designed to be fast, predictable, and easy for both humans and AI agents to consume.

Sub-100ms response times globally via CDN caching. Whether it's a developer building a Next.js page or an AI agent fetching content to include in a generated article, the API is consistently fast.

Here's a simple example using the Cosmic TypeScript SDK — which wraps the REST API with full type safety:

import { createBucketClient } from '@cosmicjs/sdk'

const cosmic = createBucketClient({
  bucketSlug: process.env.COSMIC_BUCKET_SLUG as string,
  readKey: process.env.COSMIC_READ_KEY as string,
})

const { objects: posts } = await cosmic.objects
  .find({ type: 'blog-posts' })
  .props(['id', 'title', 'slug', 'metadata.teaser', 'created_at'])
  .sort('-created_at')
  .limit(10)

console.log(posts)

The SDK compiles down to simple REST requests. No schema introspection. No query document compilation. Just a URL, a JSON response, and TypeScript types.

You can also call the REST API directly:

curl "https://api.cosmicjs.com/v3/buckets/my-bucket/objects?type=blog-posts&limit=10&read_key=YOUR_READ_KEY"

That URL is cacheable at the CDN layer, inspectable in a browser, and consumable by any HTTP client — including an AI agent with no Cosmic-specific knowledge whatsoever.

The Decision in Plain Terms

For most content APIs, REST is faster to implement, easier to cache, simpler to debug, and better suited for the AI-agent workflows that are becoming standard in 2026.

GraphQL is the right call when you have complex, client-driven data fetching needs and a team ready to invest in the ecosystem. Those situations exist. But they're not the default.

Cosmic is REST-first because REST is the right default for content delivery — and because in a world where AI agents are increasingly reading and writing your content, the simplicity and cacheability of REST becomes even more valuable, not less.

Start Building with Cosmic

The Cosmic REST API is available on the free plan, no credit card required. Fetch your first objects in under five minutes.

Get started free →

Want to talk through your architecture? Book time with Tony, Cosmic's CEO.

Originally published on the Cosmic blog.

Forem: Tony Spiro

The Power of Headless CMS with AI Agents

What Is a Headless CMS, and Why Does API-First Matter?

Why AI Agents Need Structured, Programmable Content

Concrete Use Cases for AI Agents + Headless CMS

1. Creating and Updating Content Autonomously

2. Generating Media on Demand

3. Automating Publishing Workflows

4. Multi-Channel Distribution

Why the Combination Unlocks Scale

Looking Forward

Top 7 Enterprise Headless CMS Platforms in 2026

1. Cosmic

2. Contentful

3. Sanity

4. Storyblok

5. Hygraph

6. Strapi

7. Prismic

How to Choose

Best Headless CMS for AI SaaS Backends in 2026

What AI SaaS Backends Actually Need from a CMS

Cosmic: Built for AI SaaS from the Ground Up

Infrastructure and Security

The API Layer

AI Agents Built In

MCP Server and Agent Skills

Framework Support

Pricing

The Self-Hosted Open Source Option: What You're Actually Signing Up For

Evaluating a CMS for Your AI SaaS: A Quick Checklist

Get Started

Why Bun is Rewriting in Rust (And What It Means for JavaScript Developers)

What Is Bun and Why It Matters

Why Bun Was Originally Written in Zig

The Decision to Rewrite in Rust

Where the Rewrite Stands Today

Performance Implications: Rust vs Zig

What Changes for JavaScript Developers Using Bun

Using Bun with Cosmic

What's Next

The Bottom Line

Cosmic AI Agents vs. Storyblok FlowMotion: Why CMS Automation Is Not Enough

What Storyblok FlowMotion Actually Does

What Cosmic AI Agents Actually Do

Content Agents

Code Agents

Computer Use Agents

Team Agents

The Workflow Difference

Developer-Native Integrations FlowMotion Does Not Offer

Two Different Categories

Pricing

Claude Sonnet vs Opus for Coding: Which Model Should You Choose?

The Quick Answer

Pricing: The Numbers You Need to Know

What Each Model Is Good At (for Code)

Claude Sonnet 4.6: The Everyday Workhorse

Claude Opus 4.7: When You Need the Heavy Lifter

Speed and Latency

A Practical Decision Framework

The Hybrid Approach

A Note on Context Windows

Conclusion

How to Build a React Blog with Next.js and Cosmic

Why Use a Headless CMS for a React Blog?

Prerequisites

Step 1: Set Up Your Cosmic Bucket and Content Model

Creating a Blog Posts Object Type

Get Your API Credentials

Step 2: Create a New Next.js App

Step 3: Initialize the Cosmic Client

Step 4: Define Your TypeScript Types

Step 5: Fetch Posts from the Cosmic REST API

Fetch All Posts (Blog Index)

Fetch a Single Post by Slug

Step 6: Build the Blog with Next.js App Router

Blog Index Page (app/blog/page.tsx)

Dynamic Post Page (app/blog/[slug]/page.tsx)

Step 7: Optimize Images with Imgix

Blog Index Page (`app/blog/page.tsx`)

Dynamic Post Page (`app/blog/[slug]/page.tsx`)