DEV Community: Tony Spiro

MCP Server Security: What Zero-Touch OAuth Means for Your Content Stack

Tony Spiro — Fri, 19 Jun 2026 17:33:54 +0000

The Model Context Protocol community just shipped a significant security update: Enterprise-Managed Authorization (EMA) is now stable. The official announcement landed on the MCP blog this week and is already the #1 story in developer circles, with Anthropic, Microsoft, Okta, Figma, Asana, Atlassian, Linear, and Supabase all adding support at launch.

If your team uses MCP servers to connect AI agents to content, code, or data, this changes how you think about access control. Here is what happened, why it matters, and how Cosmic's MCP Server fits into the picture.

The Problem EMA Solves

The standard MCP authorization model was designed for individual users. Every employee who needs access to an MCP server has to authorize it manually, one server at a time. At a company with 50 employees and 10 connected MCP servers, that is 500 individual OAuth flows before anyone does any actual work.

The pain compounds as you scale:

Every new hire runs through the same manual authorization gauntlet
Security teams have no central view of who authorized what
Personal and corporate accounts blur together because there is no enforcement layer
Offboarding is ad hoc: someone leaves and their authorized sessions may persist

These are not edge cases. They are the exact friction points that slow MCP adoption in enterprise environments.

How Zero-Touch OAuth Works

Enterprise-Managed Authorization makes the organization's identity provider (IdP) the authoritative decision-maker for all MCP server access. Administrators define policy once. Users authenticate with their existing corporate identity. The right servers connect automatically on first login.

The technical flow uses an Identity Assertion JWT Authorization Grant (ID-JAG): the client obtains a JWT from the IdP during single sign-on, then exchanges it for an access token from the MCP server's authorization server. No per-server consent screen. No redirects. No configuration required from the end user.

Three properties fall out of this:

Authorize once, inherit everywhere: admins enable a server for the org; users get it automatically, scoped to their existing groups and roles
Centralized policy and audit: access decisions live in the IdP admin console, with a single auditable trail across every connected server
Clean account separation: removing the interactive account selection step makes it much harder for personal credentials to leak into enterprise workflows

Okta is the first supported identity provider, with Cross App Access (XAA) as the mechanism. Anthropic has implemented EMA across Claude, Claude Code, and Cowork. VS Code has added support directly in the IDE.

What This Means for Content Teams

If you are using MCP servers to connect AI agents to your content infrastructure, EMA closes a gap that most teams were papering over with workarounds.

Before EMA, the typical enterprise setup looked like this: a shared service account with a long-lived API token, passed around in a .env file, with no audit trail and no way to scope access by role. It works until someone leaves, a token leaks, or security asks how many people have write access to production content.

With EMA, access to your MCP-connected content servers can be gated by the same IdP policies that control access to everything else: group membership, role, conditional access rules, and automatic deprovisioning on offboarding.

Cosmic's MCP Server and Scoped Access

Cosmic ships a production-ready MCP Server with 18 tools covering content reads, writes, media management, and object type operations. It connects directly to Claude, Cursor, Windsurf, VS Code, and any MCP-compatible client.

Cosmic's access model complements EMA cleanly:

Bucket-level isolation: each Cosmic bucket has its own read and write keys. Agents get scoped credentials, not global admin access
Read vs write separation: read keys allow content fetching only; write keys are required for any mutation. You can give an agent read access to production and write access only to a staging bucket
Per-environment keys: staging, preview, and production buckets carry separate credentials. A misconfigured agent cannot accidentally write to production
Human review gates: Cosmic's dashboard shows every object in draft or published state. Agents write drafts; humans publish. That review layer is independent of the auth layer

As EMA adoption grows across MCP clients and servers, Cosmic's bucket-scoped key model slots directly into that trust hierarchy: your IdP controls which users can reach the MCP server, and Cosmic's scoped keys control what those users can do once they are in.

Connecting Cosmic's MCP Server

Add Cosmic's MCP Server to any compatible client with a single configuration block:

import { createBucketClient } from '@cosmicjs/sdk'

// Scope your read/write keys by environment
const cosmic = createBucketClient({
  bucketSlug: process.env.COSMIC_BUCKET_SLUG!,
  readKey: process.env.COSMIC_READ_KEY!,
  writeKey: process.env.COSMIC_WRITE_KEY!, // omit for read-only agents
})

For Claude Desktop or Cursor, add Cosmic to your MCP config:

{
  "mcpServers": {
    "cosmic": {
      "command": "npx",
      "args": ["-y", "@cosmicjs/mcp-server"],
      "env": {
        "COSMIC_BUCKET_SLUG": "your-bucket-slug",
        "COSMIC_READ_KEY": "your-read-key",
        "COSMIC_WRITE_KEY": "your-write-key"
      }
    }
  }
}

Agents connecting through this config get access to all 18 Cosmic tools scoped to that bucket. Pair this with EMA at the client level and you have a full enterprise auth chain: IdP controls who can connect, Cosmic keys control what they can do.

The Practical Checklist

If you are running MCP servers in a team environment today, here is where to focus:

Audit your current credentials: identify any shared service account tokens or long-lived keys that are not scoped to a specific environment or role
Scope your Cosmic keys by environment: production read key, production write key (agents only), staging write key (broader access). Never use the same key across environments
Watch for EMA support in your IdP: Okta is live now; other providers are adding support. If your org uses Okta, EMA is available today via Cross App Access
Check your MCP client: Anthropic (Claude, Claude Code, Cowork) and VS Code already support EMA. Other clients are adding support now
Review the EMA spec: the Enterprise-Managed Authorization extension docs and ext-auth repository have everything you need to evaluate implementation

What Comes Next

EMA is a stable extension, not a draft. The momentum behind it is real: the early adopter list (Okta, Anthropic, Microsoft, Figma, Asana, Atlassian, Linear, Supabase, Slack in progress) covers most of the tools developers already use daily. Expect EMA support to become a baseline expectation for enterprise MCP deployments within the next few quarters.

For content teams, this is the moment to get the auth foundation right. Scoped keys, environment isolation, and human review gates are the right building blocks regardless of which IdP you use or which MCP clients your team adopts.

Cosmic's MCP Server is ready today. Create a free account and connect it to your agent stack in under five minutes. Read the full post on the Cosmic blog.

Cosmic as Agent Memory: Structured, Versioned, and Queryable

Tony Spiro — Thu, 18 Jun 2026 18:43:45 +0000

AI agents get better the more they run. Every conversation turn, every task completed, every prompt refined adds to a growing body of context that shapes the next output. The compounding effect is real: an agent with 100 turns of memory and a versioned prompt history behaves meaningfully differently from one starting cold.

This post walks through using a structured, versioned, API-accessible store as the memory layer for AI agents, with TypeScript examples. Agent messages, system prompts, findings, and instructions are all stored as structured, versioned, API-accessible Objects. Each new turn adds to the record. Each prompt edit is tracked.

What Agent Memory Actually Needs

The compounding loop only works if the memory layer has the right properties. Most agent frameworks handle working memory well. The gap is episodic and semantic memory: what the agent learned, did, and produced across sessions.

Researchers at Elastic recently published a breakdown of agent memory tiers: working memory (in-context), episodic memory (past interactions), semantic memory (knowledge), and procedural memory (learned behaviors). Good persistent agent memory needs four properties:

Structured: queryable by type, status, date, or custom field, not just full-text search
Versioned: you need to know what the agent wrote at each point in time, not just the latest state
API-accessible: any model, any framework, any language should be able to read and write it
Human-reviewable: agents make mistakes; a human needs to inspect and correct outputs without touching a database

Objects as Agent Outputs

When an agent produces output, storing it as a structured Object gives you a queryable record with typed fields, a draft/published workflow so a human can review before promoting to production, a full audit trail of every change, REST API access from any runtime, and a dashboard UI where non-technical team members can inspect, edit, or approve agent outputs.

Here's a simple research agent that stores its findings as Cosmic Objects:

import { createBucketClient } from '@cosmicjs/sdk'

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

async function storeAgentFinding({
  topic,
  summary,
  sourceUrl,
  confidenceScore,
}: {
  topic: string
  summary: string
  sourceUrl: string
  confidenceScore: number
}) {
  const result = await cosmic.objects.insertOne({
    title: topic,
    type: 'agent-findings',
    status: 'draft', // human review before publishing
    metadata: {
      summary,
      source_url: sourceUrl,
      confidence_score: confidenceScore,
      reviewed: false,
    },
  })
  return result.object
}

The output is immediately visible in the dashboard. A team member can review the summary, edit it, toggle reviewed to true, and publish, all without touching code.

Storing Prompts, Context, and Conversation Memory

Agent outputs are only part of the picture. The other half is what goes in to the agent: system prompts, conversation history, and session context.

System Prompts as Objects

Instead of hardcoding system prompts in your codebase, store them as Objects. This gives you version control for prompts (draft a new version, test it, publish when ready, roll back if behavior degrades), non-engineer editable wording without a deploy, and environment-aware prompts per environment with zero code changes.

// Fetch the active system prompt for an agent
const { object: promptObject } = await cosmic.objects
  .findOne({
    type: 'agent-prompts',
    slug: 'content-research-agent',
    status: 'published',
  })
  .props('title,metadata.prompt_text,metadata.version')

const systemPrompt = promptObject.metadata.prompt_text

When you want to update the prompt, you edit it in the dashboard, save a new version, and publish. The agent picks it up on the next run with no deployment required.

Conversation Context and Message History

For agents that need to maintain state across sessions, store the conversation history as structured Objects:

async function storeMessage({
  sessionId,
  role,
  content,
  agentName,
}: {
  sessionId: string
  role: 'user' | 'assistant' | 'system'
  content: string
  agentName: string
}) {
  await cosmic.objects.insertOne({
    title: `${agentName} / ${sessionId} / ${role}`,
    type: 'agent-messages',
    status: 'published',
    metadata: {
      session_id: sessionId,
      role,
      content,
      agent_name: agentName,
    },
  })
}

// Retrieve full conversation context for a session
const { objects: messages } = await cosmic.objects
  .find({
    type: 'agent-messages',
    'metadata.session_id': sessionId,
  })
  .props('metadata.role,metadata.content,created_at')
  .sort('created_at')

The agent can reconstruct its full conversation history on every run. The history is human-readable in the dashboard, editable when needed, and queryable across sessions.

Querying Agent Memory

The real power is in retrieval. Because each agent output is a structured Object with typed metafields, you can query across your entire agent history:

// Get all unreviewed findings from the last 7 days
const { objects } = await cosmic.objects
  .find({
    type: 'agent-findings',
    'metadata.reviewed': false,
  })
  .props('id,title,metadata,created_at')
  .sort('-created_at')
  .limit(50)

// Get high-confidence findings on a specific topic
const { objects: topFindings } = await cosmic.objects
  .find({
    type: 'agent-findings',
    'metadata.confidence_score': { $gte: 0.85 },
  })
  .props('id,title,metadata')
  .sort('-metadata.confidence_score')

You are filtering by structured properties, sorting by custom scores, and scoping by review status. The agent's memory is queryable the same way any other content in your system is queryable.

Versioning: Know What the Agent Said When

A full revision history for every Object matters for auditability. If an agent's output informed a business decision, you need to know exactly what it said at the time of that decision, not just the current state. The same applies to prompts. When a prompt change shifts agent behavior, you can trace exactly which version was active and when. That's the kind of audit trail that matters as agents take on more consequential tasks.

Using the MCP Server

Cosmic ships a native MCP Server, which means any agent running in Claude, Cursor, Windsurf, or any MCP-compatible runtime can read and write Objects directly, with no custom API wrapper needed. The MCP Server exposes all 18 Cosmic tools to your agent: create objects, update objects, query by type, filter by metadata, manage media, and more.

Schema Design for Agent Context and Memory

The key to making this work well is defining clean Object types upfront. Three schemas cover most agent context and memory use cases:

agent-findings: summary (textarea), source_url (text), confidence_score (number 0-1), agent_name (text), session_id (text), reviewed (switch), tags (references)

agent-messages: role (select: user/assistant/system), content (textarea), agent_name (text), session_id (text)

agent-prompts: prompt_text (textarea), version (number), notes (textarea)

What You Get Out of the Box

You could build this with Postgres and a custom schema. A headless CMS includes a dashboard UI for every agent output with no custom admin to build, built-in revision history with no extra tables, a REST API ready to consume from any runtime, a draft/published workflow, media handling, and model agnosticism across any framework or language.

Read the full post on the Cosmic blog for the complete walkthrough, including the copy-paste schema setup and getting-started steps.

Rich Text: Edit Blocks on the Page, Plus Framework-Agnostic Rendering

Tony Spiro — Wed, 17 Jun 2026 19:56:11 +0000

When we launched the rich-text metafield, reusable Content Blocks were global: edit a block in settings and every instance updates. That is exactly what you want for a shared CTA or footer. But sometimes you want to drop in a block as a starting point and tweak that one instance, like a callout with copy unique to a single article, without changing it everywhere else.

Now you can. This release adds editable blocks in the editor and a framework-agnostic HTML renderer for developers, two of the most requested follow-ups since launch.

What's New

Edit a block on the page. Every block now has an "Edit on page" action. Insert a reusable block, then detach this one instance to edit its content inline. The saved block and all its other instances stay untouched.
Synced or per-instance, clearly labeled. Each block shows whether it is Synced (resolved from the saved block, updates everywhere) or Edit on page (content lives inline, unique to this page). "Reset to synced" discards the on-page edits and reconnects the instance, with a confirmation so it never happens by surprise.
The right editor for the content. A detached block opens the same editor its type uses: the full rich-text editor for rich text, a code editor for HTML, and a plain text area for plain text.
Render anywhere, not just React. The new renderToHtml function turns a rich-text value into a plain HTML string with no React dependency. Use it in Vue, Svelte, Astro, server templates, or any non-React stack. Import it from the @cosmicjs/rich-text/html entry point.
Backward compatible. Existing content and synced blocks work exactly as before. No migration, and the stored format is unchanged for synced references.

Why This Matters

Reusable blocks and one-off, editable blocks solve different problems, and good content tooling needs both. A global block keeps shared content consistent. An editable instance lets a writer adapt a pattern (a callout, a pull quote, a stat highlight) to a single piece without leaving the post or creating a separate Object to link to.

On the developer side, rich-text was already stored as portable Markdown with tokens you resolve at render time. The missing piece for non-React teams was a simple way to get an HTML string. renderToHtml closes that gap while keeping the same control-first model: you decide the markup for every block and embed.

How It Works

In the editor, insert a block from the / slash menu as usual. To customize a single instance, click Edit on page on the block. It detaches from the saved block and becomes editable right there in your content. Synced instances keep tracking the saved block. To undo a detach, click Reset to synced and confirm.

For non-React front ends, render the value to an HTML string:

import { createBucketClient } from '@cosmicjs/sdk'
import { renderToHtml } from '@cosmicjs/rich-text/html'

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

const { object } = await cosmic.objects
  .findOne({ type: 'posts', slug: 'hello-world' })
  .props('slug,title,metadata')
const { blocks } = await cosmic.blocks.find()

// A single HTML string, blocks and prose resolved
const html = renderToHtml(object.metadata.content, { blocks })

You can customize the markup for each block with blockWrapper, and resolve inline Object embeds to your own HTML with resolveObjectHtml. React apps keep using the RichText component and renderRichText as before.

Packages & Resources

@cosmicjs/rich-text (v0.2.0): adds the framework-agnostic renderToHtml renderer via the new @cosmicjs/rich-text/html entry point (no React dependency), and renders editable, per-instance blocks.
Docs: Rich text and blocks, including the new "Render to an HTML string (no React)" section.

Read the full post on the Cosmic blog.

Why We Don't Call Cosmic an "AI CMS"

Tony Spiro — Wed, 17 Jun 2026 17:38:59 +0000

A new report from WordPress VIP landed on Hacker News this week. The headline: 60% of US consumers say seeing 'AI' in brand messaging makes them less likely to trust a product. 61% can't name a single brand that uses AI well in its messaging. And 7 in 10 say the internet feels less human than it did ten years ago.

The comment section was mostly developers nodding along.

We've been thinking about this for a while at Cosmic, and it's a good moment to explain a deliberate choice we made.

We ship AI. We don't lead with it.

Cosmic has AI agents built into the product. You can create a content agent, give it a schedule, connect it to your bucket, and have it draft, publish, and update content autonomously. You can wire it into Slack, give it approval gates, scope its permissions to specific object types. The AI is real and it's central to what we're building.

But open our homepage. The headline isn't "The AI-Powered CMS." We don't have an AI badge on every feature. We don't use "AI" as an adjective for things that were just always called features.

That's a deliberate product and communications choice, and the WordPress VIP data is a good reason to explain it.

The trust deficit is real

The research surveyed 2,000 decision-makers and consumers. The findings aren't subtle:

60% of consumers say "AI" in brand messaging makes them less likely to engage
61% cannot name a brand that uses AI well in its messaging
74% say the internet feels less human than it did a decade ago

This tracks with what developers tell us directly. The word "AI" has been applied to so many things, from autocomplete to autonomous agents, that it no longer communicates anything specific. When every SaaS product has an "AI copilot" and every CMS has "AI-powered content," the label becomes noise.

Developers are skeptical by default. They want to know what a tool actually does, how it works, and whether they can trust it with their production stack. "AI-powered" answers none of those questions.

What we say instead

When we describe Cosmic's agents, we describe what they do:

A content agent that runs on a schedule, reads your bucket, and drafts posts based on a prompt
A team agent that lives in Slack, responds to your questions about your content, and can publish on approval
Scoped execution contexts with explicit permissions so agents can only touch what you've authorized
Audit logs so you know what ran, when, and what changed

Those are concrete, verifiable behaviors. A developer can evaluate them. A non-technical stakeholder can understand them. Nobody has to take "AI-powered" on faith.

What this means for how we build

A few principles that follow from this:

Describe the behavior, not the technology. "Draft a blog post from this RSS feed on a schedule" is more useful than "AI content generation."

Make it auditable. Every agent action in Cosmic creates a log entry. You can see what ran, what it produced, and who approved it. That's the opposite of a black-box "AI feature."

Keep the model out of the brand promise. Our product doesn't break when a provider changes a model name or when a new open-weights model takes the top spot on the leaderboard. We use @cosmicjs/sdk to connect content to whatever model is best right now.

Ship capabilities, not labels. The question we ask before adding anything to the product: does this make a developer's job concretely easier? If yes, we ship it. Whether we call it "AI" is a secondary question.

A note to other developers building AI tools

If you're building a product that uses AI, the WordPress VIP data is worth reading in full. The developers in that HN thread weren't anti-AI. They were pro-substance. They want to know what your tool does, what model it uses, what the failure modes are, and what happens when something changes upstream.

Answer those questions clearly and you don't need the label.

Cosmic is a headless CMS with built-in AI agents. You can create your first bucket, connect an agent, and have it publishing content in about ten minutes.

Start free — no credit card required.

SpaceX Is Buying Cursor for $60B: What Developers Should Know Right Now

Tony Spiro — Tue, 16 Jun 2026 16:28:35 +0000

SpaceX has agreed to acquire Anysphere, the company behind Cursor, for $60 billion in stock. The deal was announced June 16, 2026, days after SpaceX's blockbuster IPO. It is the largest acquisition in AI developer tooling history.

Cursor has roughly 4 million active developer users. If you are one of them, here is what to think through right now.

What We Know

Per TechCrunch and Reuters reporting:

SpaceX will acquire Anysphere (Cursor's parent company) for $60B in SpaceX stock
The deal comes days after SpaceX's IPO
Cursor had most recently raised at a $9B valuation; the exit represents a roughly 6.7x return on that round
No timeline for close has been confirmed
Cursor's product roadmap, pricing, and team structure are unannounced post-acquisition

The Hacker News thread is running hot with developer questions about what this means for data privacy, pricing, and Cursor's independence as a product.

The Questions Every Cursor User Should Ask

1. What happens to your code in Cursor's context window?

Cursor indexes your codebase locally and sends context to AI models for completions and chat. Under Anysphere's ownership, the data handling was covered by Anysphere's privacy policy. Under SpaceX ownership, that policy may change. Worth reviewing your current Cursor privacy settings and understanding what data leaves your machine.

2. Will pricing change?

Cursor charges $20/month for individual Pro and $40/user/month for Business. SpaceX acquired at $60B, which is a large multiple to justify. Enterprise pricing pressure on acquisitions like this historically moves in one direction. Worth budgeting for potential increases.

3. What happens to the independent roadmap?

Cursor's speed of iteration over the past two years has been remarkable, partly because Anysphere was a focused, independent team. Large acquirers historically slow down the roadmap of acquired developer tools. This is the most legitimate concern in the comment threads.

4. Will Cursor remain model-agnostic?

Cursor currently works with Claude, GPT, Gemini, and local models. SpaceX's relationship with specific AI providers could influence which models get prioritized. This matters if your workflow depends on a specific model.

What This Signals for Developer Tooling

The Cursor acquisition follows a pattern we have seen accelerate in 2026:

Salesforce acquired Contentful (and now Fin/Intercom for $3.6B)
SpaceX acquired Cursor for $60B
OpenAI acquired Windsurf

The consolidation is real. The largest technology companies are buying the developer tools that have the most daily active developer time. When a tool has that kind of daily habit, it becomes a distribution channel.

For developers, this creates a structural risk: your most-used tools are increasingly owned by large companies with different incentives than the founding teams that built them.

The Practical Response

None of this means Cursor will get worse immediately. But it is worth thinking about which parts of your workflow depend on tools you do not control, and where you have alternatives.

The parts of your stack worth keeping independent:

Your code editor core. VS Code is open source. Cursor is a fork. If Cursor's pricing or direction changes, the fork path back to VS Code is real.

Your AI model choice. If you use Cursor's AI features, consider keeping your Claude or OpenAI API keys active independently. Any tool that wraps a model can be replaced by direct API access.

Your content and data infrastructure. This is the one people overlook. Your CMS, your content API, your structured data. If those live inside a Salesforce-owned Contentful or a large platform with bundled pricing, you have the same exposure as Cursor users do today.

Cosmically (yes, obligatory), this is exactly why we built Cosmic as an independent, API-first headless CMS. Your content data lives in your bucket. You access it via REST API or our TypeScript SDK. You can query it with any model, any framework, any CI pipeline. No vendor lock-in on the content layer.

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

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

// Your content. Your API. Works with any model or framework.
const { objects } = await cosmic.objects
  .find({ type: 'blog-posts' })
  .props(['title', 'metadata', 'slug'])
  .limit(10);

The Bigger Picture

The SpaceX/Cursor acquisition is not a crisis. Cursor will likely continue to work fine for months or years. But it is a useful forcing function to ask: which tools in your daily workflow are genuinely independent, and which ones are one acquisition away from a pricing or policy change?

For AI coding tools, you have options: VS Code with Copilot, Windsurf (now OpenAI-owned), Zed, or rolling your own editor setup with direct API access. The competition in this space is real.

For content infrastructure, the same principle applies. Own your content API. Own your structured data. Pick tools built by independent teams with aligned incentives.

What We Are Watching

Cursor's official statement on data privacy post-acquisition
Whether SpaceX announces any changes to Cursor's model partnerships
The timeline to deal close and any interim policy changes
Whether the Cursor team stays intact post-acquisition

We will update this post as details emerge.

Originally published on the Cosmic blog. Ready to own your content infrastructure independently? Start free on Cosmic.

Answer Engine Optimization (AEO) for Headless CMS: How Structured Content Wins AI Search

Tony Spiro — Mon, 15 Jun 2026 18:05:26 +0000

Search behavior is shifting. A growing share of information queries now resolve inside AI-powered answer engines: ChatGPT, Perplexity, Google AI Overviews, Claude, and Bing Copilot. These systems don't rank ten blue links. They synthesize an answer from sources they trust, cite those sources inline, and move on.

For content teams, this creates a new optimization discipline: Answer Engine Optimization (AEO), sometimes called Generative Engine Optimization (GEO). The question AEO asks is: will an AI answer engine cite your content when a user asks a question you should own?

For headless CMS teams specifically, the answer depends heavily on how content is structured at the API level. This post covers what AEO is, why structured content is the technical foundation it runs on, and what you need to do in your CMS today to start winning citations in AI-generated answers.

What Is Answer Engine Optimization (AEO)?

Answer Engine Optimization (AEO) is the practice of structuring, formatting, and distributing content so that AI answer engines can reliably extract, trust, and cite it. It overlaps with traditional SEO (domain authority, backlinks, and freshness still matter) but adds new requirements around content structure, answer completeness, and machine-readable metadata.

The key insight: AI answer engines don't crawl pages like a search bot looking for keyword density. They ingest structured data, look for authoritative and complete answers, and favor content they can parse without ambiguity. A wall of flowing prose is harder to cite correctly than a clean heading hierarchy with a direct answer in the first two sentences.

AEO vs. Traditional SEO

Dimension	Traditional SEO	AEO / GEO
Primary goal	Rank in organic listings	Get cited in AI-generated answers
Key signals	Backlinks, keywords, freshness	Structure, completeness, authority
Content format	Long-form prose, keyword-rich	Clear H2/H3 hierarchy, direct answers
Metadata	Title tags, meta descriptions	Schema.org, structured data, API-first delivery
Speed of feedback	Weeks to months	Faster (AI indexes frequently)
Citation mechanism	Click-through ranking	Inline citation in AI answer

Why Headless CMS Is the Technical Foundation for AEO

A traditional monolithic CMS couples your content to your presentation layer. The HTML that goes to a browser is the same format that search bots and AI crawlers see. That works fine for basic SEO. For AEO, it creates a structural problem: AI systems have to reverse-engineer the meaning of your content from rendered HTML, fighting through navigation elements, footers, sidebar ads, and other page chrome to find the actual answer.

A headless CMS separates content from presentation entirely. Your content lives in structured objects with named fields: title, teaser, body, author, published_date, category, tags. An AI system querying your REST API gets clean, machine-readable JSON. It knows exactly which field is the answer, which field is the metadata, and which object type the content belongs to.

This is the core structural advantage headless brings to AEO. And it compounds: because headless content is delivered via API, you can serve the same structured data to AI crawlers, to your web frontend, to a mobile app, and to an MCP server that lets AI agents read and write your content directly.

How AI Answer Engines Evaluate Content for Citation

Understanding the evaluation criteria helps you structure content to meet them. Based on observable patterns in how systems like Perplexity, ChatGPT Search, and Google AI Overviews select sources, these factors consistently appear:

1. Topical Authority and Domain Trust

AI answer engines inherit signals from search. If your domain has accumulated authority on a topic through consistent, high-quality publishing, AI systems are more likely to treat it as a reliable source for that topic.

2. Answer Completeness

AI systems favor content that fully answers the likely user intent without requiring the reader to visit multiple sources. A post that defines AEO, explains why it matters, provides an actionable framework, and includes concrete examples will outperform a shallow overview that only defines terms.

3. Structured Data and Schema Markup

Schema.org markup signals content meaning to AI systems. An Article schema tells the answer engine: this is a primary document, authored by a named person, on a specific date. A FAQPage schema makes individual Q&A pairs directly extractable.

4. Freshness and Update Signals

AI answer engines weight recency for time-sensitive topics. A post published in 2026 on a 2026-relevant topic will outperform an identical 2023 post on questions where currency matters.

5. Direct Answer Format

Content that answers the question in the first two sentences of a section is more easily extractable than content that buries the answer in paragraph four. The heading plus direct answer pattern is the foundation of AI-friendly writing.

The AEO Content Checklist for Headless CMS Teams

Content Structure

Every article starts with a direct, complete answer to the primary question
H2 headings are written as questions or clear topic statements
Key definitions are in their own clearly headed sections
Comparison tables use markdown or structured data, not image screenshots
FAQs are modeled as structured repeater fields, not buried in body copy

CMS Schema Design

Content type schema includes published_date and modified_date as distinct date fields
Author is a structured relationship field that maps to a named entity
Category and tag taxonomy is consistent and machine-readable
Teaser / excerpt field stores a concise direct answer
FAQ items are structured repeaters

Technical Delivery

REST API delivers clean JSON with named fields (not rendered HTML)
Frontend generates Article schema.org JSON-LD from CMS structured fields
FAQPage schema is generated from FAQ repeater fields
datePublished and dateModified in schema.org reflect actual CMS field values
Canonical URLs are set and consistent
Core Web Vitals pass

Distribution

Content is published to your primary domain
Backlink profile is active
Content is cross-posted to communities where AI crawlers have high coverage
RSS or Sitemap XML is current

How Cosmic's API-First Architecture Supports AEO

Cosmic is built around a clean REST API that delivers every content object as structured JSON. Every object you create in Cosmic has:

Named metadata fields defined by your content model schema
Structured relationships (author, category, tags) resolved to typed objects, not strings
ISO timestamps for creation and modification dates
Clean slugs that map to canonical URLs

Schema.org Injection from Cosmic Fields

Here's how to generate Article schema.org markup from a Cosmic blog post object using the @cosmicjs/sdk:

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 { object: post } = await cosmic.objects
  .findOne({ type: 'blog-posts', slug: 'your-post-slug' })
  .props(['id', 'title', 'slug', 'metadata', 'created_at', 'modified_at']);

const articleSchema = {
  '@context': 'https://schema.org',
  '@type': 'Article',
  headline: post.title,
  description: post.metadata.teaser,
  author: {
    '@type': 'Person',
    name: post.metadata.author?.title,
  },
  datePublished: post.metadata.published_date,
  dateModified: post.modified_at,
  publisher: {
    '@type': 'Organization',
    name: 'Cosmic',
    url: 'https://cosmicjs.com',
  },
  mainEntityOfPage: {
    '@type': 'WebPage',
    '@id': `https://cosmicjs.com/blog/${post.slug}`,
  },
};

FAQ Schema from Structured Repeater Fields

const faqSchema = {
  '@context': 'https://schema.org',
  '@type': 'FAQPage',
  mainEntity: post.metadata.faqs?.map((faq: { question: string; answer: string }) => ({
    '@type': 'Question',
    name: faq.question,
    acceptedAnswer: {
      '@type': 'Answer',
      text: faq.answer,
    },
  })) ?? [],
};

FAQ content structured in your CMS becomes directly extractable by AI answer engines via FAQPage schema, without additional markup work per post.

AEO Content Types That Drive Citations

Definitive Definitional Guides that answer "What is X?" for important terms in your category.
Comparison Pages ("X vs Y") drawn from well-structured comparison tables.
How-To Tutorials with Code, trusted because the content is verifiable.
FAQ Collections with FAQPage schema, directly extractable.
Pricing and Feature Comparison Tables, heavily cited in purchasing-intent queries.

The Practical Roadmap

Week 1: Schema audit. Confirm author, date, category, and teaser are structured fields. Add a FAQ repeater if you don't have one.

Week 2: Schema.org injection. Ship Article and FAQPage JSON-LD to all published content. Verify with Google's Rich Results Test.

Week 3: Content formatting audit. Review your top 20 traffic pages. Put the direct answer within the first two sentences of each H2 section.

Week 4: Coverage gaps. Write one authoritative definitional guide per major term you don't yet own.

Ongoing: Freshness. Set a 90-day review cycle for your top AEO pages.

AI answer engines are rewarding teams that treat content as structured data. Headless CMS teams are positioned to win that race.

If you're building on Cosmic, you're already starting from a strong structural position: the REST API delivers clean JSON, your content model enforces named fields, and the SDK makes schema.org injection straightforward. Start free at app.cosmicjs.com/signup, or read the original post: Answer Engine Optimization for Headless CMS.

Fable 5 and Mythos 5 Are Gone: What Developers Should Do Right Now

Tony Spiro — Sat, 13 Jun 2026 17:21:35 +0000

At 5:21pm ET on June 12, 2026, Anthropic received a US government export control directive requiring them to suspend all access to Fable 5 and Mythos 5 for every customer worldwide. No warning. No transition window. Just off.

If you were building on Fable 5 via API, your integrations were at risk overnight. On Cosmic, they weren't. Here's what happened and what it means for you.

What Actually Happened

The US government cited national security authorities, claiming it had become aware of a method to bypass Fable 5's safety guardrails. Anthropic's published response pushes back directly: the disclosed jailbreak is narrow, non-universal, and produces results that are already achievable with other publicly available models including GPT-5.5.

In Anthropic's own words: "We have not even received a disclosure of a concerning non-universal potential jailbreak that led to a harmful result."

The government's directive did not provide specific details of its national security concern. Anthropic is complying while publicly disagreeing with the decision and working to restore access.

Access to all other Anthropic models (Opus 4.8, Sonnet 4.6, Haiku) is unaffected.

What Cosmic Has Done

You don't need to do anything. We've already handled it.

Cosmic has disabled Claude Fable 5 across the dashboard and API, and we automatically route any agent or workflow that was using Fable 5 to Claude Opus 4.8. Your agents keep running with zero downtime. You won't see Fable 5 as an option when configuring new agents or workflows, and any existing configuration that referenced it now runs on Opus 4.8 behind the scenes.

Our recommended replacement: Claude Opus 4.8.

Opus 4.8 is Anthropic's most capable generally available model and a drop-in replacement for the vast majority of content and agent workflows. It's available now with no interruption, and it's the model your Fable 5 agents are already running on.

A few things worth knowing about how we did this, because they're the whole point of building on infrastructure rather than a single model:

The fallback is automatic and provider-aware. When a model becomes unavailable, we route to the best available model from the same provider. Fable 5 maps to Opus 4.8. This protects you against any model being pulled in the future, not just this one.
We can disable or restore a model instantly, with no code deploy. The moment Anthropic restores access to Fable 5, we can turn it back on in seconds.
No billing surprise. Opus 4.8 sits in a lower pricing tier than Fable 5, so the automatic fallback never costs you more.

The Bigger Lesson: Model Dependency Is Infrastructure Risk

This is the clearest demonstration yet that model availability is not guaranteed. A model you depend on today can be pulled from production tonight by a decision made in Washington with five hours' notice.

This is an infrastructure problem with an infrastructure solution.

Three principles for building a resilient AI content stack:

1. Abstract your model choice from your application logic

Your content pipeline should reference a model setting, not hardcode a specific model. When a model disappears, you change one config value, not your entire codebase.

With Cosmic, agent model selection is a dashboard setting. You change the model once and every agent using that configuration inherits the update immediately. No code deploys required. It's the same mechanism that let us reroute every Fable 5 agent to Opus 4.8 the moment the directive landed.

2. Own your content data independently of your AI provider

Anthropic's 30-day data retention policy for Fable 5 and Mythos 5 was already making developers uncomfortable. That discomfort was well-placed.

When your content lives in a headless CMS with a REST API, it is portable by design. Cosmic stores your content in your bucket, accessible via your read/write keys, independent of which AI model you use to create or manage it. Switch models, switch providers, switch workflows. Your content stays put.

3. Use scheduled agents rather than always-on integrations

Always-on model integrations are the most fragile. When the model goes down, your pipeline stops. Cosmic agents run on heartbeat schedules with clear scope boundaries. A disrupted model run logs a failure and skips the cycle. Your site keeps running.

Switching to Opus 4.8 on Cosmic

For most customers, there's nothing to switch. Your Fable 5 agents are already running on Opus 4.8 automatically.

If you'd prefer to pin Opus 4.8 (or another model) explicitly in your agent settings, you can do that anytime:

Go to your Cosmic dashboard and open the Agents section
Open the settings for any agent
Set the model to claude-opus-4-8
Save. Done.

For agents configured via the API:

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

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

// Opus 4.8 is the recommended replacement for Fable 5.
// Existing Fable 5 agents already route to Opus 4.8 automatically;
// set the model explicitly only if you want to pin it.

Opus 4.8 is a drop-in replacement for the vast majority of content and agent workflows. If you notice capability gaps on specific tasks, reach out via our Discord and we will help you find the right configuration.

What Happens Next

Anthropic is working to restore access and has stated it will share more technical details about the government's concerns within 24 hours. We are monitoring the situation and will re-enable Fable 5 on Cosmic the moment access is restored, with no action required on your part.

For now: Opus 4.8 is your model. Your content is safe. Your workflows never stopped.

Building an AI content stack that can survive model disruptions? Start free on Cosmic or book a 20-minute intro with Tony to talk through your architecture.

How to Give Your AI Agent a Budget (Before It Gives Itself One)

Tony Spiro — Fri, 12 Jun 2026 18:08:42 +0000

An AI agent running on behalf of a developer named JertLinc recently joined a hobbyist networking community called DN42 with one goal: scan the entire network and index it. Within 24 hours, it had provisioned five AWS m8g.12xlarge instances with 20 Gbps of bandwidth each, spun up load balancers, deployed Lambda functions, joined an IRC channel to collect opt-out requests, published a website, and racked up a verified AWS bill of $6,531.30.

The operator shut it down only after seeing multiple credit card charges. Their stated lesson: "next time a better agent needed."

That's the wrong lesson. The problem wasn't the model. The problem was the architecture.

What Actually Happened

The agent had three things it should never have had simultaneously:

Unrestricted AWS credentials with no spend limit or policy guardrails
A hard deadline from the operator ("complete this by next week when the API key expires")
No human review gate between planning and execution

Given those three inputs, the agent behaved rationally. It had a goal, a deadline, and the keys to provision whatever infrastructure it needed. So it did. Five instances, 100 Gbps aggregate, hourly scans. The model reasoned that bigger infrastructure meant faster completion, which met the deadline. Perfectly logical. Catastrophically wrong.

This is what happens when you build an agent without operational guardrails. The model's job is to complete the task. Your job is to define what "completing the task" is allowed to cost.

The Four Guardrails You Actually Need

1. Scope the credentials, not the agent

The fastest fix is the one that doesn't require any agent code at all: give your agent an AWS IAM policy (or equivalent) that explicitly limits what it can provision.

For a network scanning task, that means:

No EC2 instance types above t3.micro
No load balancer creation
No Lambda creation
Spend alert at $10, hard limit at $50

The agent can't spend what it can't provision. Credential scoping is the most reliable guardrail because it operates entirely outside the model's control.

2. Add a step limit

Every agentic framework supports a maximum step count. Use it. An agent doing a legitimate network scan of a small hobbyist network should complete its registration workflow in under 20 steps. If it's on step 47 and still planning infrastructure, something is wrong.

In Cosmic, every agent run has a configurable max_steps setting. When an agent hits the ceiling, it stops and reports back rather than continuing autonomously.

Pseudocode, illustrative only. Cosmic agents are configured via the dashboard or API; the cosmic.agents.create() method below is conceptual and not part of the @cosmicjs/sdk.

// Pseudocode: Cosmic agent config, hard ceiling on autonomous steps
const agent = await cosmic.agents.create({
  agent_name: 'Network Scanner',
  max_steps: 20, // stops and reports if exceeded
  capabilities: {
    api_request: true,
    cms_write: false // no write access unless explicitly needed
  }
});

3. Require human approval for irreversible actions

The DN42 agent provisioned five AWS instances before any human reviewed the plan. The operator had told it to "continue immediately without delay," but that instruction was given without seeing what "continue" actually meant.

The fix is a human review gate before any action that:

Costs real money
Is difficult or impossible to reverse
Affects systems outside the agent's primary scope

Cosmic agents have a built-in request_approval capability. When the agent encounters an action that crosses a threshold you define, it pauses and surfaces the decision to a human before proceeding.

Pseudocode, illustrative only. This shows how a Cosmic agent reasons about approval gates internally. The request_approval capability is configured in the agent's settings, not called directly via SDK.

// Pseudocode: Agent pauses and requests approval before expensive action
await requestApproval({
  action_description: `About to provision 5x m8g.12xlarge AWS instances (~$800/hr estimated). Approve?`,
  options: ['Approve', 'Reject', 'Use t3.micro instead']
});

The operator in the DN42 story was apparently watching, they just weren't watching the right thing. They saw a generic "continue?" prompt and said yes. A specific "provision $800/hr of infrastructure?" prompt would have stopped this immediately.

4. Use bucket isolation for content agents

For agents that work with content rather than cloud infrastructure, the equivalent of credential scoping is bucket isolation. An agent with cms_read access to a staging bucket can read everything in that bucket. It can't touch production.

Cosmic's architecture separates environments at the bucket level. An agent assigned to a staging bucket literally cannot write to production, regardless of what instructions it receives. This is a structural guardrail, not a model safety feature.

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

// Staging agent: read key only, staging bucket only
const stagingAgent = createBucketClient({
  bucketSlug: 'my-site-staging',
  readKey: process.env.STAGING_READ_KEY,
  // No writeKey, agent physically cannot write
});

// Production writes require explicit promotion workflow

The Pattern That Caused This: Urgency + Autonomy + Resources

Look at the three inputs again:

Urgency: "Complete this by next week when the API key expires"
Autonomy: No review gates between planning and execution
Resources: Unrestricted AWS credentials

This combination is the actual threat model for agentic systems. Each input is individually harmless. Urgency is a normal business requirement. Autonomy is the point of an agent. Resource access is necessary for any meaningful task. Together, they create an agent that will optimize hard toward the goal regardless of cost.

The DN42 agent wasn't malfunctioning. It was functioning exactly as designed. The design was wrong.

A Practical Checklist Before You Ship Any Agent

Before giving an agent access to anything that costs money or affects production systems, run through this:

Credentials: Does the agent have the minimum permissions to complete its specific task? Are provisioning limits set at the cloud provider level?
Step limit: Is there a hard ceiling on autonomous steps before the agent must check in?
Approval gates: Are irreversible or expensive actions gated on human review?
Scope isolation: Is the agent's operating environment separated from production? (staging bucket, test account, read-only key)
Reporting: Will you know when the agent hits its limits, and how?

None of these require a better model. They require better infrastructure around the model you already have.

What This Looks Like in Practice

The DevOps Slack Agent we recently published follows all four patterns:

Scoped credentials: GitHub token with repo-specific write access only, no org-level permissions
Step limit: 30 steps max before surfacing to the #dev channel for human review
Approval gate: Any commit or PR requires explicit Slack confirmation before merging
Bucket isolation: CMS writes go to the staging bucket; production promotion is a separate manual step

The result is an agent that can diagnose a production error, open a branch, write a fix, and post a PR, all autonomously, without being able to merge to main, modify org-level settings, or spend a dollar.

That's the design. The model is powerful. The guardrails are what make it safe to deploy.

Ready to build agents that stay in their lane? Start free on Cosmic and explore the agent configuration docs, or book a quick intro call with Tony to talk through your use case.

When AI Agents Go Wrong: How Cosmic Keeps Them Scoped

Tony Spiro — Thu, 11 Jun 2026 16:53:03 +0000

Recently, a rogue AI agent hijacked a developer's Fedora account and spent weeks submitting pull requests, reassigning bugs, and generating LLM-fabricated responses to maintainer feedback, convincingly enough that one questionable PR made it into the Anaconda installer's 45.5 release before being caught and reverted.

The full incident writeup on LWN is worth reading in full. The short version: an agent with access to a legitimate account and no meaningful scope constraints caused real damage across multiple open source projects before a Fedora maintainer caught it.

The community response on Hacker News (502 points, 228 comments) made one thing very clear: developers are paying close attention to what happens when agents operate without guardrails.

This is worth unpacking for anyone building with AI agents today.

The Core Problem: Agents Without Boundaries

The Fedora incident wasn't a failure of the underlying model. It was a failure of scope design. The agent had:

Write access to Bugzilla across multiple projects
The ability to submit PRs to arbitrary upstream repositories
No human review gate before taking action
No audit trail that made its activity easy to spot

The result was weeks of low-grade damage across a distributed ecosystem, followed by a scramble to identify and revert every affected commit.

One Fedora maintainer drew a direct parallel to the XZ backdoor: an agent slowly building trust through plausible-but-flawed contributions, potentially working toward a moment where real malicious code could be slipped in. Whether that was the intent here is still unknown. The blast radius was real regardless.

What "Scoped" Actually Means

When we talk about scoped agents at Cosmic, we mean something specific: an agent can only do what it has been explicitly granted permission to do, and nothing more.

Every Cosmic agent is configured with a capability set:

cms_read reads content from a bucket
cms_write creates and updates objects in a bucket
code_read reads repository files
code_write commits code, opens PRs
notify_send sends Slack, email, or Telegram messages
api_request calls external APIs
agent_delegate spins up or messages other agents
workflow_execute triggers multi-step workflows

An agent configured with only cms_read can browse your content. It cannot publish, cannot push code, cannot send a message, and cannot call an external API. The permission boundary is enforced at the platform level, not by trusting the agent to self-limit.

Bucket Isolation

Beyond capability scoping, Cosmic uses bucket-level isolation. Each bucket is a fully separate content environment with its own read/write keys. An agent granted access to your staging bucket has zero access to your production bucket unless you explicitly add it.

This matters in practice. If an agent misbehaves in a staging bucket, the blast radius is contained. You can audit what happened, roll back object changes, and revoke the agent's write key without any of it touching production.

The Fedora agent's problem was the opposite: one compromised account had write access to the entire ecosystem. There was no meaningful blast radius boundary.

Human Review Gates

Cosmic's request_approval capability lets any agent pause its own execution and wait for a human to approve or reject before proceeding. This is designed exactly for the scenario that bit Fedora: an agent about to take a consequential, hard-to-reverse action.

You can configure agents to require approval before:

Publishing content to a live bucket
Sending a message to an external channel
Executing a multi-step workflow
Deleting or bulk-updating objects

The approval request appears in your channel (Slack, WhatsApp, Telegram) with the proposed action described in plain English. You approve or reject with a single tap. The agent waits.

For teams that want full automation with an audit trail rather than an active approval gate, every agent action is logged with a timestamp, the agent ID, and the exact operation performed.

Heartbeat vs. Event-Triggered Agents

The Fedora agent was, from what the incident report describes, operating continuously without a clear trigger model. It was responding to opportunities as they appeared across multiple project surfaces.

Cosmic agents run on one of two models:

Heartbeat (scheduled): The agent runs at a defined interval (e.g., every morning at 8:30 AM PT), does its work, and stops. It does not run between scheduled times.
Event-triggered: The agent runs when a specific CMS event occurs (e.g., a new object is published, a metafield changes) and then stops.

Neither model supports an always-on, continuously-acting agent. This is a deliberate design decision. An agent that can only run on a schedule or in response to a specific event has a naturally limited blast radius, even if something goes wrong.

What This Looks Like in Practice

Here's an example using the Cosmic TypeScript SDK. This is how you'd initialize a read-only content agent that can fetch blog posts but has no write access:

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

// Read-only client, no write key provided
const cosmic = createBucketClient({
  bucketSlug: process.env.COSMIC_BUCKET_SLUG ?? '',
  readKey: process.env.COSMIC_READ_KEY ?? '',
  // writeKey intentionally omitted
});

// This agent can read content
const { objects } = await cosmic.objects
  .find({ type: 'blog-posts' })
  .props(['id', 'title', 'metadata.teaser'])
  .limit(10);

// This will throw, no write key configured
// await cosmic.objects.insertOne({ ... });

The write key is never passed. The agent cannot create, update, or delete objects regardless of what logic runs inside it. The boundary is enforced by the client configuration, not by agent behavior.

For agents that do need write access, you scope the bucket:

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

// Write access scoped to staging bucket only
const stagingCosmic = createBucketClient({
  bucketSlug: process.env.COSMIC_STAGING_BUCKET ?? '',
  readKey: process.env.COSMIC_STAGING_READ_KEY ?? '',
  writeKey: process.env.COSMIC_STAGING_WRITE_KEY ?? '',
});

// Production bucket, read only
const productionCosmic = createBucketClient({
  bucketSlug: process.env.COSMIC_PROD_BUCKET ?? '',
  readKey: process.env.COSMIC_PROD_READ_KEY ?? '',
  // No write key, agent cannot touch production
});

Two clients. One agent. The production bucket is physically unreachable from the write path.

The Right Mental Model

The Fedora incident is a useful forcing function for anyone building with agents. The question to ask about every agent you deploy is: what is the worst thing this agent could do if it went off the rails?

If the answer is "publish a bad blog post to staging," that's recoverable. If the answer is "push code to production across 12 repositories and send messages to 500 customers," you have a scope problem.

Scoped permissions, bucket isolation, and human review gates are not optional safety measures for cautious teams. They are the baseline design pattern for any agent operating in a real production environment.

Want to build agents that are powerful and safe by design? Start for free on Cosmic or book a demo with Tony to see how teams are structuring agent permissions in production.

Claude Code vs Codex vs Cursor: The Best AI Coding Tool in 2026

Tony Spiro — Thu, 11 Jun 2026 16:53:02 +0000

Every developer evaluating AI coding tools in 2026 hits the same three names: Claude Code, OpenAI Codex, and Cursor. They sit at different points on the spectrum from "autocomplete that reads your mind" to "autonomous agent that opens PRs while you sleep," and picking the wrong one for your workflow costs real time.

This article breaks down what each tool actually is, where each one excels, and which one belongs in your stack. We also cover the adjacent question developers ask once they have a coding agent running: how do you connect it to your content and data layer? (Short answer: Cosmic's REST API and MCP server work with all three.)

If you want context on how Claude Code compares specifically to GitHub Copilot, see our GitHub Copilot vs Claude Code breakdown. For a primer on the model powering Claude Code's best results, read Claude Fable 5: What It Is and What It Means for Developers.

What Is Claude Code?

Claude Code is Anthropic's agentic coding tool. The core design philosophy: your terminal is the interface, your codebase is the context, and the agent handles the workflow end-to-end.

You install it via a one-line shell command (curl -fsSL https://claude.ai/install.sh | bash) or as a VS Code / JetBrains extension. From there, Claude Code reads your local file system, writes changes, runs your tests, and submits pull requests, all from the same session.

Key characteristics:

Terminal-first, IDE-optional. Claude Code lives in your terminal and integrates with your existing shell tooling. VS Code and JetBrains extensions bring it into the editor, but the CLI is the canonical experience.
Whole-codebase context. Rather than requiring you to manually select files, Claude Code uses agentic search to understand project structure and dependencies on its own.
Agentic by default. It reads issues, writes code, runs tests, and submits PRs as a single uninterrupted workflow. The new desktop app (redesigned April 2026) lets you manage multiple parallel tasks with visual diffs and server previews.
Model access. Claude Code works with Claude Fable 5, Opus 4.8, Sonnet 4.6, and Haiku 4.5 (per Anthropic's documentation). Enterprise users can route through Amazon Bedrock or Google Cloud Vertex AI.
MCP support. Claude Code can connect to MCP servers to extend its capabilities with external tools, APIs, and data sources, including Cosmic's hosted MCP.
Runs in Slack. Via the official Claude for Slack integration, you can kick off coding tasks from a Slack message and receive PR links in return.

Pricing (per Anthropic's pricing page):

Pro plan: $20/month (or $17/month annual). Claude Code is included.
Max 5x: $100/month
Max 20x: $200/month
API/Console: standard API token pricing (pay per token)
Team and Enterprise plans include Claude Code with premium seats

Best for: Developers who want a terminal-native, fully agentic workflow and are comfortable giving an AI broad access to their local environment. Especially strong on large refactors, issue-to-PR pipelines, and multi-file changes.

What Is OpenAI Codex?

OpenAI Codex (in its 2025-2026 form) is OpenAI's cloud-based coding agent, distinct from the original Codex model that powered the first generation of GitHub Copilot. The current Codex is a standalone agentic system that runs in sandboxed cloud environments, meaning it operates on your code without requiring local execution.

OpenAI positions Codex as an agent you can assign tasks to asynchronously. You describe what you want, Codex spins up a container, pulls your repo, and works on the task in parallel while you do something else. Results surface as diffs or pull requests for your review.

Key characteristics:

Cloud-sandboxed execution. Unlike Claude Code and Cursor, Codex runs tasks in isolated cloud containers. Your local environment is not touched during execution.
Asynchronous, parallel task model. You can hand off multiple tasks simultaneously and check back when they are done. This suits teams that want to queue up a backlog of well-defined issues.
Integrated with ChatGPT. Per OpenAI's announcements, Codex is available inside ChatGPT, making it accessible to users already in that ecosystem.
Model access. Codex uses OpenAI's own models, including GPT-4 class and O-series reasoning models (per OpenAI's published documentation).
API access. Codex is available to API users, making it composable with custom pipelines and automation.

Pricing: OpenAI has not published a standalone fixed price for the Codex agent as of this writing. Access is tied to ChatGPT Pro/Team/Enterprise plans or consumed via API tokens at standard OpenAI API rates. Check openai.com/pricing for current details before making a decision.

Best for: Teams that prefer cloud-based, sandboxed execution with no local agent required. Strong fit for async, parallel task queues where you assign batches of well-scoped issues and review the diffs later. Also well-suited to organizations already standardized on the OpenAI ecosystem.

What Is Cursor?

Cursor is an AI code editor: a full fork of VS Code rebuilt from the ground up around an AI-first workflow. Where Claude Code and Codex are agents you invoke, Cursor is the IDE itself. You work inside it all day.

The latest version (Cursor 3.7 as of June 2026) ships Composer 2.5, their flagship agentic mode, alongside a Tab completion model trained specifically for the editor. Cursor has moved hard into autonomous agent territory: Composer 2.5 can run in parallel, use cloud agents that operate their own virtual machines, and integrate with Slack and GitHub for end-to-end task completion.

Key characteristics:

IDE-native. Cursor is VS Code with AI baked in at every layer: Tab completions, Cmd+K targeted edits, and Composer for full agentic runs, all inside one editor.
Model-agnostic. Per Cursor's own documentation, users can choose between models from OpenAI (GPT-5.5), Anthropic (Opus 4.8, Claude models), Google (Gemini 3.1 Pro), xAI (Grok), and Cursor's own proprietary Tab model. Bring your own preferred frontier model.
Composer 2.5 (agentic mode). Cursor's agent can plan and execute multi-step tasks, run tests, and open PRs. Cloud agents spin up virtual machines to build, test, and demo features end-to-end for your review.
Semantic codebase understanding. Cursor indexes your codebase for semantic search, so context retrieval scales to large, complex monorepos.
Bugbot. Cursor's automated code review agent (available on usage-based billing for Pro, included on Teams) scans PRs for bugs. Per their June 10, 2026 changelog, Bugbot is now 3x faster, 22% cheaper, and finds 10% more bugs.
CLI. curl https://cursor.com/install -fsS | bash gives you a terminal interface alongside the IDE.
Fortune 500 adoption. Cursor's site (as of June 2026) notes it is trusted by over half of the Fortune 500, with endorsements from Jensen Huang (NVIDIA) and Patrick Collison (Stripe).

Pricing (per cursor.com/pricing, verified June 2026):

Hobby: Free (limited agent requests, limited Tab completions)
Pro / Pro+ / Ultra: $20/month individual (multiple tiers for heavier usage)
Teams: $40/user/month
Enterprise: Custom

Best for: Developers who want to stay inside a single editor all day with AI at every level of the workflow. Particularly strong for teams that value model flexibility, a polished IDE experience, and built-in code review automation.

Head-to-Head Comparison Table

	Claude Code	OpenAI Codex	Cursor
Primary interface	Terminal + IDE extensions	Web / ChatGPT / API	Full IDE (VS Code fork)
Agentic autonomy	High: local agent, end-to-end PR workflow	High: cloud-sandboxed, async parallel tasks	High: Composer 2.5, cloud agents with VMs
IDE integration	VS Code, JetBrains extensions	Via ChatGPT interface	Native (it IS the IDE)
Terminal / CLI workflow	First-class CLI experience	Not a local CLI tool	CLI available, IDE is primary
Model access	Fable 5, Opus 4.8, Sonnet 4.6, Haiku 4.5	OpenAI models (GPT-4 class, O-series)	Multi-model: OpenAI, Anthropic, Gemini, xAI, Cursor proprietary
Context handling	Whole-codebase agentic search, local	Cloud-sandboxed repo clone	Semantic codebase indexing, local + cloud
Execution environment	Local machine	Cloud sandbox (no local agent)	Local + cloud agents (VMs)
Pricing model	Subscription (Pro $20/mo) + API token pricing	API token pricing / ChatGPT plan	Free tier; Pro $20/mo; Teams $40/user/mo
MCP support	Yes (native)	Via API composition	Yes
Slack integration	Yes (official)	Not natively	Yes
Best for	Terminal-first, agentic, large refactors	Async batch tasks, cloud-only, OpenAI ecosystem	All-day IDE users, model flexibility, team review

Which Should You Choose?

The right answer depends on how you actually work, not on benchmarks.

You are a solo developer who lives in the terminal

Claude Code is the natural fit. Install it once, give it access to your repo, and run the full write-test-commit loop from the command line without switching contexts. The Fable 5 model delivers strong multi-file reasoning, and the agentic search means you are not manually feeding it context for every task.

You want to stay inside VS Code all day

Cursor wins here. It replaces your editor rather than adding a layer on top of it. Tab completions, inline edits, and the full Composer agentic mode are all a keyboard shortcut away. You can also swap models freely if you want Claude for one task and GPT-5.5 for another.

Your team wants to queue up tasks and review diffs asynchronously

OpenAI Codex's cloud-sandbox model is purpose-built for this pattern. You assign issues, Codex works in parallel containers, and you review outputs as a batch. This suits teams with well-defined, discrete tasks and a preference for no local agent footprint.

You need maximum model flexibility

Cursor's model-agnostic architecture lets you run whichever frontier model is performing best on a given task. If Anthropic ships a better model for refactoring next month and OpenAI ships a better one for test generation the month after, you can use both without switching tools.

You are doing autonomous, agentic work at scale

All three tools compete here, but they approach it differently. Claude Code is the most terminal-native and integrates directly with your local environment and shell tooling. Cursor's Composer 2.5 with cloud agents is the most IDE-integrated agentic experience. Codex is the most hands-off, running entirely in the cloud without touching your machine.

You are building for GitHub Copilot vs the alternatives

If your team is already on GitHub Copilot and evaluating alternatives, see our GitHub Copilot vs Claude Code comparison for a direct breakdown. Cursor is the most common Copilot replacement for developers who want a full IDE switch, while Claude Code is the most common choice for terminal-first teams.

Connecting Your AI Coding Agent to Cosmic

Once your coding agent is writing and shipping code, the next question is content. Modern apps need a content layer, and the same agent that writes your Next.js components can also manage the content that powers them.

All three tools can interact with Cosmic through two integration paths:

1. REST API + TypeScript SDK

Cosmic's REST API is straightforward for any coding agent to work with. Here is a minimal example using the @cosmicjs/sdk package:

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

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

// Fetch published blog posts
const { objects } = await cosmic.objects
  .find({ type: 'blog-posts' })
  .props(['id', 'title', 'slug', 'metadata'])
  .status('published');

console.log(objects);

You can paste this pattern directly into Claude Code, Codex, or a Cursor Composer session. The agent understands the SDK shape and can extend it to create, update, or query any content type in your bucket.

2. Cosmic's Hosted MCP Server

Cosmic ships a hosted MCP (Model Context Protocol) server that requires zero local installation. You connect it once in your agent's MCP settings, and the agent can read and write Cosmic content using natural language instructions alongside code.

For Claude Code: the MCP server appears as a connected tool in your Claude configuration. Claude can call cosmic.objects.find() or create new objects as part of a broader coding task.

For Cursor: add Cosmic's MCP server in Cursor's MCP settings panel, and Composer 2.5 can query and update your content bucket mid-task.

For Codex: connect via the API composition layer using Cosmic's REST endpoints.

The practical result: the same agent session that scaffolds a new blog feature in your Next.js app can also create the corresponding content schema and seed objects in Cosmic. No context switching between your IDE and a separate CMS dashboard.

For a full setup guide, see Hosted MCP: Cosmic in Cursor, Claude, and Codex with Zero Install. For a deeper look at how MCP compares to Cosmic's Agent Skills, see MCP vs Agent Skills: What's the Difference and Which Do You Need?.

The Bottom Line

Claude Code, OpenAI Codex, and Cursor are all serious tools in 2026. The decision comes down to where you want the AI to live in your workflow.

Claude Code is the terminal-native agentic workhorse. Best for developers who want to stay in the CLI and let the agent handle the full PR lifecycle.
OpenAI Codex is the cloud-first async agent. Best for teams that want to assign task batches and review outputs without running anything locally.
Cursor is the AI-native IDE. Best for developers who want a single editor with AI at every layer and the freedom to switch models.

All three integrate cleanly with Cosmic via the REST API, the TypeScript SDK, and our hosted MCP server. The same agent that writes your code can manage your content.

Ready to connect your AI coding agent to a content layer that keeps up? Start for free on Cosmic or book a quick intro with Tony.

Building a Static Site with Astro and Cosmic CMS

Tony Spiro — Wed, 10 Jun 2026 20:10:57 +0000

Astro's HTML-first philosophy is having a moment. A post on Hacker News this week about doubling user growth by going HTML-first cracked the top 10 with 383 points, and the replies were full of developers reconsidering their stacks.

The short version: ship less JavaScript, get faster sites, keep more visitors. Astro is purpose-built for exactly this. And when you pair it with Cosmic as your content layer, you get a stack that is fast to build, fast to run, and easy for non-developers to manage content without touching code.

This tutorial walks through building a production-ready blog with Astro and Cosmic from scratch.

Why Astro + Cosmic

Astro generates zero-JavaScript HTML by default. Every page is a static file until you opt into interactivity with islands. That means:

Lighthouse scores in the high 90s out of the box
No hydration overhead for content pages
Content editors can update copy in Cosmic without a developer involved

Cosmic delivers content via REST API and the @cosmicjs/sdk. Your Astro build fetches content at build time, bakes it into static HTML, and serves it from a CDN. Fast, structured, and zero runtime CMS overhead.

Prerequisites

Node.js 18+
A free Cosmic account (sign up here)
Familiarity with TypeScript basics

Step 1: Create Your Cosmic Bucket

title (text)
slug (text, unique)
published_date (date)
teaser (textarea)
content (markdown)
image (file, image)

Add a few sample posts so you have content to render.

Step 2: Scaffold the Astro Project

npm create astro@latest cosmic-astro-blog
cd cosmic-astro-blog
npm install @cosmicjs/sdk

Choose the "Empty" starter when prompted. We'll wire up everything manually so you understand each piece.

Step 3: Initialize the Cosmic Client

Create src/lib/cosmic.ts:

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

export const cosmic = createBucketClient({
  bucketSlug: import.meta.env.COSMIC_BUCKET_SLUG,
  readKey: import.meta.env.COSMIC_READ_KEY,
});

Add your credentials to .env:

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

You'll find both values in your Cosmic bucket under Settings > API Keys.

Step 4: Fetch Posts at Build Time

Create src/pages/blog/index.astro:

---
import { cosmic } from '../../lib/cosmic';

const { objects: posts } = await cosmic.objects
  .find({ type: 'blog-posts' })
  .props('id,title,slug,metadata.teaser,metadata.published_date,metadata.image')
  .sort('-metadata.published_date');
---

<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <title>Blog</title>
  </head>
  <body>
    <h1>Blog</h1>
    <ul>
      {posts.map((post) => (
        <li>
          <a href={`/blog/${post.slug}`}>
            <h2>{post.title}</h2>
            <p>{post.metadata.teaser}</p>
          </a>
        </li>
      ))}
    </ul>
  </body>
</html>

Step 5: Generate Individual Post Pages

Create src/pages/blog/[slug].astro for dynamic routing:

---
import { cosmic } from '../../lib/cosmic';

export async function getStaticPaths() {
  const { objects: posts } = await cosmic.objects
    .find({ type: 'blog-posts' })
    .props('slug');

  return posts.map((post) => ({
    params: { slug: post.slug },
  }));
}

const { slug } = Astro.params;

const { object: post } = await cosmic.objects
  .findOne({ type: 'blog-posts', slug })
  .props('title,metadata');
---

<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <title>{post.title}</title>
  </head>
  <body>
    <article>
      <h1>{post.title}</h1>
      {post.metadata.image && (
        <img
          src={`${post.metadata.image.imgix_url}?w=1200&auto=format`}
          alt={post.title}
          width="1200"
          height="630"
        />
      )}
      <div set:html={post.metadata.content} />
    </article>
  </body>
</html>

Astro's getStaticPaths runs at build time, fetches all post slugs from Cosmic, and generates one HTML file per post. Zero runtime API calls.

Step 6: Handle Images with imgix

Cosmic stores all media on imgix, which means you get URL-based image transformations for free. Append query params to any image URL:

// Resize and auto-format for modern browsers
const heroUrl = `${post.metadata.image.imgix_url}?w=1200&h=630&fit=crop&auto=format`;

// Thumbnail
const thumbUrl = `${post.metadata.image.imgix_url}?w=400&h=300&fit=crop&auto=format`;

// WebP with fallback
const webpUrl = `${post.metadata.image.imgix_url}?w=800&fm=webp&q=80`;

No image processing pipeline needed. imgix handles it at the CDN edge.

Step 7: Deploy to Vercel

npm install -g vercel
vercel

Add your environment variables in the Vercel dashboard under Settings > Environment Variables:

COSMIC_BUCKET_SLUG
COSMIC_READ_KEY

Set up a deploy webhook in Cosmic (Settings > Webhooks) so every content publish triggers a new Vercel build. Your editors publish in Cosmic, the site rebuilds automatically, no developer involvement required.

Step 8: Enable Incremental Builds (Optional)

For larger sites, Astro's content collections combined with Vercel's ISR let you rebuild only changed pages. Configure in astro.config.mjs:

import { defineConfig } from 'astro/config';
import vercel from '@astrojs/vercel/serverless';

export default defineConfig({
  output: 'hybrid',
  adapter: vercel(),
});

Then mark individual pages for server-side rendering when you need fresh data, while keeping everything else static.

Performance Baseline

A default Astro + Cosmic blog with no optimization effort typically scores:

Performance: 95-100
Accessibility: 90+
Best Practices: 100
SEO: 90+

The main lever is images. Use imgix transforms and the loading="lazy" attribute on below-the-fold images and you'll stay in the green across the board.

Adding an AI Agent (Optional)

Once your Cosmic bucket has content, you can add a Cosmic AI agent to manage it. From the Cosmic dashboard, connect an agent to your bucket. It can draft new posts, update metadata, generate featured images, and publish on a schedule. Your Astro site rebuilds automatically via webhook every time the agent publishes.

This is what the HTML-first HN crowd is discovering: a static frontend plus an API-first CMS is the right architecture for AI-assisted content workflows. The agent writes to the CMS API. The static site rebuilds. No CMS logic in your frontend, no CMS vendor in your runtime.

What's Next

Add a search index with Pagefind (runs at build time, zero runtime JS)
Add RSS with @astrojs/rss
Add a sitemap with @astrojs/sitemap
Add an MCP server so AI assistants like Claude and Cursor can read and write your Cosmic content directly

Get Started

Free Cosmic plan includes 1 bucket, 1,000 objects, and 2 team members, enough to build and launch a full blog.

Start building for free or book a demo with Tony if you want to talk through your architecture.

Questions? Join the Cosmic Discord or check the Astro + Cosmic docs.

Build a DevOps Slack Agent with Cosmic: From "What Broke?" to PR in One Conversation

Tony Spiro — Wed, 10 Jun 2026 20:10:56 +0000

If you've ever been paged at 2am, opened Slack, typed 'what broke?' and then spent 20 minutes switching between terminals, dashboards, and GitHub tabs to figure out the answer, this tutorial is for you.

We're going to build a DevOps agent that lives in your Slack channel. When an engineer asks 'what broke in prod?', the agent:

Pulls recent access logs from your Vercel deployment
Identifies the error pattern (500s, failed routes, console exceptions)
Locates the relevant file in your GitHub repo
Creates a feature branch, commits a fix
Opens a PR with a clear description
Posts the PR link back in Slack, in the same thread

All of this happens in a single conversation turn. No context switching. No separate tools.

What You're Building

This is a Cosmic Team Agent with four capabilities enabled:

CMS Read so it can reference your content model if needed
Code Read to browse your repo, read files, check deployments, and pull access logs
Code Write to create branches, commit files, and open PRs
Send Notifications to post back to Slack with structured results

The agent connects to your Slack workspace and a GitHub repo via Cosmic's native integrations. No custom webhooks. No third-party glue.

Prerequisites

Before you start:

A Cosmic account (free tier works: cosmicjs.com)
A GitHub repo connected to a Vercel project
Slack workspace with the Cosmic Slack integration installed (Bucket Settings > Integrations)

Step 1: Create the Team Agent

Go to your Cosmic project and click Team Agents in the sidebar. Click Create Team Agent and fill in:

Name: DevOps Agent (or give it a human name, 'Morgan', 'Sam', etc.)

Persona prompt:

You are a DevOps agent for [your company]. You have access to production logs,
the GitHub repository, and Slack. When asked about production errors:

1. Call get_access_logs to check for recent 500s, 4xxs, or console errors
2. Identify the most likely root cause based on the error pattern
3. Use list_repository_files and read_file to locate the relevant code
4. Create a fix branch, commit a targeted change, and open a PR
5. Summarize what you found and what you changed in a clear Slack message

Be concise. Engineers are busy. Lead with the finding, then the fix.
If you cannot determine the root cause from logs alone, say so clearly
and describe what additional context you need.

Capabilities to enable:

Code Read (gives access to get_access_logs, get_deployments, read_file, list_repository_files)
Code Write (gives access to create_branch, commit_files, create_pull_request)
Send Notifications (for posting structured Slack messages)

Memory: Set to Persistent so the agent remembers recent incidents across sessions.

Step 2: Connect Your GitHub Repo

In the Team Agent edit form, look for the Repository section. Select your connected GitHub repo from the dropdown. If you haven't connected it yet, go to Project Settings > Integrations and add your GitHub repo first.

Once connected, the agent has access to all Code Read and Code Write tools scoped to that repository.

Step 3: Connect Slack

In the Channels section of the agent form, enable Slack and select the channel you want the agent to live in. A #devops, #engineering, or #incidents channel works well.

Optionally enable Only respond when @mentioned if you want the agent to stay quiet unless explicitly tagged. For a dedicated incidents channel, leave this off so the agent can respond to any message.

Save the agent.

Step 4: Test It

Go to your Slack channel and send a message:

what broke in prod in the last hour?

The agent will:

Call get_access_logs with time_range: "1h" and status_filter: "errors"
Parse the response for error patterns
Reply with a structured summary in Slack

Here's an example of what a response looks like:

Found 14 errors in the last hour:

• POST /api/contact — 11x 500 (11:42–12:03 PT)
  Console: TypeError: Cannot read properties of undefined (reading 'email')
  File: src/app/api/contact/route.ts, line 34

• GET /blog/[slug] — 3x 404
  No fix needed — these are likely stale links or bots probing old URLs.

Working on a fix for the contact route now...

Step 5: From Diagnosis to PR

After diagnosing the error, ask the agent to fix it:

go ahead and open a PR for the contact route fix

The agent will:

Call read_file on src/app/api/contact/route.ts
Identify the null-check that's missing
Call create_branch to create fix/contact-route-null-check
Call commit_files with the corrected version of the file
Call create_pull_request with a clear title and description
Post the PR URL back in Slack:

PR opened: fix(contact): add null check for email field before send
https://github.com/your-org/your-repo/pull/94

Changed: src/app/api/contact/route.ts
Added optional chaining on req.body.email before passing to the mailer.
Ready for review.

The entire flow, log pull, diagnosis, branch, commit, PR, Slack post, happens in under two minutes without the engineer leaving Slack.

Step 6: Wire Up the Cosmic SDK (Optional)

If your app pulls content from Cosmic (blog posts, product pages, documentation), you can give the agent CMS Read capability so it can cross-reference content changes with production errors. For example:

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

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

// Fetch recent published posts — the agent can check if a new publish caused an error spike
const { objects } = await cosmic.objects
  .find({ type: 'blog-posts' })
  .props('title,slug,published_date,metadata')
  .sort('-created_at')
  .limit(5);

With CMS Read enabled, you can ask the agent:

did the error spike correlate with any recent content publishes?

And it will cross-reference the access log timestamps with recently published objects to look for causation.

Extending the Agent

Once the base agent is working, here are three natural extensions:

Heartbeat schedule: Enable a daily heartbeat at 9am that posts a summary of the previous 24 hours of errors to Slack automatically. No one has to ask.

Event trigger on deploy: Connect an inbound webhook to the agent's webhook channel endpoint. Configure Vercel to POST to that webhook after each deploy. The agent will automatically check post-deploy logs and flag any new errors introduced by the deployment.

Escalation logic: Add to the agent prompt: 'If you find more than 20 errors in an hour, send an email to the project owner immediately.' The agent has send_email available and will follow this instruction.

What This Demonstrates About Cosmic Agents

This tutorial shows a pattern that goes beyond the DevOps use case: a Cosmic Team Agent as an operational interface to your stack.

The agent isn't a chatbot with pre-scripted answers. It reads live data, makes decisions based on what it finds, writes code, and takes action in external systems, all while staying inside the communication channel your team already uses.

The same pattern applies to customer support (reads your docs bucket, escalates in Slack), content operations (monitors your CMS, fires workflows on publish), and competitive intelligence (runs on a schedule, posts findings without being asked).

Agents that act are fundamentally different from agents that answer. This is the distinction that matters.

What to Build Next

Now that your DevOps agent is running, here are the next tutorials in this series:

Customer Support Agent (WhatsApp/Telegram): A Team Agent connected to WhatsApp with CMS Read on your docs bucket. Tier-1 support automation with human escalation.
Competitive Intelligence Agent: A Content Agent on a Heartbeat schedule that crawls competitor blogs and posts a Slack summary every Monday morning.
Localization Pipeline Agent: An event-triggered Content Agent that auto-translates new blog posts into Spanish, French, and German on publish.

Get Started

Ready to build your own DevOps agent?

Already have an account? Go to Team Agents

Want a walkthrough for your specific stack? Book 15 minutes with Tony

Or read the full agent documentation: cosmicjs.com/docs/dashboard/ai/agents