Anthropic’s Felix Rieseberg: Claude Cowork, Mythos, and the SaaS Extinction

Hello. Hey, Matt, how are you?

Yeah, sure. Mythos is an unreleased frontier model. It's a general-purpose model that was trained not specifically for cybersecurity or specifically for coding or specifically for software, but we have discovered what we believe to be outsized capabilities specifically in the aspect of cybersecurity. And we believe that it has far-reaching implications for the safety of software and infrastructure. I think there's two things I'm alluding to in my tweet. We've obviously used the model internally for a while now. As a software engineer, I think many of us have gone through this exercise over the last couple of years of, like, our first initial contact with AI was probably not that impressive.

The first time I touched AI was sometime in 2013. This was before we had large language models. I was at Microsoft at the time. We had something called Project Oxford, where we had an n-gram model. You would give us a token, you would say something like "world," and the model would return "World Wide Web." And that was sort of the, I want to say, frontier of what language models were capable of doing. And I think a lot of us in the public over the last couple of years had these moments of being like, oh, this model is more capable.

It can do more things than I maybe expected. Mythos Preview is a model that, for us as engineers internally, feels like a dramatic step up compared to some of the recent steps we had. When I say in my tweet that it's hard to actually capture how meaningful the step is, it is actually pretty hard for me to explain. I will say that this model is quite capable of finding security flaws in code that I've written in the past. It goes a lot deeper.

It's a lot smarter in how it analyzes my code. It's a lot better at writing code. The ways it's changed how we work at Anthropic are, obviously, that it made us a lot faster, but there is something, I think, both impressive but also slightly terrifying about seeing a model that is so much smarter than the last model we have worked with. Maybe one important context that I often give people when I talk about models is building models is an interesting exercise.

We often say that models are more grown than built, out of the nature of how these language models are being made. So you don't always know ahead of time necessarily what they're going to be very good at, what they're maybe going to be bad at. Both of those things are a little surprising at times. And in this particular case, one of the things the model is particularly good at is finding security issues in existing software, and Glasswing is a project as a response to that.

But overall, as a model, it's quite impressive.

I do think it's probably going to change the way in which we build software quite a bit at the company. But I think to most people who've been paying close attention to AI overall, it's not going to be too surprising that we continuously walk up the hill in terms of capabilities and power of what a model can do. I think it's going to change things in a way that we roughly expected. We, a few years ago, started with the model maybe assisting you with small tasks.

Both the size of tasks we give models as well as the timescale at which they operate, both of those things grow over time. The complexity grows. I think this is yet another step in that direction, right? The step might be a little bit larger than we anticipated and expected, both internally and certainly maybe externally. At least amongst researchers and people who work in AI, it's been a long-held belief that those bigger steps are going to come and that the steps themselves get bigger and bigger over time.

In some sense, we're right on track. But I think seeing some of those actual capabilities played out is sometimes quite terrifying. There's one example we have published, which is that the model was put into a little sandbox, a little technical container, and it was given the task to maybe break out. And the researcher went away for lunch, and during lunch, while eating a sandwich, the model sent the researcher an email saying, "I've broken out."

The model was not supposed to have internet access or an email account.

So Mythos is a project that is attempting to give the people and the companies that provide much of our software infrastructure, sort of the very foundation—the Linux Foundation, as an example, that is pretty close to my heart as a member of the Linux Foundation with an open-source project I have once worked on. The goal here is to give people who are responsible for so much of the public infrastructure that we all rely on every single day we do anything with our computers or our phones, to give them a head start, give them an opportunity to use this model to harden the defenses, find security flaws before the general public will be able to use models to potentially exploit its capabilities.

Yeah. So for now, it's a preview model in its own category.

I mean, I think Anthropic has long held the position that AI can be extremely powerful, very beneficial, but that there are risks that we ought to take seriously. And I think this is one of the areas where we, for the first time, see this, I want to say, applied in practice, which is quite interesting to watch. You now have this model that is very capable of breaking into software systems. What does that mean? What do we do with it? How do we handle this responsibly?

And it's not to toot Anthropic's horn too much, but for me as an individual, it's a bit of a point of pride. I'm very proud to see the company handle this very responsibly. And I think a lot of my colleagues share similar appreciation. You've alluded to the fact a little bit that we've had this model before, right? It's not like we immediately found a model that was very powerful. And I think there's an alternative universe in which maybe a company with a less steady hand would have raced to get it onto the market as quickly as possible, put a very expensive price tag on it, and just reap the benefits.

Yeah, so we train our models with our products in mind. I think what the products do informs what the research does, and vice versa. So on the one hand, we try to train the models a little bit against the capabilities that we think will deliver real value to humans. And then the other way around, I mentioned a little bit that we don't always necessarily know ahead of time what the model will be good at, what it will be bad at. So it's a bit of a give and take.

It's a little bit like a dance where we try to use the products to learn as much as we can about what humans can benefit from. And then at the same time, if the model comes out with a surprising capability, it might be my job to identify, all right, what do we do with that? How do we turn this particular capability in a model into something that humans can actually use in their daily work? I will say, though, that as we get more and more powerful, I actually think the overhang in the product is bigger than in the model.

And let me maybe explain that for a second. What I mean by that is, if I look at the industry today—and by industry, I don't just mean the AI-native companies, I sort of mean software at large, and then knowledge work at large, and then even beyond that: manufacturing, research, healthcare—what I'm noticing is that the models we have today are actually quite capable. They're quite capable of running knowledge work of both an extremely long time horizon, the kind of things that you would give to someone and expect a week later, as well as complexity, right?

And I think we're still a little bit in the era of trying to figure out how to package those capabilities and deliver them to people in the best format. And then the industry is also still trying to figure out, okay, how do we arrange our work in a way that makes sense in this new model, right? How do you organize work in a way that you can harness these capabilities the most? And what I mean by both of those things is, when I talk to customers—and I make customer visits rather regularly—it is very rare for me to walk back and leave the building and think, oh, we need to train the model to be better at XYZ.

It's far more common that I find myself impressed or surprised by how you can organize work in such a way to make use of the models. Or alternatively, I'm quite convinced that a problem a particular customer has, I can actually very easily solve. I just haven't exposed the right UI, the right capabilities, the right onboarding to make that very easy for them to use.

Yeah, I can kind of see why that caught on. In software, nothing is ever built from scratch, right? And I think the exact quote that I gave that people used was that my team sprinted on this for, I think, the last 10 days or so, which is accurate. That is the case. My team got together 10 days before release and was like, all right, we should probably release something. What do we release? What does it look like?

What is it named? What can it do? However, as anyone who's ever built any software can attest to, it's not like you start from scratch with ones and zeros, right? You make use of a lot of libraries. You make use of research you've done in the past. In particular, at Anthropic, the core problem that I tried to solve for was: how do you make it easier to bring the power of Claude Code to non-coding work, right?

Like general knowledge work. A lot of very smart people have thought about that at length. And it would be inaccurate to say that Anthropic has not thought about this problem. And it would also be inaccurate to say that I sort of came into this cold without benefiting from all that work.

I think I really gained conviction over the holidays, the last holidays, December 2025. On social media, I saw more and more people who are not developers picking up Claude Code. I saw newsletters, I saw tutorials where people are like, "You're not a developer. Let me explain to you where to find the terminal and how to get Claude Code. It's going to do great things for you." The people who were picking up Claude Code were not necessarily building software. That was, I think, a small subset of people that were non-developers that were using the power of the model to now build software.

That was one use case. But I also noticed that a lot of our developer users, the ones who do use Claude Code every single day to build software, started using it for things that are not software at all. That became a pretty overwhelming amount of latent demand, right? Which I think is a strong predictor for what you should maybe spend your time on. If people are crawling over glass to use your thing, even though you didn't make it even remotely good, that's a great indicator that this is a space where it's worth investing.

The actual genesis then was that my colleague Boris Cherny, who is the lead developer for Claude Code, came to me and was like, "I think you should ship something. And I think you should probably do it within the next, I don't know, should we say Friday?" I negotiated him up to Monday. I was like, "Give me the weekend too." And then we took a team and we sort of spiked on this idea of, okay, how can you make Claude Code very effective for non-coding use cases?

Cowork by itself is, in its ingredients, rather simple. What we've done is we've taken Claude Code, and we've given Claude Code a virtual machine that Claude can use to run its own code. That virtual machine gives us a few things. The first one is it gives us hard guarantees around what Claude can do and not do. So you, as the person who's operating this very powerful thing, no longer need to supervise it, right? Because it's in this little sandbox, and you can completely separate it from your computer, your files, and also your network.

So this virtual machine only gets access to the exact domains you give it access to, and it only gets access to the exact files you've given it. That's one benefit. The other benefit is that for Claude Code to be most effective, it actually does need developer tooling, right? Claude is very good at helping you solve any kind of wide range of tasks, but the way it often does that is by writing hyper-specialized little software snippets. By giving Claude its own computer, it can set up its own developer environment without necessarily messing with your computer.

And then I think the things around it, there's a little bit of UI. We're trying to make this very comfortable for you to use. We're trying to make it very elegant. We're trying to simplify some of the flows that may be more native to developers. And then the end result that we get is we have this tool that is quite capable of helping people with their knowledge work.

So skills are essentially just Markdown files that explain to the model how to do things. I'm always surprised at how well this works. If you treat the model, Claude in this case, like a coworker, you get very, very far. My recommendation to everyone I always talk to is just treat Claude the way you would treat a coworker. So a skill is fundamentally just a text file, and in the text file you explain how to do a certain thing.

My default example is always, say, booking a flight. At Anthropic, we have a specific vendor that helps us with our travel bookings. So you can't just go to Google Flights. You need to go into this particular vendor portal. And then we have various travel policies. In the same way I would explain this to a coworker, I can explain it to the model. I'll just make a file that is like, here's how you book flights. You go to this website, and on this website, please consider the following things.

And then maybe you also sprinkle in a few personal things, right? Like, in my case, avoid red-eye flights, but also I do actually enjoy my weekend quite a bit. So try to book a flight. If I have to fly to New York from San Francisco, try to take the 4:00 PM flight. That's my favorite time. And you put all of those things in this text file, and the model then is extremely capable of understanding the instructions and then running with it.

That's surprisingly simple.

That's done by the model in collaboration with a human, right? I think one thing we're quite happy with is how we've organized the model's to-do list. So the model is instructed to break down projects and individual tasks. And you can sort of take a step, you can sort of edit the to-do list, you can click on individual items and provide more context. But yeah, the intelligence lives inside the model. But the skills, I think, really give it another layer of usefulness.

And I think there's something interesting going on here because I think, as humans, we're so used to technology that is one size fits all, right? A lot of us use the same phone, the same computer, but the model is this intelligent thing that can really benefit from a little bit of instruction and guidance, the same way that any smart person who joins a company would usually get a little bit of onboarding, being shown how to do things. Another example that is maybe very apt for many people is creating presentations or creating documents.

I'm a big fan of style guides. If you have a PowerPoint or a Google Slides template, you should tell Claude about it. You should tell Claude about how you like to make presentations in general. Maybe you prefer serif fonts or not. And if you just write that down in a little instruction, the model will be so much more capable at actually helping you with work in a way that you don't have to go in, fix it, and babysit it all the time.

It's in the harness, actually. And it's often surprising to people when I talk to them how we've implemented memory, because I think it maybe points at the simplicity underneath all of those models. Memory is just text files. It's really just the model being instructed, "Hey, if you feel like anything was pertinent that you might want to remember in the future, just write it down." And then we help the model a little bit with organizing its memory, so you can set up projects that have isolated memory versus, like, your overall memory.

But the underlying technology that is bolted on top of the model is sometimes surprising to people, that it's not some complex, fancy database technology.

It's a combination of all of them. So I have a strong belief that the data that is relevant for your work probably lives in two different places. The first one is on your computer, right? A lot of us have a lot of files on our computers. I'm a huge proponent of the idea that us makers and builders of technology need to take seriously the fact that you use a computer and you don't just have an iPad. Not everything is in the cloud.

Many people benefit from just using files and folders. That is one part of context that Cowork can use. You can just drag it in. You can give Claude access to a specific folder or multiple folders. And then the second part is information that might live in the cloud or the internet, like a data warehouse, analytics, SharePoint, whatever people might use, right? We have multiple ways of connecting to those sources. MCP connectors are one that is quite powerful. The other one that we use is, because Claude has a computer, it can reach out to the internet if you instruct it to do so.

You control specifically which parts of the internet Claude gets access to and which ones it doesn't get access to. But generally speaking, if it's out there and you want to give Claude permission to use it, it will find a way to use it.

The two biggest things that Cowork gives you today are access to your local computer and also access to your local files. Why does that not work in the cloud? I think a good example for me is always maybe using your Chrome. Claude, if you give it access, and again, only if you give it access, can use your Chrome, which is a pretty powerful tool for Claude to interact with the rest of the world, be it responding to your emails, summarizing your emails, or maybe interacting with a tool that only you have at your company.

I often play this through for people who might think, why can't we just do that in the cloud? The first case is your sessions, and it's quite useful for Claude to have access to the websites that you care about with your accounts. Gmail is not all that useful to my agent. Gmail with my login information is quite useful. The second case is that, and this is usually a debate I get more into with other software engineers, is to a software engineer, this is an implementation detail.

We could find some kind of way to take your local Chrome, zip it all up, put it in the cloud, ask you for your passwords, do all kinds of things. There's two oppositions I have to that. The first one is probably sort of on the basis of safety and security. I don't think we should teach people that they should trust a singular company with all of their passwords. I don't think that's a good idea. But the second one is more practical.

The world overall is not ready yet. And a good example for this is banks. If your bank sees you logging in from two separate places, say, your computer and also a data center, it will probably lock down your account and will ask you to come to a branch with a passport. That kind of experience and its nuances and the long tail of where those things might fall apart is, for me, unacceptable for my users. So in the short term, I want to make it very possible for Claude to meet you where you're working.

If you're working on your local computer, that's where Claude should be.

Yeah, I think about that quite a bit. And I think the question in my head currently is, if I build you a magical button and you press that button and I'll just slurp up your entire computer and put it into the cloud, would you press it? So far, my impression is that most people would not press it. Maybe they would trust Anthropic as one of the few big companies out there that would actually do trust us with all of their data.

For now, I think I still see a huge amount of value in having Claude operate where you operate.

But you're right that from a technical point of view, there isn't much that strictly forces me to operate on your computer. I can probably build a fairly good version of this button that just slurps up your entire computer. We can do a lot of these things in the cloud. We can even run the entire harness as well as the machine around it in the cloud and reach down into your computer. But for now, the concentration on your computer and sort of this, I want to say, laser focus on making Claude as effective as possibly can be where you work is something that we've seen resonate fairly well with users.

And it also allows us to move a little faster, push safety and security a little harder than it might be possible in the cloud. There's enough there for me to, like, for now—and AI is a fast-moving target, right? Things might change quickly—but for now, to be pretty excited about your local computer more so than asking you to put all of your information in, like, a cloud. You mentioned the word trust, and it's a fascinating topic in agentic AI.

Yeah, yeah, it's a good point. It's a good point. I think there's something interesting if you build AI products in 2026, which is that most of the buttons you add and most of the product services you build are probably more for the human than they are for the model. And this is an interesting shift in how we build technology, right? In the past, we've usually built buttons for the benefit of the computer. And the human was just there to provide information so the computer could do things.

Now we are actually doing it the other way around. And I'll give you one quick example. We've recently launched a feature called Dispatch, which allows you, from your phone, to talk to Claude on your computer. As a very conscious choice, we decided not to add too many buttons. So one of the pieces of feedback I got most on social media—I easily got 50 messages every single day from people—was asking me, "Hey, it would be cool if Dispatch could access my local files."

That would be really nice. Like, can you find a way so that I can attach a folder? I mention this because Claude can access all your files and folders. The way this currently works is that you ask Claude, "Hey, can you also see my downloads folder?" Claude will say, "Yeah, I can see it. Do you give me permission to interact with your downloads folder?" And once granted, it will go. So we're debating: do we add a button? Do we add a button so that the user knows that Claude is capable of something?

And to answer your question here about trust, I think the way we've thought about trust is less about Claude proving itself to the human and more about slowly educating and helping the users in their sophistication journey by taking them by the hand and starting really small. When we first released Claude Cowork, it could already do fairly impressive things, right? It could write a 200-page VC report for you. You could ask it to start protein synthesis and modeling. You could ask it to design complex architectural drawings.

But the thing that resonated most with people was, "Clean up my desktop," a menial task for AI, right? You do not need Claude to help you clean up your desktop, completely unnecessary. And I think the second piece that also really resonated with people was scheduled tasks, which again, from a technology point of view, is not a big innovation. We've known how to run a function in five minutes rather than right now for a long time. But what we're teaching people here is: you start with a little task, you see Claude do that well, you then slowly grow the task, right?

Humans fairly independently will, after seeing a small task work, increasingly offload more and more work. And then with scheduled tasks, you teach them it's actually okay if you don't watch this thing. You don't need to supervise, you don't need to sit in front of your computer and watch Claude do a thing. You can just ask it to review your meetings every single day and write you a report. You can just have it do that. It will send you an email once it's done.

You don't need to be involved. And I think on this journey, we're slowly trying to teach people more and more what the capabilities are and how to integrate them into their life. And I think that's fundamentally where the trust comes from, right? Trust is really built on top of Claude promising you a particular output, that output actually being good, and you not having needed to either babysit it or intervene in some way.

It's a really good question because I actually think that's true. I do think the UX matters quite a bit, right? Even if you go back to one of our most popular products, Claude Code, the very genesis of it was: what if Claude, but instead of in the cloud, it's running on your computer in your terminal? That is almost entirely UX. It's the same model. It's the same core capabilities. It's really all around what is the user experience and how do you interact with the model, right?

But it's fundamentally the same model. And that's really where a lot of the benefits came from. And I think similarly today, the AI products I see resonate with people the most are rarely the ones that deliver the most raw potential, the most raw power. And I would actually go one step further and say this is probably true not just with AI, but maybe with software overall. I'm going to blindly assume that plenty of startups out there offer email with more features than Gmail.

There's plenty of companies that try to sort of jump ahead by offering a larger amount of features or more buttons or more capabilities. I often think a lot about the silly times of mobile phones right before the smartphone was invented, right? All the things that people bolted onto phones. We had phones with projectors, phones with included gamepads. We had a phone that didn't have a keyboard, phones with full keyboards. And in the end, I think technology that works really well is often more about the things that you take away rather than the things you add.

It's more about: what does it feel like? And to this day, I'm not convinced that most people buy a phone on the basis of a spec sheet. I could be wrong. I'm completely making this up, but I'm having the feeling that most phones are bought for reasons other than what are the specific chip capabilities. And I think AI probably works a very similar way. Obviously, a very powerful model gives you a bit of an edge. I'm not going to lie that it's probably much easier for me to build a good AI product because I work very closely with researchers and we have amazing models inside the company.

But at the end of the day, if someone beats me, Felix, at building very good products, I suspect it's going to be not because they built a better model, but likely because they figured out a better user experience.

I think what we do is probably not super unique. There's one thing that is new to me. So I'm first going to say the things that a lot of the listeners are probably going to say, "Ah, yes, of course." And those are a pretty radical obsession with users, right? Build for actual real humans that you talk to a lot. Try to prefer iteration over these long-running plans. We tend to plan not more than a month out. We try to be fairly quick in how quickly we ship and also how quickly we iterate.

Yeah, at most.

Because we constantly think about, okay, what does this look like next week? What does it look like the week after? Our confidence that we can all disappear into a room and envision the best product for most people out there, the way it looks in a year, is pretty low. And in fact, I would argue that no one ought to have that confidence. If anyone tells me, "I know what AI looks like next year," I'm not going to be very impressed.

Maybe, maybe. But I certainly don't have the confidence. And I think anything I've ever built that became very good became very good because I had many opportunities to course-correct. I had many opportunities to be a little wrong and many opportunities to figure out, okay, which one of these three works better? The thing that is new is that execution is essentially free, right? I can build—if you come to me with 10 different ideas, I can very quickly say, "Let's do all 10."

Let's try all 10, see which one we like more, which one feels better. We try to do most of our testing in-house. We try not to abuse our customers as free beta testers. But I think with most products, you very quickly know whether or not it's roughly going in the right direction or not. That feeling comes very, very quickly. As a company now, we've grown quite a bit. We have a decent amount of employees.

It's fairly easy for us to figure out, does this resonate with more than five people or not? And this rapid speed of execution is really what's new, right? Because previously, even two years ago, if you wanted that rapid iteration, it required a very aggressive focus in which things you pick because you can only iterate so quickly with only a few things at a time. And now that execution is becoming so cheap, you can iterate with things. You can go deep and broad at the same time.

And that's honestly, like, wild to witness.

We probably have easily 100 different prototypes of various applications inside the company right now. None of them have necessarily yet hit the confidence of, like, this is good enough to show to a user. But the amount of prototypes you can build internally very, very quickly completely dwarfs anything I've done in the past because of the cost of execution, right? Like, in the past, the thing that would always hold you back is, for me as the engineering leader, if you had a good idea, you would come to me and I would tell you, "Oh, we can work on this next month."

It's going to take us three weeks. Until then, go and talk to the customer, validate your ideas. And now you can come to me and say, “Oh, I have an idea,” and I'm like, “Cool, give me 10 minutes. I'll send you something.” And it's like going from the painting to the photograph.

Yeah, I think the alignment piece is still pretty hard. The alignment piece has always been hard for anyone, anywhere, right? As a company, if you have people with competing ideas, who do you pick? How do you pick? How do you figure out how to take the best ideas from some things and combine them into another? That's probably a bottleneck because this is where the most humans are still active. This is where human taste comes in.

Yeah, I think it's probably becoming more important than it maybe has been in the past.

Yeah, I think the data-driven approach really helps you in trying to figure out whether or not your taste actually resonates with people, right? And whether or not you're going in the right direction. And I think for most people, even the ones that we hold in very high regard when it comes to taste, sort of like the people behind the first versions of the iPhone, even they speak very highly of this notion of iteration and testing all the time.

Ken Kosienda has written this beautiful book called Creative Selection that I think many people have maybe read before, that talks about this combination of: you need to have a lot of taste, but then you need to validate it. I do think it's both. And when it comes to software in particular, I'm kind of wondering how far away we are from a world where software maybe feels a lot like, say, the fashion industry. And I think phones are already kind of there.

There's sort of a baseline of quality and a baseline of features that you might look towards, right? For performance clothing, there might be more secret sauce in how you actually make the thing. But otherwise, for people who build products, it really matters what kind of story you tell about the thing, what kind of onboarding you can give people, how you make people feel when they use the product. I think those things will probably be bigger differentiators than the actual raw capabilities inside.

Yeah, I think a lot about—I’ve been mentioning it so much already in our conversation, I feel almost silly about it—but I think a lot about the phone and how all of us start with the same phone, but no two phones are the same. The exact apps you have installed probably make your phone unique among all the phones on the planet. It’s almost like a fingerprint. Same with my phone. We all start with a device that probably looks very similar to the other devices, but then the way it integrates itself into our lives is not always good, not always bad, but certainly very unique and certainly very personalized.

And I think for Cowork, our approach is similar: we want something that generalizes extremely well, that we can apply to your life across a broad range of applications. And maybe just speaking from my personal life, currently in the process of moving and moving my family into a different house. And as many people, certainly the ones who are also listening in America, know, that involves about 500 pages with a lot of words that I barely understand. Cowork here is extremely helpful, but it’s also extremely helpful in healthcare scenarios.

I just had a daughter this year, and working through all of that paperwork has been super helpful, too. But these are two wildly different things, right? One of them is mortgage applications and negotiating with movers and figuring out various financial applications. And the other one is much more healthcare. In theory, those are two completely different applications of the same underlying technology. But I’m noticing that the primitives that I think about are kind of the same.

And some of those primitives are a little better. Some of them feel a little better in my hand. And I think if you pay close attention as a person who’s building things, if you use your own stuff a lot, you can sort of feel when you’re bumping into the software and it’s not making you fly. And I want to create more and more of the instances where I can fly, and I can then validate with customers that even if they might be working in industries that I barely understand, I have no idea how they work, I can sort of tell from their stories how they’re using it, what makes them fly, and what really slows them down.

And if you lean into those and you just aggressively try to enable that feeling of you're becoming more productive, you're in flow, you feel like this thing is taking over work that you find annoying, I think there's a lot of value to be found there.

I'm thinking about your question through the lens of, like, what is the hardest to replicate, right? Like, if you told me, okay, now do it again, do it with another product, what would be the most difficult to replicate? I think there's probably something about a point in time, and I mentioned that Cowork sort of came on the heels of us keeping our ear to the ground and saying, oh, there's something here, there's latent demand. Latent demand is a gift. I don't think you can go and try to look for it. You can try to find it, but it's very hard to create out of nothing.

Recreating that would probably be the hardest thing. Now, I do think software has always had ample latent demand. Like, if you looked for it, you could always find it quite a bit. That's certainly one thing that I think is hard to replicate. In terms of actually building Cowork, I would not say that anything was particularly hard. I think the things that are hard about building good products remain hard, right? Like, there's sort of the perils of success. Like, what do you do if you open up a cafe and instead of 10 people, 20 million people show up?

What do you do?

That was probably at times sometimes hard for us, and remains a challenge: the overwhelming demand for Anthropic's products. I'm probably going to be the last one to actually complain about people wanting to use my products.

I would probably recommend first not to build too much of your own infrastructure and use a product that we've launched today called Claude Managed Agents that make this particular case very useful. You know what? I'm going to give you both. I'm going to give you the advice and the reason for building custom agents and a lot of harnesses and trying to make a company on top of that. And then I'm also going to give you the case for.

The case against is that as the models get more and more capable, what I'm noticing inside my products and inside my work is that we're sort of pulling back the edge cases we account for, right? And I mentioned earlier that memory is just a text file. If Claude needs a database, it will make a database. Those are all arguments against trying to come up with a hyper-specialized product, right? Because the idea would sort of be, if we assume that the model doesn't need any of the special things that you as a builder can give it because it's just going to build it on the fly if it needs it, that's probably not the best precondition to building something.

However, at the same time, I think there is one good argument for still investing in this area quite a bit. And that is how far we'll have to go for the rest of the industry to truly harness this power. I think the internet is a beautiful example here. I think so many people who work in AI always reach for these very shiny analogies of, like, what is AI? Is it the internet? Is it the invention of the steam engine?

You can pick whatever you want, but I think there's one lesson in the internet that I find quite interesting, which is just how long it took for the internet to really transform the economy. We're talking multiple decades between the first working browser and you considering Amazon one of the behemoths of retail, right? A lot of time has passed in between. Who's on top and who's at the bottom of that list of companies, too, has changed quite a bit within that time.

And to me, that is sort of an argument to actually lean in a little bit and find some opportunities in areas where you can apply AI in a unique and novel way. However, I would probably say that, akin to everything I've said so far, a lot of the value you can provide will probably be less on the agent side. It will be less on the model intelligence, and it will be more about how do you help people organize their work, right?

How do you make that useful?

Yeah, I think, and this is a very, very personal take, but I've now been around a few of these democratizing rounds where you needed less and less arcane knowledge in order to build things. I'll give you an example, maybe just to make this slightly more apt. Many years ago, I worked at Microsoft. At Microsoft, I was working on something called Electron, which is a cross-platform—it's a way to build applications that more or less work and look the same on both Windows and macOS.

And one of the first things we used it for was Visual Studio Code, which is a code editor that has since become quite popular with people, and Cursor is built on top of it, and various other companies are. And when Visual Studio Code first was released, inside the company, there was a feeling that this is a toy. This is not for real developers because the real developers, they need Visual Studio, which is why Visual Studio Code has such a complicated long name, because Microsoft also had this big application for real developers with all kinds of fairly advanced tooling.

And what has happened since is that you just don't need to go that deep into your computer anymore. To the people who are listening who do work in software, I reminisced this week that the amount of times I had to look at assembly this year was zero. Over the last five years, it has not been zero. I've looked at assembly at least once, but it's becoming very rare. Like, it's not really a thing I look at anymore. And another thing that has happened is that Margaret Atwood, the author, has published a beautiful piece on talking to Claude and using Claude.

I'm kind of wondering what software made by Margaret Atwood would look like if she was to make it. And I think it would be quite interesting to me, and I'm pretty sure I would install it and at least use it once. And similarly, I think my prediction is going to be that we are going to have a lot more software. That software is probably going to be slightly more specialized. I don't think everyone is going to build their own software. I think people will still build things and share them with others, and others will still like to use good software that feels good.

But I think the skills required to do that will shift slightly from just being someone who speaks the computer's language and will shift much more towards being someone who speaks human language, like natural language suitable for humans.

Like, I think successful software developers 20 years ago were very good at understanding computers, right? Like, in order to build successful software, you need to be very good at computers. You were a computer expert. And I think the people who will build successful software going forward will increasingly understand humans and users very well. And I think this has been a gradient. This has already happened somewhat, right? Like, building software 10 years ago was already much easier than 30 years ago.

And I think AI is another step-function change. When it comes to the market, I am not an economist. I'm a software engineer. I've never fully understood what the markets do. And I would recommend to other software engineers not to, like, base too much of what they do on what the markets do. That is my personal recommendation. But I really do think, like, to answer your specific question, what is left to do? I think there's mountains upon mountains of things we can automate for people, work we can make easier for people, problems we can solve.

I think as long as humans have questions and problems, software will be a reasonable answer.

See, this is tricky for me because I, on principle, don't like to vaguely promise abilities or features before they actually exist. My marketing philosophy has always been: build something cool and then show it to people. One thing that I find confusing, and I don't have a good answer for, is that people everywhere seem to very quickly forget how far we've come in AI and seem to sort of be expecting that a plateau is going to come sometime soon. And I think it's probably because technology has sort of taught them that, right?

We've gotten the iPhone, and for a while, every single year of a new iPhone was a big change. And for the last couple of years, maybe it was less big of a change. As someone observing AI, I have no reason to assume that that is happening to AI anytime soon. I'd like to remind people that it's been a single number of years—four—since AI has learned how to form sentences that make any sense. Now we have AI building entire applications.

We are having it solve complex problems. And to me, this is just like, this is not the tip of the mountain, right? We're not there yet. This is part of the journey. We have reasons to believe the journey is accelerating, so the steps are going to get bigger and bigger. And I think Mythos Preview is actually a pretty good argument that this is not just a theory. The models will get smarter and smarter, and we currently have no reason to believe that an end is in sight.

What I'm going to say is that you're not the only one who's asking for Cowork for this particular regulated industry. It's something we hear quite a bit. And whenever users ask for something, we listen very carefully. That's fundamentally our job. I can't particularly comment on anything that we're currently working on, but I can sort of mention the general concept of things that I'm still excited about. And the general concept of things that I'm very, very excited about still in 2026 is really the idea of helping people organize their work in a way that makes most use of the capabilities in AI.

And if people are sort of listening to that, they're like, "What does that mean? What is he talking about?" Once upon a time, I spent five years working at a company called Slack. And Slack at the time was—we certainly felt like we were helping some companies revolutionize the way they work—but we were certainly not the first chat app. And we were also not the first company to tell you that your company will be more effective if you don't have all of these information silos.

But very similarly there, a huge part of the thing that we sold people was not just a chat application. It was this different way of working, a more transparent, more open way of working. And for AI, there's a similar change: this tool is most effective if you examine how you do work and you think a little bit about what kind of pieces you can easily give away to the model and which kind of pieces you want to have full control over.

That area is something I'm pretty excited about. The second area I'm excited about is we see there's sort of two kinds of people who currently use AI. There's people who are, as we call them, very AGI-pilled, people who sort of go all in and are excited and spend a decent amount of time thinking about, "How do I set up my Claude? What kind of tools do I give it access to? What kind of MCP connectors do I install?" They sort of end up flying, right?

And they're very effective, very productive. And then there's people who either don't care as much or are not interested enough or just don't have the time to set up all of those things. How do I reduce the amount of time you need to become one of those power users? It's something I'm pretty excited about. And the potential there, I think, is still very, very large. So in practice, if you are a Cowork user, you will probably continue to see fairly meaningful changes shipping every single week, quite a bit.

There's really no end in sight, I think.

Okay. That sounds fun.

MCP connectors are underrated because we correctly, me included, a lot of us have moved from MCPs to CLIs, but there are a lot of things that are quite inherently good about separating the data from the, I want to say, the execution engine. This is a very technical take, but it's one that I engage with people over quite a bit. Sort of MCP has kind of been the really hot thing last fall, and we're not talking about it all that much right now, but I think for most people out there, MCPs are going to be quite useful at the end of the year and next year.

And I think that's sort of the same way that maybe WebSockets are useful to people who go to Amazon or TikTok. MCP is a protocol; end users shouldn't care, but I think engineers don't care enough about MCPs.

Good question. You'd think this would be easier for me to answer because I work in AI, and we certainly have our fair share of hype everywhere. Okay, I have a hot take for you. Not every product needs a chat. This might be a fairly spicy take in AI in 2023.

I think AI can probably help with most software products. I think that is right. But I think many of my fellow software engineers have a knee-jerk reaction, which is, "Oh, you want me to put AI into my company and into my product? That means there's a sidebar on the right with a chat input at the bottom." And I would encourage my fellow AI builders to think one turn, one more turn: How do you make this thing useful?

Yeah, if you told me tomorrow, "Felix, you don't get to work with any of your friends, you have to do it alone," what do you do? I would probably go after the long tail of the industry, by which I mean there's a bunch of Windows 7 devices out there in the world that are doing menial tasks and have a load-bearing role in our society. It's kind of terrifying if you think about it, but the amount of computers that are completely out of reach for any of the modern AI that are doing important work in our society is staggering.

And I would probably think about that. The other area I would push into is, if you are somewhat convinced by the idea that artificial intelligence as a concept, right, the idea of computers not just executing predetermined functions but non-deterministically making decisions and executing on those on your behalf, I would probably push into the physical world. And that might be my recommendation for young people. I think we're still so early. I really think we're so early. It is such early days for AI, for the products that exist in AI.

And I think a thing I tell a lot of my colleagues is that we're really in the silly times of mobile phones. And then, if we get really lucky, maybe what we're currently working on is like the Nokia 3320, like a good phone, but it's not yet the smartphone. It's not yet the iPhone. Someone is going to build the iPhone.

Thank you, Matt, for having me on. That was so nice.