Home
May 21, 2026
View All

Anthropic Is Winning on Platform, and Karpathy Just Joined Them

·1 underrepresented voice

The Short Version#

Ravi Mehta has the sharpest framing I've seen for the OpenAI vs. Anthropic dynamic: Anthropic is winning at the platform layer while OpenAI competes at the model layer, and that distinction predicts enterprise spend better than benchmark scores. Pair that with Andrej Karpathy joining Anthropic, Teresa Torres running a real agent workflow every morning, and Cursor shipping Automations improvements, and the through-line today is clear: the people and companies taking AI seriously are building infrastructure, not just using features.

Ravi Mehta - OpenAI Has the Smarter Model. Anthropic Is Winning Anyway.#

Source: https://blog.ravi-mehta.com/p/openai-vs-anthropic Credibility: High (Ravi Mehta is a former Product VP at Facebook and Tinder; this is a first-person analysis post with specific strategic framing, not a hot take)

What happened: Mehta published a post arguing that Anthropic is capturing enterprise spend faster than OpenAI despite GPT models outperforming Claude on most public benchmarks. His core claim: OpenAI is competing at the model layer (who has the best outputs), while Anthropic competes at the platform layer (who makes it easiest to build reliable products on top of AI). That platform layer bet is winning where it counts, which is enterprise procurement.

Key strategic patterns:

  • Enterprise buyers don't optimize for raw capability, they optimize for predictability, trust, and integration depth. Anthropic's developer experience, API consistency, and Claude's Constitutional AI framing maps better to enterprise risk tolerance than OpenAI's faster-moving, more fragmented product surface.
  • Mehta introduces "harness PM" as a distinct emerging role: the PM who builds the infrastructure layer between foundation models and the product, rather than building features directly. This is less about prompt engineering and more about reliability, fallback design, and evaluation frameworks.
  • The product implication: companies treating foundation model selection as a pure capability question are optimizing for the wrong variable. Platform factors (SDKs, documentation quality, rate limit policies, trust and safety posture) compound over time.
  • Mehta suggests the current enterprise split will widen. Anthropic's strategy is designed for a world where models are roughly equivalent and differentiators live in the surrounding infrastructure.

Why it matters for PMs: If you're making a model provider decision for your product, Mehta's framework says benchmark scores are a secondary input. What you should be evaluating is: which provider has a platform I can build on reliably for 18 months, and whose trust posture maps to my enterprise buyer's concerns? That's a different RFP question than "which model has better evals." The "harness PM" concept is also worth sitting with. If your company is building meaningfully on top of AI, someone owns the harness. Either that's explicit in your org or it's nobody's job, which is a real organizational risk.

Critical questions:

  • Mehta's argument depends on enterprise spend data we can't fully verify. Is Anthropic actually winning on revenue, or just on developer mindshare and deployment conversations?
  • Is the "platform layer" advantage durable? OpenAI has dramatically improved its API reliability and developer experience in the last year. How much of the gap is structural vs. catchable?
  • The "harness PM" framing assumes your company is sophisticated enough to have a model abstraction layer. What does this mean for smaller teams who are just calling an API directly?
  • Does this analysis hold outside the US? Enterprise AI procurement in Europe may weight data residency and compliance over platform UX in ways that change the calculus.

Action you could take today: Write down your current model provider decision criteria. If your list is mostly capability and cost, add three platform factors: API reliability track record, SDK quality and maintenance cadence, and how the provider's trust and safety posture would sound in a procurement conversation with your most risk-averse enterprise buyer. Then see if your answer changes.

Teresa Torres - My Team of Agents: How I Get Claude to Do Tasks While I'm Away from the Computer#

Source: https://www.producttalk.org/my-team-of-agents/ Credibility: High (Teresa Torres is a product discovery coach and author of Continuous Discovery Habits; this is a first-person account of her actual workflow, not a hypothetical)

What happened: Torres published a piece about her working agent setup with Claude, describing how she's structured what she calls a "team of agents" that execute tasks while she's offline. The framing is practical and specific: each morning she wakes up to a to-do list Claude has already populated. If she has a podcast recording on the calendar, a "podcast manager" agent has already done prep work. These aren't automations in the traditional sense — they're agents with enough context and instruction to make judgment calls, not just run scripts.

Key workflow patterns:

  • Torres is running multiple specialized agents rather than one general-purpose assistant. Each agent has a scoped role (podcast manager, task manager, etc.) and operates within defined boundaries.
  • The workflow operates asynchronously — the agents work while she sleeps and report back, rather than requiring her to supervise in real time. This is a different interaction model than most PM use of AI, which is still mostly synchronous and interactive.
  • She's using Claude Code specifically (per the upcoming May 26 "Show and Tell" event she references), which means these aren't just chat prompts — they're more structured agent programs with file access and tool use.
  • The implication: effective agent use at this level requires upfront investment in defining agent scope, giving agents the right context, and trusting them enough to let them run unsupervised.

Why it matters for PMs: Most PMs using AI are still in "copilot mode" — asking questions, generating drafts, reviewing suggestions. Torres is describing "agent mode" — delegating work with the expectation that it gets done, not just started. That shift requires different mental models about what constitutes a good instruction, how to handle errors, and what it means to trust a non-human collaborator. For PMs building products: your users are still mostly in copilot mode, but the early adopters are moving toward agent mode. What does that mean for how you design the delegation experience, the error recovery path, and the confidence signals you show?

Critical questions:

  • How much setup time does this workflow require? The piece describes the outcome but the "how I built it" detail matters a lot for assessing replicability.
  • What breaks? Asynchronous agent workflows that run while you sleep are only useful if failure modes are surfaced quickly and clearly. What does Torres do when an agent produces something wrong?
  • This workflow is built by someone with deep product and AI fluency. What's the path for less technical PMs to get to this kind of setup, and is that path getting shorter?
  • How does this change her relationship to the work? There's a trust and ownership question here that isn't just a workflow question.

Action you could take today: Pick one recurring task you do every week that is mostly information gathering or prep (writing up meeting notes into a doc, compiling competitive updates, preparing a brief before a user research session). Write a prompt that gives an agent enough context to do that task unsupervised. Don't run it yet — just writing the prompt will reveal what context you're currently holding in your head that isn't written down anywhere.

Cursor - Improvements to Cursor Automations#

Source: https://cursor.com/changelog/05-20-26 Credibility: High (first-party changelog)

What happened: Cursor shipped a release that brings Automations into the Agents Window and adds the ability to configure automations with multiple attached repos or no repos at all. For the next 7 days, all agent runs for newly created Automations are 50% off.

Key technical details:

  • Automations are now accessible from the Agents Window, which means they're integrated into the same interface where you manage running agent tasks, rather than being a separate configuration surface.
  • Multi-repo support means a single Automation can operate across more than one codebase. This is significant for teams with monorepos or microservice architectures where a task might span multiple repos.
  • The "no repos" option lets you configure automations that don't require a codebase at all, opening Automations to non-coding tasks.
  • 50% discount on agent runs for new Automations this week is a clear adoption incentive to get teams to try the new multi-repo configurations.

Why it matters for PMs: Automations are Cursor's move toward scheduled and triggered agent workflows — not just "ask and answer" but "run this on a schedule or when X happens." Multi-repo support is the tell: Cursor is positioning Automations as an engineering workflow tool, not just a personal productivity feature. Teams managing multiple services or repos now have a plausible way to automate cross-cutting tasks (dependency audits, style checks, documentation updates) without building custom tooling. For PMs thinking about developer tooling: the interesting question is what the trigger and visibility model looks like for these Automations at scale. Who sees what's running? Who owns the results?

Critical questions:

  • What does error handling look like when an Automation fails mid-run, especially across multiple repos where partial completion could leave things in a bad state?
  • How does the multi-repo credential and permissions model work? Enterprise teams have strict access controls, and a cross-repo agent introduces real security surface area.
  • The 50% discount is a week-long adoption hook. Does this indicate Automations adoption has been slower than Cursor hoped?
  • How does this compare to GitHub Actions for the use cases where they overlap?

Action you could take today: If you use Cursor, check the Agents Window and create one new Automation for a repetitive task in your repo (even something small like running a linter or generating a summary of recent commits). The 50% discount this week makes it a low-cost experiment.

Quick Hits#

The Thread#

The platform layer is becoming the moat. Ravi Mehta's OpenAI vs. Anthropic analysis, Teresa Torres's agent workflow, and Cursor's Automations expansion all point at the same pattern this week: the teams and companies pulling ahead aren't the ones with access to the best models, they're the ones who've built reliable infrastructure around those models. Mehta calls this the "platform layer." Torres has turned it into a personal workflow. Cursor is building it into their product. The question for PMs isn't "which model is best?" anymore — it's "what's the harness?"

Sit With This#

Ravi Mehta's piece introduces the "harness PM" — the person who owns the platform layer between foundation models and the product. This is a real emerging role, but in most organizations it's either invisible or absorbed into engineering.

For your team: Does anyone explicitly own the harness at your company — the evaluation framework, the fallback design, the model provider decision criteria, the reliability layer? If not, whose job should it be, and what would you need to give them to do it well?