Home
Jun 20, 2026
View All

AI Agent Infrastructure Is the Real Story Right Now

·1 underrepresented voice

The Short Version#

Three separate companies shipped or expanded agent infrastructure this week — AWS AgentCore harness, Cursor Automations, and Notion's Custom Agents learnings — and the pattern is clear: the platforms are doing the hard scaffolding work so product teams don't have to. Meanwhile, Stripe published real consumer spending data on AI, and Arthur Mensch made his open-source positioning explicit in a way that matters for enterprise PMs evaluating model providers.

AWS Bedrock AgentCore Harness — From Prototype to Production in Two API Calls#

Source: https://aws.amazon.com/blogs/machine-learning/amazon-bedrock-agentcore-harness-is-now-generally-available-go-from-idea-to-production-grade-agent-in-minutes/ Credibility: High (first-party AWS announcement, GA launch)

What happened: AWS shipped the general availability of AgentCore Harness, a managed service that lets you go from agent idea to production in literally two API calls. CreateHarness defines the agent, InvokeHarness runs it. The agent gets its own isolated environment with a filesystem and shell, so it can read files, run commands, and act autonomously — without you building any of that scaffolding yourself. Same week, AWS also shipped Web Search on AgentCore as GA, meaning agents can now browse the live web natively as a built-in tool rather than a custom integration.

Key capabilities:

  • Two-API entrypoint: CreateHarness + InvokeHarness to deploy a working agent
  • Isolated execution environment (filesystem, shell access) included out of the box
  • Web Search now GA as a native AgentCore tool — agents can query the live web with a few lines of code
  • Positioned as the path forward after Vertex AI Extensions deprecation (Google is also shutting down their equivalent, pushing users toward Agent Platform)

Why it matters for PMs: The scaffolding work for agents — sandboxed environments, tool access, execution isolation — has been the real build cost that kept agent features expensive to ship. AWS just commoditized most of it. If you're building on AWS and evaluating whether to build agent infrastructure in-house or use a managed layer, this changes that calculus significantly. The two-API model also lowers the barrier for prototyping: your engineering team can test an agentic feature concept in hours, not weeks. The simultaneous GA of Web Search means agents that need live information (pricing lookups, news summarization, research tasks) are much more viable without custom web-scraping pipelines.

Critical questions:

  • What are the actual cold-start and latency characteristics of isolated harness environments? Agents that need to feel "instant" may still need custom infrastructure.
  • How does pricing compare to running your own agent on EC2 or Lambda? The convenience premium could be significant at scale.
  • What are the security boundaries — can agents in one harness affect another? Enterprise customers will ask.
  • Is this composable with your existing LangChain/LangGraph or Mastra setup, or does adopting AgentCore mean committing to the AWS agent ecosystem?

Action you could take today: If your team has an agent prototype sitting in a Jupyter notebook or a proof-of-concept that never made it to production because the infra work felt too heavy, pull up the AgentCore Harness docs and estimate what a two-week spike would look like to productionize it on this stack.

Cursor Automations 3.8 — Always-On Agents with GitHub and Slack Triggers#

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

What happened: Cursor's 3.8 release significantly expands Automations — their "always-on agents" feature — with three things that matter: a /automate skill for creating automations directly inside an agent conversation, new GitHub and Slack triggers (so agents can respond to PRs, issues, or Slack messages without a human in the loop), and support for computer use. This is Cursor moving from "AI coding assistant" toward "AI coding coworker that acts on your behalf while you're doing other things."

Key technical details:

  • /automate skill: describe what you want automated inside a chat, and Cursor creates the automation
  • GitHub triggers: agents can fire on PR events, issue creation, or repo changes
  • Slack triggers: agents can listen and respond to Slack messages, closing the loop between communication and code
  • Computer use support: agents can operate the UI directly, not just the editor

Why it matters for PMs: This is the agentic coding assistant story crossing a meaningful threshold. The difference between "Copilot helps me write code" and "an agent that watches my GitHub and handles routine PR review or issue triage while I focus on harder problems" is significant. For product teams using Cursor, this is a workflow shift worth running an experiment on — particularly for repetitive tasks like dependency updates, documentation generation, or test coverage gaps. The Slack trigger is the most interesting piece: it creates a path where a developer says something in Slack and the agent takes action in the codebase without a context switch.

Critical questions:

  • What's the error recovery story when an automation does something wrong to a repo? Undo / rollback mechanisms matter a lot before trusting this with real code.
  • How are Automations priced — per trigger, per run, or bundled into the existing subscription?
  • What audit trail exists for actions taken by always-on agents? Enterprise compliance will require this.
  • Is computer use scoped to the Cursor environment or can agents reach outside (browser, system)?

Action you could take today: If your team uses Cursor, pick one genuinely repetitive coding task — a lint check, a changelog update on merge, or a specific Slack alert — and try setting it up as an Automation using the /automate skill. Timebox to 30 minutes and see if the setup UX actually delivers on the "create automations naturally" promise.

Notion — What They Learned From the Custom Agents Beta#

Source: https://www.notion.com/blog/what-we-learned-during-the-custom-agents-beta Credibility: High (first-party Notion post, post-beta retrospective from co-founder Akshay Kothari)

What happened: Notion's co-founder Akshay Kothari published a retrospective on what the Custom Agents beta taught them. Custom Agents are Notion's "AI teammates that handle entire workflows autonomously" — the premise being that repetitive work gets offloaded to agents while humans focus on judgment-heavy tasks. The post is a retrospective on what actually worked and what didn't during the beta, which is rarer and more useful than a launch announcement.

Key patterns (based on what the excerpt reveals):

  • Agents were described as handling "entire workflows autonomously" — the framing is teammate, not tool
  • The beta was specific enough to generate learnings worth publishing, suggesting real usage with real edge cases
  • Notion framed the outcome as: agents take repetitive work, humans handle what "needs you" — a clear positioning choice that shapes user expectations

Why it matters for PMs: Notion publishing beta learnings matters more than the feature itself. Any PM thinking about how to run an AI agent beta can learn from this: Notion ran it constrained enough to get real signal, scoped it to workflow automation rather than open-ended AI, and named the core design principle (humans handle what needs humans) before shipping broadly. That principle is actually a product decision with UX implications — it sets expectations, constrains scope, and tells users where the agent should stop and ask. If you're designing an agent feature, what's your equivalent of "this needs you" — the trigger that hands back control?

Critical questions:

  • What failure modes did the beta surface? A retrospective that only describes wins is marketing; real learnings include what broke.
  • How did users discover which workflows were good candidates for agents? Discovery design for agent features is underexplored.
  • What does "entire workflows autonomously" actually mean in Notion's context — is the agent reading and writing Notion pages, or executing steps in external tools?
  • How did Notion handle trust and verification — did users review agent actions before they were committed?

Action you could take today: Read Kothari's full post and map their framing ("this needs you") to a current AI feature on your roadmap. Write down explicitly: what is the trigger that hands control back to the user in your feature, and is that trigger surfaced clearly in the UX?

Stripe — What 250 Million Customers Are Actually Spending on AI#

Source: https://stripe.com/blog/industry Credibility: High (first-party data from Stripe Link, 250 million customer dataset, authored by Dan Hill, PM on Link Consumer Product)

What happened: Stripe's Link Consumer Product team published an analysis of AI spending patterns across 250 million customers who pay through Stripe Link. This is the closest thing to a ground-truth view of consumer AI monetization — not survey data, not signups, but actual payment transactions. Dan Hill (PM) authored the piece, making this a PM-to-PM signal on what the numbers actually say.

Key data (from excerpt):

  • Dataset: 250 million Stripe Link customers and their spending patterns across AI products
  • Focus: How consumers are actually spending on AI, which categories are seeing wallet share, and what the payment patterns look like

Why it matters for PMs: Consumer AI monetization is the question everyone has an opinion on and almost nobody has data for. Stripe has the data. Even if the findings feel confirmatory ("people pay for ChatGPT and Midjourney subscriptions"), the payment-level view will likely surface nuances that surveys miss — things like churn rates implied by subscription cancellations, price sensitivity signals from failed payment retries, or which AI categories are seeing expanding vs. contracting spend. For any PM building a consumer AI product and making pricing decisions, this is primary source material.

Critical questions:

  • Does the data break out subscription vs. one-time purchase patterns? The business model question matters as much as the spend level.
  • Is the spending concentrated in a few large platforms (OpenAI, Midjourney) or distributed? Market concentration shapes the opportunity for new entrants.
  • What's the geographic spread? AI spending patterns likely vary significantly across markets.
  • Does Stripe segment by user demographics or income level? Willingness-to-pay for AI is not uniform.

Action you could take today: Read the full Stripe blog post (it's short and data-forward) and compare whatever AI price point you're considering to the spending patterns Stripe describes. If your product is priced above the average AI subscription in the data, what's the justification?

Quick Hits#

  • Arthur Mensch (Mistral): Posted on LinkedIn that Mistral "exists to make sure that everyone gets access to the best AI systems, outside of centralised control exercised by states or corporations." This came in the context of the Anthropic export control situation. Clear competitive positioning — if you're evaluating Mistral vs. US-based providers for enterprise use, Mensch is making the sovereignty argument explicitly. (June 17, 2026): LinkedIn (referenced in Sifted)

  • Ben Tossell: Critiques AI software quality using Perplexity as a case study — promised capabilities (restaurant reservations, reminders) don't actually work reliably across locations. The gap between what AI assistants claim to do and what they do reliably is still wide, and this is the kind of user-facing failure that erodes trust fast. (June 19, 2026): https://x.com/bentossell/status/1915392814390694184

  • Simon Willison: GLM-5.2 is "probably the most powerful text-only open weights LLM" — Willison's take on a Chinese open-weights model that's worth watching if you're doing build-vs-buy evaluation for LLM-powered features. Open weights at this quality level changes what's viable to self-host. (June 17, 2026): https://simonwillison.net/2026/Jun/17/glm-52/#atom-everything

  • Figma: Enterprise customers now get an AI credit usage API — you can query AI credit consumption programmatically. Small but meaningful for any org admin trying to manage AI feature costs at scale. (June 17, 2026): https://developers.figma.com/docs/rest-api/ai-usage/

  • Melissa Perri (Product Thinking Podcast, Ep. 270): Episode on what it actually takes for experimentation to become culture — covering leadership behaviors, portfolio decisions, and how to tell real experimentation from theater. (June 3, 2026): https://www.produxlabs.com/product-thinking

The Thread#

The scaffolding layer is being built, and fast. AWS, Cursor, and Notion all shipped or reflected on agent infrastructure this week — not agent features, but the layer underneath: isolated execution environments, always-on triggers, workflow handoff patterns. The pattern from earlier this week (LangSmith's no-code agent builder, Vercel's eve framework) continues here. Platforms are racing to own the scaffolding so teams can skip straight to the use case. The risk for product teams: the scaffolding choices you make now (AWS vs. Vercel vs. LangChain vs. custom) are likely to have meaningful lock-in implications once agents are production workloads.

Sit With This#

Notion's Akshay Kothari framed their Custom Agents design around a single principle: agents handle the repetitive work, humans handle "what needs you." That's not just a tagline — it's a scope decision with direct UX consequences. It determines where the agent stops, what triggers a handoff, and what users are responsible for reviewing.

For your current roadmap: Pick the AI feature closest to shipping on your team. Write down one sentence that completes this: "The AI handles X, the human handles Y." If you can't write that sentence clearly, you haven't made the scope decision yet — and your users will feel that ambiguity when they use it.