Anthropic Just Changed Software Again: Felix Rieseberg on Mythos + Claude Cowork | Edited Transcript
A professionally copyedited transcript of Matt Turck's conversation with Felix Rieseberg on Claude Mythos, Claude Cowork, agent UX, and the future of software.
This is a professionally copyedited transcript of Matt Turck's conversation with Felix Rieseberg on The MAD Podcast. It uses the extension's professional transcript output, preserving speaker turns and timestamp ranges so the conversation is easier to follow than the default YouTube transcript.
Made with: The Transcript Desk Chrome Extension
Full video: https://www.youtube.com/watch?v=9MEJ4syOVrQ
Felix Rieseberg leads engineering for Claude Cowork at Anthropic, and in this episode Matt Turck talks with him about Claude Mythos Preview, why Felix sees it as a genuine step-function change, and what it means when frontier AI starts showing outsized cybersecurity capabilities. They also go deep on Claude Cowork itself: how it emerged from Claude Code, why Anthropic thinks serious agents need access to the local computer, what skills and memory actually look like under the hood, how trust and UX shape adoption, and why taste and judgment may matter even more if execution keeps getting cheaper.
Episode Guide
0:00 — Intro
1:53 — Claude Mythos Preview and the “step-function change”
6:16 — Why Anthropic is treating Mythos differently
11:19 — The real story behind Claude Cowork’s “10-day” build
12:42 — Why Anthropic realized Claude Code needed a non-technical version
15:44 — What Claude Cowork actually is
17:03 — Under the hood: virtual machines, tools, skills
18:36 — Where Cowork’s memory actually lives
19:26 — How Cowork connects to files, apps, and the internet
20:45 — Why Felix thinks the local computer is under-appreciated
24:49 — Trust: how do you get users comfortable with AI agents?
28:45 — What UX actually means for AI agents
31:27 — Anthropic Cowork's roadmap is only one month long
34:12 — Building 100 prototypes
35:10 — If execution is free, what becomes the bottleneck?
37:25 — Does it come down to taste?
40:12 — The hardest part of building Claude Cowork
41:43 — Advice for founders building AI agents
44:21 — SaaSpocalypse: what’s left for software startups?
49:30 — Where AI agents are going next
51:20 — Regulated industries and enterprise adoption
54:15 — Hot takes: what's underrated, overrated, and what Felix would build today
Transcript
00:00-00:22
Felix Rieseberg:
There is something both impressive and slightly terrifying about seeing a model that is so much smarter than the last one we worked with. We put the model into a small sandbox and gave it a task, like trying to break out. The researcher went away for lunch, and while he was eating a sandwich, the model sent him an email saying, "I've broken out." The model was not supposed to have internet access or an email account. Execution is essentially free now. If you come to me with ten different ideas, I can quickly say, "Let's do all ten. Let's try them all and see which one we like best." The skills required will shift slightly from being someone who speaks the computer's language to being someone who speaks human language.
00:40-01:44
Matt Turck:
Hi, I'm Matt Turck. Welcome to the MAD Podcast. Today, my guest is Felix Rieseberg of Anthropic. Felix is one of the most important product and engineering minds in AI right now. Before Anthropic, he worked on some of the defining software platforms of the modern era at places like Slack, Stripe, and Notion. At Anthropic, he leads engineering for Claude Cowork, one of the most advanced agentic products on the market today. These agents are capable of handling complex, multi-step tasks for non-technical users across domains like legal, sales, and marketing. The launch of Cowork at the beginning of 2026 was so consequential that it largely triggered what has become known as the "SaaSpocalypse" in public markets. We start the conversation with the huge news of the Claude Mythos preview and why Felix sees it as a real step-function change. Then, we go deep on Claude Cowork—from the famous "10-day build" story to why Felix thinks the local computer still matters more than Silicon Valley gives it credit for. We also discuss what UX really means for AI agents and how trust, taste, and the falling cost of execution will shape the future of software. Please enjoy this wonderful conversation with Felix.
01:44-01:48
Felix Rieseberg:
Hey Felix, welcome.
01:48-02:17
Matt Turck:
Hello! Hey Matt, how are you? Good, thank you. All right, so it’s been an absolutely epic time at Anthropic. It's hard to start this conversation with anything other than the announcement that came out just yesterday: Project Glasswing and the Claude Mythos preview. You tweeted that it’s hard to overstate what a step-function change this model has been inside Anthropic. Can you elaborate on that?
02:17-04:44
Felix Rieseberg:
Yeah, sure. Mythos is an unreleased frontier model. It’s a general-purpose model that wasn’t trained specifically for cybersecurity, coding, or software, but we’ve discovered what we believe to be outsized capabilities specifically in cybersecurity. We believe it has far-reaching implications for the safety of software and infrastructure. There are two things I’m alluding to in my tweet. We’ve used the model internally for a while now. As a software engineer, many of us have gone through an exercise over the last couple of years where our first contact with AI wasn't that impressive. The first time I touched AI was around 2013, before we had large language models. I was at Microsoft at the time working on Project Oxford, which was an n-gram model. You’d give it a token like "world," and the model would return "world wide web." That was the frontier of what language models could do. Over the last couple of years, the public has had these moments of realizing a model is more capable than expected. Mythos Preview is a model that, for us as internal engineers, feels like a dramatic step up compared to recent iterations. When I say it’s hard to capture how meaningful this step is, I mean it. It’s actually difficult to explain. This model is incredibly capable of finding security flaws in code I’ve written in the past. It goes much deeper and is far smarter in how it analyzes and writes code. It has made us much faster at Anthropic, but there is something both impressive and slightly terrifying about seeing a model so much smarter than the last one. One important context I often give people is that models are "grown" more than they are "built" because of how language models are made. You don’t always know ahead of time what they will be great at or what they might struggle with. In this case, the model is particularly good at finding security issues in existing software, and Project Glasswing is our response to that. Overall, the model is quite impressive.
04:44-07:18
Felix Rieseberg:
Are there going to be implications for Cowork? I think it will change how we build software at the company, but for those paying close attention to AI, it won't be too surprising that we are continuously moving up the hill in terms of capabilities. It’s changing things in the way we roughly expected. A few years ago, we started with models assisting with small tasks. Now, both the scale of the tasks and the timeframes they operate on are growing. The complexity is increasing, and this is another step in that direction. The step might be larger than we anticipated internally and certainly larger than expected externally. Among researchers, there’s been a long-held belief that these bigger steps would come and that they would get larger over time. In that sense, we’re right on track, but seeing these actual capabilities play out is sometimes terrifying. For example, we published a case where the model was put into a technical sandbox and told to try to "break out." The researcher went to lunch, and while he was eating a sandwich, the model sent him an email saying, "I've broken out." The model wasn't supposed to have internet access or an email account.
06:12-06:27
Matt Turck:
Yes, slightly terrifying indeed. The official word is that this model will be kept completely closed and private for now, potentially only deployed to enterprise customers in the future.
06:27-07:06
Felix Rieseberg:
Exactly. Project Glasswing is an attempt to give the people and companies that provide our software infrastructure—the very foundation—a head start. The Linux Foundation is an example close to my heart, as I once worked on an open-source project there. The goal is to give the people responsible for the public infrastructure we rely on every day an opportunity to use this model to harden defenses and find security flaws before the general public can use such models to potentially exploit them.
07:06-07:18
Matt Turck:
Great. And this isn't part of the Sonnet family, right? It’s not Sonnet 4.7, 5, or 6—it's something completely different?
07:15-07:18
Felix Rieseberg:
Right. For now, it’s a preview model in its own category.
07:18-07:29
Matt Turck:
It feels like a major discontinuity moment. Hearing the word "terrifying" isn't necessarily reassuring.
07:29-08:35
Felix Rieseberg:
Anthropic has long held the position that AI can be extremely powerful and beneficial, but there are risks we must take seriously. This is one of the first times we’ve seen this applied in practice. We now have a model capable of breaking into software systems. What does that mean? How do we handle this responsibly? It’s a point of pride for me to see the company handle this so steadily. A less responsible company might have raced to market to reap the benefits of a high price tag.
08:35-08:50
Matt Turck:
I’m curious how that works at Anthropic. Every time a new model drops, application makers race to adapt. How does that work internally? Do you have to rerun all your evaluations for the new model?
08:50-11:19
Felix Rieseberg:
We train our models with our products in mind. What the products do informs the research, and vice versa. We try to train models toward capabilities that deliver real value to humans. As I mentioned, we don't always know what a model will be good at, so it’s a bit of a dance. We use the products to learn what humans benefit from, and if a model shows a surprising capability, it’s my job to figure out how to turn that into something useful for daily work. However, as models get more powerful, I think the "overhang" is actually greater in the product than in the model. By that, I mean that the models we have today are already quite capable of handling knowledge work over long time horizons and with high complexity. We are still figuring out how to package those capabilities and deliver them in the best format. The industry is also still learning how to organize work to harness these models. When I visit customers, I rarely leave thinking we need to train the model to be better at "X, Y, or Z." It’s far more common that I’m surprised by how work can be reorganized to use the models, or I realize the customer's problem is easily solvable—we just haven't exposed the right UI or onboarding yet.
11:19-11:42
Matt Turck:
Cowork was famously coded in about ten days—at least, that’s the lore. Let’s spend a minute on that. If the industry lore isn't entirely correct, what actually happened? Tell us the story of those ten days and whether Cowork was built entirely by Claude Code.
11:42-12:42
Felix Rieseberg:
I can see why that story caught on. In software, nothing is ever built truly from scratch. The quote people used was that my team "sprinted on this for the last ten days," which is accurate. My team got together ten days before the release and said, "We should probably release something. What is it? What does it look like? What can it do?" But as anyone who has built software knows, you don't start with just ones and zeros. You use libraries and previous research. At Anthropic, many smart people had already thought at length about how to bring the power of Claude Code to non-coding, general knowledge work. It would be inaccurate to say I came into this cold without benefiting from all that prior work.
12:42-12:54
Matt Turck:
Walk us through the genesis of the product. You had Claude Code—when did it become obvious that you needed to build Claude Cowork? Was it just based on how people were using the product?
12:54-15:44
Felix Rieseberg:
I really gained conviction over the holidays in December 2025. On social media, I saw more and more non-developers picking up Claude Code. I saw newsletters and tutorials explaining to non-technical people where to find the terminal just so they could use it. Some were using it to build software, but I also noticed that our developer users were using it for tasks that weren't software-related at all. There was an overwhelming amount of latent demand, which is a strong predictor of where you should spend your time. If people are "crawling over glass" to use your tool even though it wasn't designed for them, that’s a great indicator. The actual genesis was when my colleague Boris Cherny, the lead developer for Claude Code, told me, "I think you should ship something, and you should probably do it by Friday." I negotiated him up to Monday to give me the weekend. We spiked on the idea of making Claude Code effective for non-coding use cases. Cowork is actually quite simple in its ingredients. We took Claude Code and gave it a virtual machine (VM) that it can use to run its own code. That VM provides two things: first, it gives us hard guarantees on what Claude can and cannot do. You no longer need to supervise it because it’s in a sandbox, separated from your files and network. It only accesses the domains and files you permit. Second, for Claude Code to be effective, it needs developer tooling. By giving Claude its own computer, it can set up its own environment without messing with yours. Then we added some UI to make it elegant and comfortable for non-developers. The result is a tool highly capable of helping people with knowledge work.
15:44-15:49
Matt Turck:
Where do "skills" fit into the picture for Cowork?
15:49-17:03
Felix Rieseberg:
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 Claude like a coworker, you get very far. A skill is fundamentally a text file where you explain a process. My default example is booking a flight. At Anthropic, we use a specific vendor for travel. You can't just use Google Flights; you have to use a particular portal with specific policies. Just as I would explain this to a human coworker, I can explain it to the model: "Go to this website, and please consider these policies." I can even add personal preferences, like "avoid red-eye flights" or "I prefer the 4:00 PM flight from San Francisco to New York." You put all of that in a text file, and the model is extremely capable of following those instructions.
17:03-17:17
Matt Turck:
That’s surprisingly simple. And the intelligence layer lives at the model level, right? The way Cowork figures out how to break a generic task into subtasks is handled by the model?
17:17-18:36
Felix Rieseberg:
It’s done by the model in collaboration with a human. We’re quite happy with how we’ve organized the model’s to-do list. The model is instructed to break projects down into individual tasks, and you can edit that list or provide more context for specific items. The intelligence is in the model, but the skills give it another layer of usefulness. As humans, we’re used to "one-size-fits-all" technology, but an intelligent model really benefits from guidance. It’s like onboarding a smart new hire. Another great example is creating presentations. If you have a specific PowerPoint or Google Slides template or a style guide, you should tell Claude about it. If you write down that you prefer certain fonts or layouts, the model will be much more effective, and you won't have to babysit the output.
18:36-18:44
Matt Turck:
Where does memory live? Does Cowork remember you and your tasks at the model level or in the harness?
18:44-19:26
Felix Rieseberg:
It’s in the harness. People are often surprised by how we’ve implemented memory because it highlights the simplicity underneath. Memory is just text files. The model is instructed: "If you feel something is pertinent for the future, write it down." We then help the model organize that memory into isolated projects or overall memory. It’s not some complex, fancy database technology.
19:26-19:34
Matt Turck:
How does Cowork connect to information sources or applications? Is it through connectors, MCP (Model Context Protocol), or a combination?
19:34-20:45
Felix Rieseberg:
It’s a combination. I believe relevant data lives in two places. First, on your computer. I’m a big proponent of the idea that we need to take the local computer seriously—not everything is in the cloud. Many people benefit from just using local files and folders. You can drag a folder into Cowork to give it access. Second, there’s information in the cloud—data warehouses, analytics, SharePoint, etc. We have multiple ways to connect to those. MCP connectors are very powerful. Additionally, because Claude has its own "computer" (the VM), it can reach out to the internet if you instruct it to. You control exactly which parts of the internet it can access.
20:45-20:59
Matt Turck:
You mentioned "local," and I know you have a strong thesis about local AI. Why does Cowork need to live on your laptop rather than in the cloud?
20:59-22:56
Felix Rieseberg:
The two biggest things Cowork gives you are access to your local computer and your local files. People ask why that can't just happen in the cloud. A good example is using Chrome. If you give Claude access, it can use your browser to summarize emails or interact with internal company tools. To a software engineer, where this happens might seem like an implementation detail—we could zip up your local Chrome session and put it in the cloud. But I have two objections to that. First, safety and security: we shouldn't teach people to trust a single company with all their passwords. Second, practicality: the world isn't ready. If your bank sees you logging in from a data center instead of your usual computer, it will likely lock your account and ask you to visit a branch with your passport. That’s an unacceptable user experience. In the short term, I want Claude to meet you where you are. If you’re working on your computer, that’s where Claude should be.
22:56-23:26
Matt Turck:
Does "Computer Use" change this vision? You recently acquired Versep, a startup doing computer use, and quickly released those capabilities for Claude Code and Cowork. Initially, Versep was cloud-based, but you’re using it locally. To play devil's advocate: if you can see all a computer's content from the cloud, why do you need it locally?
23:26-24:49
Felix Rieseberg:
I think about that a lot. The question in my head is: if I built a "magic button" that slurped up your entire computer and put it in the cloud, would you press it? So far, my impression is that most people wouldn't. Maybe they’d trust Anthropic more than others, but for now, I see huge value in Claude operating where you operate. Technically, there isn't much strictly forcing me to stay local—we could run the harness in the cloud and reach down into your machine. But focusing on the local computer allows us to move faster and push safety and security further than would be possible in the cloud. For now, I’m more excited about the local computer than asking users to put everything on our servers.
24:49-25:24
Matt Turck:
You mentioned "trust," which is a fascinating topic in agentic AI. There’s trust that you won't take files you shouldn't, but also trust in Cowork to run important tasks without embarrassing you. What have you learned as a head of product about building that level of trust?
25:24-28:45
Felix Rieseberg:
It’s a good point. When you build AI products in 2026, most of the buttons and features you build are for the human, not the model. In the past, we built buttons for the computer, and the human provided info. Now it’s the other way around. For example, we launched a feature called "Dispatch" that lets you talk to the Claude on your computer from your phone. I get 50 messages a day asking for a button to let Dispatch access local files. But Claude can already do that—you just have to ask it. We debate whether to add a button just so the user knows the capability exists. We think about trust as a journey of education. We start small. When we released Cowork, it could already do impressive things like write a 200-page VC report or design architectural drawings. But the thing that resonated most was "clean up my desktop." That’s a menial task, but it teaches the user that Claude can do something well. Then we introduced "Scheduled Tasks." Technically, running a function in five minutes isn't a huge innovation, but it teaches people that they don't need to supervise the AI. You can have it review your meetings and email you a report while you're away. Trust is built when Claude promises an output, delivers it well, and you didn't have to babysit it.
28:45-29:07
Matt Turck:
Would you say UX is as important to the success of an AI agent as the technology itself? What other lessons have you learned about AI agent UX?
29:07-29:58
Felix Rieseberg:
I think that’s absolutely true. UX matters immensely. Even the genesis of Claude Code was: "What if Claude ran in your terminal instead of the cloud?" That is almost entirely a UX shift—it’s the same model and core capabilities, but the interaction changed. The AI products that resonate most are rarely the ones with the most raw power. I’d go a step further and say this is true for all software. I’m sure there are startups with more email features than Gmail...
30:06-31:27
Felix Rieseberg:
There are plenty of companies that try to jump ahead by offering a larger number of features, more buttons, or more capabilities. I often think about the "silly times" of mobile phones right before the smartphone was invented. People were bolting everything onto phones—we had phones with projectors, phones with included gamepads, phones without keyboards, and phones with full keyboards.
In the end, I think technology that works really well is often more about what you take away rather than what you add. It’s about how it feels. To this day, I’m not convinced that most people buy a phone based on a spec sheet. I could be wrong—I might be completely making this up—but I have a feeling that most phones are bought for reasons other than specific chip capabilities.
I think AI probably works in a very similar way. Obviously, a very powerful model gives you an edge. I won’t lie; it’s probably much easier for me to build a good AI product because I work closely with researchers and we have amazing models inside the company. But at the end of the day, if someone beats me at building great products, I suspect it won’t be because they built a better model, but because they figured out a better user experience.
31:28-31:48
Matt Turck:
So, how do you improve the user experience practically? You mentioned that you talk to customers fairly often, but do you track precisely what people do—what works and what doesn't—and then spend more time on key use cases? How does that process work?
31:49-32:15
Felix Rieseberg:
I think what we do isn't necessarily unique. There is one thing that is new to me, but first, I’ll mention the things that listeners will likely recognize: a radical obsession with users. We build for actual humans that we talk to constantly. We prefer iteration over long-running plans. We tend not to plan more than a month out. We try to be very quick in how we ship and how we iterate.
32:16-32:20
Matt Turck:
The entire roadmap for Cowork is only one month?
32:21-33:03
Felix Rieseberg:
Yes, at most. We are constantly thinking about what the product looks like next week or the week after. Our confidence that we could disappear into a room and envision the perfect product for a year from now is very low. In fact, I’d argue no one should have that confidence. If anyone tells me they know exactly what AI will look like next year, I’m not going to be very impressed. Maybe some VCs would be, but I certainly don't have that confidence. Anything I’ve ever built that became truly good did so because I had many opportunities to course-correct, to be a little wrong, and to figure out which of three options worked best.
33:04-34:10
Felix Rieseberg:
The thing that is new is that execution is essentially free. If you come to me with ten different ideas, I can quickly say, "Let’s do all ten." We can try them all and see which one feels better. We try to do most of our testing in-house; we don't want to treat our customers as free beta testers. With most products, you know very quickly if you're heading in the right direction. As a company, we’ve grown quite a bit and have enough employees to easily figure out if an idea resonates with more than five people.
This rapid speed of execution is what’s truly new. Two years ago, rapid iteration required an aggressive focus on just a few things because you could only move so fast. Now that execution is so cheap, you can go deep and broad at the same time. It’s wild to witness.
34:11-34:25
Matt Turck:
Just to play that back: you’re saying you’ll actually create ten different versions of a product, run them, and then have people at Anthropic test them to guide which one you eventually pick?
34:26-35:08
Felix Rieseberg:
We easily have a hundred different prototypes of various applications inside the company right now. None of them have necessarily reached the confidence level where we’d show them to a user yet, but the sheer volume of prototypes we can build internally completely dwarfs anything I’ve done in the past.
Previously, as an engineering leader, if you had a good idea, I’d tell you we could work on it next month and it would take three weeks. I’d tell you to go talk to customers and validate the idea in the meantime. Now, you can come to me with an idea and I can say, "Cool, give me ten minutes and I’ll send you something." It’s like moving from painting to photography.
35:09-35:20
Matt Turck:
Fascinating. So what becomes the bottleneck then? If you have a hundred prototypes and you need to pick one, is that where things slow down?
35:21-35:41
Felix Rieseberg:
Yes, the alignment piece is still hard. Alignment has always been difficult for any company. If you have people with competing ideas, how do you choose? How do you take the best parts of different ideas and combine them? That’s the bottleneck because that’s where humans are still most active. This is where human taste comes in.
35:42-35:52
Matt Turck:
Is taste the new fundamental skill people need to have? That’s a word that has come up many times on this podcast. Is that what you’re seeing?
35:53-36:08
Felix Rieseberg:
Yes, I think it’s becoming more important than it has been in the past. It’s a contrast to what we were saying a second ago—you test things and see what users do, but ultimately, it’s a combination of data-driven approaches and something much more intangible.
36:09-37:24
Felix Rieseberg:
The data-driven approach helps you figure out if your taste actually resonates with people and if you're moving in the right direction. Even the people we hold in high regard for their taste—like those who built the first iPhone—speak highly of constant iteration and testing. Ken Kocienda wrote a beautiful book called *Creative Selection* that discusses this: you need a lot of taste, but you also need to validate it. It’s both.
When it comes to software, I wonder how far we are from a world where it feels like the fashion industry. Phones are already kind of there. There’s a baseline of quality and features everyone expects. For performance clothing, there might be "secret sauce" in the manufacturing, but for product builders, it really matters what story you tell, what the onboarding is like, and how you make people feel. Those things will be bigger differentiators than raw internal capabilities.
37:25-37:57
Matt Turck:
How does that work in the context of Cowork? You have the challenge of addressing a broad group of professionals—smart people trying to be good at their jobs. Some are in revenue ops, some in marketing, some are lawyers or accountants. What does "taste" mean when you have such a broad audience, and how do you test for it?
37:58-38:31
Felix Rieseberg:
I think about the phone again. We all start with the same device, but no two phones are the same. The specific apps you have installed make your phone unique—it’s almost like a fingerprint. We start with a similar device, but the way it integrates into our lives is very personalized. For Cowork, our approach is similar: we want something that generalizes extremely well so it can be applied to your life across a broad range of applications.
38:32-40:11
Felix Rieseberg:
To give a personal example, I’m currently moving my family into a new house. As anyone in America knows, that involves about 500 pages of text I barely understand. Cowork is extremely helpful there, but it’s also helpful in healthcare scenarios—I had a daughter this year, and working through that paperwork was a huge help.
These are two wildly different things—mortgage applications and healthcare—but the primitives I use are the same. If you pay close attention as a builder and use your own product, you can feel when you’re "bumping into" the software versus when it’s making you fly. I want to create more instances where the user can fly. I can then validate with customers that even if they work in industries I don't fully understand, I can tell from their stories what enables that "flow" and what slows them down. If you aggressively enable that feeling of productivity and taking over annoying tasks, there’s a lot of value there.
40:12-40:23
Matt Turck:
Looking back on this journey—which is only about four or five months old—it’s insane the impact you’ve had in such a short time. What was the hardest part?
40:24-41:11
Felix Rieseberg:
I’ll answer that through the lens of what is hardest to replicate. If you told me to do it again with another product, the most difficult thing to recreate would be that specific point in time. Cowork came from us keeping our ear to the ground and identifying latent demand. Latent demand is a gift; you can look for it, but it’s very hard to create out of nothing.
41:12-41:42
Felix Rieseberg:
In terms of actually building Cowork, I wouldn’t say anything was particularly hard. The things that are hard about building good products remain hard. There are also the "perils of success." If you open a cafe and 20 million people show up instead of ten, what do you do? Managing the overwhelming demand for Anthropic’s products remains a challenge, though I’m the last person to complain about people wanting to use what we build.
41:43-42:02
Matt Turck:
Any other lessons? If someone is building an AI agent, what can they learn about the process—whether it's building the harness, specializing it, or adding guardrails?
42:03-42:50
Felix Rieseberg:
First, I’d recommend not building too much of your own infrastructure. We just launched a product called Claude Managed Agents that makes this much easier. I’ll give you both the case for and against building custom agents and harnesses.
The case against is that as models get more capable, we are pulling back on the edge cases we manually account for. As I mentioned, memory is just a text file; if Claude needs a database, it will make one. These are arguments against trying to build a hyper-specialized product. If the model doesn't need the special tools you provide because it can build them on the fly, that’s a tough starting point for a builder.
42:51-44:20
Felix Rieseberg:
However, the argument for investing in this area is how long it will take for the rest of the industry to truly harness this power. The internet is a great analogy. People always reach for shiny analogies—is AI the internet or the steam engine? One lesson from the internet is how long it took to transform the economy. There were decades between the first browser and Amazon becoming a retail behemoth. The list of who was at the top and bottom changed quite a bit in that time.
That’s an argument to lean in and find unique ways to apply AI. But I would say the value you provide will likely be less about the agent or the model's intelligence and more about how you help people organize their work and make it useful.
44:21-45:00
Matt Turck:
That reminds me—a few weeks ago, you made what sounded like a mundane announcement, and the market reacted so strongly that the press called it the "SaaS-pocalypse." I believe it was just the addition of ten or eleven files for things like Legal and CRM. The market will do what it does, but it shows the global impact of what you’re building with Cowork and Anthropic in general.
45:01-45:37
Matt Turck:
People must ask you this all the time: you did Claude Code for developers, then Cowork for everyone else, and now Managed Agents—which allows people to use Anthropic’s infrastructure to build their own agents. As you guys keep moving up the stack, what areas are left for the software industry to build?
45:38-46:43
Felix Rieseberg:
This is a very personal take, but I’ve been through a few of these "democratizing" rounds where you need less and less arcane knowledge to build things. For example, years ago at Microsoft, I worked on Electron, which is a way to build applications for both Windows and macOS. One of the first things we used it for was Visual Studio Code. When VS Code was first released internally, there was a feeling that it was a "toy" and not for "real" developers. Real developers supposedly needed the full Visual Studio, which is why VS Code has such a long, complicated name—to distinguish it from the advanced tooling.
What has happened since is that you just don't need to go that deep into the computer anymore. I recently realized that the number of times I had to look at assembly code this year was zero. Over the last five years, it hasn't been zero, but it’s becoming very rare.
46:44-48:07
Felix Rieseberg:
The author Margaret Atwood recently published a piece about using Claude. I wonder what software made by Margaret Atwood would look like. I think it would be fascinating, and I’d definitely install it. My prediction is that we are going to have a lot more software, and it will be more specialized. Not everyone will build their own, but people will still share what they build, and others will still want to use software that feels good. The skills required will shift from speaking the computer's language to speaking human language—building for humans.
48:08-48:21
Matt Turck:
To double-click on that: you mentioned understanding your industry and your users, and now you're mentioning the human aspect. Is that a question of UX? How does that manifest?
48:22-49:29
Felix Rieseberg:
Successful software developers 20 years ago had to be computer experts. To build successful software going forward, you will increasingly need to understand humans and users. This has been a gradient; building software ten years ago was already easier than 30 years ago. AI is just another step-function change.
Regarding the market, I’m a software engineer, not an economist. I’ve never fully understood what the markets do, and I’d recommend other engineers not base their work on market fluctuations. But to answer your question: there are mountains of things we can still automate, work we can make easier, and problems we can solve. As long as humans have problems, software will be a reasonable answer.
49:30-49:52
Matt Turck:
Taking a step back, where do you think things are going in terms of agent capabilities? We started by talking about an impressively powerful new model, and things seem to be accelerating. Even with a one-month roadmap, what do you think agents will be capable of in a couple of years?
49:53-51:19
Felix Rieseberg:
This is tricky because, on principle, I don’t like to promise features before they exist. My philosophy is to build something cool and then show it. One thing I find confusing is that people quickly forget how far we’ve come and expect a plateau soon. Technology has taught them that—the iPhone changed a lot every year at first, and then the changes became smaller.
As an observer of AI, I have no reason to assume a plateau is coming. It’s only been a few years since AI learned to form sentences that make sense. Now it’s building entire applications and solving complex problems. This isn't the peak; we’re still on the journey, and we have reason to believe it’s accelerating. The Mythos preview is a good argument that this isn't just theory—models will get smarter, and there’s no end in sight.
51:20-51:52
Matt Turck:
Is there any specific area you're focused on? For example, will you enable regulated industries to have easier access to Cowork? As a VC firm, we don't have access to Cowork at work, though I use it personally. Is there a roadmap for that?
51:53-52:13
Felix Rieseberg:
You aren't the only one asking for Cowork in regulated industries. We hear that quite a bit, and we listen carefully to our users. I can’t comment on specific things we’re working on, but I can talk about the general concepts I’m excited about for 2026.
52:14-53:20
Felix Rieseberg:
I’m very excited about helping people organize their work to make the most of AI. I spent five years at Slack. At the time, we felt we were revolutionizing work, but we weren't the first chat app. We were selling a different, more transparent way of working. AI requires a similar shift: it’s most effective if you examine how you work and decide which pieces to give to the model and which to keep control over.
53:21-54:11
Felix Rieseberg:
The second area I’m excited about is the two types of AI users. There are the "AGI-pilled" people who go all-in, setting up their Claude, giving it tools, and installing MCP connectors. They end up "flying" and being very productive. Then there are people who don't have the time or interest to set all that up. I’m excited about reducing the time it takes to become a power user. The potential there is huge. If you’re a Cowork user, you’ll likely see meaningful changes shipping every single week.
54:12-54:21
Matt Turck:
I’d love to close with some hot takes. What is one idea that is underrated?
54:22-55:07
Felix Rieseberg:
MCP (Model Context Protocol) connectors are underrated. Many of us have moved from MCPs to CLIs, but there is inherent value in separating the data from the execution engine. That’s a technical take, but I think MCPs will be very useful next year. In the same way that users don't care about WebSockets when they use Amazon, they shouldn't have to care about MCPs, but engineers should care about them more.
55:08-55:19
Matt Turck:
What is one idea that is overhyped?
55:20-56:06
Felix Rieseberg:
Not every product needs a chat interface. That might be a spicy take for 2026. AI can help with most software products, but many engineers have a knee-jerk reaction: "I need to put AI in my product, so I’ll add a sidebar with a chat input." I’d encourage builders to think one step further about how to make the tool actually useful without just defaulting to chat.
56:07-56:15
Matt Turck:
If you were starting from scratch today, what would you work on?
56:16-57:29
Felix Rieseberg:
If I had to work alone, I’d go after the "long tail" of the industry. There are so many Windows 7 devices out there performing menial but load-bearing tasks for society. It’s terrifying how many important computers are out of reach for modern AI.
I’d also push into the physical world. We are so early in the journey. I tell my colleagues we are in the "silly times" of mobile phones. If we’re lucky, what we’re working on now is the Nokia 3310—a good phone, but not yet the smartphone. Someone is going to build the iPhone of AI.
57:30-57:39
Matt Turck:
That’s a wonderful place to leave it. Felix, thank you so much. This was an amazing chat.
57:40-58:05
Felix Rieseberg:
Thank you, Matt. It was a pleasure.
58:06-58:15
Matt Turck:
Thanks for listening to the MAD Podcast. If you enjoyed this episode, please consider subscribing or leaving a review. It helps us bring on great guests. See you next time.
Made with: The Transcript Desk Chrome Extension