Anthropic 的 Felix Rieseberg 谈 AI 同事、本地优先智能体与知识工作的未来

This is maybe where I hold a somewhat contrarian view to a lot of people in AI. I actually don't think that the future is going to be hyper-personalized software, down to the point where everyone is running their own version. I think it's going to be quite helpful on the bus to have our own internal chat tool.

Silicon Valley overall is undervaluing the local computer. My default argument for that is always: how come we're all using MacBooks and not an iPad or a Chromebook? Now, when I think about Claude, it's this entity that's supposed to be tremendously useful to you. I think that entity needs to have access to all the same tools you have access to. Otherwise, it's going to be hamstrung in all these complex ways.

[music]

Hey everyone, welcome to the Latent Space podcast. This is our first one in the new studio at Kernel Loop. This is Alessio, founder of Kernel Labs, and I'm joined by swyx, editor of Latent Space.

Yeah, so nice to be here. Thanks to TJ, Alessio, and Alan for helping to set everything up. It looks beautiful. We even have the logo outside.

When you walk in here as a guest, you're like, "Oh, this is a serious production." You feel it immediately. Felix, you're currently product manager of Cowork. Every year, we change titles.

Member of technical staff.

I know. Member of technical staff is the official title we'll carry around forever. I've been using Cowork a lot, even for managing Latent Space. It helps me upload videos, title things, edit, and everything. It's really amazing.

He said multiple times that Cowork is AGI in the group chat.

We have a second channel for Latent Space TV. This is our Discord meetup, and we have this idea that Claude Cowork might be AGI. I don't know if we've uploaded it yet, but 1 of the sessions was a Claude Cowork thing.

I would love to see it. I'm so curious. One of the most fun parts of my job is constantly seeing the weird things people use Cowork for, because it's obviously very hard for us to design for specific use cases. We do, but every person who's most amazed is usually amazed by something that I didn't even expect Cowork would be good at.

We have a new designer, and it was one of his first small tasks. I said, "Hey, we need a new emoji for Cowork for our internal Slack." It's a pretty small thing. I said, "Can you please do it?" He drew an SVG and just gave it to Cowork. I said, "Can you make this emoji?" Now it has this beautiful loopy animation.

I think, obviously, this goes down to a ton of stuff. You can do more things with code than you expected. But it's that kind of stuff that's really fun to me.

Long story short, I would love to see the kinds of things you're doing. I'll pull it up. But before we get into it, I always want to start with a top-level question: what is Claude Cowork for people who haven't heard of it or tried it out?

Claude Cowork is a user-friendly version of Claude Code. The way it basically works is that we have Claude Code, which for us is a fairly impressive agent harness. In December, we noticed more and more people were using it even though they weren't technical. They weren't at home in the terminal, or they were at home in the terminal but had started using Claude Code for non-coding workloads, like managing expenses, filling out receipts, or organizing a knowledge base. There was a big Obsidian moment that a lot of people liked.

We wanted to capitalize on that, but also bring this capability to people who aren't terminal-native and might not know how to brew-install something. So, Cowork is Claude Code running in a virtual machine, with a little bit of padding and a few more guardrails, making it a little safer and more convenient for people who don't want to first open up the terminal when they go to work.

It's interesting that it's pitched that way as a more user-friendly thing, because I always feel like—I'm familiar with Claude Code. We did a Claude Code episode about 1 year ago. But this one has even more power-user tools, because it integrates much better with Claude in Chrome and all the other tooling. Maybe that's a perception thing, right?

No, honestly, I don't think you're wrong. This is something I've been thinking about a lot over the past few weeks.

When people say "user-friendly," they mean, "Oh, it's the dumbed-down version."

But no, actually, this is the superset. A similar thing happened to me about 10 years ago, maybe 12 years ago, when I was at Microsoft and we started working on Electron, browser-based technologies, and cross-platform stuff. One of the first use cases was Visual Studio Code, which used to be a website. The initial narrative was, "Visual Studio Code is a more user-friendly version of Visual Studio." But in a similar vein, there were voices saying, "This is not for serious developers. We're not going to use this for anything."

I think people have different stories about why Visual Studio Code became such a big thing, but my personal belief is that the hackability and extensibility played a pretty big role. You can hook Visual Studio Code into almost any workload. It's so easy to hack on and so easy to build extensions for. I think Cowork might be hitting something similar, where it's very easy to extend and very easy to bring into your workflows.

The convenience is obviously the thing we strive for as developers. But the way people find value in it is probably by mapping it onto whatever they actually have to do in their job.

At the end of last year, you saw the spike in nontechnical usage in Claude Code. What's the design process that led you to say, "We should make Claude Code work this way"? You built that in only 10 days. I'm sure there was some discussion beforehand about what "easier to use" means. Making a desktop GUI is obviously one way to do it, but there's a lot of nuance in the product.

Maybe talk people through what triggered the decision: "We should build a separate thing," and why we shouldn't build a different Claude Code thing. Then, maybe some of the more interesting design decisions that you didn't make.

At Anthropic, we've been thinking about ways to move people who are comfortable with using Claude as a question-and-answer tool toward bringing more of the power of this thing to bear—to execute tasks for you, solve problems for you, or build things for you. How do we bring that capability to people who are currently mostly comfortable with a question-and-answer paradigm within chat?

We've had a lot of prototypes around that, going back easily 1.5 years. We had a lot of people working on it. Internally, Anthropic is a very prototype- and demo-first culture. We have a lot of internal prototypes that don't reach the public. What Cowork became is that we picked the right pieces out of the many prototypes we had.

That's also an important qualifier whenever people mention the 10-day number. We didn't start from scratch. There was already a lot of stuff happening. It's important for people to remember that when you build a website, you use React and a bunch of other things. This was a similar scenario, with a lot of pieces we already had.

In terms of decision paths, we live in an interesting new world where execution is actually quite cheap.

I mean, what you're saying is crazy to hear. That was wild. You should be saying, "Ideas are cheap; execution is the hard part."

No, but we used to live in this world where you would take a product manager, and the product manager would go to a number of potential customers and, in this very low-bandwidth way, try to tease out what problems they were having and what they were willing to buy. Then you would think about what you could build to address that need. You'd go back, draft a spec, think about it, make a design, and execute it.

At Anthropic, we're now probably much closer to the point where you don't even write a memo. You just build all the candidates very quickly. Let's build all of them and then pick the best ones.

I think the decision that's most impactful, both for the product and for the users right now, is the way we put value on your local computer. That's a big decision point. A lot of people have thought about whether this thing, whatever it is, should ultimately run on your computer or in the cloud, because there are trade-offs.

I guess if we solve auth, it would be easy to do in the cloud. But the fact that I can just download any file from anywhere and then put it in Cowork is a big unlock.

It's interesting that you mention reusing certain pieces. This is something I've been thinking about even with Claude Code. The price of writing code is going to zero, blah blah blah, but it actually seems like the value of having some sort of platform substrate is increasing, because as you build these new things, you can plug them together.

Yeah. So I almost feel like when people are saying, “Oh, the value of a lot of software is going to zero because you can recreate it,” to me it’s almost the opposite. Having an existing platform to build on top of is even more valuable because you can bolt things on. You have MCPs, you have skills, and you have the models, which are obviously a big part. All these things come together.

Do you feel like that’s a valid way to think about it? Should people invest even more in these primitives to rebuild on, or are you recreating a lot of it each time because things change and it’s easier to rewrite than reuse?

You know, I think you’re right. I think you’re right that the holistic platform is really useful. This is maybe where I hold a somewhat contrarian view to a lot of people in AI. I actually don’t think the future is going to be hyper-personalized software to the point where everyone is running their own version. I think it’s going to be quite hard for all of us to have our own internal chat tool. If I want to talk to you, how is that going to work?

In the context of Claude Cowork and how we build it, I think it’s a combination. The execution that gets cheap isn’t necessarily rebuilding all the primitives. A priori, there’s also not a lot of value in it. For instance, my team didn’t think about rebuilding Claude Code. We very much started with the core thesis that this should be Claude Code.

Mhm.

And then we built things on top of it. The part of the execution that gets a little cheaper is: how do you take all of these Lego pieces and put them together in a way that makes sense for users? That is actually valuable.

You have so many different approaches now in terms of what kinds of things you actually elevate to a primitive. Do you strongly believe that all your products should be built by just combining primitives that are available to all of us, or is it valuable to keep some things internal?

I think that’s still evolving. But I think what’s probably going to go away—I’m not sure if it’s going to fully go away, but I’ll say this: for me personally, I will probably no longer try to come up with a really good product without testing it out with people.

This isn’t a new concept, but wherever you used to have to make costly decisions around whether to pick technology A or technology B, or whether to build it this way or the other way, I really strongly believe that now you just build all of them and try them out with a small focus group. Whatever is better is what you go with. That is probably quite different even from how we worked a year ago. I think this happened very recently.

Yeah, I started building something in Electron since you’re here. Coincidence. But then Electron and SQLite had some issues between development and building, anyway. I was like, “I’ll just rebuild the whole thing in Swift.” So I recreated the whole thing in Swift, and it’s done, you know? It didn’t take any effort. I don’t even know Swift. [laughter]

Yeah, exactly. I was like, “I’m not reviewing it anyway. Whatever, you can write it in whatever language you pick.” But the important stuff that I did was not write the Electron bindings. It was the logic of what happens in the app. Then the model was like, “Yeah, I can just recreate the same thing in Swift.”

Yeah, I think you still want, especially for people who are doing high-performance software or really complex software, some view of the architecture. But you can use Markdown for that. Right. [laughter]

Can we build a good mental model of Claude Cowork? This is what I have: fundamentally, Claude Cowork—we don’t want to touch it. There’s the Claude app, and there’s Claude in Chrome. I think you guys do something different in planning. I’ve been talking with someone on the Claude Cowork team, and they said, “No, we just exposed planning.” Maybe you can clarify it. What are the major pieces that people should be aware of that go into Claude Cowork?

Okay, I think you basically have them. You can take planning more or less out. I think there are a few things that are really valuable in Claude Cowork. The virtual machine is probably the most powerful thing. We currently run a lightweight VM, and we put Claude Code into the VM. We do that for a number of reasons. Safety and security are a big one.

But even if you ignore safety and security for a second and you’re just like, “Okay, YOLO, I want this thing to do whatever,” it’s quite useful to give Claude its own computer. That is generally a good idea. In terms of the architecture and UX and everything else that we’ve been working on around this topic, it’s often quite useful if you anthropomorphize Claude aggressively and just say, “This is a person.”

What would you do if you had a person? The analogy I gave my dad this morning, who is still quite insistent on using chat even for coding, is: “If you were a developer and your employer told you that you don’t need a computer, they’re just going to send you emails with the code and you send emails with code back, that may work for a person on the back end, but that is not very effective.”

With the VM, because it’s a Linux system, Claude Code has more or less free rein to install whatever it needs to install. It can install Python, it can install Node.js. We do have strict network ingress and egress controls, so you can still, as a user, in plain human language, make it clear to the entire system what you’re okay with and what you’re not okay with. But at no point do we have to ask a real person—someone who might be in marketing or a lawyer—“Are you okay with me installing Homebrew?” The implications of the question and the answer are complex and nuanced and not easy to reason about. This gives us a lot of abstraction that makes Claude very powerful.

Around it, we do have a number of things that keep growing almost every single week that make Claude better for certain tasks than just Claude Code on its own. Most of those actually live in the system prompt. They’re about what we can infer about the work that you do and what we can introduce into the system prompt to make it more effective.

There’s also the very tight integration with Claude in Chrome. You’re noticing that a lot of people, especially as the models get better, throw up their hands when it comes to MCP connectors in this area. They’re not going to go through 25 MCP connectors, click through everything, and then find that half of them don’t let them do anything anyway. Claude in Chrome is quite powerful because we can just talk to the Claude in Chrome subagent, and it will do things for you.

Yeah. So one example: in MCP, I honestly think the state of MCP is really hard to integrate. I needed to add Figma MCP to the coding agent that I use, but I didn’t want to read the docs, so I just had Claude do it. [laughter]

And it’s great at reading docs. In the same way, I had to set up a Google Cloud account for some project I was working on and get some API keys somewhere. Google Cloud is famously super hard to navigate, so I just used Claude Code.

Within the first week of developing on Claude Code, this happened very quickly. I caught myself starting to use Claude Code for coding tasks, which is not ostensibly what we built it for, right? We don’t need to. But I found myself on an internal tool we have for collecting crashes and debugging information, picking out the ones that I thought we could easily fix versus the ones that might be kernel corruption or something else in the operating system. I found myself picking these out and then just telling Claude, “Go fix this bug.”

I was like, “What am I doing here?” Go one level up. Tell Claude Code, “I want you to go to all these crash tools. I want you to find all the bugs that you think are fixable and aren’t operating-system crashes. Then I want you to tell another Claude to fix all of that.”

Another Claude?

Yeah. It can spin up another instance. Currently, what I do—and this is a bit of a hack—is tell it to use Claude Code Remote to call itself.

Yeah, that’s interesting. So you basically take—if you imagine a dashboard with 20 bugs—is this remote control or Claude Code Remote?

The way I’m using it is, I have Claude Code running, and I’m telling Claude Code, “Here’s where I normally go every morning to find the latest bugs. Go read the entire bug list. Separate out which ones are fixable and which ones are not fixable. For the fixable ones, write a Markdown file with a prompt. Then, for each Markdown file that contains a prompt, start up Claude Code.”

Natively, Claude Code has this concept of subagents.

And this is basically a subagent, but you're not using the subagent's functionality.

I'm not using the subagent's functionality, and the reason I'm not is because I'm firing that off as a Claude Code Remote task. It's kind of nice because then I can just fire it off and go to my next meeting. In Claude Code Remote, the work is happening.

Yeah, you see, you're already starting to use the cloud over your local machine, and I think this is one of those things where you think, “Well, shouldn't everything just be cloud-first?”

This is such a good question. I have so many thoughts about this. I generally believe that Silicon Valley overall is undervaluing the local computer, and my default argument for that is always: How come you're all using MacBooks and not, like, an iPad or a Chromebook? There's still value in having a local machine.

And now, when I think about the cloud, it's this entity that's supposed to be tremendously useful to you. I think that entity needs to have access to all the same tools you have access to. Otherwise, it's going to be hamstrung in all these complex ways.

There are sort of 2 approaches we could take. We could say, “Okay, we're going to chip away at everything that's on your computer, one by one, and move it into the cloud.” That's one way to do it, and I think other products have taken that path. Personally—this is a very personal opinion—for the amount of tools that I use, I just don't have the patience to give another tool permissions to every single thing and keep those permissions up to date.

The second thing that I'm still grappling with, and I don't have a good answer for anyone to say yet, is what it looks like for someone to slurp up your entire work and put that in the cloud. If, just as an example, you click a button and it clones your entire computer into the cloud, is that something you would want? I'm not totally convinced yet that everyone would. And that's sort of upstream of all the technical issues we're going to have, because in general, I think the world is not ready for this kind of stuff.

I'll give you one quick example that would probably be very easy for us. As a desktop app, we, in theory, with your permission, can do a lot of things on your computer, including reading your Chrome cookies, if you really want us to. We could take your Chrome cookies—you wouldn't have to decrypt them for us—and put those on the cloud if we really felt like it. That's a pretty easy solution that would be super cool because it'd be like, “Oh, we can do all the tasks in the cloud now.”

A lot of websites, banks included, if they see the same authentication from 2 different locations, will just lock down your account. And now you have to go to the branch and be like, “Okay, I'm here with my passport.” As tired as we all are of the term “agent” for the agentic future, I think there's a lot of stuff that slowly needs to catch up. Until that's the case, the way I, as someone who's working on Claude, can make Claude most effective is to put it where you're working.

Anything else I should be thinking about with our mental model? Basically, part of me also just wants—the more I understand how it works, the more I can use it to its full potential, right?

Yeah. And so, what I'm hearing from you is that you told me to delete the planning thing. You're not doing anything special on the planning side that's exclusive to Claude Cowork. We have some tricks, but this is sort of like— We evaluate Claude Cowork against different use cases than you would evaluate Claude Code, right? How do you think about it this way?

Okay. So Claude Code is ideally more like Claude Cowork, yeah.

Claude Code is quite optimized for coding tasks, and we mostly evaluate whether we're getting better or worse depending on how good it is at a typical suite of jobs. Claude Cowork, on the other hand, we evaluate more against typical knowledge work—the kind of stuff you would find in finance or maybe a legal office.

My personal use case is always managing my things, like managing my personal mortgage or wealth planning for me and my family. Those are the kinds of use cases we evaluate Claude Cowork on.

What you might be picking up on is the subtle changes we make to the system prompt, what we put in the system prompt, and how we steer Claude with the tools we give it. Either it will be better in one direction or the other, and whether there's a trade-off—trade-offs exist a lot.

Claude Code will be better for code, and Claude Cowork will be better for non-coding tasks. Will those gaps still exist in the next few generations of models? It's a little unclear to me, though.

I thought it was so long. I was referring to the fact that it also just qualitatively felt different. It's probably just all prompting and I'm reading too much into it, but the fact that it comes out as a 9-step plan, I can edit the plan, get feedback, and see it execute the plan—it felt more long-range than in Claude Code. But maybe that already existed in Claude Code, and you just built a nicer UI for it.

It's kind of both. If the Claude Code people who built the planning functionalities were here, they would probably say, “Yes, we have one of those things in Claude Code.” And they do. I think people tend to give Claude Cowork tasks that are maybe of a longer time horizon.

That's one thing, right? The chunk of work tends to be maybe a little bigger. And then the second thing is that because the work, when it gets longer, gets a little bit more ambiguous, we do tell Claude Cowork to make heavy use of the planning tool or to make heavy use of the AskUserQuestion tool.

We do want it to come up with different scenarios and tease out what the user actually wants. Don't go off to work for 4 hours and then come back with the wrong thing. You're probably picking up on that.

I wish I could tell you I built this magical thing and there's some secret sauce. I'm like, no, clarity is good. Engineers just want to know that they can plan around it.

I think I have to switch to my other machine because this is a new machine and it doesn't have my session. The planning is really important for me to approve or to see whether it's right. The AskUserQuestion tool is so beautifully presented. It's also available in Cursor and Claude Code, but I think it's still nice to see that it gets me and gets what I want to do.

Yeah. It parses our ask.

Just on the topic of evals, when you say “eval,” I think people are very vague about what it means. Is it just vibe testing, or do you have automated, programmatic evals of Claude Cowork?

When we say “eval,” what we really mean is that we essentially take the entire transcript, including all the tools that Claude ultimately has available to it, and then measure what the outputs are depending on what we tweak. We do run that a lot. We use that in training.

If you separate out post-training from the scaffolding around it, Claude Cowork sort of exists in the scaffolding space, but obviously we also train on it a little bit. When we say “eval,” we mean: Given a certain transcript, what do the outputs look like, including the file outputs as well as the actual token outputs—the ones that you see in the chat window?

I'm curious how much of the failure modes come from the model's intelligence versus the use of the tools to put that intelligence in. Wealth planning is a good example, right? It's one thing to come up with a plan; the other thing is to make a nice spreadsheet that runs you through the plan. How are you seeing that evolve?

The thing that I grapple with a lot is that whatever scaffolding you come up with, I think we still have a bit of model overhang, where the model is dramatically more capable than users have been using it for. I think part of that is that we're just not giving the model all the tools to do all the things it's theoretically capable of. That's one thing.

However, whenever you do put in the scaffolding, I'm sort of wondering: At what point will that scaffolding go away? And how much you invest in figuring out what the right scaffolding is kind of up to a bet, right?

One thing that I, as an engineer, quite enjoy is that working at Anthropic and working at a frontier lab, I maybe have a little bit more insight into what's coming down the chute. What is the next model? What is the model capable of? What is it good at, and what is it bad at?

I'm increasingly wondering whether the right thing for us is to invest too much in these scaffolding corrections, where the model might otherwise not misbehave but just not do the thing that you want.

Yeah. Or is it to just give it as many capabilities as possible, try to make those safe so that the worst-case scenario is not as bad as it might be otherwise, and then simply wait a second for the next model drop?

I'm personally currently leaning more into the latter. I think we're going to see a lot of applications and companies that do very impressive things with AI that, in the short term, might seem very effective because they're very specialized to individual use cases.

But once models get better at generalization and get better at those specific use cases without being super-guided on them, I'm not sure how long that's going to stick around.

And you can already see this in MCP servers and skills, right? We've already seen a slow shift from MCP servers to skills. A good example is Barry, who made skills. He was initially hacking on something that honestly looked a lot like what Claude does today. He was thinking, “What if Claude, but for people who don't want to write code?”

He, too, did that as a prototype inside the desktop app. One of the first use cases we thought of was: what coding use cases could really benefit from graphical interfaces and from being somewhat separated from the underlying code? Everyone comes to the same answer: data analysis.

Mm-hmm. Right. First, how many users do we have today? It's always data analysis.

I think the thing that ultimately led to skills was that we wanted to connect this little prototype to our data warehouse. The team very quickly discovered that, instead of building a custom tool for the data warehouse, they could just make a file where we were like, “Dear Claude, if you want to get data, here's the endpoint, here's what the API looks like. You figure it out.” They ended up handing over control.

Also, just go 1 step up in the layer of abstractions. Instead of telling the thing, “Here's the CLI; please call the CLI,” or, “Here's an MCP; please call this interface shape,” just say, “This is the endpoint. If you want to know something, post here. Maybe you can do PostgreSQL. It's going to be okay.”

That ended up being so effective that they started trying the same pattern of just giving the model a Markdown file that describes whatever it needs to do. The whole thing eventually became skills, and we were like, “We should package this up. This is a really good idea.”

Yeah, we've had Barry and Mahesh at our conference. They've definitely got a good idea there. I wanted to show you how I've been using Claude Cowork. This is my favorite part. This is how we run the Discord.

At first, I didn't trust Claude Cowork. This was my very first usage. I thought, “Okay, I'll just try to manually download all my recordings from Zoom and upload them to YouTube,” because this is a very laborious process. I have to click, click, click, and YouTube isn't super user-friendly. It just did it.

Then I thought, “Actually, even the download-from-Zoom part should also go into Claude Cowork.” So I did that. Here's a bunch of them. It starts compacting here, and it even starts being able to do things like look through the individual frames of the video to name the video so that I can upload it automatically. All of that replaces my job as a YouTuber. [laughter]

We will forever appreciate your great work.

Yes, you know? [laughter] And so that's great. But then it compacts and makes a new thing, right? I don't have the initial thing, but then I asked it to make its own skill so that something repetitive and one-off and human-guided becomes more automated, and I can use the skills independently and reuse them.

I told it to wrap everything up into a skill. Then I thought, “Actually, sometimes I might need to break things apart, because some parts fail or some parts might be needed individually.” So I told it to split 1 skill into 3 skills. There's a skill-splitting thing, and then there's a parent skill that orchestrates all of them if I want to use that.

There's 1 more part, which is the Google Chrome thing that I told you about. I thought, “What's better than uploading to YouTube using Claude Cowork? Actually looking at the docs to programmatically upload to YouTube, and then putting that in a skill.” I've never done that before, and I don't want to deal with Google Cloud. So Claude Cowork does it for me.

That is really cool.

I just don't care. I let it do its thing. It doesn't really matter.

And then you've paired the skill with the same script that it built?

Yeah, and then I just update the skill.

Ah, that is beautiful. That's wonderful. The way that people ease into Claude Cowork is by taking a knowledge-work task that they would normally be clicking around for and trying to turn that into a skill. Then you ask, “What if you went further?” And then, “What if you went further?” You expand the scope of Cowork as you gain trust in it and teach it how to replace you.

It's a little bit like playing Factorio, but for your own life. You start really small. You start automating something tiny, and once it clicks, you keep adding to this automation empire to make your life easier and easier.

My favorite skill has been having Cowork look at my calendar every single morning and make sure there are no conflicts. People tend to schedule meetings at the last minute or sometimes miss them, and it's often painful. A lot of products have existed for that, but I've written a custom prompt there. I haven't made it a skill. Honestly, I should.

I've given it pretty clear instructions: “Here are some people. If they book over other meetings, I'm probably going to go to their meeting.” If Dario schedules a meeting, don't try to reschedule Dario out of it. There are some other rules about which meetings I care more about, which meetings I care less about, what it's okay to punt, when I want to be working, and when I don't want to be working.

Those are the really small things that can click with people. When we launched Cowork, I think the user story that went most viral on Twitter was “clean up your desktop,” which is, of course, silly. You don't really need a model to clean up your desktop.

“Clean up my desktop?” Yeah, exactly. I need to show it my desktop, I guess. Give it access to my desktop.

Okay, this is very scary. We'll do it.

I did it with my Downloads folder. It was like, “You have so many term sheets, and there are 8 copies of your office rental lease.” I was like, “All right, don't yell at me.” But I think that's the point: it's such a small task. I would never normally tell people, “I've built a product that can organize your folder for you,” because it feels small.

But to your point, here's the question it asks you.

Beautiful, right? It says, “Delete obvious junk.” You probably shouldn't click that.

No. If it's not done right, that could be a problem. It's nice that this is reversible.

I don't know. Maybe I'll learn. I have a typical everything-is-super-messy folder, so yes, I think this is super helpful.

This is a pretty simple task.

Okay, here it is. Here's the progress. I don't see this in Claude Code. This is why I'm thinking it has to be something different from Claude Code.

We do—

Yeah, that's what we do with the system prompt. We say, “All right, we want you to think about this task.”

Yeah, I mean, that's all I—

And then I can make little suggestions for these things. It's beautiful. Look at this. I can say, “Oh, don't do that. Don't do this.” It's amazing.

I'm so happy you like it. I mean, the other way around, we're part of the Claude Code team. If you would like that in Claude Code—

Damn.

I have other things, like signing up for PG&E. [laughter] If you can make phone calls for me, that would be great.

People have done that. Obviously, you can't do that natively, but people have done it with various other providers.

And then this is signing up for the Figma MCP. I'm really trying to do everything. Data analysis as well. I do think design-to-code is very good. Here's the Figma file: take it, and then—

A lot of other knowledge-work tasks replace my manual clicking.

I would normally use Claude Cowork for this, but because I perceive that you have better Chrome integration, I think you can actually do a better job with this. This is 1 shot at my conference website.

That's pretty cool. At some point, I'd love to hear how you feel about Claude Code in the desktop app, which I never use.

[Laughter.] Which is the same team. Yeah, so I use Claude Code, which I perceive to be the default way to code with Claude. So, one thing this has—sorry, I'm not here to wrap up all the products. I can talk about other stuff. I'm not sure if people out there want to hear me advertise my stuff for an hour.

Please do that.

This thing has a built-in browser, which is something a lot of products have. You see it here: it's a built-in browser. I think giving Claude eyes into what you're actually working on makes it much more effective. This is probably what you've seen in Claude Cowork, because it can see Chrome, debug the DOM, and see things. That does make it more powerful.

Yeah, so I think my mental model is kind of broken because I only use Claude Cowork. I thought they had a browser thing in it, but I understand that the Claude Code app, or the app version of Claude Code, does have a built-in browser. I've seen this preview thing. I've just never used it.

But in the end, you basically get the same thing, right? The additional skill you're describing is that Claude is better if it can see what it's working on. That's sort of the summary here. Whether it's using your Chrome—

Yeah.

—or it's just making up its own little browser, it doesn't really make a big difference, because either way it's going to see what it's working on, and that just makes it much better. Then you don't have to run QA for your Claude.

Why doesn't it pick up my existing Claude Code sessions? I mean, obviously I've used Claude Code, but—

Excellent question. I don't have a good answer other than I—

[Laughter.] This is what the OBI team [?] does, I think. Cool. I don't have anything else. I just want to expand people's minds and maybe show people, if they haven't really done it, how interesting it is that I sometimes use this more than I use— I mean, I use Dia, right? I've used all the other agentic browsers, and Anthropic didn't have to build an agentic browser because you just had Claude Cowork, and that's enough.

Yeah. I also think that integrating with a number of excellent browsers out there is currently on my personal priority list a little higher than trying to rebuild a browser from scratch.

Yeah. You know, never say never, but going back to this idea that we want to plug this into our entire existing workflow, I think our goal is actually not to replace any of the applications you have on your computer, but instead to work really well within your workflow.

Meet the new one, yeah. It seems that nowadays, especially on the browser, most of the innovation is user ergonomics. It's not really the underlying browser engine, so I feel like it doesn't really matter if it's Dia or Chrome or Atlas, whatever.

Yeah, we want to meet you wherever you are. Obviously, I would say that, but it's also just generally true, because I don't want to shrink my potential user base artificially by saying, “Okay, I'm going to start building for the people who are willing to switch browsers.”

There have been many lawsuits filed over who gets to operate the browser, and a lot of money has been spent over the question of which browser is default and which search engine is default within the browser. I just want to build for—yeah, I want to build for the swyx, essentially. I want to build for people who have a number of annoying tasks that they feel like maybe Claude Cowork could do for them.

What do you think about skills portability? I think there's one thing. I use another thing called Zoe [?], which is kind of like a cloud computer plus an agent, and I have a skill to add visitors to the office. Whenever somebody has to come in after hours, they need to check in downstairs, but I want to text the thing. It doesn't really work in Cowork.

Now that skill is in the Zoe harness, and it's not in my Cowork thing. If I make a change, I've got to sync them. How do you see that going? I see memory as, like, Claude personal. I don't necessarily want my memories to be cross-thing, but I do want my skills to be cross-agent across the agents that I use.

I think with MCPs, people did the same thing. It's like, “Oh, MCP gateway, MCP registry.” I don't really know if that's a business, so I'm curious if you've had any thoughts in this area.

I think for me, this is sort of where I go back to the really basic primitives. Our skills are file-based instead of this complicated thing that exists inside of a place somewhere that's super proprietary. I'm really leaning into the idea that it's all just files and folders, and that makes it very portable on its own.

We do have skills as part of this container format, which we just call plugins. Plugins are available both for Claude Code and Claude Cowork. It's the same format, and you can install plugins. This works in Claude Code today. You can basically say, “I'm going to add a whole GitHub repo as a skills marketplace or a plugin marketplace.” That's how we're doing portability.

I think we have a lot of room left to grow in how we make it easy for people to know that they can write skills, and how we make it easy for them to just share a skill with you. Obviously, all the words I just said mean I'm losing most of the knowledge-worker base out there. I started by saying, “Oh, you can connect a GitHub repo.” That's not exactly how most people will end up working in a general knowledge-worker space.

I think there's something there. Another thing that has not really been properly explored is the combination of which part of the skill is very portable and which part of the skill is very personal to you. I think that's something we haven't really solved yet as an industry: when you want to introduce more structure to the skill, or whether you always have public-skill, private-skill pairs.

Yeah, kind of. I think the easiest way to do this would just be to use string interpolation or something, right?

Right.

Yeah, insert username here, insert phone number, insert known folder locations—that kind of stuff. That's probably clunky. That's why we haven't built it. But I do think someone is going to come up with an interesting way to keep everything we like about skills: the portability, that it's just a file, it's just Markdown, it's just text. Honestly, a text file works.

The complete lack of structure means you don't need any kind of tutorial to write a skill. Just explain it to Claude the way you would explain it to me, and Claude will probably get it before I would, right? For booking a flight, tell Claude how to book a flight the same way you would tell someone. I just thought about it today.

Combine that with a very personal thing. Maybe we'll stick with the booking-a-flight example. I don't actually think AI should be booking flights.

Yes, yeah. Finally, somebody says it.

That's the default demo that everyone was making. I'm like, my opinion is against flight-booking demos. It's not a good showcase.

Yeah, I just want to book my flight myself.

I think there's a lot of things that have a personal and a nonpersonal component. That's mainly why people reach for flight booking, because some things are very universal. A cheaper flight is usually better, right? Few people try to book the most expensive flight. Then some things are quite personal, like what time you prefer, what seat you prefer, and which airports you prefer.

Combining that in a skill format that's actually portable, compatible, and easy for people to understand—I think that would be very exciting. We're just having to figure it out.

Yeah, I think the text part—everybody by now has some sort of cloud-file thing, whether it's Dropbox, Google Drive, or whatever. It feels like, in a way, I should basically symlink my skills into all my agent harnesses and just keep those in sync.

Internally, we have this Valuable Tokens repo, which is all the commands and subagents. It's a good— I built a TUI where you can start and say, “Install this command and these 3 subagents into this agent in this folder,” and just copy-paste this. It doesn't do anything. It literally just runs `cp` on the file into that.

I feel like there should be something similar where, whenever I go into a new thing, it's like, “Hey, here's the link to exactly the cloud folder. Bring these skills into this.” Today, it doesn't quite work like that. If I install a new agent, I have to copy and paste all the skills, and I don't even know where they are.

Yeah, that's the big problem. It's like, “Where do I find them?”

I'm curious about the future, because that almost feels like my personal productivity thing would be my skills. It's not really the product that I use, because everybody has access to the same product.

I think so many things—I really like thinking about agents and LLMs just as another coworker. So many attempts have been made to build documentation companies that are like, “Oh, we're going to solve all your documentation problems.” I myself spent a little bit of time working in Notion, so I'm deeply familiar with the concept of getting everyone on the same page.

Mhm. Right? What you're basically saying is that you want all your agents to be on the same page about your preferences, your skills, the way they ought to work, and how they ought to execute.

I'm not sure what the right thing is going to be. Maybe it will be some company that can say, “All right, we're an independent body. We're not trying to push you into any particular product. It's our job to be the skill authority, and we provide—I don't know—we're going to be the Dropbox of skills, and you can just symlink us into all the products you want to use.” I'm not sure that's going to be a viable business, but as an idea, it would be cool, right?

Yeah. Yeah, I think so many things are just going away as businesses. It's like, “How am I supposed to do it?” I'm not even asking somebody to make a product about it. It's more like, “Yeah, I want to personally know.”

There are things, like you said, where you almost want a skill and then interpolate between personal and work. If I'm booking a flight for work, it's different from booking a flight personally in some ways, but a lot of the scaffolding is the same.

As an engineer, I will tell you that, technically, I would just use symlinks. That's what I do with CLAUDE.md and AGENTS.md. It's the same as symlinks. That works, but it feels like—I don't know, maybe. You can always tell Cowork your problem, and then Cowork will solve it for you. Just make the symlinks. That's one way to do it.

That's true. That's true. All right, everything is called Cowork. Potentially spicy question for both of you: which of these industries will go away?

Okay, so what Felix was saying before is interesting. There's basically the short-term pressure of, “We need to turn these tokens into valuable things,” which means I should build a last-mile product that harnesses the model. Then there's the question of which ones are still going to be valuable long-term.

I think you're seeing this today. In the coding space, everybody is moving up and up the stack because you need more engines turning tokens into code. I think enterprise search is seeing the same thing, where Glean and all these different companies are—at the end of the day, if Cowork is the one doing all the work, search itself is such a small part that I don't know if I'm really going to pay that much money just to do search.

It's almost like everything is a Cowork vertical. How much can Cowork support first-party, and how much can it not? I think for a lot of these things, the planning thing that you were showing—did we show it? The planning thing.

Okay, yeah, yeah. That's one thing where most of the value these agents provide is that they're better at planning for specific tasks and have better tools for it. But I think the models are now moving in that direction, and they have the right harnesses and are on your computer.

For me, it's almost like if the end customer trusts your startup to be the provider of that task result, then I think that works. This is a research spike that we're working on.

I don't think I'm the best person to say which industry is going to be hit the hardest, but I do think that, as a group of people, Anthropic is deeply worried about the impact these tools are going to have on the labor market, especially for junior employees.

I think it's only honest to say that when we talk about automating a lot of the work that we personally find annoying, or that we think isn't the best use of our time, in a lot of industries that kind of work would have been given to a junior, entry-level employee.

I think it's only right to be really worried about that and to worry about what that's going to do, particularly to people entering the job market.

I have a solution for that: you create simulated jobs for them.

Okay.

This is half joke, half true. If you think about software engineering, when you're a junior engineer, you work for 1, 2, 3 years. In those 3 years, there are maybe a handful of moments where you really learn something, and then a bunch of other days where you're not really progressing.

I think now we can use AI and these models to shortcut these careers and almost simulate the early years of your work, making them super dense with these learnings. It's like, “Hey, we're working on this feature, which is a distributed system, and you need to learn this thing. That might take 3 months at a company.” So you take 3 months. Here, we're just simulating the whole thing. It's not actually real, but in 1 week, we speedrun through the whole thing, and you learn your lesson from there. Then we repeat that.

In 1 year, you basically get 3 years' worth of projects and experience. I think it's harder for things like sales or marketing because you don't really have a way to get the feedback loop. But a lot of it sounds kind of silly. It's like you're making the new fake job, but it's almost like going to college, right? People pay to learn how to do it.

This might feel similar. It's like, “Hey, we have the Jane Street simulator. You want to come work at Jane Street? We'll just put you in the simulator for 3 months, and you'll come out of it as, you know, ‘I'm ready.’”

I'm not an expert enough to know what is going to happen to marketing, legal, or finance. I don't work in those jobs, and I don't think I should talk about them. But I am an engineer, and I think I have a pretty good idea about engineering.

I think one thing we're seeing is that, as a company of all sizes, and as a public company, we're deeply worried about entry-level employees. But we're also seeing more senior engineers accelerate. If you're more productive, you actually increase the value you provide.

Something I'm thinking about a lot is that, even before all of this happened, I've always had a lot of respect for the University of Waterloo. The new grads who joined my teams from the University of Waterloo always felt more ready than new grads who literally spent their entire time at the university, regardless of how good they were, but never actually had to work in an environment where they had to ship things that would eventually be used by users.

I'm German, and I initially went to a German university. The information-systems programs there tend to be very theoretical. I often give people the example of trying to become a doctor, but first having to do 4 years of biology.

As a result, when you get a new grad, you have to teach them what it's like to actually build products, work in a company, work with other people, deal with people who have different opinions, and do all of these things.

It's part of the curriculum for your job to spend a year in internships.

Yeah, they just go from company to company. They show up on your team as a junior engineer who's been to 20 companies—not really, but it seems like a lot of my new grads have also briefly worked at Apple, Google, or Tesla.

Yes, and there's a common meme where they collect all these logos like Infinity Stones. They always put it on LinkedIn, and it's very unclear that they were an intern.

Yeah, exactly. But it does actually make them so much better compared to other new grads. I wonder if that's a useful model for the future, when we also have to crunch down the amount of time you have as a junior employee because the value you have as a junior employee is going to be impacted.

My pro-young-people take is that they have higher neuroplasticity. They can learn more, and they have fewer preexisting biases. What I'm assuming is true for you, and what OpenAI often says, is that younger, fresh-grad engineers who use Codex are coding more innovatively than experienced engineers who have a set and preferred way of doing things.

Yeah, as I talk to people, I hear some of my own experiences. Maybe you're more AI-native, and therefore you get cut. But I think the problem is that you don't need that many of them.

Anthropic is on the record saying that we do believe the impact on the market is going to be sizable, and we do not think that people overall are ready. We should probably talk about it as a society much more.

I'm not sure that I'm the individual who can add anything useful there, but as societies, with economists and governments that need to wrestle with those questions in a way that is probably more meaningful than me wrestling with them, we're probably not talking enough.

Yeah, well, we try to educate people, and I think that releasing frequently, as you guys do—or probably maybe too frequently—is helping people adjust over time rather than having one big-bang thing. There's a gradual takeoff that people are living through, and we can help out, right?

Yeah, but I think a lot of us are wondering: at what point do we actually have full takeoff? At what point is there—we're all sort of expecting this big-bang moment where things start accelerating so quickly that it becomes a self-reinforcing loop.

And then at that point, it’s sort of off to the races, and there will be no more slowly catching up—just being so good at everything.

Yeah, it’s when Claude Cowork is training models. It’s when it’s looking at TensorBoard, adjusting weights and biases, and training things.

We can all debate how many years it’s away. Some people make a bet that maybe it’s 10 years away, maybe it’s 1 year away. I’m not entirely sure where I come down on this line, but I’m not entirely sure that ultimately matters all that much, whether or not it happens in 4 or 5 years. If we have a decent one, that’s certainly going to happen, and it’s probably something we should wrestle with.

By the way, the scheduled task completed. I was trying to get it to do more thematically—read the file, understand what it’s about, and group things by topic rather than file type. It’s got some topical things, but it could probably do better. I probably need to give it a skill to read video files so that it understands how I like to do things.

You can just follow up and have it do that, actually.

Oh, yeah, it did. It did it by proposing some topical things, but it could probably do better.

Honestly, though, I see that you’re using Claude Opus 4.6. My recommendation for people is increasingly: don’t worry about it anymore. Just tell it what you want it to do, and it’s probably going to figure out a way to do it. It might not be the way that you like, necessarily, or the way that you would have gone about it.

Yeah, video is deeper. But we’re also sourcing and organizing all of this, so let’s fight.

I’m honestly so curious what Claude is going to come up with. I’ll kick that off.

I wanted to also just talk about the overall picture. You talked about data analysis, you talked about your personal finances, and you also mentioned—which, by the way, is very timely for us—tax season. Use Claude for tax season. It is not responsible for any mistakes, but you might as well, right? It’s free knowledge work for you.

I think Claude for finance is a big deal, and this is definitely in that mix. Is it a separate team? Do you talk to them? How important is it? Because you also need the output Excel files now. Just talk about the finance effort you guys care about.

We care about the verticals quite a bit. We have a dedicated verticals team, and we also have a dedicated enterprise team. That is business engineering, not sales. It’s engineering.

We have people who come to work every single day and ask themselves: How do we make Claude extremely effective for people in those specific industries? How do we make it easier for them to understand? How do we make it easier for them to plug into this and get the same value out of it that software engineers get?

I think it’s no real surprise that software engineers ended up being at the forefront of the entire AI moment, because so much of it is this Rube Goldberg machine-esque process where we’re already used to automating things. It’s part of our job.

We care about it quite a bit. I think it also really matches what we see Claude being very good at as a model. It provides a tremendous amount of value to those customers in particular because we can do so much with the amount of data they have. Those are data-heavy industries, and they’re industries where correctness matters quite a bit.

So if I’ve used it to analyze my business, I just can’t show it.

[laughter]

That’s too sad. I had a similar question about taxes. I did tweet about the fact that Claude was doing my taxes. This is honestly incredible, and it’s annoying because this is so cool, but I’m not going to—

[laughter]

Twitter’s maybe not the audience that needs to see your tax return.

Here it is. It’s reading the videos, so it’s getting more capable.

How did it actually do it? I was curious.

Usually, it just takes a screenshot and then reads the screenshot with vision.

This is what I do for my Zoom upload thing. I have paper club sessions that I need to upload to Zoom, and I want it to automatically title them and do show notes and everything. It just takes screenshots and tries its best.

It probably would benefit from transcribing, which it’s not doing. It’s operating by pure vision now, but it’s good enough. I also have to call out to Nana Banana to do images, so unless you guys do images for me, I have to call the people who do images.

We’re aware. It’s just so fun for me because this is the thing that I’m increasingly doing: becoming increasingly curious about Claude’s creativity and figuring out what a great Claude approach to solving a problem looks like.

Yeah, vision for everything is the superpower, right? You guys were the first to do computer use, too. When it was launched, I was very unimpressed. I was like, “It’s slow, it’s unreliable.”

Yeah, and look at how much better it’s gotten in 1 year.

I know. It was barely usable.

I remember it was barely usable, but isn’t it wild how much better things have gotten over that 1 year?

We went to the Anthropic office for the launch event for computer use. There was a hackathon, and nobody hacked on computer use.

[laughter]

But I did briefly see that you have a macOS Automator MCP server installed. Do you use that ever?

What? Sorry, which one?

If you go to your settings.

Settings. Okay. Where? Sorry, this one?

Yeah. I noticed that in your connectors.

I probably set that up at one time, but I don’t use it actively.

A macOS Automator MCP?

Yeah. I really wanted to automate everything on my computer, but I didn’t find it super reliable.

Why?

[laughter]

No question at all. Claude is much better at writing AppleScript and executing its own AppleScript than relying on these third-party tools.

Yeah.

I initially installed MCPs and all these other MCPs that people built, but now I don’t use any of them anymore. I just let Claude write its own thing.

It’s going to be more custom-made.

We keep going up the stack, but I do think computer use is a fairly interesting area. It’s also interesting in the sense that I don’t think we’re far away from Claude being very effective at using your computer—not just a theoretical computer.

What’s the relationship between the user and the computer? There were some tweets about how huge some of the VMs that Claude Cowork creates are—12–15 GB—and people complain. But at some point, if you’re using the computer and taking action, is this just your computer and I’m just looking at it?

I think that’s why people like the idea of the Mac mini and OpenClaw or whatever on it, because it has its own home. It’s doing its thing, and I’m doing my thing. There’s some kind of—not exactly a race condition—but if I kick-start this task, now I can’t really use the computer because Claude Cowork is doing things on it. It’s kind of awkward.

I do think it’s a super interesting area. I can maybe tell you about some of the things I thought about that I think are actually a bad idea.

When we initially started working on Cowork, I had some dreams about what it would look like for Claude to have its own cursor. It could be cool, right? It’s a computer; we can write code and touch everything. Who says that computers need to have 1 cursor? We could have a second cursor.

But that actually breaks down quite a bit, even if you go and present that idea to both Apple and Microsoft. You’re like, “Wouldn’t it be cool if…” It breaks down quite a bit because so many of our mental models for the computer are built around this idea that there’s only 1 thing you’re working on. There’s a foreground app and a background app. Claude and Chrome can work in the background, but that’s within 1 application. At the operating system layer, it’s a lot harder to implement.

I’m still grappling with what it means for Claude to actually act on your computer. Is the right format for Claude to have its own computer that you set up, and maybe every now and then you zoom in and play with it? Or is the right format for Claude to wait until you’re stepping away for a little bit and take over while you’re gone? Or is the right move for Claude to have its own computer in the cloud, where whatever you want Claude to do, you set up yourself?

[laughter]

There are a number of different options. This is something I think about a lot: What is the relationship between you and your computer, and you and your data on the computer? How intimate that relationship is depends on the tool and the thing that you’re currently looking at, right? We’re quite comfortable sharing some things and very uncomfortable sharing other things.

Whatever product is going to be successful will have to deal with those different things. But even if Claude were capable of making that determination, would you want Claude to make that determination in the first place? It’s tricky because it’s more than just privacy.

It's like almost intimacy. It's tricky to reason about in a way that will make everyone comfortable.

Yeah, I could see a VirtualBox—an actual VirtualBox app where you run the VM and have a screen within the screen. You can put it in the background, but then you can jump into the screen.

Yeah, that's not a bad idea. People used to do that, virtualizing Kali Linux in a Windows machine. Then you would jump in and jump out, but it's not like a dual boot; it's within the thing. The problem is that you need twice the amount of RAM, and it's kind of taxing on the machine, but I think that would be cool.

You could see the little Claude window and its desktop, how cute it is, clicking around things.

I was going to bring up that you're the original machine-in-a-machine guy because you have the Windows 95 project. Where's the Windows 95 project at?

It's probably somewhere on my GitHub.

No, no, no, no, no. It's the first thing you see. It's this one.

Nice. [Laughter.] Yeah, exactly. That was honestly a very fun project, though. Obviously, I didn't build Windows 95 because I was a child. But I also didn't build the actual engine that is capable of simulating an x86 processor in JavaScript and WebAssembly. That's a tool called v86, which is very cool, and everyone should try it.

This came out of a debate we had at work, where people were, as they often are, debating the merits of Electron and whether or not we should be building software in JavaScript. Yes or no? I am still very upset that I can run all of Windows 95 in JavaScript, launch Microsoft Excel inside the virtualized JavaScript Windows 95 machine, and do things with that entire chain faster than I can do a lot of other things in traditional SaaS applications.

This was sort of a performance rampage that I went on. I mostly built it as a joke for some of my colleagues at Slack. This took one night.

What?

But then—I mean, it was not hard to do. All the hard work is in v86. Go to the repo; it'll say that 99% of this work was done by a guy who goes by the name copy. His name is Fabian.

Cool. I think you're kind of back on the Windows grind because you're building out the Windows support. I thought there were some really cool technical stories to tell, and it gives people an appreciation of, well, here's how hard it is and here's how important it is to invest in the sandbox. So maybe this is a good opportunity to talk about some of the details.

Oh, yeah. The VM honestly is so cool. There are a lot of things we dislike about the VM, right? There are a lot of real trade-offs, and you want to know why you're making those trade-offs.

You're right, there are a lot of people writing me, like, "Hey, how come Claude is taking up 10 GB?" I could say that in the pod it's not actually taking up 10 GB. It's just that the way macOS displays bytes is wrong. The way we actually write it to disk is that we collapse the empty space in the image, so it's not actually taking up 10 GB. But that's a technical distinction for a nontechnical manager to lie to me about. To me, the question is: why does it take too long to start?

Yeah, why does it take so long to start?

It should be faster than that.

Whatever. Fine. It's going to be 10 seconds, but it feels like 30.

Yeah, either way, whatever it is, it's going to be slower than just running Claude Code directly on your computer, right? So the trade-offs are real.

But what we're doing on Windows is using the Windows Host Compute System. It's the same thing that WSL 2 runs on—the Windows Subsystem for Linux—which I think a lot of developers appreciate quite a bit.

It's pretty cool because we have to separate out which system space the virtual machine runs in and who gets to talk to that virtual machine. Obviously, you give this virtual machine a decent amount of power. How do we optimize not just the connection between the 2 systems, but also make sure that some random other application doesn't get to talk to Claude inside the VM?

We do some pretty interesting things. Last week, we started writing a new networking service and networking driver that optimizes how Claude talks to the internet. If your company is doing weird internet things, like packet inspection or TLS inspection, or taking your pod as a cell inside your company, I think there was probably a very small, easy version to build of Claude Code that is much simpler but also breaks on most computers. This one is quite nice because it works on most users' computers.

The default example I would use is that I really want this to be highly effective on a machine that most people pick up. That machine will probably not have Python; it will not have Node.js. Even if I just take away those 2 things, Claude is going to be so much less effective on your computer. So what do you do? Maybe you require people to install Node and Python.

Oh, like—you mean, what does the future look like without a VM?

No, no, no. So, like you said, let's say the target machine is whatever the default-spec Windows desktop is. We do this, which is quite cool. On macOS, we use the Apple Virtualization framework, which is pretty solidly optimized. It's good stuff, and it's a very simple API call, right?

It's just super simple. I saw the code recently, and I was like, "That's it? What the fuck?"

Once you start shipping production code on it, you start adding all of the edge cases you learn.

Oh, yeah.

It ends up being a little longer, but I think Apple really cooked with the Virtualization framework. It is very, very good. It is very fast and very reliable.

The same is true on Windows with the Host Compute System. I think WSL 2 as well is maybe one of the diamonds within Windows. It's one of the few things that developers universally rave about. It's very, very cool. Hooking into the same subsystem makes it a lot easier for us to say, "We don't really care how locked down your computer is. Maybe it's your employer's computer, and your employer has decided that you can install nothing."

Mm-hmm. Not trusted.

But it's true in a lot of environments, right? Even at Anthropic, our IT department controls what kind of stuff we install, which is a pretty common experience for many companies. This gives IT departments a decent amount of control and makes their job so much easier, because we can say you can separate out Claude's computer from the user's computer.

For Claude's computer, what you probably care about is data loss, a potentially hostile actor, and maybe data being exfiltrated. Once you control the network and the file system layer, you don't necessarily care anymore that Claude might be writing super-useful Python scripts. What worries you is that once you install Python, now anyone can do anything on your computer. But once you put that in a VM, that risk really goes down.

Yeah, so that's why we jump through all of these hoops. I think you had a different tweet about this, but it's almost like people have approval exhaustion. You can't approve every single command. Sometimes, by default, some of the CLIs—I think even early Claude Code—we had to approve every single command.

Yeah.

There's a dichotomy between either approving every step or dangerously skipping permissions. Actually, sandboxing is kind of the middle ground.

Yeah, I do think it's maybe on us as the industry to come up with something better than, "Oh, this is super safe as long as it doesn't do anything." If you want this to be useful, then you have to approve every single step of the way.

Computer use is a good example. The only way to make computer use on your host super safe—really super safe—is probably if you approve every single action, right? Models are like, "I would like to type the word 'L.'" You're like, "Okay, that seems fine," because I know which cursor is focused.

Yeah, it's not automation if you don't delegate.

Yeah, exactly. You need to probably delegate. You need to be able to delegate and walk away and trust that this thing is not going to mess up automatically.

I don't even think we need to build perfect systems. I don't think we need to wait for 100% model alignment. We can rely on the same Swiss cheese model we've used in the industry for a long time. But I do think we need to universally, maybe eventually, invest more. That's what we're doing. We need to invest more in systems where we can say you do not need to approve everything.

Speaking of the Swiss cheese model, he just wrote a thing about this.

Oh, cool.

Yeah. It's weird how, I guess, usually I think safety and security are kind of boring words to engineers. They're like, "Just give me unsafe. Give me insecure." But I think achieving the right thing—you're going after a consumer/prosumer—

Yeah, yeah, kind of like both.

I was kind of like both. I think I also want to capture people who would have no trouble using Claude Code, like yourself.

Yeah, yeah, yeah, but still find it maybe just convenient, easier. You're like, “Oh, cool, that's the to-do list on the right. I can edit it.” Those things are just easier to do if you have to.

Yeah, but this is clearly the knowledge-work side. Claude Code will clearly capture the development workflow. But I do think you have to sweat the safety and security details in order for people to trust it. Even Claude in Chrome—having whatever API it uses to do the background thing—that's the only reason I use it. Otherwise, I would have to get a separate machine and just run it through there.

Sounds super annoying.

Yeah, I mean, I'm currently doing it. I think also, as developers, maybe we're more risk-tolerant, but we're also just accepting. We are more risk-tolerant, but I think we also have—I don't want to say arrogance, but sort of the trust that if the really bad thing happens, we can probably fix it. I just tell Claude to check with me before doing any irreversible action, like sending an email or doing something permanently. It's good enough.

But not even Claude—simple things such as npm install. We're all running npm install with full user permissions, and if it wants to read .ssh, it will. It's crazy that that is the default.

Yeah, I know. I agree. I'm obviously doing it every single day.

Right. And I think npm and GitHub, too, have done a pretty good job over the last couple of months of cleaning house and coming up with more specific tokens. But generally speaking, I think as engineers we've always been a little bit more risk-tolerant. If you do a little bit of introspection and ask yourself, “Is that how we should be doing things?” you might not always come up with the right answer.

And I think for models, too, my approach is not to do the safest thing, because the safest thing is to do nothing. We do want products that are quite capable, but to the extent possible, I don't want to ask you, “Are you okay with the script?” I kind of believe that once it starts becoming part of your workflow, you're probably not—either you don't have the skill to understand whether or not this Python script is safe, or you're not going to read it anyway.

Cool. I guess I have a couple of parting questions. What's the future of Claude Cowork?

I think we're still at such early days. We're going to keep shipping things, and we're going to keep iterating on this thing pretty quickly. By which I mean, you can continue to expect that every single week there's going to be a small new feature, if not a big new feature. I'm going to continue to double down on your computer, making you effective on your computer and making Claude effective on your computer. We're starting to grapple, as we talked about today, with the question of what it means—what your computer means. Does it have to be the one in front of you, a VM on your computer, or a computer somewhere else?

The third thing that I'm quite excited about is continuing to go up this hill, slowly taking users who are used to asking questions and getting an answer and slowly teaching them to step more and more away and let Claude take over bigger and bigger tasks, working both in time as well as in scope. I think you can probably see most of our investments and our future releases working on both of those things: the ability to do more on your computer, and then the ability to do more independently and for longer.

Does remote control work for Claude Cowork yet? No, right?

Excellent question. [Laughter] Coming soon. I mean, that's an obvious thing if you want to keep betting on the “your computer” idea.

But to me, you know, we talk about how people are not ready this year. There's no wall; it's accelerating. To me, what will we be doing differently at the end of this year that we maybe weren't even thinking about at the start of this year? I'm just trying to look ahead as to what's a good use case that we sort of aim towards.

For example, for the machine-learning scientist, it's always, okay, well, I want an AI scientist that can automate machine learning. But for knowledge work, I can already get it to sign up for Google Cloud. To me, that's AGI. But what's beyond that? I don't know.

I think it's basically the idea that you still have to tell it to build your script, right? You were still kind of involved.

Yes.

And maybe a way that felt kind of magical to you, but to me, on the other side as the person building this product, still feels kind of heavy-handed. I see so much process that I'm like, “Oh, let me take that away from you.”

Okay.

Or, like, how do I just continue to go further and further up the stack and make your life easier and easier?

Yeah. Watch everything I do on a normal day-to-day basis. I don't care about my own privacy or whatever. I trust Anthropic. At the end of the day, tell me what you think is Claude Coworkable.

You know, for good reason, I don't enjoy—I don't feel—my entire career, I've never teased too much what I'm working on, because I think you should just release it. Build the thing and release it.

Yeah, build the thing and release it. And then talk about it. I'm not a big fan of vague-posting about work ahead of time.

But the thing that's always so fascinating to me is that both of you, multiple times today, have mentioned things and I'm like, “Yeah, that is obviously—obviously someone should be working on those things.” I think we're still in the space where, if you look at Claude Cowork, the things that we're releasing will probably not be a big surprise to either of you. You're going to be like, “Yeah, obviously that's valuable. Obviously they were working on those things.”

Yeah, yeah.

And obviously that's good and useful. The more I hit those points, and the more our future is fitting into that category, I think the better it is for us, because then we don't end up building things that are too hyper-specialized or too difficult to understand.

Yeah, yeah, exactly. The hyper-specialized thing is very important. It keeps you general-purpose; it means you're not thinking too small. I don't know what the word is.

It's like the whole concept that at no point did we release—there's no Claude Code for Node.js applications that use React and TanStack and all of those things. And if it's anything else, I know several startups like that. I think that's pretty—

I'm not a VC, I'm not an investor. It's hard for me to predict where the market's going. But in terms of the building blocks that I'm interested in, Electron is probably by far the most popular thing I ever built.

Electron itself is very abstractable and generalizable, right? So many apps are running in it. I think it would have been hard for me to predict how many apps actually end up using Electron. And what would have been even less useful for me to predict is what those apps do. I do remember Bloom coming out and being like, “That is cool. You're a camera in a little circle in the corner. That is pretty smart.” That's an Electron app? Yeah, or at least it was. I'm not sure if it still is. It was for a while.

It's a level of the stack that I'm quite comfortable with, and whenever I give other engineers advice, it's actually that layer that I think is most valuable to invest in, because the tools at that layer are not that good, but that's where you get the most leverage for the future in general.

Just a quick tangent on Electron, because I always wondered this: have you looked at Tauri?

I have, yeah. What's your take?

You know, my view is that most things should be Tauri by default unless you really need the full power of Electron.

Yeah, I can give my big take. Why do we ship an entire version of Chromium inside the thing, right? Why do we do that? People ask me this question a lot because it's very counterintuitive. Wouldn't it be much easier to use the web views that are on the operating system? Wouldn't it be much easier not to have to do that? And the answer is yes.

Obviously, I did that once upon a time. There was a version of the Slack app that used just the operating system's web views.

Did you start the Slack app?

I would—well, it was a team effort in the end, but I was there and we built this Slack app.

Yeah, that's crazy. Obviously, you get the Electron guy to do it. [Laughter]

Well, this is an interesting point. By the time I joined Slack, they already had an app that was built with something at the time called MacGap, which was a little bit like the same PhoneGap thing for mobile. It just used the operating system's web views, and that didn't work for so many reasons. Then we were like, “All right, we need bigger guns. We need to take more control of the rendering stack.”

There are a few things I always mention here. If you're building a small app, just going with the operating system's web views is perfectly fine. If you're building an app that doesn't have too many users who would cry bloody murder if it doesn't work, that is fine. The reason to go with your own embedded rendering engine is because—and this is still true in 2026—the operating system rendering engines are not that good.

They're just not that good. Both Microsoft and Apple are trying to move away from that, but so far they really haven't. The only way to upgrade those is to upgrade your operating system. So, if you're, say, Slack and you have a critical rendering bug in WebView or some of the other WebView options, your only recourse is to tell your customer, “Oh, sorry, you're too poor. You didn't buy the latest MacBook.”

Unacceptable. Unacceptable to the user, unacceptable to the developer. So, you sort of need to go down the stack, find the best rendering engine, and put it in your app. Why Chromium, even though it's very big? Chromium is by far the best thing. I often remind people that if you want to render some text in the Unreal Engine, they use Chromium. Chromium is part of the Unreal Engine for the same purposes.

Chromium is very, very good. I think it's one of the marvels of engineering. It's very hard, from San Francisco, where we're recording right now—most of the people in the city are web developers—to overstate how magical it is that you can run, say, a YouTube video, dynamically negotiate a bit rate, and figure out what to do about your extremely broken hardware driver. Actually, this is a fun thing: you can enter chrome://gpu.

If you scroll down a little bit, these are all the enabled workarounds because something is going wrong on your computer. If you're doing this on a Windows computer with a GPU that is not the most popular GPU, it will be much longer. All of these are usually just there to make sure that if I say, as a developer, “I want a red pixel to appear here,” that actually happens.

Chrome is such a marvel because it works on all the machines that a user might throw at you, and it's going to work fairly reliably. If it doesn't, they will probably fix it within 24 hours.

So this is the super operating system, right? It works everywhere.

Yeah. A lot of the magic of Electron is honestly just that it makes it very easy for you to ship Chromium in a way that serves you exactly in your use cases.

Electron, exactly. Our next interview was with Martin Grissom, who had the phrase that desktop operating systems are just poorly implemented versions of the actual operating system, which is Chrome. This is the platform where you ship apps.

I think the wild thing is that, as engineers, we so often assume that the platform—the layer below us—is super stable. Then you talk to those people and they're like, “Yeah, we're also just guessing.”

I had a distinct moment at Slack where one of our customers was NVIDIA, and for a while I really put GPU developers on a pedestal in my head. I do think they're still probably much smarter than I am, but I thought, “Hardware engineers who built the chips, who then built the drivers—their work must be so much harder than mine. They must be very good.”

We had one bug in Slack where, if you had a YouTube video in Slack, it wouldn't quite render. It would have these weird artifacts. That ended up being a Chromium bug, and it ended up on this giant thread. I got to see a lot of the source code, and they also just had comments like, “TODO: We don't know why this is weird, but if you flip this bit, things work.”

This is just happening at every layer of the stack. Maybe the end-of-year AGI prediction is that Claude can build Chromium.

You see, you laugh now, but someday it's starting to get pretty good. It would be completely useless, mostly because of how hyper-specialized the tools inside the Chromium repository are. For a long time, Chromium had to reinvent all the tools because none of them were capable of handling Chrome.

I think the AGI moment I'm waiting for is: at what point are we going to say Electron is probably no longer necessary because you can just build fully native apps?

The Swifty?

Yeah, not just in Swift. I think our current models are quite capable of taking an Electron app and replicating it in Swift. Are they going to be capable of building an app that is actually more performant, uses less memory, and does all of that stuff? Is that going to involve the same hyper-optimization that developers have done for a long time?

We're not quite there yet, where I can point even our best models at a thing and say, “Just replicate this in native code. Make no mistakes.” We're not quite there yet.

I don't just think it's bad today. I think it's back. Or we'll get a native thing for days, which is a pretty long time for Boris. But he worked on a neural think for days?

Yeah. Why? It's just a front. A little more goes into it.

Another question I had is Claude Cowork. If I have my Claude Cowork, what's the multiplayer mode? I think subagents are single-player, splitting up the context. Multiplayer Cowork is more like: my colleague has some file on their machine that I want to know about, or I want to know how their task is going to update my thing. Is that interesting? Is that something that makes sense for you to build?

It's super interesting to me. It almost goes back to some of the scaffolding, where I'm like, “Are we going to end up building scaffolding that will just go away?” The question a year and a half from now is: at what point do we just assign these things their own Gmail account, give them their own Slack handle, and let them use the same tools we humans use to interact with each other?

You mentioned our finance people. They've been working pretty hard on very good office integrations. For a while, we built so much technology around Claude leaving useful comments inside a Google Doc, and now it just does it. It just leaves a comment in your Google Doc, and that's how you interact with it.

Maybe it's a similar thing. I still have open questions around what the best interaction mode is. Is it for us to build something super custom for Claude agents to talk to each other? Or do we just jump straight to the finish line and say, “We're going to give this thing a Slack handle. If you use Slack at work, that's going to be the way it's multiplayer-capable”? They communicate with each other.

As a fun project, I built this thing called PiQueue, which basically takes any repo and the Pi coding agent, puts it in a VPS, and then there's a public webhook where anybody can submit a coding task. There's a dashboard in which you review the task.

You basically get all these tasks. Anybody can submit a task. To me, it's almost like, in the organization of the future, the salespeople are talking to the engineering team, which is talking to the marketing team and the product team. All these coworkers are going to queue up decisions for other people to approve in a way.

I'm kind of curious what that looks like. How do I give my coworker the ability to approve tasks without asking me? How do I decide which ones I need to review? For some of these things, you want to change the color or something, and that's kind of a branding decision. Another one is, “Hey, your thing is just broken. This is how you fix it.” Claude can actually review whether or not that prompt matches what it's trying to do.

Today, everything is still very much multiplayer within the single-player experience. How do I get multiple people to hand things off to each other using their particular context?

Yeah, and for both of your coworkers to talk to each other, right?

Right. We previously talked about sharing skills, and I had this question: what if your cowork asks the other coworkers if they have a skill for this task? Could any of these agents do it? Skill transfer.

Again, this maybe goes back into the territory where building something very powerful and building something creepy often go hand in hand. I could tell from the reaction that my fellow engineers had that this is probably not what we're going to do, but we have Bluetooth LE, right? This computer can figure out that it's sitting right next to this computer, so you're probably working on the same thing.

Will you see that in Cowork? Probably not. But I think there are really creative solutions to problems that we haven't tried yet.

Excellent. I guess the last thing is Anthropic Labs. I always have this mental model of a model lab versus an agent lab, and this is basically Anthropic's internal agent lab, which Claude Code is now under, right? It's part of the whole organization.

I mean, people are so fungible, right? This is just—I don't know how real this is.

No, it's a real team. It's a real team.

The lab team is primarily working on things that you don't see in public yet. They're trying really wild, out-there ideas that seem quite improbable.

The mad scientists. Are you officially under this thing, or—

No. Claude Code is now a fairly big group, and I actually don't know how many people we have. I remember yesterday coming into our weekly Cowork meeting and thinking, “Whoa, this is a lot of people here.”

But we still have a labs team, and we actually made the labs team a lot bigger. Mike just joined the labs team as an IC, which I think is very cool and very fun. But they're working on things that you have not seen yet that are extremely out there and probably half-broken, right? The idea of a labs team is that it should only work on things that make really no sense for anyone else to work on.

Okay, well, we're looking for exciting things from there. But thank you so much. I know we're out of time, but I appreciate your joining us. I appreciate Claude Cowork. Everyone, go use it. It is the closest I've felt to AGI this year.

That's so nice of you to say. Thank you very much.

Yeah, thank you for your time.

Yeah.