Home
Aug 7, 2026
View All

Perplexity Goes Multiplayer, AWS Tightens Agent Control

The Short Version#

Two things happening in parallel today: Perplexity is turning Computer into a team product with persistent memory and shared sessions, and AWS is shipping real control primitives for agent behavior — temporal policies, rate limits, data residency pinning. The theme is the same in both cases: individual AI tools are becoming infrastructure.

Perplexity - Projects Turns Computer Into a Multiplayer Agentic OS#

Source: https://x.com/AravSrinivas Credibility: High (direct announcement from Aravind Srinivas, Perplexity CEO, on the day of launch)

What happened: Aravind Srinivas announced Projects for Perplexity Computer — persistent memory, files, and sessions scoped across hubs and users. The pitch is explicit: this is "a multiplayer agentic operating system for work." Computer is no longer a personal AI tool. It's becoming shared infrastructure for teams.

Key capabilities:

  • Persistent memory that carries across sessions (not just per-conversation)
  • Files scoped to projects, not individual users
  • Sessions shared across hubs and users — actual multi-user context
  • Described as scoped "across hubs and users," suggesting org-level structure

Why it matters for PMs: This is the same playbook Wispr Flow ran when it shipped Team Dictionary and Team Snippets — take a sticky individual product and add just enough shared infrastructure to make it a team standard. The moment you can scope memory and files to a project that multiple people share, the tool stops being optional for individuals and starts being required for teams. That changes retention dynamics, purchasing dynamics, and competitive moat entirely. If you're building any productivity tool right now and it still lives entirely in the individual user's context, watch this move closely.

Critical questions:

  • How does shared memory actually work — who controls what gets written to project memory versus kept private?
  • What's the permission model across hubs and users? Who can read what?
  • Does this change Perplexity's pricing structure, or is it a tier add-on?
  • How does this compete with Notion's agent-adjacent features after the ZeroEntropy acquisition?

Action you could take today: Map out every place in your product where context resets between sessions or between users. That's the gap Perplexity is betting on. If you're building for teams, persistent cross-user memory is the feature that makes individual adoption into team lock-in.

AWS Bedrock AgentCore - Temporal Policies, Rate Limits, and Data Residency#

Source: https://aws.amazon.com/blogs/machine-learning/control-agent-behaviors-and-cost-beyond-a-single-action-new-capabilities-in-amazon-bedrock-agentcore/ Credibility: High (AWS machine learning blog, first-party announcement, multiple related posts published same day)

What happened: AWS shipped a cluster of new agent control capabilities in Bedrock AgentCore: temporal policies (using a new open-source policy language called Dogwood), rate limiting at the gateway level, and single-region data residency for Claude Code. These aren't product features for end users — they're the control plane for enterprises running agents in production. Temporal policies let you enforce rules based on session history, not just individual actions: think "don't approve a financial transfer unless a human review happened in this session" or "cap total spending across this agent's entire run."

Key technical details:

  • Temporal policies (Dogwood): Stateful rules that evaluate agent authorization based on session history. Enforces workflow sequencing, prevents fabrication, caps financial exposure. Dogwood is open source.
  • Rate limiting on AgentCore gateway: Per-user and per-target controls scoped by JWT claims or IAM identity. Defines request, token, and connection limits — protects downstream models and tools from traffic spikes.
  • Claude Code data residency: Two methods to pin Claude Code inference to a single AWS region (London example): application inference profiles or the Mantle endpoint, paired with IAM region conditions. Built for regulated industries.
  • AgentCore runtime instances now generally available — the underlying compute layer for running agents just hit GA.

Why it matters for PMs: This is the "enterprise AI is ready to actually buy" layer. The reason enterprise AI deployments stall isn't model quality — it's governance. "Can we cap how much an agent spends?" "Can we ensure data never leaves the EU?" "Can we require human approval before high-value actions?" AWS just shipped concrete answers to all three. If you're building on Bedrock or selling AI agents to regulated enterprise buyers, these primitives remove the blockers that kill deals in procurement. Also worth noting: Dogwood being open source means the policy language isn't AWS lock-in — it's a bet that the control model becomes an industry standard.

Critical questions:

  • How do temporal policies interact with agent frameworks that aren't LangGraph — can you bring your own orchestrator?
  • What's the latency overhead of evaluating temporal policies on every agent step?
  • Does the rate limiting apply at the model level, the tool level, or both?
  • How granular is the financial exposure cap — per-session, per-day, per-user?

Action you could take today: If you're shipping an AI agent feature to enterprise customers, write down the three governance questions your largest prospects always ask. Check whether AWS temporal policies or rate limiting addresses them directly — if yes, that's a procurement objection removed without building anything.

LangChain - Deep Agents vs. LangChain vs. LangGraph Explained#

Source: https://www.langchain.com/blog/deep-agents-vs-langchain-vs-langgraph Credibility: High (first-party LangChain blog, published August 7)

What happened: LangChain published a disambiguation post explaining when to use Deep Agents, LangChain, or LangGraph. Given that "Deep Agents" has been shipping fast (v0.7 a couple weeks ago), this is an important signal about how LangChain thinks about its own product portfolio — and more practically, it gives teams a framework for picking the right tool rather than defaulting to the most famous name.

Key patterns (based on what the post suggests):

  • Deep Agents: Higher-level abstraction, opinionated defaults, optimized for running agents end-to-end with less configuration
  • LangChain: The broad framework layer — chains, tools, retrieval, integrations — the building blocks
  • LangGraph: When you need explicit graph control over agent flow, human-in-the-loop steps, or complex state machines
  • These are complements, not substitutes — the post appears to address confusion from teams reaching for LangGraph when they need Deep Agents and vice versa

Why it matters for PMs: Most AI agent decisions PMs are involved in right now come down to "how much control do we need over the workflow?" The LangChain/LangGraph/Deep Agents split is actually a useful proxy: Deep Agents if you want fast and opinionated, LangGraph if you need to model a complex workflow with explicit states and human approvals, LangChain if you're assembling custom components. If your engineering team is debating which to use, this post is the answer key.

Critical questions:

  • Does Deep Agents lock you into LangChain's hosting or observability (LangSmith), or is it framework-agnostic?
  • At what scale or complexity does the migration from Deep Agents to LangGraph make sense?
  • How does this map to the AWS AgentCore temporal policy model — can you use LangGraph with Dogwood policies?

Action you could take today: Share this post with your engineering lead if you're mid-decision on agent framework. Ask them directly: which of these three matches our level of control requirements? The answer shapes everything from testing strategy to production observability.

Quick Hits#

The Thread#

The individual-to-team transition is the AI product story of this moment. Perplexity adding shared project memory to Computer, Wispr Flow shipping Team Dictionary last week, Vercel adding human approval gates to agent workflows — all of it is the same underlying move. Individual AI tools are useful but not sticky at the org level. The companies figuring out shared context, team-scoped memory, and human control points are the ones building products that procurement teams will actually buy.

Sit With This#

Perplexity just shipped persistent, cross-user memory scoped to shared projects. AWS shipped temporal policies that let you enforce "human approval must happen before this agent action." Vercel shipped a "pause for approval" gate in Chat SDK. All three are different answers to the same question: how much autonomy do you actually give an AI agent before a human needs to be in the loop?

For your product: If you're building or planning an agentic feature, where exactly does your agent hand off to a human? Is that handoff point based on user research, or is it based on what was easiest to build? How would you find out if you drew that line in the wrong place?