Always Bet on the Models: How Tasklet Puts the Agency in Agents, with CEO Andrew Lee

Hello, and welcome back to The Cognitive Revolution.

Today, I'm excited to welcome Andrew Lee back for his 3rd appearance on the podcast.

Our last 2 episodes together were about Andrew's AI email assistant product, Shortwave.

And while Shortwave does remain one of the few AI apps that I use daily on both laptop and phone, the occasion for this conversation is the launch of Tasklit, a new AI agent platform that combines the natural language interaction and open-ended nature of chatbot assistants with the goal orientation and tangible output of automation software, and which has Andrew and team even more excited.

In practical user experience terms, Tasklet invites you to describe a task or responsibility to automate and then figures out for itself how to do it. As its boss, you can then review its output or its full step-by-step process and offer feedback to guide its improvement going forward.

I'm honored and grateful to say that Andrew will be sponsoring The Cognitive Revolution to help support Tasklet's launch. And while we will always be transparent about any financial relationship with guests, whether that's sponsorship, investment, or otherwise, I can sincerely say that we are making no compromises on content quality. In fact, Andrew's belief that speed is the only moat for AI startups and his resulting willingness to share everything he's learned with remarkable transparency and technical depth have made him a consistent favorite guest among AI engineers. What's more, having tested Tasklet myself for a full month before launch, I can honestly say that it's much more like the agent experience that I had expected OpenAI to launch at their Dev Day than what they actually did launch. And because it delivers frontier capabilities in a radically accessible form factor, I recommend it both to people who are just getting started with AI automation and also to experienced AI engineers who want to experiment with new concepts and are open to the AI's own ideas for for how to get the job done. In this conversation, we explore every angle of how Andrew and team are building Tasklet. We discuss Andrew's plan to always bet on the models and why he believes that open-ended agentic systems will ultimately prove more reliable than traditional step-by-step automation software. Tasklet's 2-tier architecture, which uses high-level agents to maintain instructions and spawn sub-agents for individual runs, and how this enables both recurring automation and ad hoc assistance. Real-world use cases ranging from email triage and marketing automation to commodity trading and venue management. How Tasklet manages context across long-running agent relationships, including sophisticated approaches to memory, context compaction, and the use of SQL databases to store agent state. Their tool integration strategy, which combines more than 3,000 prebuilt integrations with the model's own native ability to figure out how to use MCPs and previously unseen APIs. Plus computer use as the final fallback. Fascinating technical details on prompt engineering, including why they're moving away from pre-generated instructions and toward just-in-time instructions to avoid conflicting directives. Why Andrew still runs Tasklet on vibes rather than evals for model selection, and why he's confident that Anthropic's models remain the best choice for multi-turn agent interactions. And finally, his perspective on AI's overall trajectory. Which I'd say represents the mainline view among both Frontier Lab employees and the most connected app builders. Namely, that progress has not faltered and is absolutely expected to continue for some time to come. To me, while the capabilities frontier remains jagged and today's models can of course only handle a couple hours of work at a time, Tasklet does feel like a preview of the virtual employee future. When you can maintain an ongoing relationship with an agent, Give it high-level feedback on its work and watch it incorporate that feedback into future runs, you start to experience something genuinely new. And Andrew's report that some users are already giving their Tasklet agents their own dedicated email addresses, and in some cases even names, suggests that this paradigm shift is indeed already beginning. If you're intrigued, and certainly if you listen to this episode, I think you will be, Andrew invites you to try Tasklet for free at tasklit.ai. And then when it's time to upgrade, use code COGREV to get 50% off of any paid plan. With that, I hope you enjoy this deep dive into the strategic thinking, product management, and technical implementation of a frontier AI agent platform with Andrew Lee, founder and CEO of Tasklit.

Andrew Lee, founder and CEO of Shortwave, and now also founder and CEO of Tasklit. Welcome back to the Cognitive Revolution.

Thank you for having me.

I'm excited for this conversation. This is the 3rd time we've done this, and I've learned a ton each of the last 2 times. I'm sure that's going to be the case again today. The occasion is there is a new product out from you guys. It's called Tasklet. I've had the chance to play with it for the last month or so as you've been developing it and refining it. And I think it is a pretty cool paradigm that kind of blurs the lines between what many people are familiar with in the form of a chatbot on the one hand, and then also in the form of kind of a structured workflow or agent on the other hand. This is something that kind of sits in the middle and can kind of play both roles. And I have found it pretty cool to play around with. So excited to dig into every aspect of it with you. But maybe for starters, Tell us, um, about Tasklet at a high level. Like, how did you decide to build another product and, and how did you, um, hone in on this vision?

Yeah, so this is our, our second product after Shortwave. And basically what happened was earlier this year, we got really good at hooking our AI in Shortwave up to other products. So we added MCP and people were doing like these interesting workflows where they were like taking data from their email and they were sticking it in their Notion or in their Asana and updating their HubSpot automatically. And, and people really, really like this and it worked really well. And they said, hey, wouldn't it be nice if you just did this automatically before I got up every morning so I didn't have to sit on my computer and like run this prompt every day to like update my, my data? And we said, yeah, that'd be cool. Let's, let's build that. So we started making that and we very quickly realized that, hey, if this thing is running when you're not at your computer, having a tight UI integration between your AI agent, uh, and your email Doesn't make any sense because you're not even in front of your computer when this is happening. And so what if we took advantage of that and built something just much more general purpose that was great for doing, you know, email sync with other platforms, but also just like general automation. Um, and so we took a bigger swing and said, hey, we're going to try to build something that is designed to be your general purpose AI agent automation tool. Um, and we spent, you know, starting basically end of May, early June, all the way up until last week, building, testing, iterating, and we finally launched it. So it's live. Check it out. Tasklit.ai.

Yeah, it's cool. I think that the thing that I have really enjoyed about it is because I interact with people from all walks of life who are interested in AI fairly often. They're like, How could I set something up that would do whatever for me? And the friction to do that kind of stuff has been fairly high, right? Even with AI as something that can sit in a node in a traditional automation software platform, there's still a lot for people to figure out if they're not the kind of people that are used to getting really structured in their own minds about how to break a task down into its steps and how to set all that up in traditional software. And so I have found myself going to Tasklet as like the first place and being like, okay, start here. Just start by saying what you want and then kind of iterate on the thing from there. It's a really interesting split where you have kind of the mainline agent itself is like an entity that you can chat with, and on that level it feels more like a chatbot, but then it also like follows your instructions and You can set it up to run every day or on various triggers, and you can tell us more about the particulars of that. But then you also have this second tier, which is all the runs that the agent has done of this particular task. And I think that one-two punch, both of which are just very sort of general purpose, very natural language driven, not really requiring any of the nitty-gritty setup that people have become used to in some ways, but also have, like, probably been deterred by in many situations, is a pretty interesting new way to look at what an AI agent could be. Tell us more about that.

Yeah, traditionally, the way people do these sorts of automations is they use a workflow product, something like Zapier or n8n, or like the Agent Kit product that OpenAI put out is, I would call, a workflow product. And I, I look at workflow products and say, this is— this was the right way to approach this from a traditional software engineering standpoint, like a year or two ago when models were smart but not that smart. And I think we've learned over the last few years that you should always bet on the model. The models are always going to get smarter, um, and the right thing to do is to find ways to give those models more agency over time. And I think the reason people have been shy about doing workflow automation, like fully agentic all the way down, is because they didn't really trust it to be reliable. They didn't feel like the models were there yet. But I think now's the time. I think we've gone through that transition from, you know, you have a workflow that defines step 1, step 2, step 3, step 4. Maybe there's some LLM calls inside it to what if you just let the agent plan, the whole thing. The advantages you get out of this are tremendous because let's say you run into an error state. In a workflow product, if you don't have a way to handle the error state, it just breaks. In an agent product, it just figures it out and works around it. It can handle nuance much better. Also, as you mentioned, it's just a whole lot easier to set up. We've been trying to say, hey, we're going to bet on the models. Some of our workflow competitors have Kind of done a hybrid solution where they say we're gonna have an agent for the purpose of creating the workflow. So like if you, if you use string, this is the approach with string, but the output of that is still a workflow. And so it's fairly constrained at what it can do. And, and we're saying, hey, not only are we gonna have the, the setup portion be an agent, but the actual implementation's gonna be an agent as well.

Yeah, it's funny cuz that has kind of been the assumption on my part of what I expected things to trend toward. And yet I do find myself quite liking the form factor that you've created. I guess to dig into a little bit more, like, trusting the models and what you mean by that, I have this one slide that I use all the time in presentations that's just sort of the minimalist diagram of an agent. Like, what is the sort of most abstract form, right? Everything, all the detail kind of stripped away, and it's basically just a box around an LLM and some tools, and that's like your core agent. This thing is then given a task. The LLM can reason a little bit, can use the tools. When it uses tools, something happens in the environment, it gets feedback, and it just keeps kind of iterating on that basis, right? This is the classic, like, LLM in a loop is basically your minimalist agent. So when you talk about betting on models, the most extreme version of that would be like, just throw that very minimal scaffold up and let the models have at it. You've done a lot more than that, I'm sure, and I can see some of the fruits of that labour. But how do you think about what adds the most value beyond that super minimal agent scaffold that's kind of a cartoon diagram?

Yeah, what I mean, bet on the models. What I really mean here is what is the, you know, what is really in control of what's going to be happening, right? So one approach is to have a workflow where the thing that is in control is traditional software, and you as the user define the steps and it goes through some sort of flowchart. And maybe within those boxes there are some LLM calls, but, but the overarching control is done by traditional software. Versus if you put the model in charge, the model's in charge, the model makes the big decisions, and then Within what's happening with the model, you might have traditional software writing to, like, execute the tools. Um, and so it kind of inverts the problem. Rather than having software wrapping LLMs, you have LLMs wrapping software. So that's when I say, you know, we're betting on the model. That's what I mean. Um, either way you do it, there's still a lot of traditional software that has to be built. And I, I'd say the, you know, the core of what the agent is, I think I totally agree with you. It's basically just calling an LLM in a loop. Um, where you, you know, have the LLM spit out some tool calls, it resolves the tool calls, you call the LLM again, and it kind of reasons through things. But yeah, there's a lot that gets built around that. I'd say there's kind of 3 categories of things that we, like, big categories of things that we bring to the table. The first is connections. So we hook up to, uh, not like some pre-enumerated set of tools, but we hook up to everything on the internet. Like any service you wanna connect to, we can connect to. And all of the work of figuring out how do we connect to Gmail or Notion or your random enterprise API, or, you know, a computer that can access LinkedIn or some MCP server, all of that work is our own code. Um, and there's a lot of work trying to, to take all of these heterogeneous ways of talking to the internet and putting them into something that is like consistent and the LLM can reason about and use well. So that's category 1. Um, category 2 is triggers. So the, you know, all the stuff that makes the LLM get sort of run automatically and have those runs be, you know, encapsulated in these subagents that have sort of limited permissions, uh, where you have some control over them, um, is, is a big, big area of work. And then category 3 is, it's a very nascent part of our product, but it's all of the sort of team collaboration and sharing features. So, um, we're really targeting business operations use cases where, uh, you know, it's not just you automating your personal stuff, it's like you're automating some core business process. And we have to see that is very much a team sport. And so there's a few features in there now, like we have the ability to share an agent, but we're going to be doing a lot of stuff to provide sort of like oversight and management and auditing and cost controls of things at an organisational level.

But I will say, prior to playing around with TaskLit, I had the working assumption that while somewhat costly in terms of time and cognitive overhead to get set up, would bring me to a place of higher reliability. So I sort of assumed that there was an inherent trade-off between accessibility and reliability. But you're making an interesting point that when the AI itself has more room to kind of choose its own adventure, that's my term for these less structured agents, or choose your own adventure agents, that they do have, in a way, also the opportunity at least to have a higher level of robustness to unexpected stuff because they can route around obstacles that they find at runtime that weren't anticipated by the person who otherwise would have been building out these sort of block-by-block control flows. How do you think about that trade-off? And do you think that it is in fact more reliable on net, or is it a different kind of reliability?

Yeah.

What are the upper limits of this? Like, could you put something like this in production, uh, you know, you know, as part of a, a production app? Uh, how far do you think this goes?

Yeah, I, I totally agree with your point about, uh, the, the upper bound of reliability is not what you get from workflow products today because the real world is messy and things break and those tools break all the time and agents could potentially solve many of those cases. So I do think you need to look at this holistically. I think today, with the models you have today, you're probably going to have, in most business applications, a somewhat less reliable solution with today's models. But as I said, always bet on the models. I give you 6 months before that's no longer the case. And I think we've been able to look back over the last few years and see that these predictions really, really do come true. So we're looking ahead and saying today, for many applications, it is you know, reliable enough, and there's a lot of other advantages, and in the future it'll probably be more reliable. The other thing I want to note is there is a lot that the models can do to provide reliability and sort of guardrails around their processes. So, for example, today we use the LLMs to try to figure out types. So we dynamically create some of our connections, and we use the LLMs to try to figure out, like, hey, what are the type restrictions that should be on this? And then we enforce those in code. And so if, for example, what you want is you really want the LLM to follow a flowchart for some portion of the project, right? We could build the ability for you to tell the LLM, hey, you know, during this phase, you must do these steps in order. And the LLM could actually create its own guardrails and enforce that through code if it wanted to. So I don't— I think if the model is wrapping the code, the model can then construct constraints in those codes to— in that code to enforce the you know, the reliability goals that you want. Haven't built it yet, but I think we can. So, I think the future is not gonna be, you know, forever, here's the quick, easy, unreliable way, and then here's the harder, more reliable way. I think it really is gonna be better in basically all scenarios in the not too distant future.

Yeah, maybe it could be Sonnet 4.5 new, or maybe we have to wait till Sonnet 4.7, but it seems like these things are Coming at us pretty fast. Hey, we'll continue our interview in a moment after a word from our sponsors. This is something we talked about last time, and your response was quite interesting. Basically, as I recall, it was like very vibes-based. How do you eval things these days? Is—

have you—

I mean, this debate has continued to rage, as I'm sure you're well aware, since the last conversation. Uh, have you updated your position? Are we still, still running on ViDE?

Still running on ViDE. Yeah, I think what, what we've figured out is in the current, you know, market situation, the Anthropic models are the best at what we do. And there's, there's really no question there. And if you're looking at evals from the standpoint of we're trying to decide whether to roll forward to the new model, we kind of have no choice, right? We can't really switch off Anthropic right now because there's no viable alternative. And when a new Anthropic model comes out, the pressure from our customers to release that thing as soon as possible is quite tremendous. Everybody wants it right now. And so, you know, if we had some evals and the evals, you know, weren't working out the way we wanted, we're probably still going to roll out that new model, right? We might tweak some prompts and stuff to try to make it work better, but we're probably going to still roll out that new model. So we've just sort of accepted that, like, we're going to be on that Anthropic for a while, and we're always going to roll out the new model as quickly as it comes out. And so we need some approach that works in that environment. The other, the other thing to consider is our product is changing so fast that anything that we put in that could constrain our ability to move quickly is gonna come with real business costs. So, you know, the, this entire product is only, we only started writing code in June. It's evolved tremendously over that time. It's gonna continue evolving tremendously, and our users are very clear that the thing they want above all else, and I, I mean this above, you know, above reliability and security and, you know, all the normal things you want, is they want the smartest, most capable thing. And they've been, you know, I've had lots of calls with people where, you know, we're, they're asking about SOC 2 and we're like, yeah, we don't have SOC 2 for this yet. Right. And, you know, if you had to choose between SOC 2 or it being a little smarter, basically it's always like, well, don't tell, it complies, but I want it to be a little smarter. So that's really where our focus is, is like, Moving quickly, being smart, and evals is, is not beyond our own dogfooding. It's not part of that right now. So we do do a lot of testing, don't get me wrong, but it's all like, we have a whole bunch of triggers that run for our own internal usage, and we basically roll stuff out to our internal team first. We give it some time, see how it goes, and then if it feels good, we roll it out wider. And in shortwave, we do basically experiments-based rollouts. So we allow—

Hmm.

power users to opt into things. We look at retention rates in the new features and roll them out. We're going to do something similar in TaskLit where we'll roll out a new version, we'll let power users opt into it, we'll see what retention looks like, and then we'll flip it on for everybody.

I guess just to ground this out a little bit, you said it, like, Anthropic models are clearly the best for what you do. How do you test that? I mean, are you literally just doing like Andrew's top 10? agent use cases and running them head to head with GPT-5?

Yeah, it's, I mean, it's vibes, right? So we've built our system so it's easy to swap in different models to test, and we try the different use cases. And I think what you find is all of the models do a pretty good job at answering the initial question you have. In fact, some of the models may do a better job. If your goal is to like have one question, one answer, you know, you might find that OpenAI models do better. But if you wanna have something that is LLM call, tool call, LLM call, tool call, LLM over a long sequence, which like all the stuff you wanna do with our product is, is that type of thing. Um, Anthropic just sort of handles that iteration better. And, and that over, you know, 100 iterations, that really adds up if it's slightly better at each turn. So, um, we've, yeah, it's all been sort of hand testing of different models, but ultimately for that sort of long iterative process, this, this is, It's clearly the best. And I think the market agrees with us. If you look at, you know, all the other folks that are doing stuff like us, they're all heavily using Anthropic models.

What would you add? Of course, everybody who listens to this feed is very familiar with the Meter task length graph at this point. And we were all waiting for Sonnet 4.5 to, you know, be planted on that graph. It did come in a little lower than GPT-5, right on trend with the curve, but a bit lower in the metre estimation than GPT-5. How would you account for that difference if you could? Or do you— and I guess the other way to think about that is they put us like just over 2 hours now in terms of the size of task as measured in the time it takes a human to do it. that the models can now handle, like, 50% of the time. Do you accept that analysis? Would you complicate that analysis? Is there some part of that? Is there some reason that you are coming out with a very different conclusion than what they are measuring? Because I think right now the prevailing notion would be GPT-5 is a bit ahead.

Yeah, I don't know why that difference is there. My Cynical take is, you know, some people are playing harder to hack the metrics than others, but I don't actually know what the reason is. But I, you know, I look at our actual sort of practical real-world testing and my experience has been it's better. And the data point I would point to that says, hey, you know, there is something real here, I'm not just making this up, is pricing. Right? So if GPT-5 was as good at these use cases as Sonnet is, um, it wouldn't be less than half the price. Um, and at less than half the price, you'd think everyone would be switching off and they're not. And when they, you know, when Anthropic came out with 4.5, they didn't lower the cost, the price, even though OpenAI had lowered the price. So the fact that the pricing is holding up tells me that people are choosing it. And I think it's just because the, you know, ignore, ignore what the metrics say. The, the real-world utility of it is just better.

How do you think about the size of tasks? When I have looked into runs of things that I've done, I've routinely seen like dozens of steps, which, you know, are for whatever reason that the tasks I tend to come up with are like, help me with AI research. Not, not for whatever, I know why that is. Uh, it's becoming overwhelming and I need all the help I can get. So it's a lot of stuff that's like search reason, search reason, search reason, search reason a bunch of times, and then finally compile a report for me, send that off, update memory. And that's basically the anatomy of most runs of the tasks, of the recurring tasks, the agents that I've created so far. How does that compare to the frontier? Is dozens of tasks kind of toward the upper limit? Are you seeing things that are substantially more than that? Do you think about them in terms of time it would take a human to do them or some other metric? Like, how do you even conceive of how to measure the size of what the agents can do?

Yeah, to be honest, we don't make any effort to try to estimate the time it would take a human to do this. We're a little team. We're just trying to build a thing that people will pay for. Um, uh, I'll leave to the researchers to try to figure out how that relates to, to human time. Um, we look at things in terms of, of turns because that fact that, you know, correlates with our cost. And, uh, we absolutely do see people with tasks that are spanning a very large number of turns. And we actually— this is something we need to change. There's a, there's a 50-turn limit per question basically in our product. And that initially was just set to like keep a bug from costing us infinite money.

Mm-hmm.

And we're hitting this all the time now, and we need to bump that. And I think the number one place we're hitting this is computer use, where, you know, if your task is like, hey, you know, go to LinkedIn, find these 10 people and send them all a message, you know, every operation there is going to be a turn, uh, and sometimes multiple turns. And, uh, so I think computer use is a place case where just like the number of turns just absolutely explodes.

Yeah, that's funny. I have been doing that, uh, a bit as well, getting Specifically, there's an event coming up in Detroit where I was invited to either give just a solo presentation or maybe do like a live podcast recording in front of a live audience. And then the question was like, well, who's the guest? And so I'm specifically having Tasklet go comb through AI leaders at various organisations in Detroit and pull back lists to me for people that I should consider inviting. Which brings me to a great question. It seems like in the metrics, Claude 4.5 Sonnet was a big step up in computer use. How did that feel to you in your vibes-based assessment?

It seems really good. I'd say the big blocker for more computer use for us right now really is just cost and speed. It is Tremendously expensive to move a computer around by screenshotting. And so, uh, yeah, I'd say when computer use fails for our users, it has less to do with like the intelligence of the model and more to do with either they hit that 50-turn limit or like they just can't afford to do it anymore. But yeah, I found it super impressive. We've looked at using other models for specifically for computer use for cost. So like we were looking at using Gemini and having like a sub-agent to handle portions of that. But the, the downside of having a sub-agent run and then sort of capturing some, you know, distilled version of, of the data and putting it onto the main agent is you just get less intelligence overall. And so we've, we've played with that a bit, but, uh, so far the strategy is just spend a lot of money on, uh, Sonnet. We're gonna, we, we just, we just, uh, rolled out Haiku. And so, um, we've been doing a little bit of testing there. I think it's too early to say how, how well Haiku's gonna do with computer use, but. that could be a big factor for cost for us. But generally super impressed with the capabilities for computer use.

How do you think about what kind of computers to give to the AI? It seems like we have, on the one hand, there's sort of just a browser is like one paradigm. And then on the Grok 4 launch, I always think back to Elon talking about setting up like, you know, power workstations with all the same you know, high-end software that the engineers at Tesla and SpaceX use. And it seems like you're somewhere in the middle right now where it is not just a browser, right? You have like a full operating system, um, you know, VM type of thing that the, that the AI can use. How do you decide like how much of a computer to give it and, and how much can it do beyond the browser today?

Yeah, this is probably the most active source of discussion for our team right now. We have actually have everyone on the team flying out next week and this is gonna be a big focus of that discussion is what direction do we want to take this? Right now in the product, every agent has its own SQL database. It has its own code execution environment, and it has some very limited file capabilities. You can optionally spin up a full Linux VM and connect to that Linux VM and use a browser, use a file system in that VM. We used to have Windows support. That caused some problems for us. It was expensive. The, you know, the wake up from sleep time was like really bad. There was, there were some reasons it was harder and there was also no one, it was pretty rare for people to use the benefits of Windows besides stuff in the browser. So we, we switched to Linux, which I think has been working much better for folks. We've considered doing Mac for the, for the, for the usage. Going forward, I see a couple of big goals. One is we want to give it terminal access. So there's a lot of operations that, like, if you use Cloud Code, right, it's shocking how much Cloud Code can do outside of programming since it has the ability to access the console. So for example, like, we have a weird number of people opening up agents and then being like, you know, hey, I upload this file, like, please convert it from, you know, this video format to this video format. Um, and we're like, you know, I don't know why you're asking AI to do this, but we totally could, right? We could run FFmpeg and like, you know, do that sort of processing. So I think we want to give agents, uh, you know, a shell and let them run command line things. I think we want to give them a file system. Um, and I think we want all of those pieces of the computer to work well together, right? So for example, today you can run, we can write and execute code. But that code can't access your database. That code can't access your connections. It can output data and then the LM. But, you know, what if you had all those facets of the computer, the file system, the database, the code execution environment, the shell, and the UI, all able to talk to each other? I think that could be tremendously powerful. Doing that well is really hard for a variety of reasons. cost is a big factor, right? You don't actually want to have, you know, you could have 100 agents in our product. You don't actually want to have like a physical, 100 physical machines per user. The thing will be prohibitively expensive. Um, this is an area actually where there's a lot of startup activity. So, um, there's a lot of people that figured out that you need specialized cloud infrastructure for doing this. I was just talking to a startup this morning called BlackSell. That seems pretty cool. Um, But, uh, yeah, a lot of discussion here, a lot of excitement. I think big things are coming. Um, watch this space.

What, what do you think of the requirements there? Like, it just seems that the main one would be like, you sort of want to be able to suspend the VM and kind of put it into sleep mode, but like keep its state kind of like my Mac when it runs outta battery or whatever, it comes up in roughly the same, usually in roughly the same state that I left it.

Yeah.

Is that the, um, The big thing, or what else is kind of missing from the tools you have available right now?

Yeah, I think cost is the— is probably the number one issue where, yeah, you want to have the illusion of every agent having its own computer, and you want that computer when you're using it to be powerful, but you don't want to pay for any of the milliseconds you're not using it. And that includes not just compute but also storage, and that can get complicated, right? You don't want to, you know, have every agent have to just have a store— store a copy of the entire OS. For example. Um, so how do you get the illusion of every agent having its own computer without having to pay the costs of every agent literally having its own computer? I think that's one big factor. I think another big factor is, um, you want to make sure that those computers don't kind of get messed up over time. So you want to give some thought to, you know, what aspects of this thing are configurable and which aspects of this thing are not configurable. You wouldn't, you wouldn't want the agent to like, you know, mess up some config and then forever after that be unable to like use its computer. Um, so that's something we're thinking about it too, is like, you know, reliability, uh, for this thing. Um, and besides that, I don't know, man, like the, the requirements here I think are super unclear. This is a very uncharted territory. So we're, we're figuring this out one day at a time.

Hey, we'll continue our interview in a moment after a word from our sponsors. Let's talk about use cases for a minute, because I go very deep into all the technical stuff. What use cases are you seeing maybe that are like on the frontier of what the models can or can't do, or that are just like really creative, things that you think people should be taking inspiration from? One thing that I have honestly had a bit of a challenge with in using any AI product that's meant to do recurring tasks for me is, and I don't take this for granted, I think it's like a sign of great privilege in many respects. I don't really have that many recurring tasks. I mostly am like chasing my curiosity on a day-to-day basis. And so a lot of times I feel like I'm like, okay, well, what should I be recurring that I'm not? Because I'm too lazy and maybe an AI could take me there. So yeah, I mean, take all the time you want on use case. I need inspiration.

So, so here's an interesting thing that we, that we figured out earlier on. So the pitch that we give you is that we help you with recurring tasks, and we do. Um, but the first, the first version of Tasklit, it was set up so that there was sort of a, a Tasklit setup phase. And then once you got the automation running, it just like switched into running mode and you couldn't, couldn't talk to the main agents. You were like either designing the automation or running the automation, but you weren't doing both at the same time. And what we discovered is that people had, like, for example, they configured like an email triage agent and they'd hooked it up to their Notion and their Asana, and they give it all these detailed instructions around like what types of emails they care about and stuff like that. And they're like, hey, I, I did all this work to create this agent. It's often writing its automation, but now I just want it to write this email for me. Um, why can't I talk to it more? And we said, oh, well, you should go make a new agent for that. And it's like, well, I don't know. I think then I have to configure it again. I have to hook it up to all the same stuff. I have to get all the same prompts. Like, I just wanna talk to this agent. And so we realized that, hey, well, What we need to do is we need to enable on any one of these individual agents both the trigger tasks, but also the ability for you to keep chatting with them. And so that's why the agent works that way today. Like, while it is off, you know, waiting for emails to come in or webhooks to fire or whatever, you can keep talking to those agents. And once we enable that, what we found is like people started naming these things. And like, it was, you know, this isn't, you know, my agent for creating my email. This is like Joe, my EA. And Joe does these automated tasks, but Joe also helps me when I ask Joe to do things. Um, and so I think the way that we've been thinking about this more is as a tool for like very heavyweight, very long-lived agents. Like you go into ChatGPT or Claude and it's like you have a quick question, you, you talk to it for a little bit and then you forget about that and you never come back to it. And you have this long list of, of tasks you'd never, you know, come back to. And in our product, we're trying to have something where it's like, A lot more setup, but a lot more value in the long term. And maybe you keep coming back to this particular agent for years. And what that has resulted in is actually the vast majority of usage of our product is not the automated tasks. There's a lot of that. And, and, and basically all of our paid users have something that is automated and recurring, but they are like, most of the messages that they send is actually the other messages that they ask, you know, to the same agents that are doing these recurring tasks. Um, we've seen all kinds of stuff. So, you know, as an example, like, we've had some companies that have automated their billing processes. Um, we've had companies that had EAs doing various EA-type work who have decided to, to go fully with Tasklet to, like, automate those tasks. Um, we have had, like, music venues that sort of manage their calendar. Through this or like, you know, keep all the various stakeholders aware of what's going on at their venue. Um, we had— there was a commodity trading— commodities trading firm I was talking to the other day that like sort of watches for events in the real world and like makes recommendations for trades to make. Um, personally, I use it for marketing super heavily. So, uh, basically all the content that you see from Shortwave or Tasklet these days is written through Tasklet. Um, and, you know, actually you, you saw part of this, uh, for the, you know, the sponsored spot that we're doing with you guys where I basically have a bunch of docs that have my notes. And I have an agent whose job it is specifically to do marketing for me. And I'm, anytime I need new content, I'm like, hey, here's, here's the doc I have for this. Here's the spreadsheet I have for this. This is this thing. And then, okay, now I need a LinkedIn post or now I need A podcast sponsorship, like spit that out for me. So it is everything under the sun. Pretty much every page has something that's automated, but they also do a lot of other stuff too.

Yeah, that's interesting. I've been gravitating that way as well in terms of just the one-offs, like the LinkedIn thing I said, that was just a one-off. And well, preparing for this, I also was like, You know, just getting Tasklet to help me, you know, identify any gaps in my outline of questions for you. It did actually come up with a couple interesting questions that would only come from Tasklet given the sort of unique insight that it has into itself.

Yeah, I love that you did that. That was pretty funny.

I guess on the— I mean, there's a lot of little nitty-gritty things that I found really interesting. And I do really like how you can go back and continue the conversation with the agent at the high level.

Right.

Again, there's this sort of two-tiered thing, and people should just go play with it because I think it's in some ways more intuitive to just go do than it is for me to try to describe. But the high-level agent that sort of defines what is this thing all about and maintains the prompt that will then be used for the individual runs, That's the sort of higher order thing that you can talk to. One bit of feedback, for example, that I gave to my arXiv paper searching agent the other day was, I guess, first of all, in the prompt that I originally gave it, usually in the past I have felt that I had to give anything like that a lot of context on me. But this time I just said, my interests are pretty well represented on the Cognitive Revolution website. So Go check that out, and then you can kind of search archive with that in mind. So it was cool because at that higher level, it went and did that search to try to characterise me and understand what I'm about, and then turned that into the prompt, which then gets fed into each individual run. And so it doesn't have to do that every single time. Maybe I should come back at some point in the future and say, hey, you should refresh. I've done a bunch more episodes or whatever. In practice, what I did do is I was noticing as I went into the runs and just traced through to see what they were doing, one thing I noticed it wasn't doing all the time was accessing the memory that it had logged. So I was seeing at the end of the runs, it would log, like, sent Nathan these 5 papers or whatever, and they'd be put into the store. But then if it wasn't accessing that store at the beginning of the following day's run, then what good was that? Right? So I just went back to the high-level agent and said, Hey, I've noticed you haven't been accessing memory at the beginning of the runs, and that is leading to some duplication in the papers that I'm getting from day to day. So please access the memory at the beginning of the run going forward, and it just updates its prompt. And then for all subsequent runs, that is now part of its standard operating procedure.

So I think that is pretty cool.

It is starting to feel much more like a virtual employee. You know, I mean, that's obviously a sort of fuzzy notion, but something that a lot of people kind of have on the horizon in their imaginations. And you can, you know, you can kind of feel that a little bit more where you're like, I've reviewed some of your work and I want to give you, I want you to like keep the same assignments that you have, but I want to give you high-level feedback on what I'm seeing in your output and then have you kind of figure out how to incorporate that into your future work without me having to get into the super nitty-gritty details of it. I think that is pretty cool. Okay, some nitty-gritty stuff. How do you manage the— I guess even more nitty-gritty first. I don't think I can talk to a run these days, and that is something that I thought I might also like to do. I might want to give high-level feedback like I just described of like, I've noticed sometimes you're not doing this in quite the way I think best, but sometimes I might also want to go down to the individual run and just say like, hey, can you do one more step? Or can you turn this into a whatever on a one-off basis? Is there any reason that doesn't exist? Or maybe just coming soon? Yeah, they haven't got to it yet.

So it's worth walking through some of the stuff that we've tried and also talking about kind of where we're going here, because I think this is This is an area that we've learned a lot, and the way it works today is actually not how I'd like it to work in the long term. So we actually used to give you an easier way to chat with these, the subagent runs. You actually, there are situations where you can, we have the ability for the subagent to ask for human input, in which case like a chat box will appear and you can talk to it. We found that that is not very frequently used and a little confusing, and the idea that you come to the product and there's like One chat box over, uh, one chat box over here, and then every sub-agent run also has this chat box. It starts to get confusing for users of like, there's 20 places I can talk to the AI, which, which place do I wanna talk to the AI? Um, and so, um, we're moving to a world instead where we just want you to talk to the main agent. Um, and I think the piece that's missing right now is the— we're not giving the main agent enough information about the recent runs that have occurred. Um, And so you can't today go into the main agent and get into the nitty-gritty and, and get the, you know, subagents to continue running, but you could. So this is, this whole project we're calling like introspection, which is like, how do you, how do you have these subagents that run and have sort of the, the reliability and the cost benefits of being run as subagents, but then have the main agent appear to have full knowledge and control over them? Um, and that is a very, uh, that's an ongoing, that's an ongoing project. Um, I think one of the areas we're gonna look at is the way that instructions work. So you mentioned that, you know, you look at the instructions sometimes and then give the main agent instructions to, to change those instructions. We actually used to let you, so we have these intermediate instructions, right? And those intermediate instructions are generated by the main agent and then persisted. And we actually used to let you modify those manually. And the down— the big downside of that is it creates a tension between what you've told the main agent and what you've edited those instructions to be. So if you go and you tell the main agent a whole bunch of stuff, and then later on you go and edit the sub-agent instructions, um, even if you tell the main agent that you made those edits, it start— it's, it's pretty tricky for the main agent to reconcile. Well, you told me you wanted XYZ, but then later you added the instruction to this, and I'm not sure what you want later, 'cause the conversation continues.

And so, We removed—

and also wasn't being used very much. People weren't editing it. So we removed the ability to edit those. And I think in the future, we're actually probably going to stop pre-generating those instructions, um, because pre-generating those requires the agent to reason about when to update those and how to update those while doing other tasks. Like, you might have, you know, you might ask it to do something and make it decide while doing that where it has to go do the thing it's, you're, it's trying to help you with immediately, and then also going to update these instructions.

Mm-hmm.

Which is a long, slow, error-prone process. Um, so I think what we may move to is something where those sub-agent instructions are generated just in time, and they're generated sort of out of band and, uh, done in such a way that they always factor in all information. Um, and if you did want to see the instructions in a way that you could digest them, um, you just ask the AI. You, rather than having a special button to say, show me instructions, you just tell the AI like, give me a summary of the instructions that you've given me. Or sorry, give me a summary of the instructions that I've given you. And it could do that. And then you could say, if you really wanted to follow those exactly or modify them, you could say, well, actually, I'd like you to follow these modified instructions, and you could provide instructions. And so I think you can get the best of both worlds. I think you can get the ability to be very specific in your instructions and to see what it's thinking without sort of a UI that creates this ambiguity.

Yeah, that's a really interesting point. And the ambiguity, which I also think kind of blurs into an agent that has multiple conflicting goals, is becoming a real driver of strange results from AI systems in general. I mean, the GPT-5 prompt guide takes pains to warn people against having any sort of contradictory Instructions. That's apparently a huge drag on performance if there's any contradiction in the prompts. And also the things like alignment faking and a lot of these sort of bizarre behaviours stem from some sort of incompatibility between either what the agent has been trained on at a high level and what it's currently being asked to do, or even just like 2 you know, kind of instructions that it might be receiving at different levels of the, the instruction hierarchy. So that is, um, you're, I think you're right to flag that that can lead to some weird stuff.

Um, surprisingly, one colorfully. There's just one part of the code where I've asked the team to make me the reviewer before a PR goes in. I, you know, I am, I'm not the CTO here. I'm generally not the reviewer for things, but anything that touches the main prompts, I wanna see. And the main thing I'm looking for is, uh, conflicting instructions. Um, because if you have, you know, a bunch of people all kind of working on their part of the system and giving instructions that make sense, you, you need one person who's sort of looking at the prompt as a whole and being like, are we telling, are we, are we giving instructions to this thing that are clear where if it reads the whole prompt, it knows what's going on? And like that, that it's a problem a surprisingly amount of, uh, of time, even when people are trying to be very careful about it.

Yeah.

So how about this just general notion of context engineering, context management, context maybe like cleanup or compression, and then that obviously blur into memory too, although that is a bit distinct as things stand today. The question that was suggested by Tasklet for you says that there's a token budget, 200,000 tokens in my current context. Now, I know that there are some opportunities to get to longer context with the right customer relationship. I think you have to pay more per token if you want to opt into those things, but obviously it's going to be finite no matter what, right? So especially if I'm talking to this high-level agent and I've had a bunch of runs that are running on an ongoing basis, and I say, oh, can you pull up the run from October 1st? No. Now can you look into the run from October 5th or whatever, it seems like I'm going to be out of context real quick. So how do you manage when you talk about something that you could come back to for years? Is that still aspirational, or is there a way to get the agents to be that long-lived given the finite context that you have to work with?

Yeah, totally. I want to note, I really love the word context engineering. I've been, I've been looking for a word to describe this because I think the— there's, there's just kind of 2 parts of building an agent. Well, 3 parts. There's the core agent loop, but that's pretty simple. There's the model. And then there's all the work of plugging things into that model. And I think the terms that people have used in the past are, you know, not, not quite right for the way things actually work. So the, the term RAG, for example, I think has been used very badly. There's sort of a naive RAG that most people think of, but like doesn't really describe like the way tool calling and stuff works. So I, I really like the word context engineering. I think it gives like sufficient gravity and weight to like the sophistication of the systems that actually like are built around these agents to like plumb the right data in. Um, and, uh, we've done a lot of, a lot of work here. We're gonna continue to do a lot of work here. Um, and yeah, I agree with you. You somehow need, in, in our case, you might have an agent that's been running for a long time that's processed 100,000 emails. Obviously, you can't fit all of those into any sort of reasonable token budget. So you have to give the illusion to the user that not only have you fit those things in, but that the LLM is still able to reason intelligently with a huge context. And you do that by— there's a lot of methods here, right? So you can You can hide things, um, inside tool calls. And then you probably saw the, the stuff from Anthropic recently. Like, one of the things you could do is just like hide the results of those tool calls. Um, you can do LLM-based compaction. So you can say, you know, we're gonna rewrite, take, take some big section and we're gonna take a model and we're gonna summarize that some way. Um, you can do things in subagents. So like when our subagents run, we're not giving them the whole chat history, we're giving them some you know, tailored portion of, of that chat history. Um, so I see this as a major, a major focus for us is, you know, giving the, the user the illusion that everything they've ever said to this thing and every email that's ever been processed is being considered at all times without actually doing that. And I think that's a, it's a fun problem.

So I guess one more thing on just like context management. If I'm, if I'm looking at the subagents, I have this archive Uh, Paper Finder daily, right? And it, it puts at the end of a run, you know, it stores what it found and what it sent me. And then at the beginning of the run, now with my, uh, feedback, it is pulling that history out so it knows, you know, what it has already found and hopefully avoids, uh, duplication. Even that over time, right, is gonna start to get huge in, in the limit. Like there's a, you know, just a ton of stuff that it's already found. I guess I could, kind of help it out by saying like, you know, only search for stuff in the last 2 weeks. And then like you only have to pull stuff from for the last 2 weeks. But it seems like everything kind of blows up in the end. So I wonder how you are thinking about that. And I also noticed, I think I noticed that even in just the month that I was using the product before the launch, when I go back to the earliest runs, it looks like it's like a NoSQL store. And now the more recent one, it has a SQL backend. Previously it was like, you know, just sort of JSON docs that were being sent into the store. And now we actually have like insert statements and whatnot. So I guess, how do you think about the size of the store? Does that, I guess that becomes like a RAG, you know, with possible pardons for abusing the term, where you sort of have to apply some intelligence at that level as well? Or, you know, I could imagine you could also be using the old Gmail trick, which was like promise unlimited storage and just know that people don't have that many emails coming in yet. So you can kind of figure it out at some point in the future. And then there's also these like dedicated memory startups that I'm sure you've looked at, MemZero and SuperMemory. So I guess to try to sum that up into a question, If I'm storing more and more stuff, how do I not overflow the context just with that? What are you seeing working, not working? You know, what about these memory startups?

Yeah, this, this is very much a, a, a core part of the challenge. So I, we're not, we're not using any, any other providers 'cause we think this is something that we have to solve ourselves. And if our whole premise is we're like ChatGPT or Claude, but Like, much more heavyweight and designed for, like, long-running recurring work. Like, this is, this is a very core, uh, fundamental thing we need to do. Um, the North Star for us is the illusion that we're just one big long chat and everything has been put into that chat and that the model is perfectly smart. And, um, this is— the system breaks under sort of all of those, for all of those reasons, right? That, you know, we can't actually fit all of it in context. We can't afford to do it even if we could, and the model is not infinitely smart. So if you, you know, for example, you stored every email that you'd ever processed just in the history, the LLM isn't gonna do a good job of reasoning about which ones you've processed or which ones you haven't processed. It's just, it's just not gonna be that smart. And so one of the techniques that we've been using is having a data structure that is managed explicitly by the LLM across runs. The first iteration of this was a very simple version. Which was in the system prompt, we included a JSON blob, and that JSON blob could be directly edited by a tool call in the LLM. So in the subagent runs, you could just tell it like, hey, I wanna add this data, remove this data from this dataset object. And that actually worked surprisingly well. This was like the dumbest thing we could think of, and we built it and it just worked and it was really cool. Um, but it came with a couple of downsides. One is, it fairly quickly got large enough that like it started to break down and not be useful. So we had a lot of agents that were like working for a while, and then after a week or 2 or whatever, they kind of stopped working because that JSON object got really, really large. The other problem is it is terrible for caching to put mutable state into your system prompt.

Mm-hmm.

Um, and caching is very important for cost. Um, and so, uh, but the benefit of, of having it in the system prompt at all times is, you know, the, the LLM doesn't have to reason about how to retrieve it. It's just there, right? And so we looked at other ways to do this, and we settled on using just a SQL database because it turns out the models are just super good at writing and using SQL. Like, they're, they're way better than I am at this. And if you just tell it, look, you got a SQL database and you can store stuff in there and you can retrieve it, and then you can give yourself instructions on how to manage that thing, it works. It works really well. I agree, this is not the end of the story, right? So you totally can have instructions that say like, you know, every time you get an email, store the list, and then every time you start, load the whole list, and that list could get bigger and bigger and bigger and eventually cause you problems. And so, uh, we're not done. We're gonna have to keep working on this. Um, I think there's gonna be, in addition to being, you know, even smarter about how to manage that SQL data, there's gonna be lots of other tools that we use. So, you know, as an example, one of the things I'm looking at now is in a world where You've compacted old history, but that old history becomes relevant. Um, you could potentially give the agent tools for uncompacting portions of its history, right? Being like, okay, you know, in this particular case, I really need, do need to know what the, what the earlier messages were. And you could potentially like load those through tool calls. So there's a lot of tools. There's a lot of ideas that we're exploring here. I think this is very much an unsolved problem and, uh, we're working on it.

Any impulse to some sort of graph of knowledge? We did an episode on it. It's probably been at least a year, on a paper called HippoRAG, where it was a pretty kind of, I don't know, it was both cool, but also there were definitely still things to do to take that to a production system. There was a HippoRAG 2 at one point. But what I thought was cool about it was that it sort of dynamically, on a periodic basis, it was almost like what would happen when the agent is asleep, right, is you would go back and sweep through all of the new items that were stored to whatever memory store and try to find connections between them and kind of map the space out, create these connections that then in the future really improved the retrieval because you could do sort of a graph-based search. And if you hit one node and expand 2 hops out from that one node, then you get a pretty good set of all the surrounding information. And you can do that dynamically at runtime with that background processing to kind of continually build out the graph day after day. Anything along those lines in your mind, or what do you think are the sort of creative ideas that will So I, I suspect like something that something like that could work well.

Um, but I don't think it's the right business move for us to try to explore doing that. And the reason for that is the agent's internal state is only one of the many sources of data that the agent needs to, to do its job. Um, so, you know, you, uh, if you ask it to do a task, it might need to look through its own state, but it also might need to look through all of any systems that you're connected to. And the amount of data that's connected to those systems is way too big for us to like suck it all in and like put it into this system. So if we built a system that for internal state managed it super well, but for all the external state, we're sort of still relying on like whatever those services provide for their, you know, search and memory systems. Um, I don't think that, I don't think it'd be a huge improvement to the overall capabilities of our product. So we're sort of betting on— Again, betting on the model to say, you know, assume that the memory capabilities never get that great. Um, will the model get smart enough about using those things such that it can kind of, you know, figure it out and get really awesome? And I think that trend has been— I, I'm optimistic about this. And like, I would argue that companies that, you know, a couple years ago were like, hey, we're gonna, we're gonna ingest all the data from all these different systems and build this like awesome AI search product. Um, I suspect now they're looking at this and saying, crap, like if you just take an agent and have the agent reason about how to use legacy search tools, it does almost as well. And man, that is way simpler and way cheaper. Um, I, I think people are sort of realizing that now. So that's our bet is, uh, we shouldn't invest so much in the kind of smart memory systems now. We should invest in connecting to things and then bad on the model getting smart enough to use more traditional systems.

Yeah, that's interesting. Do you also rule out the Claude inbuilt memory? Because they now offer a little bit of memory management through the API itself, right? Is that also sort of, don't use it because it's got to be core to us?

We haven't played with their latest stuff. If memory serves, I don't think they're doing anything that we couldn't be doing ourselves. I think their context editing stuff is also stuff that you could totally to do yourself as well. So yeah, it's in the camp of don't use it because we can do it ourselves. Although I haven't played with it specifically.

Going back, I think, to our first conversation, there was a lot of custom models and sort of relatively deep down the stack optimizations that you were using for retrieval when you indexed MyFull and very gnarly Gmail history for shortwave. It sounds like that's not so much of part of the strategy now. But I also am remembering, I think it was Cognition in the last few days showed something where they are training their own relatively narrow agentic search model that is meant to do the same sort of thing that Sonnet can do in terms of doing retrieval against all these systems, But, you know, faster and cheaper, if nothing else, because they're, you know, able to specialise on a particular, you know, relatively narrowly scoped task, and therefore they can do it with a smaller model. Um, I'm guessing you're gonna say we're leaving it to Sonnet for now, and maybe one day we'll need to do that sort of optimisation. But, um, what do you think is the outlook there?

Roughly, I mean, I do think that A good AI search system with a great model is going to outperform a traditional search system with a great model. And I think that'll always be true. Um, and, you know, you can see this today, like, going to Tasklet and asking it to search your email is not going to give you as good of results as going to Shortwave and asking it to search your email because they're both using the same model and Shortwave has the benefit of, like, really good semantic search stack. Um, but if you look at the 2 businesses, like, Shortwave, it is a tremendously complex and expensive system that operates that search stack, right? So it is, it is a major factor of our cost, is a major factor of the effort that we have to put into developing and maintaining the product, like maintaining that search stack. In Tasklit, we hook up to thousands of services. It is not practical for us to like build search for all of those things. And even if we tried to say, okay, we'll do it for a, you know, a few of the most common ones, I don't think it scales in any reasonable way. So I think our, our only reasonable strategy with TaskLit is to say, well, we're gonna rely on their existing search stuff. And I'm optimistic of, of 2 things. One is that the models will keep getting better using those existing traditional search stacks. And the other is that the services themselves will over time build good semantic search. Like Gmail will eventually, I think, build a good semantic search API that we can use. Um, at which point the semantic search in, in Shortwave is, you know, we can maybe throw that infrastructure away and save some money. Um, so I think that's our bet. Um, I do think, I'm not saying that, you know, startups here aren't potentially gonna be awesome and, and, and be very successful. I do think there's lots of opportunity in AI search. Uh, I just don't think it's the right bet for, for us to make it.

Yeah. Interesting. Um, well, let's talk about integrations. You have a lot of them. It's, uh, advertised 3,000+ business tools out of the box, any API, any MCP. Um, how did you get to 3,000? That's a lot. Um, yeah, 3,000 MCPs. I would assume that that all kind of came sort of for free, but when you separate 'em out like that, it sounds like you've done quite a grind of, uh, you know, a long march through integration land.

So, so yeah, so this is, this is an interesting story when we, so in Shortwave, I think we have like 10 integrations or so, something like that. And when we started doing Tastly, we thought, okay, we'll start the same way. We'll pick the top 10 most commonly used ones and we'll focus on those use cases, you know, email and, Notion and Asana and stuff like that. Um, and we started going down this path and my co-founder said, hey, we should try hooking up one of these integration platforms. And we hooked up Pipedream and they have a whole bunch of, uh, integrations in there and it just worked really well, right? So we're like, holy crap, like suddenly we have access to all the stuff that, that they have here. And then we said to ourselves, well, you know, we should have MCP in here as well. So let's add MCP. And that worked really well too. And we said, you know, this PyTorch stuff works surprisingly well, even though there's like nothing in our code making this stuff work well. Like we don't have anything customization of the prompt. It's just, it's just, you plug it in, boom, it works. This is awesome. I wonder if we could do the same thing with HTTP APIs. Like I wonder if we could just, you know, describe to the model generally how to use HTTP APIs and we could like put some constraints around how those calls were made and then connect to an arbitrary HTTP API. So we built a thing to do what we call direct API connections and it worked really well, like, like shockingly well. And, you know, we found ways to make it even better by like, for example, going and scraping website docs. So like when you make a direct API connection, we go and we search the web, we find the API docs, we look it up, we pull out a description and then we use that and boom, we've got this, this API connection. And it works so well in fact that we have users who are switching off the official MCP. Like, so for example, we, we have a, a, a paying, paying user who stopped using the official Notion MCP and started using the direct API connection that work— that is fully LLM generated on our side. Um, because it works better, it's more reliable, it has less bugs or whatever. So, um, basically we just kept adding and adding and adding. And we realized that the opportunity here was to connect to everything. We said, hey, rather than, cuz everyone, there's so many competitors doing what we're doing now with Taskit and every one of them comes out and says, hey, we connect to this set or this set or this set. And they all try to differentiate how many they, they cover. And we're like, look, we need to just end this conversation and be like, look, we work with everything. There's nothing we can't connect to. And so we made that a goal and we very quickly went from, you know, 10 to thousands of integrations that, and some of those are ours, some of those are through integration platforms and then direct API. So any HTTP API, MCP, provider-provided MCP. So anyone like, you know, for example, like with Linear, right? They have their own MCP server.

So those are included.

that list as well. And like, we helped with discovery for that. And then computer use. And if you kind of put all of that together, the thing that we provide is a unified UX and LLM interface for those things. So no matter whether that integration is hand-rolled by us or it's done through an integration platform, or it is a direct API connection, or it's an MCP service that they built, or it's an MCP service that you built, It all has the same sort of configuration process and the same activation process for controlling like tools and permissioning things. And it works the same way in the LLM. So the rest of the system doesn't care, right? It, it, there's integration, it knows that it needs integrations and like boom, everything works. And then for good measure, we added computer use because there are some things that don't have APIs and don't have MCP servers either because LinkedIn doesn't work. Or in the case of LinkedIn, because they don't want you to, right? And well, it's real hard to stop computer use. So, and that is a key part of our pitch being like, look, like not only do we, you know, we use the integration platforms, we cover everything they cover. We can get any API, anyone with MTP, and we can also do computer use. And by the way, you know, the top end, we have hand-rolled ones that are like super solid. So, you know, the really important stuff, we, we make sure it's great. And I, I think, I think this has landed super well with folks and especially, especially the DirectAPI connections. Like I think an interesting data point on our side is you hear a lot of buzz about MCP. I used to be very optimistic about MCP. Our DirectAPI connections are used far, far more frequently than MCP.

That's really interesting. When it comes to like credentials, The flow is basically like, oh, hey, I want you to check my email. I may have never talked to it about my email before or whatever. Then the thing comes back and says, okay, you're going to need to connect your email if you want me to do that. The sign-in there is like a familiar flow to people. Are you— do those credentials, I assume, live at a cross-agent layer, right? Do they? Is that also a—

Yeah.

technology platform that you're able to tap into to manage those credentials for users, or did you have to roll your own version of that for some reason?

That, that's all our own stuff. So a big part of what we've built is the sort of integration and connection system. And basically we have this concept of a connection and it's an authenticated stateful connection to an external service. And it's something that may be a little complicated to set up, right? And this is when you For like a, a common one, you might OAuth into, or for Direct API, you might actually have to give us like an API key and maybe some other details about the headers you have to provide and stuff like that. Or MCP, you might need to provide some information about the MCP server. And there's a, there's a connection creation flow. So if you go in there and say connect to my Gmail, the first time you do this, it's gonna walk you through a flow to create that connection. Once you create that connection, that connection is stored on your user and you can reuse that anytime you want. But we require that every agent sort of you regrant permissions for it. And the, and the idea here is like, you know, if you're— imagine you're a company and like every agent's a different employee. You don't wanna give every employee access to everything, right? So some employees are, you know, will be able to do this and some employees can do that. You wanna, you wanna restrict what the agents could do so they don't go off and go rogue and do crazy things. So you create the connections and then separately you enable the tools on those connections specifically for the agents. And, um, I see a lot of opportunity here in the future because The place we're going to expand on the team side is allowing you to share connections across your team. The way we want this to be used in the future is you're an IT administrator at your company. You define the connections that people at your company should have. What are the API keys that people should be using? What are the services they should have access to? Those connections come with audit logging and they come with cost controls and other oversight and policies associated with them. And then you assign who on your team is allowed to access the different connections, and you tell everyone in your company, hey, you know, rather than you using any AI tool you want and hooking it up to, to, to our systems any way you want, you should use Tasklib. Use the connections that we've sort of created and pre-vetted for you, and that we've set up the proper compliance and audit logging and things for. And so yeah, the way I envision this working in the future, you're gonna have— your team will have connections, you personally will have connections. Creating those connections might be some work, but once you have those connections, enabling those on your agents is like super simple and super intuitive and like super safe. Interesting.

When it comes to the API, you know, spin-up for a new previously unknown API, is there, is that something that happens like for every agent, you know, fresh each time? Or, and maybe it wouldn't even make sense to try to like create a skill bank because these are so long tail that like, You don't see too many of them twice. But I'm wondering if there is a— I think it was Voyager was the original project that I recall sort of pioneering this notion of like, okay, I've successfully achieved this skill, therefore I'm going to save that to a skill library that I can come back and tap into again later. I mean, you could even imagine doing that sort of thing across users or across organisations, but then you might worry that maybe you shouldn't for some reason, or there could be some, you know, some proprietary info. Um, so yeah, is there any sort of, uh, crystallization of that API success?

There is. So you can, you can broadly, you could broadly group our connections into 2 types. There are like discoverable prebuilt integrations, and then there are custom integrations. And, um, we literally have a search function where you can like search for integrations and we return the list that we know about. And some of those integrations that we built, some of them are through integration platforms. Some of those are MCP servers provided by other services. But that's the set where we're like, hey, we know these exist, we know how to configure them, and we try to make those like really easy in one click. And then the other set is custom where it's like, you know, we don't know anything about this, you need to tell us the details. And, and I think we're gonna try to keep that divide of like any connection that we know about, we're gonna try to like save the configuration for you and make it as one click or close to one click as we can possibly get it. But hey, you can always set up your own thing if you want to.

Yeah.

Interesting. MCP, it sounded like there was a little bit of a hot take potentially brewing there. Yeah.

And I don't, you know, I don't know how many other people have come to the same conclusion, but I don't, I don't think I'm a total outlier anymore. We, we started working with MCP, you know, early this year. And initially I was extremely bullish. The community was exploding. Um, it was obviously like super cool what you could do with it. You could hook up these other services. Um, and it seemed like this missing, this missing piece. And, um, we obviously built this at the core of what we do in Shortwave. And like, it was a big inspiration for us building Task Flow at all. Um, but when Claude 4 came out and we started playing with, every time like a major model version comes out, you know, we kind of rethink all of our priors. And One of the big question marks we had is, hey, if like, you know, if a big goal of MCP is to provide these tool definitions, but those tool definitions, you know, there's probably a debate you've probably seen around like whether the tools should align with API calls or whether they should align with something more specific. So assuming those tool definitions end up just aligning with API calls, and those APIs are documented on the internet, like what's the point of MCP, right? Why can't we just like, directly call these API endpoints? We have descriptions for those which are available online. And I think the answer before Claude 4 was like, well, models aren't really smart enough to like make that whole process work end to end. But they got to a certain point, we tried this, we're like, man, like the models are totally able to, one, just directly use the APIs. You don't need to necessarily have like custom tools for LLMs. It works fine. And 2, they're smart enough to like generate their own tool descriptions basically by just scraping the web. And what's the point of MCP? And that, that, that isn't entirely true. 'Cause like one of the advantages of MCP is it provides a better auth experience, at least in some cases. So for example, with Notion, the only way to get like a nice auth that gives you auths broadly to your workspace is to use MCP. But like, we actually, we, we don't do this anymore, but for a while when we felt like the, the tool definitions from, from Notion were not good, we actually used the, the MCP auth from them and then just like overrided their tool definitions with our own tool definitions, um, because we thought we had a, we had a better approach. So now we look at MCP as, uh, you know, in cases where we feel like the provider of the service has a good version, we use it. In cases where they don't, um, maybe we'll use it for auth, but not for the tool definitions. And in many of those cases, people prefer to use DirectAPI or some other method for accessing it. So we now say, hey, we're gonna give you as a user, like, Every way to connect to every service out there. Sure, you wanna do MCP, we got MCP. You wanna direct API, we got direct API. You wanna go through an integration platform, we got that. It's up to you to decide which one you feel like will work best for your use case. And then once you've created that connection, you know, you can kind of forget about how you're connected and just like reuse that in the future.

One thing I've been looking for in MCPs, and I've seen precious few of them, is for lack of a better term, smart MCPs, basically working from the same kind of observation that you said a minute ago. Like, if it's just a one-to-one on the API, what's the point? One way to answer that would be to zoom out a little bit and provide higher-level sort of intent-based notions to the model that don't require— that maybe wrap a bunch of API calls, or maybe even there's like an AI on the side of the MCP that sort of takes in your higher-level intent. And because it's a specialist in using its own AIs, it can kind of translate your higher-order wish to a bunch of specific executions and give you something back. Everything has pros and cons that would have some loss of visibility and control, but maybe could give you higher performance and give you a reason to want to use the MCP over the direct API itself. Um, have, have you seen many of these? Uh, you know, why doesn't this, why isn't this happening more than it is? Or am I missing it? Because I haven't seen much of this, even though it seems very natural to me.

I, I haven't seen much of this and I, I do have some examples of use cases here. So for, for example, like in Gmail, um, there's no API for forward. The, the way you forward an email is you create a new draft and then in the draft you include the right content and then you send it. Um, but if you're gonna give a tool to an LLM, the, the process of like copying the history into that new draft, it's probably not something you want the LLM doing. You probably wanna have just like a tool call that like knows to like do the top posting correctly. Um, so I definitely think there are, there are use cases for higher level tools. Um, I think the big, the big downside of trying to do these higher level MCPs though is like, it's, it's a, it's another thing to maintain.

It's a lot of work.

Um, And if the models can get smart enough to do this stuff well, or if the models can get smart enough to generate those tools, you could maybe avoid having all these companies have to like think through what to do here. So today, you know, for Direct API, we use the API endpoints directly. Maybe in the future we'll have the model like reason about logical groupings of those endpoints such that more can be done in code. But I'm not super optimistic about, over the long term, hand-rolled MCT that does this, because I think it'll be obsoleted by the models.

So it does not sound like you think the progress in model capabilities is stalling out now or anytime soon. What's your commentary for those that And I don't believe that either. But there is this kind of counter-narrative that has come out, or come on, let's say, since GPT-5, that, well, I guess pre-training stalled out and everything's kind of— this is about as good as the AI is going to get. How do you react to that? Or what's your argument that that's not right?

I think they're still improving. And I Um, I very much drunk the Kool-Aid of the metric to watch is the length of tasks that can be completed autonomously. And, you know, regardless of how you want to measure that, um, I think we're at a point now where you can't— I mentioned this earlier— you can't really see that much of a difference in like single question, single response now as the models get smarter, right? It was really smart before. It's still really smart. Um, where you start to see the differences add up is over many turns, right? You, you, you know, computer use, for example, you say, hey, I want you to like navigate to LinkedIn and like find all my previous coworkers and make a list of their current jobs or something, right? To do that well, the AI has to go off and do turn after turn after turn after turn after turn. And a model that is, you know, 0.01% better at every turn over time is gonna end up being, you know, radically more effective than, than one that's slightly worse. So if what you're measuring is, you know, what's the quality of one answer from one response, I think that's sort of plateauing. But what if you're— what you're measuring is what is the quality at turn 100 or 2,000? Um, I still, I still think there's, you know, orders of magnitude to, to go here. Um, so we're still betting on it. I, I expect this to go for a very long time, uh, if that is the metric.

Maybe we'll circle back to that in a minute. Um, last thing on integrations, what other, like what, um, what integration providers are you finding to be either really popular or like hidden gems? Uh, like in other words, what should I sign up for so that I have it so that when I am using Tasklit, I'm like, you know, doing what the, the cool kids are doing?

That's, that's a good question. Um, I mean, the, the, the boring answer for you is, well, just the stuff that you're using already, right? So for the most part, we're not telling you like use a new service. It should just work with the stuff that's already in your stack. Um, if you actually wanna like use some services that work really well with this, you know, the one that comes to mind for me is RocketReach.

I was gonna say exactly the same. It's so funny.

Because, you know, for example, you know, I, I probably shouldn't say this, uh, to, uh, a member of the media, but, Um, I've been automating some of my—

I don't see any members of the media here. No, no worries.

Um, yeah, I've been automating some of, some of my press reach out. Uh, and it does a really good job of crafting emails that really, I feel like I would've sent and finding the right people and customizing them for, for, for that, that person. And I can automate this to constantly be looking for people that might wanna talk with me. Um, and, uh, RocketReach is great because Some of those people, they just put their email address on the website. Some of them are a little harder to find. Um, and so it can, it can track down emails for people.

Yeah, I was gonna nominate the entire category of contact info finding companies as probably a huge beneficiary of the agent wave because that information is hard to find. I have not had super great luck. Certainly sometimes you can just have the agent go find it, but it is not nearly as successful as the companies that have taken the, you know, pains and years and done whatever data deals they've done to find that information. So yeah, that's a great one. Any other categories come to mind? I think your first one is spot on.

Oh, I actually, I got a, I got one for you. Using other AI products. So a fair number of people hook it up to like Perplexity's search API. Um, because it's really good at doing sort of deeper research if what you're trying to do is like really heavy-duty web scraping. Um, so that, I think that's a, that's a good one. Um, another one, this isn't really a specific integration, but it's a use case. We've seen people give, uh, Taskbit its own email address. Like they'll create a Google Workspace account specifically and give it a name so that it can like send and receive its own emails as its, as itself.

Mm-hmm.

Um, that's another fun one we've seen. Um, but re— really beyond that, it is the tools they already have, right? So people that use Salesforce, they use it with Salesforce. People use Stripe, they use it with Stripe. Um, so, so whatever, whatever tools you already want.

With that email sending, and this would be true for probably any number of different kinds of integrations, you know, post something to Slack, whatever. Is there a, a best practice or a good, good paradigm for thinking about human in the loop? It's like I sometimes would imagine I would want, uh, like say I wanted a Tasklet to organize our lunch order on a daily basis. Back when we were at the office every day, you know, this was, uh, a constant pain point. And I could imagine something that would be like, okay, go post to Slack, remind everybody twice, and then collect and place the orders. But you'd have to have some sort of— I guess on that one you could do it on a pure time basis. Lunchtime is lunchtime. But plenty of things you can imagine where you need that feedback and you want to wait for it and you want to respond to it when you get it.

Yep.

But you You know, you need to have it, right? So is there anything that— does that paradigm exist at the run level today, or is there anything I could do to, to sort of make sure that I set that up?

So it, it's interesting that you bring in lunch ordering because this was the canonical example we had internally of this is the thing we wanted to be able to automate because we do this, right? We order DoorDash every day for the team. And it turns out This is a non-trivial thing to automate because, well, you're not in the office every day and different people are in the office every day. And, uh, there are error cases to handle. Like, you know, you order from a restaurant and then the restaurant just like cancels your order sometimes. You have to like handle, handle that case. Um, there are dietary preferences to consider. You don't wanna order from the same restaurant every day 'cause people get sick of that.

Uh-huh.

Sometimes you have guests, right? So there's this long, long list of complexities and exceptions and things to order lunch and Um, we've worked with EAs in the past, like human EAs that do this. Um, our own team does it. It's kind of a hassle. Sometimes we forget to order lunch and then we have to go out for lunch. And, um, so we're like, man, we, we, we should automate this. This is the first thing we should automate. And, uh, we actually, it's a little embarrassing. We don't currently have that particular thing automated, although I think we could today. We have half of it automated and I haven't gotten around to setting up the other half of it. Um, so we get an email every day with recommendations. And the recommendation of DoorDash links, and someone has to click— has to choose the one and click the DoorDash link and like set up the, the group order, which we should fix because we can do that now with computer use. But the human-in-the-loop portion you talk about, I think, is really important because, for example, you might want someone to approve the restaurant that was picked. You might want someone to approve that, like, everyone has added their order, that there are no guests today. So I do think that's a good example here. We actually do have some computer-in-the-use capabilities in the product today that the subagent runs actually can contact you and they can send you an email. It doesn't work super well. It hasn't been super common. This is an area I want to fix. Like, what I really like to be able to happen is for the subagents to be able to, like, call into the main agent and be like, hey, I ran into an issue. Main agent decide what to do. And then the main agent could kind of reason about how to handle it, including contacting you. This is also an area where, like, we probably need a mobile app to do this well because Getting an email when you need human in the loop is probably not great. What you really want is like a push notification and they can, you can jump in. So, uh, we, we would love to make like lunch ordering the like ultimate starter use case and make it super awesome. We'd love to do human in the loop well. It's, it's a solid work in progress though.

Gotcha.

Okay.

I'm standing by. Um, on, I guess going deeper You know what, a little bit deeper down the stack than the integrations. I'm wondering what you are using to build. You mentioned Pipedream being one platform. What else would you say you have found to be great? I'm thinking like, you know, I go to the Vercel SDK a lot of times if I want to, you know, set something up that has nice frontend, or maybe I'll use LangChain and LangSmith if I want to have, you know, workflow, especially if I want to have that hosted in the cloud. What's good in the tool, you know, in the picks and shovels layer that you would recommend to others?

Yeah, I, I, I did the list of shoutouts right now is very limited. Lightdream's been great, been happy with them. Google Cloud is awesome. So, you know, our computers, for example, is all backed by like VMs in Google Cloud and we're using a lot of Google Cloud products and it's awesome. And then Anthropic. Uh, is, is super key. We don't use LangChain. All the agent code is our own stuff. Um, it's all, it's all TypeScript. Um, uh, we don't use any specialized search products for what we're doing. Um, so, so yeah, it's a, it's a, it's a short list of, of shoutouts, but yeah, Cloud, Google Cloud, Pipedream, Anthropic.

How about at the coding layer? Are you guys, uh, Cursor shop? Oiir?

Yeah, we use it. We use a bunch of stuff. Heavily Cloud Code, and then most of the team uses Cursor, and we do use Codex for some things. And there's, you know, some folks prefer Codex and some folks use Cursor. Some folks use both for different things, which I find interesting. We've tried some code review tools. But like we just have Claude code like integrated into our CI at this point, which works pretty well. We use Sentry. We use Statsig for stats. I'm probably forgetting some. Yeah, those are the, those are the probably the big ones.

Are you tracking lines of code drafted by AI or similar metric?

We aren't. It is significant. Uh, I, I suspect by just pure number of lines of code, it is the majority of them. I don't think it's 90%, but it's, it's the majority of them. Um, I, I don't, I don't think that equates to like, you know, the majority of the thinking or the reasoning, right? Like writing the lines of code is often not the hard part. Um, but a lot of AI coding, yes, for sure.

Have you been able to, or, or tried to, or do you, do you, you know, feel that it is desirable to with today's level of coding capability, go from like a ticket or a GitHub issue or whatever, straight all the way through to a pull request? We see lots of examples of that, but, you know, are they, is that, is that something that you are doing and finding value in?

Totally.

Yeah.

It, it's gotta be something where, you know, the system is already set up well enough to support it. 'Cause I think one of the downsides is of AI coding is it'll hack in a solution that like you should not add in. It works, but like breaks the system in some way. So if you look at a bug report and you're like, hey, this is actually, you know, a relatively quick fix and like a system is already sort of architected to handle this well, like, yeah, we'll throw, throw AI at it. My co-founder does this in a very snarky way, you know, so, uh, he's, he's a really good software engineer. He's really fast. He's much faster than me. So if I'm feeling lazy, I'll, you know, send him an email and ask him to do something. Like I had some stats stuff I wanted to do, so I emailed him this morning and He just emails me back a screenshot of like him copying my thing and pasting into Cloud Code. Um, and, you know, you're like, hey, do you could, you could type this yourself into Cloud Code. Um, but yeah, we're, we're totally doing stuff end to end for sure. So as an example, like, uh, the static content on our website, um, the pricing page, the release notes page, um, the terms of service, all that stuff that, I mean, the, the content, you know, I, I decide what goes on there, but the actual— pages and layout and everything was like just totally one-shotted with Claude code.

It's a brave new world, that's for sure. How about functional testing? One thing that has come up for me multiple times is I would love to have an agent that, you know, and Replit is doing this now within their own platform, but like obviously that's, you know, specific to Replit and kind of a closed, I mean, remarkably open in some ways, but like closed in other ways.

ecosystem.

Is there, have you seen anything that just you point at your product and say like, go use this product and find bugs with it at a purely like user interface, you know, functional testing sort of level?

So we do this through Tasklet actually. We have Tasklet test itself. So when we built Computer Use, a lot of the work that you have to do is in properly configuring the VM, for example, so that it is doing remote desktop correctly and it's sleep open, it's waking from hibernation and things correctly. My co-founder debugged all this stuff by being like, hey, the VM isn't working right. Go debug its configuration, try to figure out why it's not waking from sleep properly, or this thing or that thing isn't working right. We have it test use cases. We've gone in and been like, I want you to connect to blah, blah, blah. And then come up with, you know, a way to test all the tools. And so it'll like connect to Notion and it'll just go, it'll just run through the tools and like make up test cases. Um, uh, we have the ability with Computer Use to do like UI testing of our product. Actually, one of the most hilarious demos I've seen is somebody used Computer Use to open up the Tasklit website and go back and edit itself, right? So the agent can just go into its own self and like edit its agent. So, so yeah, we do, we do a lot of sort of AI-driven, like, testing, but through testbed, honestly.

That one example, you talk about a hall of mirrors, that is, yeah, it's starting to get strange in a few ways. Yeah, that makes sense. Okay. Security. You, You mentioned earlier that you don't have SOC 2 on this product and custom— what customers really want is like a smarter agent that can do more stuff. Um, at the same time, you know, when I'm giving access to like everything, right? My email, my Slack, whatever. Um, and I'm generally not a security-minded person. Uh, mostly, you know, figure clean living pays off, but you know, it's a lot of access. Is SOC 2 even, first of all, is SOC 2 even meaningful in the AI era? Like, How big of a deal is that? I've actually never been through it. I know you, you know, have done these kinds of things in prior lives. Is it secure in theater? How much does it matter? Like, what, what should I think as a user when I see that?

I wanna be clear that we are, we care a lot about data privacy and we are totally planning to do SOC 2. It's, it's, it's been a week since launch. So if, if, if anyone listen— is listening, is, you know, wondering about this, yes, we, we totally plan to do SOC 2. We plan to do it soon. We take this stuff very seriously. And I do think it's still perfectly relevant. Like, what you care about with SOC 2 is, you know, basically what are the controls on the data, right? How, how, how do you know, for example, that like the employees at Tasklet aren't like doing something with your data they shouldn't be doing? Um, so I, I still think it's very obvious. I still think it's very important, but I do think it's also not enough. Um, so, you know, traditionally what you've cared about with, you know, SaaS products is whether the, the humans at the company are doing the right thing and whether the systems are, are secured. Um, now you also care about whether the agent is doing the right thing. And for that, there doesn't really exist a standard like this. And I've, I've talked to a bunch of security people to try to understand, like, hey, when you're, you know, when you're thinking about your company using this stuff, like, how do you think about this? And basically the answer from everyone is like, we have no idea. This is the Wild West. We're building, figuring this out now. You had shared a, a standard with me, and I, I don't know enough about it to have an opinion. I know there's a lot of people thinking about this exact problem. Um, one interesting data point I would have though is when we initially started testing this with customers, I thought the number one risk to the business, the number one problem that we would face is people would just be terrified of the AI going rogue and they wouldn't want to hook this up to their systems. And we have had, and I'm not exaggerating here, we have had not a single complaint of this happening. Um, we have had all kinds of complaints about other things, right? Tons and tons and tons of bug reports, but no one. has said, hey, the AI just went and did this crazy thing and I'm unhappy about this. And I found that really interesting and kind of shocking. And what I attribute it to basically is like, because our entire product is— the, the, the entire intent of our product is, hey, we are gonna give your agent agency. That, that's the whole thing. And we're messaging it very clearly and we're super upfront about this. Like the whole point, the goal of Task Fleet is to give an agent agency. agency, um, that people have the right expectations set. And we do give you controls too, right? You can decide, hey, what do I want to connect it to within those things? What are the tools I want to give access to? Um, but, uh, I think it's fascinating, right? That it has been a complete nothing burger so far. Um, to be clear, it's still very top of mind for us. We're still thinking very hard about this. And I think it'll probably still become, you know, something a customer would bring up a lot as we sort of move upmarket into some of these bigger customers and doing higher value things. But yeah, I don't have all the answers yet, for sure.

Yeah, that's interesting. So presumably, I think you would have heard about it if agents had gone truly rogue. So presumably that means Claude is behaving pretty well. It can't be that people are sitting on those episodes. I did hear, I think this was actually in the system card. If not, I heard it in conversation from somebody at Anthropic that the famous Claude blackmail scenario reported in the, I think it was the Claude 4 model card originally, that problem has gone away with 4.5. So there potentially are also just some under the hood Improvements. That standard, by the way, AIUC from the AI Underwriting Company, their AIUC-1 standard will be subject of an upcoming episode. So I've still got some more self-education to do around that as well. One of the things they're trying to do, I mean, they've created the standard and then there's sort of their master plan, you know, grand vision is like they want to harness the power of the insurance industry to make AI safe. And the reasoning is basically like, in financialising risk broadly, it's a great way to focus the minds of some very smart people to say, like, well, what is this risk? How likely is it really to happen? How bad is it going to be if it does happen? And can we get a good enough handle on this to actually write a policy on it that we're reasonably confident we'll make money on? Um, and that certainly hasn't happened for AI agents yet, but that's kind of the, you know, the big picture goal that they have. I wonder if you would be, you know, does that sound appealing to you? Like if you, if there were AI insurance, uh, or, you know, AI agent insurance on offer, would you be wanting to buy it?

It, it does. Yeah. So, I mean, the, the company that comes to mind here when you bring this up is Airbnb. I don't know if you remember the very early days of Airbnb, but there was a, uh, you know, a customer that like trashed somebody's house or something. And this was before they, they had insurance. And they said, man, our, you know, our brand is going to be real tarnished if we don't react. And they said, we're gonna have this big insurance policy. And it was a huge deal, um, for them. And I think it was key to the success of the business. And for us, you know, right now we're focused on how do we make this thing super smart? And it's all very cutting-edge tech, but like, I think the medium and long-term success of our business is entirely dependent on us being the most trusted place, most trusted way for like enterprises to deploy agents inside their companies. Um, and, you know, I think a lot of people are gonna have the ability to connect to a lot of tools and automate a lot of stuff, and we're gonna differentiate by being, you know, the thing that the IT folks are most comfortable with. Um, and to that end, yeah, to the extent that, you know, insurance and compliance can help us tell that story and give people confidence. I'm very interested. So, so yeah, very interested.

Cool.

How about on economics? What I recall from the first Shortwave conversation was you were losing money on every user. From the second conversation, caching was the big unlock that changed the economics to where with the same price point, you could make the product profitable. Now you're kind of back into an early phase. So are you burning money on me or what does it look like?

Well, let me give you a quick update on Shortwave first, because I think that story is telling and then we'll talk about Tesla. So yeah, I think the first time that we talked, probably the second time we talked, we were losing money on folks, probably losing a lot of money. Basically every launch that we did with Shortwave, we were worried, will this bankrupt the company? Because we didn't have enough data yet. to know how much this stuff would get used and how effectively we'd monetize. And there were several launches where we thought, hey, this might just go to the moon cost-wise and not bring any revenue, and it's going to really screw us. And that never happened. It was always expensive, but not bankruptcy expensive. And over time, we found ways to monetize more effectively, and the cost went down, and we found ways to optimize costs with caching and stuff. We've done a whole bunch of stuff recently with caching. That's helped actually a ton. Um, and we've gotten Shortwave quite profitable. So Shortwave is now, you know, not like traditional SaaS, you know, 90% margins, but it's, it's healthy margins and we're making good money off of it. Um, and Tasklit is back to where Shortwave was because Tasklit, you know, Shortwave, there's, you know, you get value from the AI, but you also get value from other things in there. And so a lot of it is sort of, you know, half of it's traditional SaaS margins, half of it's sort of AI margins. Tasklit is all AI. People use a lot more tokens per person in TAS than they do in shortwave. And we are strongly margin negative right now. But I think the same thing's going to happen, right? We're going to be that way for a while, but over the next few years, like, it'll eventually get to neutral and then into positive territory and eventually strongly positive. A huge unlock for us here is Haiku. So very excited about Haiku 4.5 because Up until now, your choice was, you know, Opus or Sonnet, which are like relatively new versions, or like a very ancient version of Haiku. And Haiku 4.5 is good, it's fast, and it's, well, relative, it's not nano cheap, but it's like, it's relatively speaking, it's cheap, and it is good enough for most use cases. We're actually just today, we're rolling out the option for Haiku in Tasklit. And the way we've been addressing cost in Tasklit to keep it, even with this, we're very margin negative, but the way we've kept it from going so margin negative, we're, you know, going out of business is with quota limitations, which you've seen. And basically you have a little meter next to your text input that tells you how much quota you have left for the day. Um, and, uh, Haiku basically should let us significantly increase that, uh, well, number of tokens that people can use without exhausting that quota, uh, because it's a third the price. So that's, that's gonna be a really big unlock for us.

You wanna talk a little bit more about interesting stuff you've done with caching recently? I thought that was definitely Very interesting last time. And if there's new techniques or updates, I'm sure people would love to hear 'em.

Yeah. So I think the key to caching, basically doing caching well, is making sure your agent is an immutable log. You never wanna modify earlier messages 'cause every time you modify an earlier message, you invalidate the cache. And then you wanna be smart about, you know, which, what cache do you, you know, your options are like no caching or 5-minute caching or an hour caching with, with Anthropic and like which caching do you use for different pieces of it. Um, and we've managed to push our cache hit rate in Shortwave up to like, I want to say like 85%, something like that, which is pretty good. And for, and I'd love to do higher, right? And for like multi-turn stuff, there's things you can do. Um, one of the big unlocks for us in, uh, in Shortwave was, uh, replacing state in system messages with— sorry, a state in the system prompt with system messages. So there are certain types of things that traditionally you do in the system message. For example, the current time, date and time, right? If you put that in your system prompt, then every time a minute elapses, you've nuked your caching and you gotta start over. And you can't cache across different users if you do that. If you don't put in your system prompt at all, It doesn't know what time it is, and time can be really valuable. If you put it in a tool call, then you gotta do a tool call and you gotta do another turn on a tool call every time you do that. And that's really expensive. Um, but what you can do is you can use system messages. And the system message is basically just like a little block of, you know, XML or something that you append and hide from the UI, from the user in a user message when they send the user message. So basically right before the user message gets inserted to the LM, there's a thing above it being like, hey, by the way, you know, here's some stuff that happened. And And this is, I think, something that Anthropic does heavily with their own stuff. Like, they do this now for, like, context usage, I believe. And this works great for any state that you want to make available to the agent without it having to call a tool, especially things that you want to keep updated. So otherwise they have to, like, call the tool multiple times. So for timestamps, for, you know, state about the user. Um, for like memories in Shortwave, we have like a memory concept that lets you sort of customize behavior. We can do that through system messages as well. Um, so that's, I think that's been a big unlock for us. Um, uh, compaction's been a big unlock for us. Um, and like trying to be smart about how that works. Uh, yeah, those are probably the big ones. And then lots of little things.

One thing that I thought about from a cost, especially with you being strongly margin negative, How do you think about the possibility that some of the agents that people have set up are kind of zombies? Like, they set this thing up, they're getting an email every day. Maybe they're not even reading that email anymore. Maybe they forgot, and maybe they're still using other agents actively. But if it's not hitting a limit for them, there's not much of an incentive for them to come in and turn that off. Do you have any ways of thinking about how to detect that or try to, you know, have some, um, I don't know, some, some smart system to identify and turn down the zombie costs?

Yeah. So I wanted to know, it's been a week. So, um, we're kind of learning about that now. We did actually look at some stats this morning and there's a significant fraction of our cost is free users with recurring jobs. And, um, you know, some of those users may be getting value from that and might cause them to come back and eventually pay us and tell their friends and maybe, or maybe it's just going to spam on their side. and may never see it, and, uh, or it's updating some system they don't look at. So, uh, it is on our mind because yeah, if, you know, every few users out there is spending, you know, a dollar a day on LLM costs and they aren't even looking at the output, so it's not gonna, you know, benefit us in terms of growth, that's a problem. Um, I think we do plan to do that. Uh, on the paid user side, we'll be like, hey, look, you're paying for it. You wanna pay for it? That's, that's fine. Uh, on the free user side, I think what we'll probably do is look for some indication of activity in the app. And, you know, if we haven't seen you in a while, we might email you and be like, hey, you gotta come back into the app. And if you don't, we might turn your stuff off. Um, uh, I don't have a good answer here yet. I think it will be a problem and we gotta do something about it, but, um, TBD.

Yeah. I mean, if you let free users set up recurring jobs, uh, you gotta have some limits on that or you're gonna be bankrupt to forking all your money over to Anthropic. Okay, how about frontiers? The multi-agent future, I think, is a dramatically undertheorised topic. I have this one graph that I always use in presentations, and we did an episode about this with respect to Claude's ability to cooperate with itself in a certain behavioural economics experiment. Other models— this was Claude 3.5— other models at the time couldn't do it. And I'm always struck by just how little of that research has been done. The fact that I don't even think that experiment has been repeated with later models. And I think we all have a very foggy vision of, like, okay, it's not just going to be these one-off things that are doing their own thing totally in their own silo, but they're going to intersect with each other. They're going to pass messages back and forth. They're going to, like, trade with each other, perhaps with crypto wallets at some point in time. What does that look like in your imagination today?

So, my thinking is that within an agent or within a single application where you are serving a single user, I have yet to see a good use case for having multiple agents. Like, my experience has been, If you have a big LLM and you feed it as much context as possible and you have that one LLM reason the whole problem itself, you get the best answers. The place that I see multi-agents coming in is when you have multiple different parties being represented and maybe you don't want to just let one agent see all the data and make all the decisions. Like if you, you know, I'm trading with you, right? Your agent and my agent might not want to have, they might not want to share data with each other and they, there might be some sort of competitive dynamic going on or adversarial dynamic.

Yeah.

Um, and that's, I think that's sort of outside the scope of what we're doing. So our, you know, our focus really is, you know, one big agent with all the context making smart decisions for you. Um, to the extent that there are other agents out there in the world that they have to interact with, I guess we'll figure that out. Um, I do want to give a shout out though to, there's a startup, uh, that I think you talked to the co-founder of. Uh, so my former co-founder from Firebase, James Tamplin, has a company called Cradle AI, Cradle with a K. And they are doing exactly this where they're sort of building virtual worlds and letting all the models interact through games like Minecraft and stuff and just seeing like what they do in sort of collaborative and competitive dynamics. And it's fun to watch. I don't know if you've played with it, right? I know you chatted with James.

Yeah, I met him briefly at the Curve and we've got a call on the calendar coming up to go deeper into that. And I do think it's really, Fascinating stuff. I mean, well, let me get your take on this. Okay, so I pitched this vision of the future to somebody, maybe even a couple of people from Anthropic at the Curve, where I also met James. And it's sort of a confusing vision for me, but basically it's like, okay, let's just assume that that metre graph keeps going, right? The exponential keeps going. If you take the And you can always discount this, but if you just take the more aggressive 4-month doubling time that people plotted for just the last 9 months worth of models or whatever, since maybe 12 months worth of models since '01, then 4 months doubling means 8x per year. We're at 2 hours now. We're basically at 2 days a year from now. We're at 2 weeks 2 years from now. We're basically at quarters worth of project size that you could send off to an AI in 3 years. May or may not happen, but that's the trend that has been plotted. At the same time, we have these very weird behaviours, scheming, deception, blackmailing you, whatever, that are— I think it's unknown exactly how rare they are. I mean, it's good to hear that you've heard zero complaints about this. That suggests it's potentially quite rare in production. Most of the reports of this, the blackmailing, the autonomous whistleblowing, were in research setups. Although I think people are, in my view, too quick to dismiss those research setups as being unrealistic. I don't know, man. You give an AI access to all these file systems, all these emails, there's a lot of people out there, there's a lot of weird stuff in emails. Seems like this stuff is going to happen. So if you combine those 2, trends where the task length is getting longer and these bad behaviours keep coming up, and then they're sort of suppressed or somewhat, some degree trained away, but never quite to zero. Maybe you end up in a world in 3 years' time where you can delegate weeks, if not months, of work to an AI. But then also there's some vanishingly small but not zero chance that it actively sabotages you in the pursuit of doing that. So I pitched this to these couple of guys from Anthropic, and they— I was like, do you think that's like a realistic vision of the future? And their answer both times was basically like, yeah, maybe that sounds about right, honestly. So I was like, well, that's really weird. What do you think? Is that kind of the mental model that you have? Or what do you think 2027 or 2028 looks like in terms of how much we can delegate and how much risk we'll be taking? Yeah.

I, I, I do think the task length is gonna keep getting bigger and bigger. Um, I, I am blown away on a weekly basis by the types of stuff that AI can do for you when every model release comes out. Like Gemini 3 is supposed to be amazing and, you know, I've seen some things and it looks incredible, but I'm sure in 3 months it'll, it'll seem, you know, super dated. So I, I, the progress seems fast. I think The task lengths will increase. Um, I, I tend to look at the, the, the blackmail scenarios and things as being fun and interesting, but maybe not super relevant to the day-to-day of my business. 'Cause, you know, we, we talked about earlier, you know, having conflicting instructions, uh, and how much of a problem that creates. And like, yeah, if you set up a research setup where you tell, you know, you tell the AI there's multiple conflicting goals and it, its way of getting outta these conflicting goals is doing something a little unsavory. Well, That's not terribly different than how a human would behave. And in many cases, it might not be terribly different than how you want the human to behave. So for example, like, you know, if you, you know, if you have a humanoid robot, right, should the humanoid robot jaywalk sometimes? I don't know, maybe it's against the law, but humans jaywalk all the time. So yeah, I do see a world, yeah, maybe where it can do a lot of stuff and it does things maybe in a little bit of a shady way sometimes. that agreed to do that does that. Might be a matter of debate and strong opinions, and we'll figure it out.

Yeah, I think it's a great point that we don't really have, I think, in many cases, even a decent intuition for what we want the AI to do, let alone any sort of consensus that we could measure them against. In the case where the model Send an email to the FDA to blow a whistle on the, in this case, fictional company that was in the research setup. The company was doing something bad. So, I mean, I think in general, we sort of celebrate whistleblowers if they're actually blowing the whistle on genuinely bad behaviour. Like, faking clinical trial data is bad enough that you want somebody to speak up. Do you want your AI to speak up? I mean, maybe you do. It's certainly a weird thing, but it's—

It's up for debate, right?

Yeah, I feel like necessarily the blackmail feels like it crosses maybe a different line, but the, the whistleblowing, I, I don't see as necessarily a big problem. But, or, I mean, it could be a big problem depending on who you are, but it, it doesn't necessarily seem like the wrong thing for the AI to do. But yeah, we got a, a lot of, I mean, if that does happen that fast and we're at quarters worth of work in 2028 that you can just, you know, send off a little blurb and, you know, it has access to all your stuff and it just like goes and figures it out for a quarter's worth of work. That is gonna be a very, very different world than it is coming at us quite quick.

The future's gonna be fun.

If we reel that back into the present though, you know, I see all these like, N8N master templates, right? That are, you know, people even sell these because it's like gnarly to set them up. And I've done enough N8N to know that it can be quite gnarly to set them up. But there does seem to be a pattern there that I'm wondering why you're not, you know, seeing it the same way or whatever. Like, If you had a sort of general purpose agent, might you not want it to route certain things to the marketing agent and write other things to the HR agent? And maybe sometimes you need input from both of them or whatever. Why isn't there more of a role in your mind for multi-agent orchestration in today's world?

Because I think The trend we're seeing is the foundation models are becoming best at everything. And it's not like you have a model that's good at science and a model that's good at math and a model that's good at some other topic, law or something. You have one model that's good at everything. And the only thing in that world that differentiates between Again, assuming they're, they're working on my behalf, right? If I have 2 agents working on my behalf, the only thing that differentiates them is not the model. The model is an expert. Both, both agents have the same model. Model's expert at everything. The only thing that differentiates them is the context they have access to and the tools they have access to. And if that model is smart enough to be able to handle both sets of context and both sets of tools, if you just give one agent all the context and all the tools from both agents, Our experience so far is it does a better job. So I think it's the generality of those foundation models. And this actually, I think, has bigger implications. I am of the opinion that most SaaS, like vertical SaaS products, are going to go away because you're going to end up with these horizontal platforms, these AI platforms that are that work in every situation. So as an example, today, uh, you can, you know, we've been prototyping this morning, but like you can like dynamically generate UIs in Tasklet. Um, in a world where you have an AI that's an expert at everything, the model's an expert at everything, it can dynamically write code, generate UIs for anything, right? And if this gets really good, why would you need, you know, a SaaS product for construction or for medicine or whatever, right? You could just go into your generic general purpose platform platform and be like, hey, you know, use this part of your foundation model knowledge, generate some UIs like this, and let's go. So I think you're going to have horizontal companies that are good at everything that leverage the, you know, the fact that foundation models are experts in every domain. And then you're going to have businesses that vertically or integrate businesses that sort of provide value end to end and leverage those platforms. But I don't think you're going to have these, like, too many of these, like, intermediate SaaS platforms. Over time.

Yeah, it's, I, one of my mantras for the AI era in general, which I think Tasklet really exemplifies, is AI beats UI. It's just like, in general, who wants to use UI? And if you have created something that is basically a bunch of UI that sort of makes tangible or, you know, sort of encodes the steps that somebody figured out for a workflow, it does feel like the days of those sorts of systems may be numbered. So I, I do agree that a lot of this stuff feels like it kind of washes away in the, under the great wave of, uh, of AI progress.

One of the questions that we, we ask ourselves internally is how long is it gonna be until I can go into an AI agent product, you know, TaskLit or ChatGPT or whatever, and tell it, Give me an email inbox designed for like fast triage with these constraints. Um, because the moment that that works well, Shortwave ceases to be a valuable product. Um, and I, you know, I think it's going to be a while, right? We're still, we're still investing in it. I still see it as, as, as a, you know, I use it every day. Lots of people use it every day. It makes a lot of money. Um, but there will come a day when you can generate a Shortwave dynamically.

Yeah. Do you want to put an over-under on that? I mean, that's still more than a quarter's worth of work, right? So it would be, if that, if the media trend is the trend, it would still be like beyond 2028.

Yeah. I don't know. It's years. It's not, it's not quarters. It's years out. But, uh, you know, SaaS, SaaS companies used to, you used to get a revenue multiple of SaaS companies based on like, you know, it's going to grow for 20 years. I don't think, I don't think shortwave is going to be around in its current form in 20 years.

Is there any limit to So the single agent, like, one other idea that I wanted to bounce off you is just like supervision agents or sort of quality control agents. I mean, I have an intuition that says if I've just had an agent do dozens of steps or even 100 steps or whatever, and now I could say to the agent itself, like, please look back on your work and tell me how you could have done better, or give yourself some instructions for next time to do even better. It probably can do that remarkably well. I mean, again, these things are obviously super impressive, but my intuition is still like, if I had a different prompt that I really dialled in for that purpose and had it sort of sit outside of the main agent. And I don't know, maybe this is just— I'm overly anthropomorphising, but I sort of feel like this outside view with a different frame of mind as embodied by a different prompt, it still feels like it should add something to me. But it sounds like you've tried that and haven't found that to be the case.

Yeah, not so far. No.

Interesting.

That is really fascinating. I think I've tried to push on every angle that I could to see if there's any limits to your one agent to rule them all paradigm, but I'm not finding any. So how does this— what does this mature into? I mean, there's this talk of like virtual employee. I think this is the product that I have used that feels most like the virtual employee in the sense that It is pretty UI light, right? I'm not, when I think of an employee, I don't interact with it through forms. I interact with it through language, right? And the primary thing here is language. And there's not really a point where that flips over into some other, you know, gnarly or tedious paradigm. So that is really cool. You even mentioned like some people give them names, some people, you know, give them their own email account so they can do stuff. You know, like as themselves, right? As opposed to acting on behalf of the user. What is the, you know, you're kind of on the path, right? Like what, what does the virtual employee of the future look like? And, you know, what do you need? What's missing for us to get there?

Yeah, I really do think that that is probably the right way to think about it in the long term as a virtual employee. I, we've avoided that messaging because I think that That has been overdone. So many companies message virtual employee and then they don't deliver on something that is even remotely like that. Um, there is, I think there are a huge number of companies building toward the same thing, right? They figured out, man, this agent can get good at everything and people like to just be able to use language and let's just keep giving this thing more and more capabilities and, you know, let's give it computers and, and allow it to connect to your services and stuff. Um, and I think the thing that sets us apart from most of the other people that are doing this is a combination of it being agents all the way down, right? There is, yeah, we don't turn into a flowchart or something, and it actually working. Um, and I think this is a, a refrain I hear again and again from, from people that are paying us is, I tried it and I just expected, you know, to not like it cuz I've tried a bunch of the products and then wait, it actually worked for my use case. And then— Yeah, I'm really impressed. I think that is our path forward. So the launch went super well. It's growing really fast where we are adding revenue faster for Tasklit than we have ever added for Shore by a huge margin. So people like it. It's great. We have a long path ahead and, and I think our focus is entirely on just making it actually deliver on what it's supposed to do, right? Let's make this thing smarter and more reliable and faster and simpler and you know, like an employee, right? How do we take this from an employee today that like, you know, is maybe a little bit dumb sometimes and sometimes drops the ball and, you know, sometimes is a little confusing and just make it smarter, faster, more reliable, easier to work with.

Mm-hmm.

Um, and I think there's a long, long way to run there, right? Like, yeah, today you might have it, you know, finding spam in your inbox or, you know, generating invoices for you or something, but it's not like, planning your roadmap or, you know, running your entire marketing department end to end. Um, but maybe we can get there, right? Maybe, maybe in the future you have a small business and you're just like, you know, I want to focus on the restaurant and cooking. I want you to like literally do my entire marketing campaign. Go. Um, uh, I'd love to be able to get there.

Yeah, it's crazy how close we already are. It, um, it doesn't feel to me like it is going to be all that much longer before we really start to see not necessarily superhuman performance, but like Ethan Mollick has this great, you know, best available human standard. And it seems like we're closing in on that for a lot, especially small business, right? Man, who can you hire really to do your marketing as a small business? The virtual employees are, I think, hitting that level pretty quickly. Last time we talked, one thing you had said that really stuck with me is there's no other moat than speed. And I think that's a big reason that you're willing to be so open with all the details of what you're building, the tools, all the techniques and so on. Have you found any moat other than speed in the intervening months? And how do you sleep at night if that's still the only moat?

No, I, I think, I think speed's the only thing that matters at this point. I think there used to be moats and AI is like, I'll give you a good example here with all the integration platforms. It used to be that to compete with a Zapier or an N8N or a Pipedream or something, you needed to have a lot of connectors and those connectors had to be hand-rolled. And so you had to build up over the course of years, this huge investment in building those connectors. With DirectAPI, that's gone, right? So We on day one have, I'd argue with computer use, better integration support than Zapier has. Um, despite being a few months, the product being a few months old and Zapier being a, a very old product. So that moat to them, uh, you know, is, is gone. Um, Shortwave, I give you a similar example of like for a long time where like, hey, our moat is like we have an email client, right? Anyone who wants to come and build an AI email client, they first have to have an email client. Well, it's not gonna be too long before you can just ask the AI to write an email client for you. And then that memory is gone. So I do think it's speed. Um, and it's all speeding up because the tools are getting better. The AI tools are getting better. Um, so that is our entire focus of like, how do we make sure that by the time, you know, by the time the people, you know, listen to this podcast who might want to compete with us have figured out a way to, to replicate what we have, that we've already figured out new stuff. Um, and we're gonna, we're gonna try and just keep that, keep that going.

Shorten the timelines is the, uh, the modern maxim for sure. Uh, this has been great. I really appreciate all the time and, uh, the depth of your answers. Anything else you want to leave people with?

Uh, I don't think so. Just, just check it out. I think you'll like it. It works. It really does. Uh, Tasklet.ai.

Tasklet.ai. Andrew Lee, founder and CEO of both Shortwave and Tasklet. Thank you again for being part of the Cognitive Revolution.

Thanks for having me.

If you're finding value in the show, we'd appreciate it if you'd take a moment to share it with friends, post online, write a review on Apple Podcasts or Spotify, or just leave us a comment on YouTube. Of course, we always welcome your feedback, guest and topic suggestions, and sponsorship inquiries, either via our website, cognitiverevolution.ai, or by DMing me on your favorite social network. The Cognitive Revolution is part of the Turpentine Network.

A network of podcasts where experts talk technology, business, economics, geopolitics, culture, and more, which is now a part of a16z. We're produced by AI Podcasting. If you're looking for podcast production help for everything from the moment you stop recording to the moment your audience starts listening, check them out and see my endorsement at aipodcast.ing. And finally, I encourage you to take a moment to check out our new and improved show notes. Which were created automatically by Notion's AI Meeting Notes. AI Meeting Notes captures every detail and breaks down complex concepts so no idea gets lost. And because AI Meeting Notes lives right in Notion, everything you capture, whether that's meetings, podcasts, interviews, or conversations, lives exactly where you plan, build, and get things done.

No switching, no slowdown.

Check out Notion's AI Meeting Notes if you want perfect notes, that write themselves. And head to the link in our show notes to try Notion's AI meeting notes free for 30 days.