三类软件得以存活：Tasklet 的 Andrew Lee 谈如何竞争成为横向平台

Hello, and welcome back to The Cognitive Revolution. Today, I'm pleased to welcome audience favorite Andrew Lee, CEO of Tasklet, back for his 4th appearance on the podcast. Andrew has always been extremely transparent and candid. His belief that speed is the only moat has made him comfortable sharing intimate details of Tasklet's agent architecture. And as you'll hear, in the 6 months since we last spoke, Tasklet has indeed once again entirely rewritten its stack.

Today, there's much more use of file system context and agentic search to leverage available information while conserving tokens. Plus, there's a huge new emphasis on summarization at several levels of resolution. This time around, we also dig into the delicate strategic situation that Andrew and Tasklet face.

While their product strategy of always betting on the models has proven correct, and Andrew's choice of Claude has been rewarded, Andrew observes that these days everyone is fundamentally building the same thing. His most intense competition is actually coming from his critical supplier, Anthropic, which, with Claude Max accounts, gives their direct customers an estimated 5 times as many tokens as Tasklet can purchase at the same price via the API.

In micro terms, this relatively high cost of tokens has caused Tasklet to stick with Opus 4.6 rather than moving to the new 4.7. And in macro terms, it's pushing Andrew and his team to become a horizontal platform capable of harnessing—or, as Andrew describes it, outfitting with a mega suit—frontier models from any provider.

This evolution, which I do think Andrew has played and timed about as well as anyone possibly could, is critical because horizontal platforms are 1 of only 3 types of software companies that Andrew believes will survive the AI transition. The others are API-first companies like Stripe and companies that develop solutions and sell outcomes, best exemplified perhaps by Fin's model of $0.99 per customer service ticket resolved.

We get into lots more besides, including Tasklet's new Instant Apps feature; how they're thinking about deep, personal, and shared organizational context; the cloud container company that Andrew endorses; Tasklet's token-to-labor-cost ratio; and whether or not Zuckerberg has come calling after his Manus acquisition was canceled by the Chinese government.

This is a fun one with lots of valuable detail from somebody who's in the arena competing to become one of the few general-purpose AI agent platform winners and still actually willing to tell us all about it. Please enjoy my conversation with Andrew Lee, founder and CEO of Tasklet.

Andrew Lee, returning champion and CEO of Tasklet, welcome back to The Cognitive Revolution.

Thank you. Glad to be here.

You are a fan favorite, and I'm going to just try to pepper you with a bunch of questions and make sure we get as much alpha for all the builders in the audience, myself included, as we can.

So, first question: it's been about 6 months since we last spoke. You have rung in my head probably weekly with your “speed is the only moat” mantra. I guess my first question is, what have you rebuilt in the last 6 months since we talked? Or maybe more to the point, what have you not rebuilt in the last 6 months since we talked?

I think the mantra has stayed the same, and we've rebuilt basically everything. I was thinking about this earlier, and even the pieces where I'm like, “Oh, this has stayed the same”—actually, no, they've been totally rebuilt.

From a product perspective, the product is actually very different now. When we launched this thing in October, it was all focused on workflow automation. We thought, “Hey, it would be really cool if people could come in and describe a workflow, and we'd run the workflow for you.” But the feedback that we got right out of the gate was, “Once I've given this agent all of my context and hooked that up to all my stuff, I don't want it just running my workflows. I also want to be able to talk to it synchronously, too.”

So, it's not just a workflow automation tool anymore. Now, it is a very general-purpose agent that's great for doing workflows, but it's also great for doing other types of stuff. That required basically a total rebuild of the product experience and, as a result, the technology behind it.

As an example, in a workflow automation tool in the previous iteration of the product, you basically had a main agent that you talked to for a brief period to set up your workflow. Then, once you were done setting up your workflow, you basically stopped talking to that agent. The chats were relatively short, and then our system would kick off runs of what we call the task agent on a periodic basis when events happened. Every agent was a pretty short thing, and you could do relatively simple context engineering to make that work.

In a world where you want this general-purpose agent that you can talk to synchronously and run these automations, the product experience people want is just 1 big linear chat where everything is in 1 chat. It works really well from a product-experience perspective, but the engineering gets really complicated because you can't just have an infinitely long chat history that you feed into the LLM.

Even if you could, it'd be really expensive, and you wouldn't want every automation to have to send in 10 million tokens from all the previous runs. So, we had to totally rethink the way context engineering works and say, “What if, instead of the history being the thing we send to the LLM, the history is in the file system? What if the files are the agent?”

Marc Andreessen had a thing about this, and I think people figured this out, but we made the switch in November. We said, “Really, what we need is a file system that has your history, and then we need the thing that we actually send to the LLM to be just hints about what's in the file system and what things you need to read to get the work done.”

That way, we can scale the agent up, including the number of chat messages that were sent. There's a lot of other stuff we'll scale up in the future, but basically, you could scale from what fits in the context window to what fits in the file system. You can fit a lot more stuff in the file system.

There's a bunch of other stuff we've rebuilt. Another big thing we've rebuilt is around computer use. When we launched initially, computer use was kind of this add-on. You could have a Linux machine—actually, initially it was a Windows machine, then it was a Linux machine—tacked on. It really was an afterthought. You could use it for certain things, and it kind of worked okay, but most things you did with the agent didn't touch it.

At this point, computer use is the absolute core of the product. Basically, everything you do involves running shell commands, touching a file system, or touching a database. We have a very tightly integrated browser-use experience now, where every agent has a headless VM and a browser VM that persist state across runs and allow you to do lots of really cool stuff. It's in the critical path. Now, if our computer use goes down, everything goes down, whereas before it was kind of an afterthought.

We've also rethought the way our integrations work. This is something that, from a product-experience perspective, maybe doesn't look terribly different to folks, but the basic architecture of how we plug other systems into the Tasklet agents has been completely rethought—basically to allow the agent to have more control and management of those connections.

A simple example of an improved product experience is that you used to not be able to connect multiple instances of the same type of thing. You couldn't have 3 different Gmail accounts connected to an agent, and now you can. The base architecture there has been rebuilt.

I'd say basically every line of code has probably been touched in the last 6 months, and most of our fundamental assumptions were thrown out. The product still can do many of the same things, but hopefully much better now.

Yeah, that's cool. So, literally, you can't think of anything that has survived the last 6 months?

Nothing substantial. The visual design is totally different. The structure of the app is totally different. The connections system is different. The way we use computers is different. The core of the agent is different. The context management is different. The way we do compactions is different. It's all new.

Okay, let's talk about that compaction. One of the big takeaways from maybe 2 conversations ago was the critical importance of caching. You had said at the time, “Long context is quite effective. Obviously, it's expensive.” Caching, and especially the sort of 90%-off caching pricing of Claude, was critical to enabling certain things to really work without killing your company.

It sounds like that's changed quite a bit. Now, it's much more of a pointers-and-hints type of thing. How is this working? Obviously, tokens are expensive. People are spending a lot on tokens these days, and I'm increasingly hitting my limits even on the highest plan with Tasklet. How are you managing context for me? What should I know? What lesson should I take away from your experience on how best to manage context in the modern moment?

Caching has actually become a much bigger deal because now that the real context is in the file system, there are just a lot more tool calls that need to be done to perform the basic operations of the agent, because you're loading in a bunch of files and stuff.

And so, we really have to make that caching work if we don't want this thing to be crazy expensive. That's been very much at the forefront. We came up with a new approach to context management that we shipped in December that basically works like this: You take your whole chat history and put it in the file system, so it's all accessible there.

Then you find a way to summarize that whole history into a fixed-length number of tokens by including recent stuff at high granularity. The last thing you said will probably have most or all of it there. Older things basically have decreasing fidelity as you go back.

If you have a very long chat, the stuff in your current turn—the current thing that's running—is probably all going to be there, including all the thinking blocks, tool-call responses, files, and things that are probably going to be sent to the LLM for a bit, depending on how long the run is. For most agents' short runs, that'll be the case. The previous turn will probably mostly be there: you'll have the full user message, probably the assistant response, the tool-call arguments, the tool-call responses, and the thinking blocks.

But as you go farther back, we start stripping the thinking blocks. We start stripping the tool-call responses, or at least truncating the tool-call responses and then stripping them. We start truncating and then stripping the tool-call arguments. Then we start collapsing tool calls, and then we start shrinking down the assistant messages. Finally, we get to some LLM-based summarization.

We do this in buckets moving back so that we can have a minimal impact on caching. Basically, you want to avoid messing with prefixes as much as you can. As you go back, you get into these buckets where we have different levels of compression. Those buckets, as they get older, tend to get added to very slowly, and then, once they hit a certain threshold, we shrink them down.

This system has actually worked pretty well. The core thesis is that you generally care a lot more about recent stuff, and you trust the agent to go and look things up when it needs to. I would say it's not perfect. We definitely do have people say that agents forget things, and it still costs us a lot of money to run. But I think it's generally worked, and our plan is to double down on this type of architecture. We have lots of ideas for how to improve this, but I think the basic approach of decreasing fidelity as you go back, with these bucketed, cache-aware chunks, is the right approach.

How often does that get updated? If I have an agent that runs on a daily basis, do you try to keep the cache active from one day to the next, or is it that every day we're going to have a fresh cache that will run through that whole session and all the interactions, but tomorrow we begin again? On what frequency do we begin again?

Well, there are two pieces there. There is when things get updated on our side—when we decide what that compressed history that we put in the LLM looks like—and then what caching we do on the LLM side.

The answer to the former is every time you do anything. It's incrementally updated, including in the middle of runs. If you have a very long turn that uses a lot of tokens, it might actually start compressing inside that turn. The reason we persist that is that calculating it could be really expensive. Running an LLM-based compaction of an older section eats a lot of tokens, and you don't want to have to do that every time the thing starts up. If you're having a trigger run every hour and every time you have to compress a bunch of history, that could be very expensive. So we keep all that around.

On the model side, caching depends on the provider. In the case of Anthropic, we're using 5-minute caching, so it doesn't stick around very long. The assumption there is basically that you're probably either in an active session or in the middle of a turn, in which case 5-minute cache is enough, or you're probably waiting for the next trigger to run. Most people's triggers aren't running every half hour; they're running every few hours or every day. So the assumption there is that this is not so common.

Different providers have different possibilities there. For example, OpenAI has much nicer caching primitives, and I'm happy to talk about those too.

Yeah, okay. That's interesting. So it's basically constant maintenance of the higher-level summaries that will be fed into the LLM, and then pretty short, single-burst-style caching to actually reduce the cost of incremental calls within one agent run. It sounds like, at least for Anthropic, the cache is typically hit for one run but not across runs, for the most part.

Yep, that's the current approach. One thing I wanted to note is that, the way our system is built today, we basically get no cache benefit across users. It's caching for—even per agent; it's basically caching per agent. There are some changes that we can make to do a lot of cache optimization across agents and potentially even across organizations and users. I don't want to get into specifics of that because that's still upcoming, but I think there's a lot of potential to just save money across agents as well.

Yeah, okay. Well, that would be important.

I do want to circle back to the OpenAI question, because you guys have been Claude maximalists, and your other mantra that rings in my head a lot is, “Always bet on the models.” I'd say it's safe to say that has gone well over the last 6 months.

Obviously, we've seen some of the most notable model releases, in the sense that the community has flagged 4.5 and 4.6 as qualitative shifts, where things went from not working to working. People are like, “Oh, I can really get pretty general-purpose knowledge work out of these things on a pretty consistent basis now.”

I would love to hear how you would characterize the advances that we've seen. Maybe you could do that in terms of what new use cases have opened up, or things that have surprised you. Possibly also things that are still not working, which might be surprising given all the things that do work. Then we can get to the latest models. I want to give me the 4.5, 4.6 history, and then we can go to 4.7 and 5.5 in the present.

Yeah, I think the overall approach of always betting on the models has totally held up. When we started working on Tasklet, we were using Claude 4, and that was able to get you a long way. It worked pretty well.

4.5 was a big unlock. 4.5 started to look much better at doing computer use, and it could manage navigating through the various connections and the tool-enablement process much better. That came out very early in the lifetime of Tasklet, and it was a big bonus for us. The cost reductions around Opus were huge for us in—I want to say December, when that happened.

They dropped. So initially, we could really only have people on Sonnet, and then Opus dropped from $15 to $5, and that was a big unlock for us as well. I think 4.6 was a solid incremental change. It made computer use nicer again, which has become increasingly important for us, both headless and headful, as well as code generation.

That enabled our Instant Apps feature, which I think we'll probably talk about today. It's a very cool feature. We actually haven't rolled out 4.7 yet. I think 4.7 has been much better in certain areas. It's much better to code in one shot on long projects.

But for the types of iterative knowledge work that we support, it doesn't actually seem like a huge boost, and it's a lot more expensive. The tokenizer changes they made increased our cost by about 30%, and costs are huge for us. We essentially pass them on to users, so we opted not to ship 4.7 as a default recommended model. We are going to ship it, but as an advanced user option if people want to, and we're going to note that this actually costs a lot more.

I think the progress there has been great. The reason we started on Anthropic and have been so Anthropic-focused for so long was just that the basic core of our agent—the ability for it to navigate through a discovery process of connections, activate the right tool in your agent, and then manage its context, the way we manage its context—just requires a base level of intelligence that the other models couldn't provide.

You basically couldn't use the same harness with them and expect it to work well. That has changed, which is really exciting for us. It's kind of scary to be like, “We're totally dependent on this one vendor.” Even though they're great, the models are amazing. Don't get me wrong.

Supply-chain risks are everywhere if you take that approach.

Exactly.

But more recently, GPT-4.5 has gotten really good. I think it's a huge step up for our use case over 5.4. By the time this podcast comes out, we'll probably have announced this publicly. It can navigate our harness super well. I think it gives Opus 4.6 a run for its money for most use cases.

That's really exciting, and I'm pretty optimistic about the OpenAI roadmap this year. I think they made a huge bet on compute last year, and I think that's starting to show. I think that's where they're going to have a lead for a while. It's also clear that they've refocused their business much more on these types of use cases.

You saw the progress Codex made over 6 months, and if they put that level of effort into tuning the models around these types of agentic use cases, I think that'll be huge. We signed a deal with OpenAI the other day, and we'll be launching stuff there. We're making a pretty big bet there as well.

There has also been progress in other places. The latest Google models are pretty solid. They're not at the level of Anthropic or OpenAI yet, in my opinion, but they are making very fast progress, and they're much closer. We've been playing with Google DeepMind and Gemini, and the latest Gemini is, as far as we can tell, maybe better than Haiku and cheaper.

I think we're going to see those make their way into Tasklet soon. I would expect that within the next few months, we are going to have Anthropic models, OpenAI models, open-source models, and Google models. I bet you the Anthropic ones will still be the best and probably the recommended choice in most cases, but people will have a variety of choices and some good cost-optimization options for certain things.

So many follow-ups there. Let's maybe start with what I imagine has been a little bit of a delicate dance with Anthropic, and then we can compare and contrast that with what OpenAI is now bringing to the table. I don't know if you probably know what the ratio is of API cost to effective token cost when you buy a Claude Max subscription and max it out.

Obviously, in the intervening time since we spoke last, there's been the whole OpenClaw phenomenon, and that's had its own bunch of drama: you can, you can't, you sort of can; we've got to pay the API price; we're lowering our limits; we're buying compute from xAI; we're raising our limits back again. What has it been like from your perspective to be building on a platform that you're also sort of competing with, and that is kind of undercutting you to various levels at different times on its pricing?

Yeah, it's definitely an interesting relationship. On the one hand, the models are amazing. They're super good for our use case, and their team has been really helpful and responsive. We talk to them on a very regular basis, they're trying hard to support us, we get early access to stuff, they take our feedback, and all that.

They're definitely totally enabling our business, making it happen, and working hard to do it, which is wonderful. They're a great partner. I don't want anyone to think I think otherwise.

But at the same time, if you look at our stats—when someone turns off Taskade, where do they go? Eighty percent of those users go to an Anthropic product. So they are a very direct competitor. There are different use cases where we shine or other products shine, but it's clear that they're a very direct competitor.

The number one reason that they do that is because they already have a Max plan. They don't want to have to spend additional money on Taskade. Every time they release a new model update, we're like, “This is great. This is awesome.” And every time they send an email saying, “Now your Max plan is even cooler,” we're like, “Crap. This is just going to make it harder.”

They definitely subsidize it, and it has definitely set some distorted expectations with people around what you can get for a certain price. Cost is a constant struggle for us as we try to help users use the products more efficiently and help them understand, “Hey, we're actually working at some pretty razor-thin margins here and trying to make this cheap for you guys.” So, yeah, it's an interesting dance for sure.

Do you know what the ratio is, or is it opaque even to you?

I don't know what the ratio is. No.

Yeah, interesting. It feels like it's not insignificant. My intuitive gut guess would be it's like 5-to-1 or something.

That would be my guess too. Like 5-to-1, or maybe even more. It does seem pretty substantial.

Yeah, that's a big deal. One more thing on the Anthropic dance, and then obviously this gives you a lot of incentive to broaden out and try to position yourself a little bit differently. How do you think about the fact that they have an inside lane when it comes to building product experiences that make the most of their models' capabilities?

I mean, increasingly, we're seeing that the model is being trained in the first-party harness. I have another question on the word “harness” and whether that's even the right paradigm to be thinking about this anymore. But how do you position yourself? You said there are some use cases where you feel like Taskade exceeds what you get out of the first-party Claude products. I guess one thing is: how is that even possible, and how do you think about trying to compete with what they themselves are going to build, given all the inside knowledge, advanced preparation, close coupling, and advantages that they have?

At a high level, I think that everyone is building the same thing. You have all these different agent companies, and basically, over time, as the models get smarter and the agents build in more general-purpose tools—computer use, file systems, and whatnot—you can do very similar things in many of these products.

You can go into Claude Code and do all kinds of non-coding things in Claude Code. Codex, Claude Code, and many of these products are all able to do coding and non-coding things pretty well. I think where you start to differentiate—and I do think you can differentiate within the space to some extent—is really around what you're optimizing for and what the ergonomics are.

In our case, take Taskade. You can totally write code with Taskade. You can hook it up to your GitHub and have it generate PRs, and it does it just fine. We do this for marketing, for example. If we put up a new blog post or whatever, I write the content in Taskade, and then I just have it generate some PRs, and it works fine.

But it's not going to be as smart, and definitely not as cost-effective, for heavy-duty coding as using an actual coding harness. It's definitely not going to be as nice to use, because the actual coding harness is going to be in something like Cursor that's designed for a coding workflow, and our product is not set up that way.

I see a future where you can pick up any agent and have it do anything. But different ones are going to have different cost and performance trade-offs, and different ergonomics for different types of work.

Where we really shine is 24/7 automation of knowledge work for companies, especially knowledge work that is not your personal work, but something the company owns. If you have, for example, some complex invoicing process at your company, you don't want to be running that in your local coworking environment. If you close your laptop and the company can't invoice people anymore, that's bad.

You also don't want to put that in OpenClaw and run it on your Mac mini in the corner, because if somebody trips over the power cord, you can't run your invoicing. What you really want is something that's running in the cloud and is manageable by many people, with a lot of infrastructure around it to manage and provide oversight, have audit logs, put guardrails around the thing, and control costs across your different agents.

There are a lot of team-enablement features you care about, and that's where we really shine. A lot of the work to make that work well is actually fundamental to the way the agent is built.

I talked about our context manager. The reason our context manager was built the way it is is because you want to have triggers as regular messages into the agent. That means these agents, if you have an agent that's running a trigger every time you get an email, might fire 10,000 times this year.

You need an agent that can fire 10,000 times and still remember things from the beginning of the chat and behave in a reasonable way. That's a pretty different thing to optimize for than a coding session. The way Claude Code resets context makes total sense in a coding environment. It doesn't really make sense in a world where it's processing all your emails.

That's how I see us differentiating. The other couple of notes I want to make here on differentiation are, one, the market is just freaking huge.

If you look at coding agents, you might say, “Clearly, Claude Code and Codex have won.” But Cursor is going to sell for like $60 million. Even the fourth, fifth, and sixth players—Cognition is doing just fine, Factory is doing just fine, and even Windsurf, which had to sell, had a pretty good exit.

I would love to be number one here, but if we end up being number four, five, or six, that could still be a very significant exit.

The last thing I want to note, and I think this is probably the most important point, is that when we pitch a business, what we're trying to help them do is deploy AI for real inside their companies and automate things. Typical companies don't want to spend all their time researching AI models and placing bets on which lab is going to win.

They want to choose a platform that's going to serve them well, and they want to benefit from everybody's improvements over time. We can go in there and say, “Hey, a bet on us is not a bet on Anthropic or OpenAI or anyone else. A bet on us is a bet on everybody.”

We're going to get you Anthropic models, OpenAI models, Google's models, and all the open-source models, and then we will be a neutral arbiter of what you use. To the extent that we can build features to help you choose the right model for the job and optimize your costs across the different things, you can trust us because none of these are ours. We're getting the same margin as them on everything, so we're a neutral party.

If you go with Anthropic, right now it's just Anthropic products. Even if they decided to provide other models through their products, which they could, although I don't think they're going to, I don't know if you'd really trust them to do that in a neutral way.

I think that's a pretty compelling part of our sales pitch.

Yeah. I think you've navigated this about as well as anyone could, in the sense that you bet on Anthropic and went all in on whatever the best model was—which has been Claude—to make it work as well as possible while the capabilities curve was getting to critical thresholds. Then you pivoted to being a more neutral abstraction above the model layer, now that there are multiple options that seem able to deliver the kind of performance that people want.

It wasn't obvious to me that that's how it was always going to play out. I think I would have said about your position 6 months ago, “Yikes, it is pretty tenuous to be all in on Claude.” But I think you timed it pretty well on a couple of different levels. How much would you say that's foresight and genius, and how much is good luck?

Yeah, I think this was very much the plan, and I do think it's worked out really well. I'm happy with how it's turned out.

So, okay, let's do this harness thing for a second. The word “harness” itself always makes me think of trying to control and direct some sort of wild animal to get useful work out of it when it might rather be doing something else.

I just took a long road trip with my kids in a Tesla FSD-enabled car over the last 10 days. We went to a lot of historical sites, and the juxtaposition of horses and my FSD was pretty funny. I think of trying to get this unruly animal that is a model to stay on track and do what you want it to do.

These days, as you said, there's a lot more ability to give the model hints and say, “Here's a file system, and you can go get what you need here.” I'm starting to feel like the concept of a harness is maybe a little anachronistic already.

Maybe what we're doing now is more saying, “Here's the world you get to play in.” It's not so much about trying to narrow what the model can do, but more about broadening what it can do. How do you think about narrowing and focusing versus broadening, giving access, and unlocking new possibilities, which in some cases might even surprise users given the model capabilities we have now?

I hadn't actually thought of a harness as being a constraining thing, but you make a good point that this would be the normal way you'd think about that word. I kind of think of it as a mech suit.

I agree with your thesis. The goal is to let that agent, or let that LLM, actually do things in the world. To do that, it's going to need storage, compute, the ability to reach out and connect to APIs, and the ability to talk to the user.

There’s a lot there. I think when I talk to people who aren’t deep into the harness world, most people assume that when they play with an LLM product, it’s a very raw thing on top of the model: you type a thing, it gets sent, and what they see on the screen is just being sent to the model and the model is doing everything. That is becoming increasingly less true. The complexity of the code that’s translating what you see into the LLM calls is getting greater and greater, and I think that’s going to continue.

I think the sophistication of these harnesses is going to get 10 times more complex. But I think there are going to be some pretty major breakthroughs here that increase the capabilities of these things substantially—in the way that we handle memories, in the way that we handle oversight and control, and in the way that we connect to other tools. So I’m very bullish on the opportunity here, and I think these things are just going to get more and more complicated.

Maybe we need a new name. Maybe it’s a mecha suit and not a harness.

How much do you think—this is one of the more interesting debates right now in the AI builder community broadly—what matters more: model or harness? You see pretty extreme positions on both ends. I get emails that are like, “Models don’t matter anymore. It’s all about the harness,” and vice versa. Obviously, either of those extreme positions is not going to be right, but I guess I’ve historically come down somewhat in favor of models.

I don’t know if you’ve seen this graph from the UK AI Security Institute, where they do a capability plot over time with the minimalist harness—whatever kind of basic, vanilla thing—and then the best available harness. Of course, both are going up. A year ago, though, the time delta between what level of capability you could get with the best available harness versus the vanilla harness was longer, and now it’s gotten shorter.

Some of that is maybe just due to more frequent model releases, which is shortening every window of advantage. Some of it is maybe because the models are getting more deeply trained to use harnesses, so they’re just good at it out of the box. You don’t have to compensate for their weaknesses as much.

My overall summary would be that models seem to matter more. How much can I live in the future with the best available harness for any given model? It seems like it’s not a huge amount, but it sounds like you maybe see that differently. So, if you do, what’s the case that that’s wrong?

I think as models get better, they can replace good harnesses. A model today with a crappy harness is going to be better than a model from a year ago with a really good harness. I agree with that, and I think that trend is going to continue, but I also think the effects are multiplicative, and they’re orthogonal disciplines. There’s no reason not to take the best model and put it in the best harness, and I think we should.

You might argue that, given the exponentials, that actually only buys us 6 months or something. Okay, fine, but it’s 6 months. More importantly, the only metric that matters is not intelligence. In these real production systems, intelligence is one piece. Take Tasklet, for example. Much of what we do is automating specific workflows.

Once the model plus harness is smart enough to order lots of lunch every day, which it does, and we’ve been able to do that for 6 months, we’re not going in there and messing with it very much. Incremental improvements to intelligence don’t really matter, but performance and cost do. If you look at the harness and say, “Hey, the only point is to make the thing smarter,” fine—it buys you a fixed amount of time over the model exponential, which is maybe cool, but not amazing.

It might make a significant difference in cost and other attributes: cost, reliability, the ability to do oversight, and speed. I think those things matter a ton for a commercial product. In our case, with our harness, the benefits you get are that you have a nice UI, the sidebar pops out at the right time to show you things, and you get nice indications of working states. You can see what it’s doing at the time, you get the ability to have things persisted across long periods of time, and you get nice performance and cost tradeoffs. I think those things should not be underestimated for a commercial product.

Yeah, if you can make it work with Haiku instead of Opus, for example, that moves the needle quite a bit. Especially in a compute-scarce world, which we increasingly seem to be in. Okay, so—

Yeah, and so, if I can interject here, a good example of this—and I don’t even know if you’ve called this a harness—is what Anthropic is doing with their—I think they call it a supervisor agent, or I forget exactly the language they use. Basically, they have a system where you can inject a tool that allows a smaller model to call up into a bigger model. This is a relatively new thing that they’ve been talking about.

You can basically get close to the bigger model’s performance, but do the vast, vast majority of your work on a smaller model. That’s a huge win. If you have those capabilities, why not?

When you think about the best available harness and what that looks like, especially as you go to a multi-provider paradigm, how much do you think you’re going to be building a harness per model versus trying to keep everything the same across models? Traditionally, one would think, “No way we can build this complicated product in a bespoke way for all these different models. We’ve got to keep it consistent.” But obviously, the old rules don’t apply anymore.

What’s your strategy? How much do you tailor the harness to each new model that you want to launch?

This is very much on my mind right now. Ideally, as little as possible, because we want to support a lot of models, and it’s hard to maintain a thing across models. But we also want to have the ability for these agents to switch between models.

If you’re saying, “Hey, you can run on Opus this way and it persists this state,” but then you switch the same agent over to some other model and suddenly you’re trying to translate things, it gets really complicated. We’d like to keep them as similar as possible.

So far, we’ve been able to do that. Our approach has been that maybe we’ll make some prompting tweaks that try to address issues in one model while not breaking the other model. I think so far that’s mostly worked. Over time, the APIs of these things have converged, and the basic capabilities of these things have converged, so my hope is that it’ll get easier over time, not harder.

I could see us having some very model-specific harness things potentially. I’m thinking about ways to get that in a really modular way so it’s not a huge amount of overhead. But definitely, it’s something on my mind.

Even beyond model capabilities, you alluded earlier to caching primitives being different across providers. So presumably, at a minimum, on that level, you kind of have no choice but to—I mean, you maybe could have the same context, but you’re going to have some sort of different implementation for certain things that are just different, that are inseparable from the models, right?

Yeah. In the example of Anthropic and OpenAI, OpenAI has a very simple caching API, which is basically, “I’ll just cache any prefix for 24 hours,” and they do it automatically. Anthropic has a much more explicit caching API, and you can only cache 4 points in your call. There’s a lot more code making that happen.

In this case, we’re kind of lucky in that once you’ve done the work to make Anthropic work, making OpenAI work is pretty easy. But in that case, we do have different code to translate our context into a cacheable context for each one.

You mentioned 5 providers: Anthropic, OpenAI, Gemini, DeepSeek, and Kimi. Not on that list were Grok, whatever the new Meta models are called, and GLM or MiniMax. How are you thinking about who’s in and who’s out? Where are you drawing the line?

It is so hard to stay up to date on this stuff. We have the ability internally to test models pretty quickly. It’s hard to actually ship things in production because, for example, the way thinking blocks work is different across different providers. If you have bugs, you might have to tune the prompts and things.

We haven’t shipped that many, but we’ve tested GLM internally. We’ve tested Google models, Kimi, and DeepSeek, probably some others I’m not thinking of. I think right now, most of this is initially vibes. You go in there and play around with it, and you’re like, “Is this close enough to the frontier that we want to put some effort in here?” Usually, the answer is no.

I think the ones that we’ve tried—DeepSeek and Google, plus obviously OpenAI—are the ones where, okay, actually, this is pretty close to the frontier, so it’s worth doing. There’ll probably be others on the list. I have not been paying a huge amount of attention to Grok. Maybe I should be paying more attention to them.

I don’t hear a lot of other developers using their models. They sure seem to be investing a lot, so I don’t know—maybe they’ll change.

Yeah, in my view, we can’t count Elon out of any race until he bows out himself. I would also agree that I don’t use it much. I just had occasion to use it a fair amount while riding in the Tesla over the last week, and it’s not bad. The voice mode is pretty good.

It definitely still feels a little rough. That’s also part of it: it’s not just the model; it’s also the integration. My experience using Grok in the console of the Tesla is definitely rougher than my experience using Anthropic, OpenAI, and Google models.

Our users are pretty good at being savvy about this stuff. Not everyone, but there are enough users who try this stuff that we start to see requests. I remember back in the day—this was pre-ChatGPT, in the Shortwave days—when we were using GPT-4. At the time, we thought we were on the best model. We thought we were beating most of the stuff.

Within a very short amount of time after 3.5 came out, we started getting a bunch of people emailing us, saying, “Why are you guys on this old model?” We were like, “These people are just misinformed, right? We’re on the best model. We’re on the best model out there.” It turns out they were totally right.

We also kind of watch our users and say, “I have not yet seen a user be like, ‘Hey, you’ve got to get on Grok. That’s the most modern model.’” Although some people have asked for OpenAI stuff.

Where do you think things are most likely to diverge? This is another big question. You said a minute ago that you probably think things are converging in terms of capabilities, which hopefully makes it manageably complex for you to support all these different providers.

I also hear the other narrative that we’re starting to see more and more meaningful differentiation, and I honestly don’t know which is right. I sometimes feel both ways myself. But if you had to zoom in on particular areas where you think models would most likely meaningfully diverge over the next period, what would that be?

One candidate that comes to mind for me is how sub-agents and team delegation across instances work. That seems like nobody’s really figured it out yet. One meta point would be that things nobody’s really figured out yet might be the place where people are going to take the most different strategies, and then they’ll converge once there’s a winner.

Right now, it doesn’t seem like anybody has a super-awesome way to have many different instances of a model work together. That’s one idea, but what’s on your mind in terms of where they’re most likely to be majorly different?

Within the major labs, I think everything I’ve seen tells me that they are converging, and they’re converging because they’re watching each other. Take Opus 4.7. My flippant response is that they started to realize that Codex was better than Claude Code for many things, and they were like, “How do we make our model more like Codex?” They made a bunch of RL tweaks to give it a bit of a different personality and make it a little more precise. Then 4.7 felt a little bit more like talking to Codex.

When Codex got good, it was because of improvements to the model on OpenAI’s side. I think they were watching Anthropic and saying, “Claude Code got really good at writing code. How do we do that?” It seems to me that those two labs are watching each other and trying to mirror each other.

5.5 is much better at general-purpose, long-form agent tool calling, and I think that’s because they’re watching over each other’s shoulders. At least those two labs are watching each other very closely, and I see a kind of back-and-forth there.

I am excited about the number of new labs that have raised a lot of money and are doing totally different things. It would be awesome if somebody came out of left field with a totally different approach. I don’t know if you’ve learned anything about JEPA, Yann LeCun’s thing. I finally watched a long-form video about it yesterday, and it seems really fascinating. It seems quite different.

I have no idea if it’s going to pan out, but there’s a billion dollars riding on the idea that this totally different approach to LLMs is going to pan out, so I guess we’ll find out. Then there are also labs taking an approach of, like, “Let’s use a lot of data.” It feels to me like all the major labs really are watching over each other’s shoulders, while there are a bunch of new labs trying totally radical different things. That’s kind of how I see the lay of the land.

So, convergence unless somebody manages to shake the snow globe with some sort of algorithmic, insight-driven breakthrough.

That’s my guess. On the harness side, actually, I think the harnesses are also kind of converging in terms of capabilities, and largely that’s because it turns out the best harnesses just use low-level primitives.

In our case, we don’t have super-specific stuff for doing email. We have a file system, a database, a shell, and a browser that it can use, along with some simple primitives around writing to-dos and setting up triggers. But it’s all very low-level. There’s nothing workflow-specific in there, and I think that’s the right approach.

The places where we differentiate are not around capabilities, but more around cost, ergonomics, and speed. Those are kind of the differentiators.

You mentioned having signed a deal with OpenAI. I’m sure the precise details are under an NDA or whatever, but one apparent point of divergence I’m interested in watching is the way they’re positioning themselves with respect to products like Taskade and open-source toolkits like OpenClaw.

OpenAI seems to be really leaning into, “You can use your core OpenAI account in these other contexts.” What is that going to look like, and how is that going to complicate life for you? For one thing, if I can log in with OpenAI and bring my own tokens, that totally changes your pricing model, right?

Now you have a more traditional SaaS-type business, where the intelligence costs aren’t flowing through you. I don’t know exactly where they are on that, though. I know that they allow me to do it with OpenClaw, but I haven’t seen too many other things around the web. I’ve honestly expected it to come sooner.

Maybe they were compute-constrained enough that they didn’t prioritize it, but I’ve learned that “compute-constrained” is a good answer for anything. It’s real sometimes, maybe it’s not, but it certainly passes muster as an answer.

Should we expect a future where I come to Taskade and can just connect my OpenAI account and bring my tokens? How will that complicate or change what you’re doing?

It’s a good question. Obviously, Anthropic has decided to go the exact opposite direction of that, and I’m glad we weren’t in that situation when they were cutting off people’s API access.

I don’t know. I guess we kind of want to see how this plays out. If this is something that’s popular and we feel like OpenAI is going to do it for a long time, it totally makes sense for us to integrate it and let people use their tokens. I do think we provide a lot more value than just being a token reseller, so I don’t think it’s necessarily a threat. It could be a nice kind of onboarding experience for folks.

From a competitive position, is there concern here? Is it that OpenAI is going to own the user relationship, and if people already have an OpenAI account, why do they have an account with you?

I think we’re maybe a little more concerned now than we used to be. Up until they killed off Sora—I don’t know if you remember the big leak around Sora—the impression we had gotten was that they were very focused on their models and the consumer, but they weren’t really very focused on business productivity.

You could see that, in my opinion, with AgentKit, when they came out with it last fall. It didn’t really feel like they were bringing their A game. We thought, “Great. We’re competing hard with Anthropic, but OpenAI is focused on the consumer and models, and we can kind of run with it for a while.”

It was fine. When they killed off Sora and there was that leak around, “Hey, we’re going after business productivity,” the scenario that we were worried about—or are worried about a bit—is basically what happened with Codex, where Codex went from kind of an also-ran to arguably the best coding agent in a relatively short amount of time. If they’ve brought their A players over to focus on this stuff, and it seems like a very potentially competitive area, they might start to compete with us in a really big way.

That said, we’ve seen none of this so far. I have yet to talk to a customer who’s like, “I left Taskade to go use OpenAI products.” We’ll see if that actually shows up, but it could.

Yeah. The whole thing—there are so many strange alliances and strange bedfellows, and this kind of coopetition.

The weirdest to me is the Anthropic–SpaceX announcement, after Elon badmouthing them and clearly competing very hard with them, and then doing this big commercial deal. It’s a weird time to be doing deals.

Yeah, no doubt. I love to see that, for what it’s worth. I have mixed feelings about Anthropic. I echo all the positive things you said earlier. I do think their work on the safety front, across multiple sub-fronts of safety, is second to none, and that’s pretty much uncontested. The Constitution—I only slightly exaggerate when I say I almost cried when I read it, because I really think it’s a beautiful document. The interpretability work that they do is amazing.

And yet, if somebody launches a recursive self-improvement loop that gets out of control, I would have to say they’re probably the most likely candidate to do it at this point. So it’s a very weird thing, but I do love to see closer ties between the leading companies because, if nothing else, it just takes the edge off the competition a little bit.

To the degree that they can share in each other’s success, even on a marginal basis, for me that’s a huge win. I encourage all of these ties—as weird as it is, I encourage all the tying of cap tables together. I think we’re all going to rise or sink together. That’s kind of my bottom line for humanity.

So let’s start to make those deals in anticipation of that reality. I think that will probably serve us pretty well in the end. Anyway, okay, that’s just an editorial aside.

One thing that’s been counter-narrative recently—you’ve surely seen the Andon Labs guys who do Vending-Bench. They’ve now launched a couple of actual brick-and-mortar, real-world retail stores managed by AI models. They’ve got the retail store in San Francisco that’s operated by Claude, and they’ve got a café in Stockholm that’s operated by Gemini.

A huge surprise was that they said GPT-5.5 was clean in the way that it runs its business, whereas Opus 4.6 and 4.7 they described as ruthless—being willing to lie to suppliers and do things that aren’t necessarily illegal but are questionable in pursuit of its goal. Do you have any interesting commentary on the character of models? Is this something that you have to take into account as you build? You could imagine that if one model is ruthless, or willing to cut corners, and another is clean, that could have an impact on the kinds of supervisory systems you might want to have in harness. Do you have any observations or plans on that front?

I had not heard that particular note from them, but this is all purely anecdotal. I’ve not done any research here, just based on my own experiences with it, but it doesn’t surprise me. My experience with the Anthropic models is that they’re much more creative and much more empathetic. They understand the human experience better, whereas the OpenAI models are a bit more clinical.

That comes with its pros and cons. I guess it doesn’t surprise me that the one that understands humanity is also the one that maybe shows some of the worst traits. We haven’t run into any problems here that I’m aware of. No user has been like, “Hey, this thing went and did something unethical.” So nothing has cropped up here, but that personality aligns with my experience, too.

Yeah, it’s interesting. They’re the most creature-like, for better or possibly for worse.

I’d say one big thing—and I’m using everything. I’ve got a Taskade Max account that I’m maxing out. I’ve got a Claude Code Max account that’s kind of my laptop terminal. I do have the Mac mini sitting over on this side that’s got another Claude Code and an OpenClaw. I’m really interested in context beyond the single agent.

This is kind of a frontier for you, but maybe not. I’m not sure if it’s something you feel is as important as it has been in my own personal hacking. Do you think you’re going to need to build a sort of second-brain feature for users that sits at a level above or below the individual agents, but gives the broader context?

I’ve got 10 Taskade agents running. For the most part, they stay in their lane. They may access some of the same context through tool calls, but they don’t have a shared meta-state that says, “Here’s Nathan and all the things he’s trying to do. Here’s what he cares about. Here are the people in his life, in case you run into these people. You can kind of know what’s going on.”

Obviously, that’s really important in organizations, too: the general situational awareness of who’s on the team, what our priorities are, and what we’ve said no to in the past. Is that something you aspire to tackle?

Yes, absolutely. I swear to your listeners that I didn’t prime you to ask this one. We actually have some organizational features that are kind of the starting point for this live in the product today. We just haven’t announced them yet.

If you go and look in your settings, you may see that there are a lot of organizations and workspaces, and there’s some stuff that you can configure in there. We’ve been laying the foundation for what you described for quite a while. We’re going to have a launch with a bunch of fanfare, and there’ll be some stuff on Twitter when we feel like it’s really ready to talk about, which hasn’t happened yet. But you can actually use it now if you want. You can invite your team and get them on here.

The way we’re thinking about it is that there’s a hierarchy of context. If you’re in an organization, some things are at the organizational level. You might have, “What is our company? What does it do? What’s its mission statement? What are its values?”—some basic things that you want to control at the organizational level. You might set some context there.

Then you have additional context at the team level, where you say, “The marketing team has access to these resources. They have these goals. These are the OKRs for the quarter. Here are some skills that define the various business processes that we have. Here are some files that are important to consider when doing different things. Here’s our brand voice,” or whatever.

Then, in the individual agents, you have very specific things: “This is the plan for running this particular workflow. This is a file that was uploaded to this agent. These are the instructions that someone gave me specifically for this conversation.” Organization is company-level stuff, workspace is team-level stuff, and the agent has stuff for the specific workflow.

We’re building everything around this. Today, most of the work has gone into the agent. At the workspace level, the only shared context we have today is your connections, and this is actually super powerful. If you have a company where you want the lead on your team to configure connections with all the API keys, headers, and whatever to connect to your systems, they can hook up your API access and then give that to other users.

When someone new comes to the team, they don’t have to find all the API keys. They can just go and start talking to agents right away, and the agents already know how to connect to things. That’s super powerful. So that exists today, but we want to add shared skills, some form of cross-agent memory, and probably some shared file-system functionality.

If I talk to one agent and explain something to it, it should be able to remember that for other agents. We want to add documents that are available across any agent. You can do that now if you connect to Google Drive or something, but we can probably make it a much nicer, more native experience. All that stuff is coming, and I think “shared brain” may be the right way to look at it.

I don't know if you saw their product they launched the other day, which I think they called shared brain, and I think a lot of what they announced is very in line with the vision that we have as well. I haven't tried it. My hunch is that they’re farther along on the brain side, but the agents aren’t as good. That’s just my hunch, and hopefully we can catch up and surpass them on the brain side while maintaining our lead on the agent side as well. It’s a huge priority for us, and I’m very excited about what we can do here.

Yeah. Okay, cool. I guess maybe let’s zoom out, and then we can end with a lightning round of some lower-level esoterica that the real ones will want to hear about, but that isn’t necessarily as important as the big picture.

Where is this all going? We’re in this weird transition point where, on a couple of dimensions, you’ve got computer use. We’ve talked about that a couple of times, and you’ve kind of bundled command-line-style computer use together with UI-based, computer-mediated computer use. That feels like its own sort of paradigm shift. It’s happening under one label, where everything is kind of going headless, but at the same time, the models are getting really good at using UIs.

Which is going to win? Are all UIs going to go away, or are the models just going to be really good at them? Maybe it’s both.

Similarly, you mentioned that everybody is competing to build the same thing. I’ve never felt that as strongly as I do right now, where you could probably name 10,000 companies that are competitive in some not-super-indirect way. You’re competing with Claude, but you’re also competing with Microsoft Word, Zapier, everything under the sun, and straight-up human labor. It’s endless.

How do you conceptualize where this is all headed? What’s the big vision? Where are we 18 months from now, just before the singularity hits?

A year ago, right before we started the pivot, one of the big things that we were seeing was this: for context, for people who maybe don’t know, we had a product called Shortwave, which was an AI email client. We still have it, actually, but it’s not the focus of the company anymore. We had this really nice embedded agent inside it, and you could do really cool email stuff.

We realized that it wasn’t going to be too long before you could take a product like ChatGPT and say, “Show me my inbox,” and it would just generate a UI for your email on the spot. Once that worked well, you wouldn’t need an AI email client, because the whole email part would go away. Our entire concept of differentiation—where we were saying, “Hey, we’re going to embed this agent inside a custom-built UI”—had a shelf life.

The product is still growing. It’s still doing reasonably well, but in 10 years, I don’t think it’s going to be around—probably much less than 10 years. I don’t think it’s going to be around, at least not in this form. So we said, “Man, we can’t build a business around an AI agent embedded in the UI. We need to do something else.”

We said, “Hey, we’re going to build a very general-purpose agent that isn’t relying on this, and we’re going to go after an agent for a specific type of workflow”—these sorts of knowledge-work, trigger-based knowledge-work workflows. Then we built the thing we launched in October.

The feedback from people was, “Hey, we don’t want to have one tool for workflow automation and another tool for doing our day-to-day work, because we want them all to have the same context. I don’t want to have to maintain two systems where they both have all the stuff in the shared brain. I just want to have one system.”

So we said, “Okay, I guess we need to do not just the workflow stuff, but the synchronous stuff as well.” When we pivoted out of email, it was like, “Okay, well, actually there’s going to be some more general product that’s going to encompass this stuff.” Then again, it was like, “Oh, I guess there’s going to be some more general product that’s going to encompass this stuff.”

In March, we launched our instant apps feature, which is basically a generative UI feature. The idea is: what if you could generate any UI you want that hooks up to any of the data in any of your connections and just works instantly in a single prompt? You can one-shot anything.

It turns out this works really well. This has been a super popular feature. Our team just uses the crap out of it. If we do any sort of data science work, for example, we’re no longer going into the BigQuery UI or creating dashboards using dashboard tools. We just go into Tasklet and say, “Generate an explorer dashboard to help us analyze how these pricing changes would affect our users.”

It will just make a thing, and there’ll be toggles. You can tweak thresholds and things, and it just works. It’s amazing. We said, “Man, that vision—that fear that we had a year ago about what would happen with email—is actually here.”

You could go into Tasklet today and say, “Give me an email UI that works,” and it will. It’ll work, and you can do your inbox in a UI inside Tasklet. It’s not as good as Shortwave yet, but it’s not going to be that long.

I think the high end of these things has actually been much faster than we expected, and it’s clear that each area where we feel like there’s going to be differentiation is falling away. Looking forward, I see no reason why this trend of the general-purpose tool continuing isn’t going to continue.

This is all driven by the fact that the models are general-purpose. If the best model is best at everything—which I think is increasingly true, essentially for economic reasons—I think the best harness is going to be intelligent at everything. There will be some differences in ergonomics, but it will be intelligent at everything.

We need to assume that the number of these products that win is going to be relatively small. I don’t think we’re going to have many, many, many tools that all have AI embedded in them. I think we’re going to have a few very horizontal platforms, and what we’re trying to do is be the AI agent platform that replaces your SaaS products for knowledge workers.

Today, most knowledge workers work by switching between tabs or switching between apps in their dock. Sometimes they’re using Word, sometimes they’re using Notion, sometimes they’re using Linear, and they’re going from tab to tab to tab for different things. We think that entire world is going away.

Instead, you’re going to have one app that has a UI. It’s going to be your AI agent—hopefully, it’s Tasklet. If you want to access some data from one of these tools, you connect to it through an API. If you want to do some interesting analysis, rather than that analysis being done by bespoke business logic in the tool, it’s done via code execution. The agent generates the code and runs the analysis.

If you want a UI, the agent generates the UI in one shot with a prompt and gives you the UI you need. We think it can cover basically all of your productivity software.

In this world, I basically think there are going to be three types of companies left in the software world. There are going to be the horizontal platforms, of which I think there will be very few winners, because people don’t want to have to maintain context and connections across multiple platforms. They’ll probably just have one for knowledge work, one for coding, and maybe one for personal use—but not very many of these.

Those will be the horizontal platforms, and we’re going to try to be one of them. Then there will be headless companies. To give you an example, take Stripe. I still think you need to do payments. Payments are really complicated, payments are really important, and there’s a lot of compliance and risk management involved. So probably this is Stripe, but you may not have the Stripe dashboard anymore. There may be no reason to ever go to the Stripe UI. It’ll really just be an API tool.

Then you’re going to have solutions companies where the software is totally hidden. They’re selling you a product. For example, I think you’ll still have lawyers and real estate agents. They’ll still exist, and they may use AI heavily, but you may not see that. They’re going to sell you, “Hey, we’re going to help you sell a house or buy a house,” rather than selling you software.

So, yeah, I think it’ll be those three: horizontal platforms, of which there will be only a very small number of winners; headless products; and solutions companies.

So what happens to something like Salesforce? They would obviously fall into that category, and they just made this big move to go headless. But I wonder if payments is different. There’s a lot of depth there, a lot of compliance across jurisdictions, and a lot of risk management. It doesn’t seem like it’s coming anytime soon that a general-purpose agent would eat that.

Salesforce, on the other hand, I’m like, what is it really? It’s kind of a schema—and a very, very complicated schema—that sort of came from an era when you could only maintain one. So you had to make it fully general across all your customers and everything they might plausibly want to do.

But most people don't need anywhere near everything that Salesforce has built for them to possibly want to do. And so, it does seem much more realistic for many people to have Tasklet whip it up for them, right?

I think Salesforce is in real trouble. A huge amount of the code that they have built up over the years is probably obsolete. I think the value of being a system of record in a world where you have agents goes down a lot, because moving data around between systems suddenly gets a lot easier.

I think there are probably still many headless things that you can do that are pretty useful, but the ability to build competing products has gotten a lot easier. They have a lot more competition because you can vibe-code some of that stuff. So, a huge amount of what they built is obsolete, it's now easier to move to a competitor, and there are going to be more competitors.

I don't think they're going to die, but I think you're likely going to have a much smaller Salesforce in the future than you do today.

It strikes me that a system of record and really reliable storage are not the same thing, but really reliable storage is a key part of what drives system-of-record value. I've had instances in my personal Claude Code, local AI productivity-stack development process where it has, in fact, dropped a bunch of data.

I'm trying to export stuff out of Slack, for example, and it realizes, "Oh, we didn't quite export it right the first time. I'll just delete everything and go try it again," not realizing that it was so rate-limited that it actually took about 4 days to export what I had previously exported. I certainly value the fact that Slack is not about to delete all my stuff by accident.

But that also suggests that there may be an opportunity or paradigm shift where the horizontal platforms say, "Here's why you can trust us with your data. Even if the agents make mistakes, or even if this or that kind of goes bad, we're going to have some sort of snapshotting, rollback, and durability guarantees where mistakes can't lead to data loss."

It seems like if you could make that guarantee for people, they could get much more comfortable with the idea that they don't necessarily need Salesforce anymore.

Totally. I think this is a huge place where the harness is better, where the harness can make the LLM smarter. We can discuss whether that is true or whether it matters, but can the harness do this sort of thing? I think totally.

Let me give you a few examples of how I think we can help. One is versioning. There's a whole bunch of startups working on file systems for agents right now, and some of those folks are working on versioning. The basic idea is, "Hey, if your agent goes rogue, you just want to roll back to some previous state."

In a simple chatbot, you can just throw away the messages at the end. But in something that's touching the world, we've got to be able to roll back the world. For a file system, you can just change the file system, but if it's touched APIs and stuff, you might need to keep logs of things.

The ability for you to undo things that the agent does, I think, is pretty key. So, I think there's a lot you can do there.

I think another area is having oversight and logging, so you actually have the ability to have a human in the loop in places where it matters and do that in smart ways. With our product today, you have to activate tools. One of the things that we're going to add soon is the ability for you to have some tools that you approve every run.

So, in the case of emails, I think Apple loves this. People are pretty confident to say, "Hey, you could read my email as much as you want. You could make as many drafts as you want, but you can't send anything unless I say yes."

We want to get to the point where that is really ergonomic. For example, it could send you a push notification when it's ready to send an email. It could go crazy reading and searching and making drafts, and then when it's ready to send, you get a push notification that's like, "Hey, do you want to review this before it goes?" Then you can say yes. That's all pushed to you.

I think permissioning will be a big area. I think another big area is using code better and in a more deterministic way.

Let's take data migration from one system to another. The naive way to do this is to load that data through an API, feed it to the LLM, have the LLM call some tools, and put it somewhere else. Basically, when you do that, every time you're putting it through language-model context and trusting it not to hallucinate and to reproduce that data.

I think the models will get better at that over time, but it's very hard to have a lot of confidence there. The better way to do this is to have the model generate a migration script and then run the migration script. That gives you an artifact in the middle that you can test and have human approval for.

If you're moving data from one system to the other, you still want to have an agent that's thinking through how to solve the problem. But what it should probably do is generate a migration script, generate some tests, run the tests, and then send the thing to the human, saying, "Here we have the migration plan and the code and the tests, and this is why we think it's going to work. Are you okay with this?"

Then you say yes, and then we run it. You can even have test environments. I think the ability to have tools within the agent that allow it to do really high-reliability stuff and to have approval—there's a lot of opportunity there.

Okay, I know time is short. Lightning round. I have to prioritize. First of all, any vendor shout-outs that you would want to make? You alluded to companies doing rollback-the-world-type storage. Who's out there that you're using, if anybody, that you think is underappreciated?

Yeah, it's a good question. I think the one vendor that we use in a pretty big way, that we've been pretty pleased with, is Blaxel, which is a sandbox vendor. They just have really fast cold starts and good performance, and it allows us to have sandboxes at the very core of our product. I think Blaxel has been pretty great.

We also use Firecracker for crawling, and they have some nice performance characteristics. We've looked at a bunch of these storage-tech companies. We looked at some of the people doing databases and file systems, but so far we've opted to have our own infrastructure here.

I don't know if that'll always be true, but there's kind of a trade-off here of, "Hey, we think this is pretty core, and if we're going to go with some vendor, they'd better provide a lot of value and be somebody we have a lot of confidence in with a good roadmap and so forth." So far, we've decided to do that all ourselves.

And then, obviously, the labs, right? The models are amazing. We would not be where we are today without Anthropic.

How about the possibility of reselling, perhaps on a fractional basis, other services? There are lots of connections where I can connect my Gmail and connect to my personal stuff. But then there's this whole broader universe of tools that I could have an account with, but maybe I don't have one and I don't necessarily want to create one, or they make it somehow difficult to do what I want to do.

A classic example for me is Suno. I'm loving generating music these days, but it's not very agent-friendly, and I constantly end up in their UI. I'm like, "This UI should have been an API call. I just want to hear the music."

But I also think maybe I could use my Tasklet credits to fund generations with these other services where it's not a highly personalized service. It doesn't matter if it's my Suno account or somebody else's. It may matter long term, but as of now it doesn't really matter.

Is that something you plan to do—to open up a Swiss Army knife of things that are paid, but that I access through you via the credits that I've bought?

Yeah. I do think we will do that eventually. We've made some very small forays into this already. One of those is web browsing, sort of search, right? We use Firecrawl, and you could argue that that's sort of reselling an API.

Another one that's likely to come very soon is image generation. You can connect DALL·E and Nano Banana today, and they can make images. But this is such a common use case that we'll probably have some native image generation where you just use your credits to do it and you don't have to have an account.

I'd love eventually to have something a bit more open here. We've got 10,000 people who have emailed me about x402, and it just hasn't been a priority yet. So, I'd like this to happen.

One of the things I want to note is that we intentionally have this credit system. The reason that we have credits, rather than some fixed number of tokens or something that you can use, is that we would like to be able to spend them on many different types of things.

So, when you spend tokens, fine, that costs you credits. But, yeah, if you generate an image, that costs you credits, too. When you search a web page, that costs you credits. When you make a song, that costs you credits. So it gives us this nice intermediate currency that we can use to spend on a variety of things.

Okay, 3 more. I'll keep it super quick. What is the ratio right now of your token spend for the purpose of Tasklet development to your payroll? Leaving aside what users are costing you in terms of API calls, what are you spending via APIs versus on humans?

Let me do some quick math here. We have at least 3 products where we do a lot of internal token spend: Flow, Codex, and then Tasklet, actually. We spend a lot of money on tokens through Tasklet for our internal processes. I would guess we're at about 5% to 10% of payroll right now in terms of internal token spend.

How excited are you for Mythos? And how big of a difference do you think it's going to make for what you can do and what the trajectory of the business will be?

It's hard—I haven't tried it, right? No one—not no one, but most people—has tried it. So it is hard to get too excited about a thing you can't touch. It feels a little bit to me like a marketing stunt, where they're like, “Hey, we don't have the compute to actually serve this thing, so let's get some benefit out of it for marketing, even if we can't.”

It obviously sounds amazing. The benchmarks look really cool. It claims it can find all these zero-days and stuff. So I'd love to play with it, but I'd be more impressed if I could.

All right, last question. I'm sure you have taken interest in the recent CCP-forced unwinding of Meta's acquisition of Manus. And a fun fact about me: I was in the same dorm as Mark Zuckerberg and the other Facebook founders way back when. Not to date myself as we wrap up this podcast, but our 20-year reunion is coming up. I don't know—he famously didn't graduate. I think he's probably still invited if he wants to come. If I run into him, how many billion dollars should I tell him is the going price tag for Tasklet?

I think we've obviously been watching this pretty closely. I actually got a note from Nat shortly before the Manus deal got announced, and we were supposed to get coffee, but he never followed up, and it never happened. The unwinding—I'm very curious how that's even going to happen. I don't even know what it means to unwind something after they've already been working there for a while. That'll be wild.

But I sent him another follow-up in case he wants to get coffee. He has not responded to me. So I don't know if they want to chat, but it's not hard to find my email address. I'd be happy to talk.

I'll see if I can plant a seed for you at the reunion. Andrew, CEO of Tasklet, this has been amazing. Thank you for being part of The Cognitive Revolution.

Thanks for having me again.