Home
Jun 19, 2026
View All

Cursor Automations, Stripe's AI Spending Data, and LangSmith Goes No-Code

The Short Version#

Cursor shipped always-on automation agents with GitHub and Slack triggers, Stripe published real consumer spending data on AI subscriptions, and LangSmith launched a no-code agent builder — three separate signals pointing at the same thing: the "AI as a feature you interact with" era is quietly giving way to "AI as a process that runs."

Cursor — Automations Get GitHub and Slack Triggers, Computer Use#

Source: https://cursor.com/changelog/06-18-26 Credibility: High (first-party changelog, shipped June 18)

What happened: Cursor 3.8 shipped meaningful expansions to Automations, the always-on agent layer they introduced earlier this year. The headline additions: a /automate skill you can invoke directly inside chats, new triggers for GitHub (PRs, issues) and Slack (messages, reactions), and support for computer use so agents can operate a browser or desktop app as part of a workflow. The framing is explicit — Automations are designed to handle repetitive tasks without you babysitting them.

Key capabilities:

  • /automate skill: invoke automation creation directly from a chat conversation, without leaving your current context
  • GitHub triggers: fire agents on PR creation, PR comments, issue creation, or issue labels
  • Slack triggers: fire agents on new messages or when a specific emoji reaction is added
  • Computer use support: agents can now interact with GUIs, not just code and files
  • Presumably builds on the cloud environment setup shipped in 3.7 (subagents running in isolated cloud envs)

Why it matters for PMs: The GitHub and Slack triggers are the real story here. They turn Cursor from a tool you open to a process that responds. A PR gets created, an agent reviews it. A Slack message hits a channel, an agent drafts a response or files a ticket. That's a fundamentally different product motion than "AI assistant you talk to." For PMs building on top of these platforms or managing teams that use them, this is a live preview of what agent-native tooling looks like when it matures. The question of how much autonomy users are comfortable giving agents (one of our open questions) gets pressure-tested here in a real product context — with real consequences if the agent does something wrong.

Critical questions:

  • How does Cursor handle agent errors in automated flows? Is there a review/approval step before actions are taken, or does it fire and forget?
  • What's the permission model for GitHub and Slack triggers — does the agent operate with full user permissions or a scoped service account?
  • Computer use in agent workflows has a high error rate across every product that's shipped it. Is Cursor gating this behind warnings, or is it presented as production-ready?
  • How does this interact with enterprise security policies? GitHub and Slack integrations for agentic systems are a procurement conversation, not just a technical one.

Action you could take today: If your team uses GitHub for PRs, map one repetitive review workflow (e.g., "check that new PRs have a linked ticket and pass linting") and test whether Cursor's GitHub trigger can handle it end-to-end. Note where it requires human intervention — that's your baseline for agent reliability in your specific context.

Stripe — What Link Data Tells Us About AI Spending#

Source: https://stripe.com/blog/industry Credibility: High (first-party analysis, published June 18, authored by Dan Hill, Product Manager on Link Consumer Product)

What happened: Stripe published a data-backed analysis of AI spending patterns across the 250 million customers passing through Link, their checkout network. This isn't a survey or a forecast — it's transaction data from real purchases. The piece looks at how consumers are actually spending on AI products, which categories are growing, what the payment patterns look like, and what this signals about the AI subscription economy.

Key details (from excerpt and title framing):

  • Data source: 250 million Link customers — this is actual checkout/payment behavior, not self-reported survey data
  • Focus: AI spending specifically, not general SaaS or software
  • Likely surfaces: which AI product categories are seeing fastest growth, average spend per user, churn or renewal signals, and possibly demographic patterns
  • Context: published by a PM on the Link consumer product team, suggesting the lens is consumer behavior rather than enterprise procurement

Why it matters for PMs: This is exactly the kind of evidence that's hard to come by: revealed preference data on AI spending from a payment network with massive coverage. Most "AI monetization" analysis is based on surveys or company-reported ARR. Stripe is showing you what people actually paid for. If you're making decisions about AI feature pricing, subscription tier design, or willingness-to-pay assumptions, this is primary source material. It also connects directly to our open question about whether users will pay for AI features or expect them free.

Critical questions:

  • Does the data break out subscription vs. one-time vs. usage-based purchases? The payment model matters a lot for product design.
  • Are there signals about trial-to-paid conversion or early cancellation that would tell us about AI product retention?
  • How much of the spending growth is new customers vs. existing customers upgrading? That distinction changes how you interpret "AI spending is growing."
  • Stripe has obvious selection bias toward products that use Link for checkout — does that over-index on consumer-facing or developer-adjacent AI products?

Action you could take today: Read the full piece at stripe.com/blog/industry and pull out any numbers that map to your current pricing assumptions. If you have a monetization review or roadmap discussion coming up, this is citable external evidence — not anecdote.

LangSmith — No-Code Agent Builder Goes Live#

Source: https://www.langchain.com/blog/langsmith-agent-builder Credibility: High (first-party announcement, published June 18)

What happened: LangSmith shipped an Agent Builder that lets you create, configure, and deploy agents without writing code. The builder supports memory, guided prompts, and MCP (Model Context Protocol) tools. This is a significant product shift for LangSmith, which has historically been an observability and evaluation platform for developers who are already building LLM applications. The no-code path opens it to a different user entirely.

Key capabilities:

  • Build agents visually without writing code
  • Agent memory: agents can retain context across conversations
  • Guided prompts: structured prompt templates within the builder
  • MCP tool support: agents can use MCP-compatible tools, which is becoming a de facto integration standard
  • Presumably connects to LangSmith's existing tracing and eval infrastructure, so agents you build are immediately observable

Why it matters for PMs: LangSmith moving into no-code agent building is a category expansion, not just a feature add. They're going from "platform for AI engineers" to "platform for anyone who wants to build an agent." That's a meaningful bet. For product teams, it changes the build-vs-buy calculus: if you can configure an agent in LangSmith without engineering time, the barrier to prototyping drops significantly. It also means the evaluation and observability infrastructure LangSmith already provides comes bundled with agents you build — which is a real advantage over pure no-code tools that give you no visibility into what's happening inside the agent.

Critical questions:

  • How does this compare to similar no-code builders (Zapier AI, Make, n8n AI nodes)? What does LangSmith offer that those don't?
  • What's the handoff path from no-code to code? If an agent outgrows what the builder supports, can you export it to LangChain/LangGraph and keep going?
  • MCP tool support is listed but vague — which MCP servers are supported out of the box, and what's the setup process for custom ones?
  • Who is the intended user? The messaging says "no technical expertise needed," but LangSmith accounts are developer-oriented. Is there a new GTM motion here?

Action you could take today: If you have a repetitive internal workflow that runs on text (weekly status summaries, ticket triage, meeting follow-ups), open LangSmith's Agent Builder and try to configure an agent for it. You'll learn more from 30 minutes of hands-on friction than from reading the launch post.

Quick Hits#

  • Pieter Levels: "In San Francisco everyone is saying software is commoditized by AI so smart people are moving to hardware" — a short field note from SF that captures a real sentiment shift worth tracking if you're thinking about where developer attention (and talent) flows next. (2026-06-18): https://levels.io/san-francisco-ai-commoditizing-software-hardware-shift

  • Noam Shazeer joins OpenAI: The co-inventor of the transformer architecture announced he's leaving Google and joining OpenAI. No product implications yet, but this is the kind of talent signal that tends to precede model architecture changes. (2026-06-18): https://x.com/NoamShazeer/status/2067400851438932297

  • Arthur Mensch / Mistral: Teased "a nice model coming this summer" that will be "fat indeed, but sparse" — a new model family with early access opening in July for partners in research, government, and industry. Sparse MoE architecture at larger scale is the inference cost story to watch. (2026-06-16): https://x.com/arthurmensch

  • Dare Obasanjo: Commentary on ChatGPT's market share dropping below 50% for the first time, noting that brand strength is carrying it more than product differentiation. Sharp read on what happens when a category leader faces commoditization pressure from below. (2026-06-16): https://mas.to/@carnage4life

  • OpenAI: Shipped new spend controls and usage analytics for ChatGPT Enterprise, giving orgs programmatic visibility into AI usage and cost. Small feature, big signal — this is the infrastructure enterprises need before they'll expand AI seat counts. (2026-06-18): https://openai.com/index/chatgpt-enterprise-spend-controls

The Thread#

Agents are shifting from interactive to autonomous. Cursor's GitHub/Slack triggers, LangSmith's no-code agent builder, and AWS AgentCore (covered earlier this week) all point at the same architectural bet: agents that run on events, not on prompts. The user is no longer the trigger — the system is. That's a different product to design, a different trust model to manage, and a different failure mode to handle. The question isn't "how do we make the AI more helpful when someone asks?" It's "how do we make the AI trustworthy enough to act before anyone asks?"

Sit With This#

Cursor's Automations now fire on GitHub and Slack events — meaning an agent can take action (comment on a PR, respond to a message, file a ticket) before any human reviews what it's about to do.

For your product or team: What's the threshold of consequence where you'd require a human approval step before an agent acts? Draw that line for one specific workflow your team runs today, and think about whether Cursor's current design respects it.