Anthropic's Katelyn Lesse & Angela Jiang: Building an Ecosystem, not a Walled Garden
In a Nutshell
Anthropic is building a three-layer platform—knowledge primitives, execution infrastructure, and coordination strategies—that gives builders the same tools used internally rather than creating a walled garden. The company prioritizes open standards like MCP and self-hosted sandboxes while focusing on token-heavy, iterative use cases like coding, finance, and legal where users continuously generate more work. The key insight is shifting from single harnesses to composable "strategies" that assign different jobs to tokens—such as best-of-N approaches, model advising, and memory writing—to maximize intelligence per dollar as models become more capable.
These notes were generated by AI and may contain inaccuracies.
Platform encompasses both the externally facing APIs and developer platform that people build on top of when creating applications and systems that access Claude's intelligence, as well as the internal product infrastructure that Anthropic's own apps build on top of.
The team maintains two distinct north stars given their dual internal and external responsibilities. Internally, the focus is providing maximum leverage for internal teams to ship products quickly with a reliable platform foundation, with speed being a particularly intentional priority. Externally, the goal is giving any builder the tools needed to work with Claude to build whatever they want, bringing the platform close to the builder's specific business context.
Integration work with hyperscalers like AWS and Google supports this external goal. The team creates primitives that allow builders to express their product vision and enables custom software development that was previously economically impractical. This sometimes manifests as primitives, APIs, and higher-order abstractions, and other times as standards like skills and MCP that Claude needs to be useful.
The team intentionally keeps internal and external offerings aligned rather than bifurcating them. The same primitives are available to everyone, whether internal or external builders. This approach stems from the recognition that model capabilities are evolving exponentially and form factors are constantly changing—two years ago the focus was chat interfaces, now agents are emphasized, and new form factors will emerge.
The philosophy is that building a robust platform with tools for experimentation enables the market to discover optimal form factors through democratization rather than the team attempting to determine them alone. Internal dogfooding happens simultaneously with external early access to gather diverse feedback rather than over-indexing on internal requirements.
When Angela Jiang joined Anthropic around a year ago, the platform was primarily the stateless Messages API, along with standards like MCP and developer tooling including SDKs, docs, and console.
The evolution has been driven by customers solving the same problems repeatedly around long-running contexts and remote contexts without human-in-the-loop oversight. Higher-order abstractions emerged from infrastructure the team was already building internally, including spawning sandboxes with appropriate governance and security, managing spin-up and spin-down, and storage for transcript sessions to enable resuming work.
The second major area addressed is harnesses and harness engineering, covering prompt caching, context window management, extracting more intelligence from the model, and cost management.
AI-native startups that tinker and experiment at low layers tend to select the raw primitives. Enterprises and startups whose core competency is not AI optimization but rather stringing together workflows to deliver user value more often choose the higher-order packaged offerings.
Knowledge Layer
The base layer concerns knowledge about the model and what the model needs. Primitives at this layer include the specific shapes and parameters on the Messages API that showcase Claude's design, how it thinks, respects parameters, and handles tool calls. Standardization of tools followed, along with context elements like skills and memory.
Execution Layer
The execution layer addresses moving from knowing something to actually executing work—editing files across systems, producing outputs, and handling the infrastructure complexity this requires. The low-level harness plus managed infrastructure form the abstractions here. Claude Managed Agents represents the high-level product for this layer.
Coordination Layer
The coordination layer sits above execution. At this layer, the team is beginning to think about strategies as a meta-harness. The concept recognizes that tokens are not fungible and should be given different jobs—some tokens advising, others executing, some dreaming. These orchestrated strategies compose together and sit on top of execution infrastructure because execution is still ultimately required.
The team prioritizes providing primitives across knowledge, execution, and coordination layers so builders can compose and create on top of them. Connectors built on the MCP spec enable native embedding with first-party products. The goal is enabling transactability where agents and products built by companies can plug into other agents, whether Claude agents or third-party agents.
Standard setting occurs at multiple levels. Traditional interoperability standards include skills and MCP at the builder layer. A higher-order layer addresses safety interoperability—ensuring critical infrastructure protection, preventing fraud and negative actions on services, and working with industry partners on shared security concerns.
The broader vision compares AI to electricity: a transformative utility that becomes valuable when wired into everything with standards for interconnection, which requires ecosystem and partner collaboration rather than any single entity acting alone.
On execution infrastructure, the team is not prescriptive about running on Anthropic-controlled sandboxes or storage. Self-hosted sandboxes were launched with partnerships including Modal, Vercel, Cloudflare, and Amazon's microVMs. MCP tunnels enable calling MCP servers behind firewalls. The priority is the architecture for building powerful, reliable, scalable agents rather than controlling the underlying infrastructure.
Two frames guide first-party product decisions. The first is constantly seeking new form factors, recognizing they are dynamic rather than static. Products may be launched to showcase a new form factor rather than because they represent the largest TAM opportunity. The internal labs team experiments extensively—many projects are tested internally for weeks then abandoned without shipping.
Claude Design exemplifies this approach. It offloads more work to Claude with an opinionated stance encouraging users to talk to it and let it figure things out rather than traditional editing workflows. It also demonstrates using code purely for design generation rather than integrating against design systems in a traditional WYSIWYG style, showing that code can solve problems not normally approached that way.
Anthropic tends to focus on token-heavy or token-hungry applications. These are defined as experiences where after completing one turn, users want to do more rather than walk away. Coding is the prime example because finishing a task creates the desire to build more, unlock new capabilities, and generate additional work. In contrast, some services complete a job in a single turn and users move on. The team prefers use cases with iterative flows where users build and generate together continuously.
Certain business functions are prioritized as buyers where Anthropic can optimize workflows and help create better products. The company has been transparent about verticalization efforts in finance and legal. These areas were selected because providing the right context, tools, and form factor creates meaningful value.
In each vertical, the approach involves showing the art of the possible across different implementation methods. For finance specifically, customers can build directly on the Messages API with tokens, use cloud managed agents for more out-of-the-box functionality, or create plugins and connectors that sit within Anthropic products. Claude for Financial Services was launched as packages of skills available within Anthropic products or other platforms. Cookbooks were also released demonstrating how to use cloud managed agents for specific tasks. The overall philosophy is providing different pieces and observing where customers take them, while also packaging complete products.
Claude Tag emerged from observing industry patterns where companies like Shopify with River and Square Block with Builderbot built internal agentic platforms. These systems provide proper context and are accessible from Slack or other collaboration platforms. Claude Tag packages these same capabilities so anyone could build something similar, but this represents Anthropic's internal approach that customers can plug into directly.
People initially reacted to Claude Tag by calling it just a Slackbot. The interface of tagging it in Slack is visible, but the real value lies in the context engineering and architecture underneath. The goal is for the agent to feel like a coworker who enters a channel, is proactive about identifying useful actions, and gets things done. For non-technical audiences this represents a significant unlock because users can create a channel, mention Claude Tag, and handle tasks like submitting expense reports without navigating multiple people and systems.
Andre Kaparthi described it as an org-level harness containing significant baked-in complexity. While customers can construct similar systems using APIs, Claude Tag represents an opinionated take on how to deliver an always-on agent for an entire company. The futuristic aspect is that most of the complexity sits underneath the visible interface like an iceberg, and the interface itself can swap across platforms. The vision is for agents to occupy the same form factors as humans whether that is Slack, WhatsApp, text, or email, functioning as intelligent assistants that understand context.
Cloud managed agents were launched as a generic but high-performing harness. The lower-level work includes prompt caching, context management, clearing old items from the window, and programmatically calling tools to avoid pulling everything into the context window. Best practices include implementing prompt caching to save money and token costs, keeping the context window clear, and using evals to verify performance.
The team is moving toward concepts of strategies or meta harnesses. Rather than spending tokens only on execution, the same token budget can be allocated to reflecting on past agentic sessions and writing learnings to memory, having a bigger model advise a smaller model, or using a grader to evaluate outputs and trigger retries. Innovation is expected at this higher meta level where token budget allocation strategies are optimized.
Two years ago, harnesses functioned as scaffolds to guide models from point A to point B because models required extensive structure. Current models are highly steerable, so much of the steering logic can now be handled through prompts. This allows deletion of portions of harnesses that previously handled steering. The remaining requirement is enabling models to run longer across extended task sequences from B to C to F to Z and back. This shifts harness design toward strategy harnesses that operate at a higher level of thinking aligned with model intelligence gains.
The opinion at Anthropic is that task-specific or domain-specific harnesses make sense rather than pursuing a single general harness. Coding is a broadly useful capability across domains. However, very specific domains require customized harness pieces. One area is error handling and verification logic between model outputs and execution. Domains like legal and finance with high consequences for errors benefit from owning these verification mechanisms because small tweaks can create meaningful differentiation.
Context handling is considered somewhat overdone because any harness can manage substantial context, so the advantage comes from having unique data rather than superior context architecture. When people discuss harnesses, definitions vary widely from simple loops of user-model-tool interactions to packaged tools. Lower-level concerns like prompt caching and clearing old tool calls from context windows are less interesting to own, while higher-order strategies and tool definitions represent areas where control may be valuable.
Cloud managed agents provide significant control through custom tools, skills, system prompts, and MCP servers. The longer-term direction is enabling users to specify desired outcomes and budgets while the system handles underlying details. Different users may choose to operate at different layers depending on optimization needs.
Advanced users demonstrate innovative context handling. Teams have developed clever approaches for reaching contacts across multiple systems, generating permissions, and feeding information into agents. Much of this innovation appears in internal use cases rather than external products. AI-native companies show increasing innovation in areas like custom SDLC setups and back office operations, with particular interest in how they stream context.
Another category involves companies working with legacy software that lacks APIs, particularly healthcare organizations. These teams use computer use capabilities to automate connectivity. Innovation here includes running agents on laptops to autogenerate artifacts and experimenting with various connection methods. The goal is supporting standardization so Claude can respect specifications and organically connect systems.
A notable example involved a customer with agents on cloud managed agents alongside agents on other models and platforms. They exposed an MCP server on top of one agent so another agent could call it as a tool, creating modular interoperability. This connectivity layer represents an exciting area of customer innovation.
Beyond coding's continued explosive growth, manufacturing is emerging as a category with increasing AI adoption. PMs are traveling to locations like Detroit to understand customer needs in this space, suggesting broader use cases outside traditional categories will develop.
Following a period of token maximization, the industry is entering token rationalization. As models become more capable, intelligence maxing gives way to optimization on cost and speed dimensions. The recommendation is avoiding stopping AI usage when returns are being realized through faster shipping and operational efficiency. Shadow IT patterns where employees independently adopt tools create management challenges.
The suggested approach is constructing architectures that assess task complexity and route accordingly. Hard tasks route to larger, more capable models while simpler tasks use cheaper models. This router-like strategy involves technical complexity but enables continued innovation while managing spend.
Within the Claude space, the team encourages experimentation with recomposable design approaches. The pace of AI development feels like a new era every month, requiring architectures that support rapid redesign. The strategy involves thinking in terms of recomposable primitives that can be quickly adapted when new capabilities emerge.
The core design principle is building the platform specifically for Claude rather than creating general model routing across different providers. The focus remains on making Claude excellent at solving problems within its domain.
A key insight is that harnesses and agentic layers should be tuned to specific model families rather than designed as universal abstractions. Earlier approaches assumed builders could create a single harness or agent and simply swap models underneath, but the pattern emerging is that entire harnesses and agents are now being built tied to specific model families.
The value provided becomes smarter ways to mix and match models within a single model family rather than routing across entirely different providers.
Companies are entering a natural cycle of learning how to make the best use of AI technology while running businesses effectively. The experience at Stripe involved careful attention to infrastructure costs, with guardrails to identify and address inefficient background jobs that consumed excessive resources.
Similar patterns are expected to emerge with AI usage, where teams identify and optimize expensive operations that don't deliver proportional value.
Setting hard spending caps can be dangerous because it may stifle innovation. The recommended approach encourages teams to create excellent outcomes first, then examine whether those outcomes could be achieved through different strategies that reduce costs.
One path involves running the most capable model extensively. An alternative involves developing smarter strategies that accomplish the same outcome at lower cost. This represents the next layer of thinking teams will need to develop.
The focus is on building ways for users to compose strategies, moving into a coordination layer of abstraction. The types of problems being built require cleverness about the nature of the problem being solved.
A concrete example involves building a bug hunting agent. The initial approach sends a single agent to perform the task. When results are insufficient, the typical levers are switching to a larger model or allowing longer runtime. However, experimentation reveals a third lever—best-of-N approaches—that often delivers significantly more returns than the first two options.
While best-of-N strategies are well-documented in research, implementing them in production environments to test with real users is extremely difficult. Builders end up creating custom harnesses and infrastructure to support these approaches.
The philosophy is that if a technique provides valuable returns but is hard to implement, the platform should make it easy so users can focus on running the experiments they need.
Agent swarms represent one type of strategy, similar to how one large model separating into multiple instances represents another. The concept connects to human organizational patterns but extends further.
The emphasis is on viewing each token as having a specific job. This job-oriented perspective is where significant returns are being observed, and the goal is to make it easier for users to experiment with different job combinations.
Internally, the team has identified approximately five jobs. When released to the broader ecosystem, the expectation is that users will discover 100,000 to 200,000 additional combinations.
The ongoing goal is hill climbing on how to extract the most value and intelligence per dollar spent, then putting that capability into users' hands.
Beyond the core optimization work, different personas have distinct needs. Enterprise users require security and compliance controls. They also need modularity to plug different solution pieces into existing systems, as many operate within walled gardens and need ways to integrate new capabilities.
A dedicated team works on strategies and jobs to maximize intelligence, but enterprise constraints often prevent adoption of these innovations. Solving enterprise-ready security, compliance, and integration problems is a priority.
The weekend developer persona has different needs—more open, hackable solutions that allow experimentation. Table stakes improvements in developer experience are essential because they unlock adoption, after which users can engage with more innovative, intelligence-maximizing capabilities.
The platform aims to serve both enterprise requirements and open experimentation needs, avoiding a purely walled garden approach.
Keep Sequoia Capital in your library
Save the videos and channels worth coming back to, and find them again in one place.
