Mike Krieger & Jesse Zhang | Decagon Dialogues 2025

Good to be here.

Yeah, I think there are two challenges that the Instagram experience directly led me to on the Anthropic side. The first one is trying to make something that's emerging more understandable. We take camera phones for granted now, we don't even call them camera phones, they're just phones. But the idea of mobile interfaces and that being the primary way we might interact with something was new when we were building Instagram for the first time. Similarly, you're seeing this paradigm shift where people are getting used to the idea of interacting with AI in all sorts of form factors, whether voice or text. So understanding meeting people where they are, but also being really experimental on that edge of the capabilities, because the same UI paradigms that worked for classic web apps are not going to work on mobile. The same pre-generative AI interfaces also start breaking down. That's the first piece. The second one is actually maybe more surprising: as Instagram grew, we also became a platform for businesses to build themselves on. Similarly, one of the things I was really excited about coming into Anthropic is that sure, we have our first-party products and we'll work hard to make them understandable and user-friendly, but it's also a platform to power other companies like Decagon and others. That was very exciting for me because my in-between chapter between Instagram and starting a second company was doing some investing, and I liked seeing a lot of companies. I liked feeling that my day was not just a single product, but I missed building. So this is the best of both worlds.

Yeah, I think the art and science of AI deployment, as many of you are experiencing as you roll it within your own companies, is that we have a phrase I heard internally and love: there are two ways of timing an exponential: too early and too late. It's really hard as these capabilities are advancing. Too early, you end up in that trough of disillusionment from people who rolled out internally where you've overpromised. Some products that were earlier to market really did this: 'Great, you're just going to hit a button and all your work will be totally automated.' People try it and it's like, 'Well, it made something, but I'm not sure I'll ever do that again.' Or products that push too far or too quickly on autonomy or delegation before the actual quality is there. But you don't want to be too late and feel left behind while other companies have adopted and accelerated their own efforts. For us, the most successful deployments often start by having champions inside enterprises who are constantly playing with these capabilities. I was giving a talk last week with a very large bank, and they're fortunate to have leadership that day in and day out plays with these models and gives us feedback. It probably reflects more poorly on us than well on them: we'll report brokenness in features we didn't even notice ourselves. That's a sign we need to improve our auto-detection, but it also shows they're really out there trying these different pieces. What's interesting is that when it leads to a deployment, whether it's an internal productivity tool or a customer-facing feature, it's not grounded in the myth that AI will solve every problem, but more around 'I tried it, it's really good for these pieces, we're going to put it in production.' I love the conversation around starting with an ambitious but scoped use case and building up from there, with really strong evaluations: 'Is this actually working? Can we scale this up?' Then what we find is that one successful use case starts unlocking others, because other product teams see a good deployment and ask how they did it. We also find that the first several months are just getting through contracting and getting comfortable. So if you can land that initial use case, the second, third, and fourth are much easier.

Yeah, it's kind of funny. If you talk to customers of our models, the two things they often say the models are really good at are coding or using tools in general, and having a really good voice and being very friendly. You wouldn't expect those two to necessarily emerge from the same model, but it comes from the longer arc of research at Anthropic. We want to build powerful, intelligent AI, and we want to do it safely and responsibly. We think the critical path is models that can do two things really well: one is plan and work on tasks for longer and longer, which fits well into codegen but also into many customer service use cases where you don't just want a single answer. A few years ago, we could have done retrieval off an internal knowledge base and answered a simple question. What you really want is what we saw in the demos today: understanding context, retrieving data, and taking actions to ship a replacement. That all involves acting agentically. The second is models that can interact with humans over time, because many important interactions on the way to powerful AI will involve collaboration with humans. So those two pillars of our research are long-horizon tasks and Claude having a character—not a single character, because each customer steers it differently, but fundamentally an empathetic voice you want to interact with that doesn't feel robotic. Those have been two use cases where we've seen customer traction. Customer service actually took off before codegen in the initial phase, but I think there's more in common between those two than you might think. As we think about the agents we're building even inside Anthropic for problems outside of code, we deployed one for our legal team to help with redlining, and one for our security team to intake new product ideas before they hit a security engineer. They're all using the same tool-using, agentic loop, and they might write code under the hood, but the person on the other end doesn't know that. They're just trying to solve a problem, and Claude is solving it for them.

Yeah, I describe it as an L-shaped platform. The breadth of the platform we want to power is everything, from companies like Decagon to life sciences, healthcare, and financial services. There's a lot of specialized knowledge about how to go to market, tools to be built on top, and integration into customers. That entire relationship is differentiated and unique for all those companies. We'll choose to build some verticals when it's something we know a lot about, like code. Or places that will teach us a lot about a particular vertical. The feedback from having cloud code in market directly informs the next model releases and lets us improve. The feedback from work on the knowledge worker horizontal with cloud for work has been helpful in training the model to produce PowerPoint documents better. So that's where we choose to build vertically. Connecting back to the Instagram experience, we were really focused on a focused set of features we wanted to do extremely well, rather than a platform that did everything not as well. We're applying the same philosophy: we're not going to do 500 things, but a few things we try to go deep on.