When Microsoft made its initial investment in OpenAI, the deal came with strings. Big ones. OpenAI’s models would be hosted exclusively on Azure. API access? Azure. Enterprise workloads? Azure. For years, that was fine. Microsoft poured in billions, OpenAI got the compute it needed, and Azure got to be the front door to the hottest AI on the planet.

But the landscape has shifted dramatically since then. And the constraints baked into that original partnership are starting to look less like guardrails and more like handcuffs.

The Multi-Cloud Reality

Here’s what the enterprise AI market looks like right now.

Microsoft Azure can host just about any model. They’ve got OpenAI’s models, obviously. But they’ve also brought in Anthropic’s Claude through Azure AI Foundry. GitHub Copilot, which is part of Azure Foundry, has become one of the most widely deployed developer tools in the enterprise. They’re hedging.

Google Cloud hosts Gemini natively, of course. But they also host Claude models through Vertex AI. Their platform is model-agnostic in practice, and developers and enterprises can mix and match.

Amazon Web Services has Bedrock, which hosts a whole ecosystem: Anthropic’s full Claude lineup, Amazon’s own Nova models, Meta’s Llama, Mistral, and more. It’s a buffet.

And then there’s Anthropic. Claude is now the only frontier AI model available across all three of the major cloud platforms: AWS Bedrock, Google Vertex AI, and Microsoft Azure Foundry. That’s not an accident. That’s a strategy. And it’s working.

The Enterprise Salesforce Advantage Nobody’s Talking About

Now, not to take anything away from Anthropic, because they’ve done a phenomenal job with their models. Claude Code has basically taken over every developer’s mind. It’s the most-used AI coding agent on the market, with roughly 46% of developers naming it their “most loved” tool in a recent survey of 15,000 engineers. Anthropic’s run-rate revenue has surpassed $30 billion, up from about $9 billion at the end of 2025.

But here’s the part that I think gets underappreciated: distribution through cloud seller networks.

Amazon, Microsoft, and Google each have tens of thousands of enterprise sellers. Account executives, solution architects, and partner teams, all of them incentivized to sell whatever runs on their platform. And since Claude is available on every major cloud, those sellers can position Anthropic’s models regardless of which hyperscaler their customer is on.

OpenAI doesn’t have that luxury. Their models can’t run on Google Cloud or Amazon in the traditional sense. Their API is exclusive to Azure. So the only enterprise sales force pushing OpenAI models at scale is Microsoft’s. And even Microsoft is now somewhat agnostic, having started offering Claude inside Office 365 and hiring Mustafa Suleyman to build their own in-house models.

Think about that for a second. You’ve got tens of thousands of enterprise sellers at three hyperscalers who can get paid on Claude deals. OpenAI? They’ve got Microsoft. That’s it. And even that relationship is getting complicated.

OpenAI’s Push to Break Free

OpenAI clearly sees this problem, which is why they struck the $50 billion deal with Amazon back in February. AWS is now the exclusive third-party cloud distribution provider for OpenAI Frontier, which is their enterprise platform for building, deploying, and managing teams of AI agents. The two companies are co-creating a “Stateful Runtime Environment” that would run on Amazon Bedrock, giving OpenAI models persistent context, memory, and identity within the AWS ecosystem.

This is OpenAI trying to build a harness around their models, something almost like a Claude Code equivalent, so they can get out from under the Azure-only constraint and actually reach enterprise buyers where they already live.

But here’s where it gets messy.

Microsoft believes this deal violates their exclusivity agreement. Their contract states that all stateless API calls to OpenAI models must be hosted on Azure, and Microsoft executives reportedly think the AWS arrangement crosses the line, both in spirit and in letter. People familiar with Microsoft’s position have been quoted saying, essentially, “We know our contract. We will sue them if they breach it.”

The legal argument hinges on a technical distinction: Microsoft’s exclusivity covers stateless API calls. OpenAI and Amazon are building a stateful runtime environment. Is that a legitimate architectural difference, or is it a clever workaround? That’s what lawyers, and potentially courts, will have to figure out.

I’m genuinely curious whether that contract holds up. Because the reality is that OpenAI is at a competitive disadvantage precisely because they can’t activate distribution into enterprise buyers the way Anthropic can. And they don’t have the sales force to do it single-handedly. They just don’t. You can’t go up against the combined weight of AWS, Google Cloud, and Azure seller networks with a direct sales team, no matter how good your product is.

The Why Cheaper Models Wasn’t The Right Strategy

I’ll be honest. I thought OpenAI’s play with smaller models was going to be the winning move. The nano, mini, small model strategy seemed smart because it’s been difficult to compete on price and performance at that level. OpenAI’s smaller models have had phenomenal intelligence relative to token price. And Anthropic always had Haiku, but it felt like the smaller models were where the real leverage was.

I was wrong. It’s been the race toward the frontier, the most capable and most intelligent models, that’s captured everyone’s attention and, more importantly, enterprise wallets. Opus 4.6, Sonnet 4.5: these models are what’s driving adoption. Anthropic got that right.

Now, I don’t think smaller models and frontier models are contradictory. There’s absolutely a place for small language models. When you’re talking about inline use cases like observability, telemetry, and email classification, things built on something like TinyBERT or other SLMs that need to run on CPUs locally, process quickly, and handle narrow data types, you don’t need a large language model. Fine-tuned SLMs are perfectly suited for that.

But for the enterprise buying decisions, for the platform bets, for the “which AI partner are we going all-in on” conversations happening in boardrooms right now? It’s the frontier models winning those deals. And Anthropic positioned themselves perfectly for it.

What Happens Next

So here’s the question: does OpenAI swing back?

If the Frontier platform on AWS actually launches and works, if they can build this stateful environment that gives enterprises the agentic AI capabilities they want, running natively in AWS, that changes the distribution math significantly. Suddenly OpenAI isn’t just a Microsoft story. They’re accessible through the world’s largest cloud provider, with Amazon’s massive enterprise seller network behind them.

And if they eventually expand to Google Cloud too? That would close the distribution gap entirely.

But that’s a big “if.” Microsoft isn’t going to let this go quietly. The contract dispute is real. The three companies are reportedly in talks to resolve it before Frontier goes live, but if those talks fail, we could be looking at litigation that reshapes how AI-cloud exclusivity agreements are written for years to come.

Meanwhile, Anthropic just keeps executing. They announced a partnership with Google and Broadcom to secure multiple gigawatts of next-generation TPU capacity starting in 2027. They’ve got over 1,000 enterprise customers each spending more than $1 million annually, double what they had just two months ago. Claude Code is authoring roughly 4% of all commits on GitHub. The flywheel is spinning.

The irony is that the deal that once gave OpenAI its biggest advantage, Microsoft’s compute and capital, may now be the thing holding them back from competing in the enterprise market that matters most. Distribution wins markets. And right now, Anthropic has it. OpenAI is fighting for it.

It’s going to be a fascinating year.

Between late 2025 and early 2026, the software engineering landscape shifted from basic “autocomplete” assistants to Agentic Coding Workflows. While tools like Cursor, Claude Code, and OpenAI Codex have reached record-breaking adoption and revenue, a significant “Productivity Paradox” has emerged, where developers feel faster despite objective debugging bottlenecks.

Subscribe now

1. Cursor’s “Hyper-Growth” Revenue Surge

Data: Cursor reached a $2 billion annualized revenue run rate (ARR) in February 2026.

• Trend: 60% of revenue now originates from enterprise-level deployments rather than individual pro-sumers.

• Insight: Companies are moving away from generic chat interfaces to AI-native IDEs that understand the full local codebase context.

2. The “Trust Gap” (Stack Overflow 2025-2026)

Data: 84% of developers utilize AI tools, yet 46% do not trust the accuracy of the output.

• Impact: This has led to the rise of “AI-gardening”—the specific skill set of auditing and refactoring AI-generated logic rather than writing original code.

3. Anthropic’s “Agentic Coding” Breakthrough

Data: Claude Code (March 2026 report) successfully completed complex extractions on the vLLM library with 99.9% numerical accuracy in 7 hours.

• Trend: The transition from “suggesting a line” to “executing a PR” is now the industry standard for senior-level AI agents.

4. The TypeScript Dominance (GitHub Octoverse)

Data: TypeScript has officially overtaken Python as the #1 language by monthly contributors.

• Trend: Developers are favoring TypeScript because its strict type system acts as a “safety net” for AI-generated code, catching potential hallucinations before they reach runtime.

5. The Productivity Paradox (METR Study)

Data: A February 2026 RCT found developers using AI tools were 19% slower on complex issues despite a 20% increase in perceived speed.

• Graphic Insight: High-velocity code generation often leads to longer code review cycles and subtle architectural “technical debt” that offsets initial time gains.

6. OpenAI Codex & GPT-5.4 Efficiency

Data: The March 2026 release of GPT-5.4 reduced token usage for background tasks by 47%.

• Trend: While Cursor dominates the “active” window, Codex remains the leader for asynchronous, multi-file maintenance tasks (e.g., automated dependency updates).

7. The “First Check” Advantage (Ramp Data)

Data: Anthropic now wins ~70% of new enterprise contracts over OpenAI for coding-specific use cases.

• Driver: The Model Context Protocol (MCP) has allowed Claude Code to integrate more seamlessly with proprietary corporate databases than its competitors.

8. SWE-bench Verified Performance (March 2026)

9. Regional Growth: The Rise of APAC

Data: The APAC market is growing at a 20.3% CAGR, with India showing trust levels in AI coding tools double those of the United States.

• Trend: Rapid integration of AI assistants into junior dev training programs in India and China is accelerating their “Time-to-Seniority.”

10. The Death of Shell Friction

Data: Usage of Shell/CLI-based AI agents increased by 206% in the last six months.

• Insight: Tools like Claude Code CLI have removed the “context switching” barrier, allowing developers to manage infrastructure and DevOps directly from the terminal via natural language.

  ---

Source & Reference Links

1. Cursor $2B ARR Analysis

2. Stack Overflow 2025/2026 Developer Survey

3. Claude Code “Agentic” Benchmarks

4. GitHub Octoverse 2025/26 Language Trends

5. METR 2026 Productivity Paradox Study

6. GPT-5.4 Efficiency & Codex Updates

7. Ramp Spending Analysis: OpenAI vs. Anthropic

8. SWE-bench Verified Leaderboard (Morph)

9. Nvidia State of AI Report 2026

10. Claude Code CLI & Terminal Usage Stats

A friend who built and sold a service business outside tech recently used Claude Code to build an entire back-office system for his new business. He isn’t a coder, just a high-agency individual—driven and always looking to learn new things. This was an eye-opening moment for me. If people outside of software engineering are building applications to run real businesses without the ability to code, it was time to double down on what’s possible.

Open a chat with Claude.ai to get started, here was the prompt i used.

I want Claude to help me build out webpage content based on google business profile categories. I’ve got a process documented with instructions on how to build the content. How should I set up the Claude code environment with skills, Claude.md, or other guardrails to act a system of agents working on the research and content creation, similar to a human agency?

Here is what Claude came back with:

Claude Code Environment Architecture

1. CLAUDE.md (Project Root)

This is your master orchestration file — think of it as the “agency playbook.” It should define:

• Project overview — what the system does (generates webpage content mapped to Google Business Profile categories)

• Agent roles — define distinct personas/responsibilities (more on this below)

• Workflow sequence — the order of operations from research → draft → review → publish-ready output

• Global rules — tone, brand voice, SEO constraints, output formats, quality standards

• File conventions — where inputs live, where outputs go, naming conventions

2. Skills as “Agent Specializations”

Create a /skills/ directory where each skill folder represents an agent role:

/skills/
├── researcher/
│   └── SKILL.md          # Instructions for category research, competitor analysis, keyword extraction
├── content-strategist/
│   └── SKILL.md          # Maps GBP categories to page structures, defines content outlines
├── copywriter/
│   └── SKILL.md          # Writes the actual page content following brand/SEO guidelines
├── seo-editor/
│   └── SKILL.md          # Reviews for keyword density, meta tags, schema markup, internal linking
├── qa-reviewer/
│   └── SKILL.md          # Final quality check — grammar, accuracy, brand compliance
└── templates/
    ├── service-page.md
    ├── location-page.md
    └── category-landing.md

Each SKILL.md should contain:

• Role definition — “You are acting as a [role]...”

• Inputs expected — what this agent receives

• Process steps — exactly how to do the work (paste your documented process here)

• Output format — structured deliverable (markdown, JSON, etc.)

• Quality criteria — what “done” looks like

3. Workflow Orchestration via CLAUDE.md

Define the pipeline explicitly:

## Workflow

### Phase 1: Research (skills/researcher)
- Input: GBP category name + business info
- Output: `/research/{category}-research.md` (keywords, competitor insights, search intent)

### Phase 2: Strategy (skills/content-strategist)
- Input: Research output + template
- Output: `/outlines/{category}-outline.md` (page structure, H1-H3, CTA placement)

### Phase 3: Draft (skills/copywriter)
- Input: Outline + brand voice guide
- Output: `/drafts/{category}-draft.md`

### Phase 4: SEO Review (skills/seo-editor)
- Input: Draft
- Output: `/drafts/{category}-seo-reviewed.md` (with inline comments)

### Phase 5: QA (skills/qa-reviewer)
- Input: SEO-reviewed draft
- Output: `/final/{category}-final.md`

4. Invoking It

When you run Claude Code, you’d prompt something like:

“Process the GBP category ‘Emergency Plumbing Service’ through the full content pipeline. Follow the workflow in CLAUDE.md, using each skill in sequence. Save all intermediate outputs.”

This gives you traceability (every phase produces a file) and the ability to intervene at any stage.

Below is the full system I built yesterday that created a sitemap, researched the google business profile categories, created internal and external links, reviewed the content for fact checking and no-ai readability, and outputted markdown files for uploading.

I highly recomend directing Opus 4.6 and directing it to leverage Sonnet 4.6 for sub-agents. The orchestration agent will continue to leverage Opus 4.6 for thinking and checking sub tasks. If Claude Code seem daunting to you, just open a chat with Claude.ai and start asking how to build a similar project. You’ll be shocked how much you can acomplish by asking.

Happy building!

How my Web Content System Works

This posts explains how the Handyman website content production system is built and how it turns a business profile into a full website’s worth of SEO-optimized pages.

Part 1: How CLAUDE.md and SKILL.md Files Work

What is CLAUDE.md?

CLAUDE.md is a plain-text instruction file that sits at the root of a project folder. When Claude (the AI) opens a project, it reads this file first — before doing anything else. Think of it as a playbook. It tells Claude what the project is, what rules to follow, and how to do the work.

In this project, CLAUDE.md defines:

• The site architecture — a template showing how pages are organized (homepage at the top, category pages below it, service pages below those, and so on)

• The production pipeline — seven phases that every page moves through, from planning to final review

• Content rules — reading level, sentence length limits, voice and tone, and a list of banned words and phrases

• Page types — five types of pages the system can produce, each with a different role and format

• How to run the system — commands for building a full site, adding pages, resuming mid-project, or checking progress

CLAUDE.md is the single source of truth. Every phase of the pipeline refers back to it. If a rule is in CLAUDE.md, it applies everywhere.

What are SKILL.md Files?

SKILL.md files are specialized instruction sets — one per phase of the pipeline. Each SKILL.md lives in its own folder under skills/. When Claude enters a specific phase of work, it reads the corresponding SKILL.md to know exactly what to do, what to check, and what to produce.

Think of CLAUDE.md as the company handbook and each SKILL.md as a job description for a specific role. The handbook applies to everyone; the job description tells one role exactly how to do its part.

This project has seven SKILL.md files:

Each SKILL.md contains the specific steps, templates, checklists, and rules that its phase requires. For example, the outline strategist’s SKILL.md contains four different outline templates — one for each page type — so the outline format automatically matches whether the page is a service page, a neighborhood page, or a supporting article.

Part 2: How the Project Processes Inputs Into Finished Pages

What Goes In

The system starts with three input files:

1. Client Profile (inputs/client-profile.md) — The business’s Google Business Profile data: business name, city, primary category, secondary categories, services offered, neighborhoods served, and landmarks nearby.

2. Authority Domains (inputs/authority-domains.md) — A list of approved websites (mostly .gov and .edu sources) that can be used for external citations. Each page gets one external link from this list.

3. Internal Links (inputs/internal-links.md) — An inventory of every page that has been completed so far, with its URL, title, and a short description. This file grows as pages are finished. New pages link to existing ones, and the inventory is updated so future pages can link back.

What Comes Out

For each page, the system produces files at each stage:

• research/{slug}-research.md — Research brief with PAA questions, local details, and competitor analysis

• outlines/{slug}-outline.md — Structured outline with H2/H3 headings, section purposes, and word targets

• drafts/{slug}-draft.md — Progressive draft built section by section

• drafts/{slug}-factcheck.md — Fact-check report listing every claim and its verification status

• drafts/{slug}-linked.md — Draft with internal and external links inserted

• final/{slug}-final.md — Production-ready content with meta tags, quality report, and similarity checks

The final file is what goes to the client. It includes the finished content, two to three meta title options, two to three meta description options, a quality report, and a status marker.

The Site Map

The site map (sitemap/sitemap.md) is the master tracking document. It lists every page in the site, its position in the hierarchy, its target keyword, its production status, and its linking relationships. The site map is created in Phase 0 and updated after every page is completed.

Part 3: The Seven Phases

Every page moves through the same seven-phase pipeline. Each phase has a specific purpose, a specific output, and a checkpoint before the next phase begins.

Phase 0 — Site Planning

Purpose: Turn the client’s business profile into a complete site architecture.

What happens:

• The site planner reads the client profile and maps every secondary category to a category page

• Every service is assigned to its parent category as a service page

• High-priority services that don’t fit neatly under one category are elevated to top-level pages

• Neighborhood and landmark pages are planned from the client’s service area

• Supporting content (educational articles) is planned for the highest-value services

• A production order is set — the most impactful pages are built first

• The full site map is saved and presented for approval

Output: sitemap/sitemap.md

Checkpoint: The site map must be approved before any pages are written.

Phase 1 — Research

Purpose: Gather everything needed to write a specific page.

What happens:

• The researcher checks the site map to understand where this page fits — its parent, its siblings, and its children

• Input requirements are validated based on the page type (service pages need PAA questions; neighborhood pages need geo targets; etc.)

• PAA (People Also Ask) questions are identified for the topic

• Local details relevant to McAllen and the Rio Grande Valley are gathered

• The page’s linking context is noted — what should link to this page and what this page should link to

Output: research/{slug}-research.md

Phase 2 — Outline

Purpose: Create a structured blueprint for the page before any writing begins.

What happens:

• The outline strategist reads the research brief and selects the correct template based on the page type

• Category pages get a template with service listing sections

• Service pages get a template with cause/solution sections, a DIY-vs-professional section, and an FAQ

• Neighborhood pages get a template focused on local housing stock and common service needs

• Supporting content gets a template built around answering a specific question in depth

• Every section in the outline has a purpose statement, a target word count, and notes on what to include

Output: outlines/{slug}-outline.md

Checkpoint: The outline must be approved before writing begins.

Phase 3 — Content Writing

Purpose: Write the page content section by section, following the approved outline exactly.

What happens:

• The content writer works through the outline one section at a time

• Every sentence must be 20 words or fewer

• Every paragraph is 2 to 4 sentences

• The reading level targets Grade 5-6

• The voice is “we/our” (the business) speaking to “you” (the reader) — practical, calm, and local

• A banned word list of 80+ words and phrases is enforced (no marketing fluff, no AI-sounding transitions)

• The similarity guard is active — if a sentence could appear on another page in the site, it gets rewritten with specifics

Output: drafts/{slug}-draft.md

Checkpoint: Each section is reviewed before the next one is written.

Phase 4 — Fact Check

Purpose: Verify every factual claim in the draft and add citations.

What happens:

• First pass: Every fact, statistic, measurement, and technical claim in the article is listed alongside its source

• Second pass: The draft is re-read to catch any facts that were referenced but not yet cited

• Unverifiable claims are flagged for removal or rewording

• Citations are added in numbered format (e.g., [1]) with full source details at the bottom of the page

Output: drafts/{slug}-factcheck.md (report) + updated draft with citations

Phase 5 — Link Curation

Purpose: Connect this page to the rest of the site and to one external authority source.

What happens:

• The link curator reads the site map to understand this page’s linking hierarchy:

  • Category pages link down to their child service pages

  • Service pages link up to their parent category and down to supporting content

  • Supporting content links up to its parent service page

  • Neighborhood pages link to relevant services and categories

  • Sibling pages can cross-link where it makes sense in context

• The internal link inventory is checked for all available link targets

• Links are inserted naturally within the content — no forced link blocks or lists

• One external link is selected from an approved authority domain (typically .gov or .edu)

• The internal link inventory is updated with this new page as a target for future pages

Output: drafts/{slug}-linked.md + updated inputs/internal-links.md

Phase 6 — Quality Review

Purpose: Final audit for AI detection risk, content quality, and production readiness.

What happens:

• AI detection assessment: The content is evaluated for patterns that make text sound AI-generated — uniform sentence length, hedge phrases, filler transitions, generic structure. If risk is elevated, specific rewrite strategies are applied (varying sentence rhythm, adding local specifics, breaking predictable patterns).

• Similarity check: The page is compared against every sibling page in the site map (pages at the same hierarchy level). Sentence-level overlap is flagged. The target is less than 20% overlap with any related page.

• Quality checklist (17 points): Reading level, sentence length, paragraph length, banned words, voice, geo mentions, price claims, keyword placement, internal links, external links, FAQ format, scope boundaries, and completeness are all verified.

• Meta tags: Two to three title options and two to three description options are generated with character counts.

Output: final/{slug}-final.md + updated sitemap/sitemap.md (page marked COMPLETE)

Summary

This system turns a single business profile into a complete set of website pages by running each page through a structured seven-phase pipeline. CLAUDE.md provides the rules and architecture that apply everywhere. Seven SKILL.md files provide the specific instructions for each phase. The site map tracks progress and relationships between pages. The internal link inventory grows as each page is completed, connecting the site together.

For this website, this system produced 44 pages: 4 category pages, 23 service pages, 7 neighborhood pages, 5 supporting content articles, and 5 additional service pages — all following the same pipeline, all cross-linked, and all checked against each other for quality and uniqueness.

Do you ever get kind of annoyed when something new comes out that’s supposed to help you? It’s just another thing you have to figure out when everything is working fine. Oh, that’s me this week. And Model Context Protocol, or MCP, is the tech du jour. So I wanted to figure out why everybody’s talking about it.

I think what made it real for me was when I was talking to a product manager about integrations, and I was saying, “Oh, of these three products, this one has the least amount of integrations, and therefore, you know, customers won’t want to use it as much because it’s not as useful.” And he said, “Well, in the era of MCP, that’s a moot point.” I said, “Okay, like why?” And so I wanted to unpack that a little bit and, uh, yeah, here we go.

So we’ll start off with what is MCP—how it’s being used in your toolkit today already. You don’t even realize it. And then, you know, as a GTM professional, if you’re working at a company, do you have MCP? How should you be positioning it? Should you be working on it, thinking about it, etc.? So here we go.

Subscribe now

Why MCP matters now

SaaS applications—especially AI-powered ones—are no longer valuable just because of what model they use, but because of what they can connect to:

• Business systems (CRM, ticketing, docs, repos)

• SaaS tools (Slack, Jira, GitHub, Google Drive)

• Internal APIs and proprietary data

• Real-time actions (create ticket, approve expense, deploy code)

LLMs without integrations are smart but blind. MCP exists to solve that gap in a standardized “easy button” way.

Before MCP

• Every integration was bespoke

• Each assistant hardcoded adapters

• Tool schemas, auth, and error handling were inconsistent

• High friction → fewer integrations

With MCP

• If a third-party app exposes an MCP server:

  • Tools are described in a standard way

  • Inputs/outputs are typed and self-describing

  • Capabilities are discoverable at runtime

• Platforms like enterprise assistants can integrate much faster

So —integrations become first-class citizens, not custom projects.

MCP examples in your GTM day-to-day

✅ Clay

How Clay uses MCP:
Clay has built (or partnered on) an official MCP server that exposes core CRM functionality—things like searching contacts, pulling interaction history, contact stats, and creating/updating records—via the MCP interface. This effectively lets AI assistants (e.g., Claude, ChatGPT with MCP support) directly query and manipulate your Clay data through natural language.

What that means in practice:

• Instead of manually exporting contact lists or writing API code, an AI model connected via MCP can fetch relevant contacts or generate insights for you.

• A model like Claude or ChatGPT can treat Clay as a tool it can call, just like any other external service.
  This aligns with MCP’s goal of reducing custom wrappers and letting agents use structured tool knowledge without bespoke connectors.

✅ Lovable

How Lovable uses MCP:
Lovable integrates MCP to connect its AI assistant with external team tools and data sources, letting the AI pull context like tickets, docs, issues, and specs from systems like Notion, Jira, etc., without separate custom integrations.

Specifically:

• Lovable has built built-in personal MCP connectors that act like adapters to third-party systems.

• When Lovable’s agent needs context—say project specs from Notion—that connector exposes relevant data via MCP to the model.

• On paid plans users can also deploy custom MCP servers to hook up any unsupported service.

Why this matters for Lovable users:
It lets the AI generate more accurate prototypes, suggestions, and automation because it’s reading real team context instead of guessing based on training data.

✅ Anthropic

How Anthropic uses MCP:
Anthropic is the originator of the Model Context Protocol — they designed MCP to standardize how AI systems connect to external tools and data sources.

In their products:

• MCP is used to let agents like Claude access real-time data and connected services securely, similar to how a developer would use an API.

• Anthropic’s own reference MCP servers cover things like file systems, enterprise services (Google Drive, Slack, GitHub, etc.).

• Latest updates include MCP Apps, which let external tools show interactive UI inside model contexts (not just back-end calls).

Broader ecosystem role:
Anthropic actively donates MCP to the Agentic AI Foundation, helping position it as an open standard that everyone — including direct competitors — can adopt.

✅ OpenAI

How OpenAI uses MCP:
Although OpenAI didn’t create MCP, they have officially adopted it across multiple products — including the ChatGPT desktop app, the Agents SDK, and the Responses API. This means OpenAI’s AI systems can discover and call MCP tools the same way other agent frameworks do.

What this looks like in real use cases:

• AI tools inside ChatGPT can connect to remote MCP servers (e.g., HubSpot’s or third-party MCP servers) to fetch data and perform operations.

• OpenAI’s involvement in the Agentic AI Foundation alongside Anthropic shows a broader commitment to standard, interoperable agent tooling.

✅ HubSpot

How HubSpot uses MCP:
HubSpot built a Remote MCP Server that exposes CRM data (contacts, interactions, company records, etc.) and actions to AI agents via MCP. They specifically highlight using this to integrate with ChatGPT without requiring local installs or manual configuration.

What each does with MCP

MCP concepts a SaaS GTM leader should understand (no engineering fluff)

1. MCP = agent-native integration

• Traditional integrations are app-to-app

• MCP integrations are agent-to-capability

• The “user” becomes an AI assistant acting on the customer’s behalf

Why this matters to you:

• Your product shows up inside ChatGPT / Claude / copilots

• You don’t need a custom deal per AI platform

2. MCP servers = capability access points for your SaaS

Think less:

“We integrate with HubSpot”

Think more:

“We expose create_campaign, analyze_pipeline, enrich_lead as callable capabilities”

Why this matters:

• GTM value is in verbs, not features

• The better the verbs, the more often agents call you

3. MCP clients = distribution platforms

Whoever controls the MCP client:

• Controls user attention

• Controls workflow orchestration

• Controls upsell and bundling

As GTM:

• You should know which platforms are MCP clients

• And which verticals they dominate (sales, marketing, dev, ops)

4. MCP collapses the “integration tax”

Historically:

• Integrations = long roadmap + heavy PM + slow adoption

With MCP:

• One MCP server → many agent platforms

• Faster partner launches

• Easier co-marketing

That’s a CAC and velocity unlock.

MCP Is Quietly Rewriting GTM Software

At first glance, MCP sounds like another technical standard best left to engineers. That’s a mistake.

MCP is not just a protocol. It’s a shift in how software gets discovered, integrated, and used—and it has direct implications.

Last week, the USD.AI protocol publicly launched a set of core products and its governance token, $CHIP. If you saw the announcement but weren’t sure what it means — here’s a straightforward breakdown.

(Source: official USD.AI launch announcement)(X (formerly Twitter))

🧱 1. What Is USD.AI Aiming To Do?

USD.AI is a decentralized finance (DeFi) protocol seeking to unlock capital for AI infrastructure financing — particularly expensive computing hardware like GPUs — by using crypto liquidity in a structured way.(CoinDesk)

This isn’t about speculative tokens. It’s trying to marry stable, dollar-like assets with productive lending to real compute infrastructure (an area that historically has had trouble accessing traditional capital markets).

💵 2. The Two Tokens: USDai and sUSDai

The launch centers on two related but different tokens:

🟢 USDai

• A stablecoin, designed to stay close to $1.

• Think of this as a synthetic digital dollar within the USD.AI ecosystem.

• You don’t earn yield just by holding USDai.

• USDai is the base layer — stable, liquid, and widely usable — but yield-free by design. (docs.usd.ai)

What backs USDai?
According to protocol details, funds backing USDai are often held in short-term U.S. Treasury instruments while the protocol prepares them for productive deployment. This helps avoid “cash drag” while capital waits to be allocated. (docs.usd.ai)

🔷 sUSDai

• This is the yield-bearing version of USDai.

• To earn anything, holders must convert USDai into sUSDai (typically by staking).

• The value of sUSDai accrues yield over time, which is not paid directly as cash but reflected in the rising redemption value of each sUSDai.(IQ.wiki)

Where does the yield come from?
It comes from revenue-generating activities the protocol finances:

• Loans backed by AI compute hardware

• Productive uses of deployable capital beyond just cash investments

• Interest paid back into the protocol that’s shared with sUSDai holders

The goal is to earn more than what short-term Treasurys would deliver, though returns are variable and not guaranteed. (CoinDesk)

🧠 3. So What Happens Under the Covers?

In simple terms: the protocol accepts stablecoin deposits → monetizes them through structured finance → and distributes a share of the economic return to sUSDai holders.

Behind the scenes the architecture has a few components:

• Treasury management for idle funds
  When capital isn’t actively deployed, it may be held in instruments like Treasury bills to avoid losing yield while waiting for productive use.(docs.usd.ai)

• Credit deployment to AI infra
  Qualified operators can access liquidity using hardware as collateral. This segment is where the anticipated yield originates.(CoinDesk)

There are mechanisms (like legal asset tokenization and structured risk tranches) that try to align incentives and manage counterparty risk, but this is fundamentally a credit-linked system, not a traditional money market.

🗳️ 4. What Is $CHIP?

$CHIP is the governance token of the USD.AI DAO (Decentralized Autonomous Organization).(X (formerly Twitter))

Think of it as voting power and protocol influence:

• Holders can vote on protocol parameters

• They decide which initiatives the ecosystem supports

• They influence risk frameworks and future expansions

$CHIP does not pay yield. It’s governance, not revenue-sharing.

📌 Why This Matters (And What to Watch)

This launch tells you a few things about the trajectory of new financial infrastructure:

1. Stablecoins are evolving
   They’re no longer just digital dollars backed by cash or Treasurys; some are being tied to productive economic activity.

2. Capital markets for AI infrastructure are emerging
   Instead of banks or VCs exclusively underwriting GPU financing, crypto-native liquidity can flow into this layer.

3. Returns are not guaranteed
   Yield-bearing tokens like sUSDai accrue return over time, but that depends on how well the underlying financed assets perform. It behaves more like a credit investment than a savings account.

4. Governance is decentralized
   With $CHIP, USD.AI is pushing decision-making toward a tokenholders’ collective, rather than a centralized board.

🧾 In Plain Terms for Risk-Aware Readers

• USDai is a digital dollar in this ecosystem — stable and used to participate.

• sUSDai is the investment instrument — it’s meant to earn yield by backing productive real-world capital.

• $CHIP is governance, not a payout token.

• Funds flow through structured financial engineering, not traditional deposit/lending.

This is essentially a credit vehicle wrapped in digital assets, marketed with stablecoin terminology. It’s innovative, but it will attract scrutiny from traditional capital allocators as they evaluate risk, liquidity, and regulatory clarity.

Working with people who are building agents, part of my role is to help them navigate this constantly changing landscape while staying on schedule to release key features. My recent focus has been on understanding agent runtime platforms and how they work with popular frameworks like LangChain/LangGraph, CrewAI, and OpenAI Agents.

The Brain vs. Body Analogy

To a semi-technical audience, the best way to distinguish these is to think of them as the “Brain” vs. the “Body”:

The Frameworks (LangGraph, CrewAI, etc.) are the “Brain”
They define the logic, the personality, and the decision-making process.

Agent Runtimes (like AWS AgentCore) are the “Body”
They provide the physical infrastructure, the security, the memory, and the environment where that brain operates.

What Are Agent Runtimes?

One prominent example is Amazon Bedrock AgentCore, a collection of seven primitives (basic building blocks) for agentic applications. I’m most familiar with this platform, so I’ll use it as the reference model to help us understand the tech stack. The idea is: once we understand a single platform and framework ecosystem in depth, we can swap in other third-party, open-source, or managed offerings.

Key Difference: Agent Runtime vs. Framework

AgentCore (Runtime) is a managed runtime and control plane, not a coding framework. It runs agents in production with scaling, isolation, security, memory, and observability handled for you.

Frameworks (LangGraph, Strands Agents, etc.) are developer libraries that define:

• Agent logic and loops

• Planning and tool-calling patterns

• Multi-agent coordination

In simple terms:

• Frameworks = how you write agents

• AgentCore = where and how agents run in production

How They Work Together

AgentCore hosts and operates agents built with frameworks:

1. You build logic in LangGraph, CrewAI, OpenAI Agents, or Strands Agents

2. You deploy them into AgentCore

3. AgentCore executes steps, manages state, enforces IAM, scales, and emits telemetry

4. Observability tools like Langfuse can be layered on top for deeper tracing and evaluation

Bottom Line

An agent runtime like AgentCore doesn’t replace frameworks—it makes it easier to productionalize and host the agents you’ve built at scale.

It’s important to note there are many runtime alternatives. I see many customers running their agentic applications on virtual machines and containers, but you can also look at hosted open-source or proprietary solutions. The key consideration when choosing your runtime is that it supports a broad range of agentic frameworks and observability options.

Top Runtime Options (January 2026)

Managed / Cloud Runtimes (Production-Ready)

• AWS Bedrock AgentCore — AWS’s managed production runtime (framework-agnostic)

• Google Vertex AI Agent Builder / ADK — Cloud-native agent runtime with integrated tooling & deployment

• Microsoft Azure AI Foundry Agents — Enterprise agent service combining AutoGen + Semantic Kernel with identity & governance

• OpenAI Assistants / Agent services — Managed agent hosting tied to OpenAI ecosystem

Open-Source / Developer Frameworks

These are libraries and frameworks you run yourself or embed in your apps:

• LangGraph — Leading open-source orchestration and workflow engine

• OpenAI Agents SDK — Lightweight, model-agnostic agent framework

• Microsoft AutoGen + Semantic Kernel — Multi-agent orchestration stack (often paired with Azure)

• CrewAI — Role-based multi-agent coordination

• Strands Agents (AWS open source) — AWS’s self-managed agent framework with strong AWS service integration

• LangChain & related libraries — Broad ecosystem for agents, RAG, and workflows

*These thoughts and opinions are my own and not affiliated with any employer.

**Images created with ChatGPT.