By playing, you agree to uListen's Terms and Privacy Policy and YouTube's Terms of Service.

Sequoia Capital

Anthropic's Katelyn Lesse & Angela Jiang: Building an Ecosystem, not a Walled Garden

Katelyn Lesse and Angela Jiang lead the team building Anthropic's developer platform - the layer that both outside builders and Anthropic's own products run on top of.

Angela JiangguestSonya HuanghostKatelyn LesseguestLauren Reederhost

Jul 14, 202648mWatch on YouTube

Summaries, chapters, transcripts, and FAQs on this page are made by uListen, not YouTube.

CHAPTERS

Jump to publisher timestamps

Chapter summaries

Anthropic Platform scope: external APIs plus internal product infrastructure
The hosts ask where Anthropic’s Platform team sits and what it owns. Katelyn Lesse explains the team builds the externally facing APIs developers use to access Claude, while also running the internal platform layer that Anthropic’s own apps rely on.
- •Platform includes both developer-facing APIs and internal infrastructure
- •External users build applications and systems that access Claude’s intelligence
- •Internal product teams build on the same platform layer
- •The conversation sets up Platform as both an external product and an internal enablement function
Two North Stars: internal shipping speed and external builder empowerment
Angela Jiang describes having two guiding goals because the team serves both internal and external builders. Internally the emphasis is on leverage and speed for shipping reliable products; externally the goal is giving any builder the tools to build what they want with Claude, including close integration with hyperscalers and ecosystem standards.
- •Internal focus: maximum leverage and speed for teams shipping products
- •External focus: enable any builder with tools to work with Claude
- •Platform aims to be close to where businesses run, including hyperscaler integrations
- •Tools can be primitives/APIs, higher-order abstractions, or standards like Skills and MCP
What to externalize: shared primitives, avoid over-indexing on internal needs
Lauren asks how the team decides what belongs in the platform and what to expose. Angela and Katelyn explain they try to keep internal and external primitives aligned, because AI form factors change quickly and the platform should let many builders experiment; they also dogfood internally while running early access with external users to avoid bias.
- •Philosophy: keep internal and external primitives as consistent as possible
- •Reasoning: form factors evolve fast, and the platform should be robust across shifts
- •They don’t assume Anthropic will be the only group discovering winning form factors
- •They dogfood internally while running external early access to gather diverse feedback
From stateless messages to agentic abstractions: why higher layers emerged
Katelyn recounts that the platform was once largely a stateless messages API and developer tooling. As models became better at longer-running work, both customers and internal teams repeatedly rebuilt the same agent infrastructure, motivating Anthropic to package primitives into higher-order offerings that handle infrastructure and harness engineering out of the box.
- •Earlier platform centered on a stateless messages API
- •Customers and Anthropic repeatedly solved similar problems for long-running agents
- •Higher-order abstractions target infrastructure needs (sandboxes, governance, storage, resumable sessions)
- •They also package harness concerns: prompt caching, context management, intelligence extraction, and cost management
Who uses primitives vs managed offerings: startups vs enterprises
Sonya asks how often customers choose managed agents versus a “grab bag” of platform components. Angela says AI-native startups tend to work at the primitive layer, while enterprises and workflow-focused teams prefer higher-order packaged offerings because harness/infrastructure optimization isn’t their core competency.
- •AI-native startups often choose low-level primitives for tinkering and experimentation
- •Enterprises and workflow-focused teams often prefer higher-order packaged offerings
- •The difference is tied to whether optimization is a core competency or not
- •Adoption varies by user group and product philosophy
The three-layer cake: knowledge, execution, and coordination
Angela introduces a three-layer framing for platform primitives. She describes a knowledge layer (messages API shapes, tools, skills, memory), an execution layer (harness + managed infrastructure, including Claude Managed Agents), and an emerging coordination layer that composes strategies across token “jobs.”
- •Knowledge layer: primitives that reflect how Claude works (messages API, tool calls, Skills, memory)
- •Execution layer: making Claude do work requires harnesses plus infrastructure; Claude Managed Agents is the flagship product here
- •Coordination layer: composing strategies that orchestrate different roles across tokens
- •Roadmap direction: move up the abstraction stack from knowledge to execution to coordination
Building the broader ecosystem: connectors, interoperability, and safety standards
The discussion shifts from Anthropic’s products to how they support an ecosystem. Angela emphasizes giving primitives across layers, enabling native embedding via connectors built on MCP, and aiming for an environment where many agents can interoperate; she also highlights the need for both interoperability standards and shared safety-oriented standards.
- •Goal: provide primitives so others can compose products and agents across layers
- •Connectors (built on MCP) enable tighter embedding into Anthropic products
- •Vision: agents and products should plug into other agents, including non-Claude agents
- •Standard setting includes interoperability and shared approaches to safety concerns (e.g., preventing misuse)
Open ecosystem vs walled garden: modular execution and third-party infrastructure
Sonya asks about open ecosystem philosophy and what Anthropic should own versus integrate. Katelyn says they’re not precious about running everything on Anthropic infrastructure and describes modular execution components, including self-hosted sandboxes with partners and MCP Tunnels for accessing servers behind firewalls.
- •Anthropic isn’t insisting execution must run on its own infrastructure
- •They launched self-hosted sandboxes and partnered with multiple infrastructure providers
- •MCP Tunnels support calling MCP servers behind a firewall
- •Anthropic focuses on architecture and interfaces that enable reliability and scalability
Why build vertical products: form-factor exploration, token-hungry workflows, and specific buyers
Angela explains the rationale behind building first-party vertical products. One motive is showcasing evolving form factors; another is focusing on areas where users want to do more after each successful turn (iterative, token-hungry workflows), and a third is serving specific business functions where better tools and context packaging matter.
- •They build products to explore and demonstrate new AI form factors, not only for market size
- •They expect form factors to be dynamic and encourage a “build, learn, and throw away” mindset
- •They’re drawn to iterative workflows where users want to do more after each turn
- •They also target specific buyer functions and have been transparent about verticalization like finance and legal
Packaging primitives into solutions: finance example and Claude Tag as an internal blueprint
Katelyn describes how vertical packaging can span from raw API usage to managed agents to connectors inside Anthropic products. She highlights recent packaging for financial services and positions Claude Tag as an example of taking internal agentic platform patterns and making them available as a ready-to-plug-in approach.
- •A given domain can be served via messages API, managed agents, or in-product connectors
- •They launched a financial-services package with skills, guidance, and cookbooks
- •Claude Tag reflects patterns seen in other companies’ internal agent platforms
- •Tag is presented as a packaged “this is how we do it internally” option rather than a novel UI
Claude Tag under the hood: context engineering, proactivity, and the interface as an iceberg tip
Angela addresses the misconception that Tag is “just a Slack bot.” She argues the value is the underlying context engineering, harnessing, and proactivity that makes it feel like a coworker, and suggests the UI surface can change (Slack, Teams, email, messaging) while the underlying architecture does the heavy lifting.
- •Tag’s interface is simple, but the core value is the architecture underneath
- •Focus areas: context engineering, proactivity, and harness work that makes it reliably useful
- •It’s framed as especially unlocking for non-technical audiences with collaboration-centric workflows
- •The interface layer can vary across communication tools while the underlying agent system stays consistent
Harness best practices and the shift toward strategies (meta-harnesses)
Asked for best practices, Katelyn points to practical harness concerns like prompt caching, context window hygiene, and evals. Both speakers argue the next innovation is higher-level strategies that allocate different “jobs” to tokens—reflection, advising, grading, or execution—because models are more steerable and the challenge is running longer and coordinating work.
- •Lower-level harness tips: prompt caching, context management, tool usage to keep context clean
- •Evals are necessary to ensure performance
- •Emerging focus: strategies/meta-harnesses that allocate token jobs (execute, reflect to memory, advise, grade)
- •Angela notes older harnesses were about heavy steering, while newer models need more long-running and coordination-oriented harnessing
When task- or domain-specific harnesses matter: verification, error handling, and token budgeting
The conversation digs into whether harnesses should be generic or specialized. Angela says domain-specific customization can matter, especially for verification and error handling in high-consequence domains, and also in higher-order strategies for allocating token budgets; Katelyn adds that “harness” can mean many things, from loops to tool packaging, and customers may want control at different layers.
- •They believe domain/task-specific harness adjustments can be important in some cases
- •Verification and error-handling logic is highlighted as especially differentiating in high-consequence domains
- •Higher-order strategies for allocating token budgets are another key customization point
- •The term “harness” is ambiguous; generic parts include caching and context cleanup, while higher layers may warrant ownership
What advanced builders are doing: context connectivity, legacy systems, and agent-to-agent modularity via MCP
Lauren asks what they’re learning from top users. Angela describes innovations around proactively gathering and permissioning context from many sources and connecting systems that lack APIs (including using computer use), while Katelyn shares an example of exposing an agent behind an MCP server so other agents can call it as a tool; they also note usage shifts such as growth in manufacturing.
- •Advanced users innovate on context engineering and proactive context retrieval
- •Some customers tackle environments without APIs, experimenting with computer use and creative workarounds
- •Example: wrapping an agent behind an MCP server so other agents can call it as a tool
- •They’re seeing category shifts in usage, including growth in manufacturing-related interest
Token cost rationalization: routing by task complexity and organizational guardrails
Sonya asks about the shift from token maximization to cost rationalization. Angela argues the next optimization dimension after intelligence is cost or speed, and warns against simply stopping AI usage; she describes routing tasks by complexity to appropriate models within the Claude family, while Katelyn compares it to managing cloud spend with guardrails rather than hard caps and emphasizes strategy design to achieve similar outcomes more efficiently.
- •Cost rationalization follows capability gains; the next dimension is cost or speed
- •They caution against halting AI usage and instead focus on better architecture and governance
- •Angela describes complexity-based routing to different Claude models and sees it as a strategy they may compose
- •Katelyn frames it like cloud cost control: detect waste, add guardrails, and redesign strategies for similar outcomes at lower cost
What’s next: composable strategies, coordination layer, modular platform for enterprises and hobbyists
In closing, the hosts ask what’s coming next. Angela says they’re focused on enabling composition of strategies in the coordination layer, citing bug-hunting as an example where techniques like “best-of” can boost results but are hard to productionize; Katelyn adds they’re also investing in enterprise security/compliance needs, modular plug-and-play platform components, and a more open, hackable developer experience for smaller builders.
- •Near-term focus: making strategies composable as coordination-layer primitives
- •Example problem: improving bug-hunting agents beyond just bigger models or longer runs via more complex strategy patterns
- •They want to productize what’s hard to operationalize so users can run real experiments
- •Parallel focus: enterprise readiness (security/compliance), greater modularity, and better DX for both enterprises and weekend developers

Publisher timestamps

Get more out of YouTube videos.

Read along on your phone, search it beside the video, or ask your favorite AI app what was said.