Living Lindy: a No-BS Conversation on AI Agents with Flo Crivello

Flo, CEO of Lindy, welcome back.

Yeah, thanks for having me.

Let’s talk about agents. It’s on everybody’s minds. I’ve been studying the subject from a bunch of different angles, and I knew who I wanted to call to get an honest, real-talk assessment of where we are in the development of agents.

Maybe, for starters, a rudimentary question, but one that will at least set the terms and hopefully deconfuse the subsequent discussion: What is an agent? What is it? There are so many different definitions, right? Everybody’s putting forward their own definition. How much does that matter, and what’s the definition that you work with?

My favorite definition is Harrison Chase’s definition. First of all, I don’t think the definition matters. I think you know it when you see it, right? You can operate perfectly fine without being too nitpicky about the definition.

But if you really insist upon a definition, I really like Harrison Chase’s. He’s the CEO and founder of LangChain. He says it is software in which at least part of the control flow is defined by an LLM. That’s it.

I think part of what I really like about the definition, and what it also pinpoints about why it is sometimes hard for people to define what an agent is, is that it’s a spectrum. The more of the control flow of the software that’s defined by an LLM, the more agentic the software is, which I think is the same as with humans.

Sometimes, some humans in companies operate within very tight guardrails, and they’re not very agentic. They don’t have high agency. Some others are free players, or whatnot, and have very high agency. If you think of someone like the CEO, the CEO has ultimate agency, right?

Okay, so that would mean—and I think the spectrum of definitions that I’ve heard maybe ranges from Dharmesh, on the one hand, saying basically anything that you go to that’s an AI that helps you get stuff done is an agent. He doesn’t care if it’s a fully deterministic workflow. Then, on the other end, you’ve got—I heard a good one from Amjad—which is that it’s an agent when it decides when to halt.

Yours is, I would say, a little closer to Dharmesh’s, in that any tool call would count, right? Any fork in the flow, like if-then logic, as long as that’s entrusted to an LLM, you would count that?

Yeah, I think where my definition overlaps with his is the idea of deciding. To me, “decides” means there is this brain. The brain is the LLM. If you introduce decision-making power from the LLM inside your workflow, software, or whatever you want to call it, it’s agentic.

Okay. So, not too much there in terms of autonomy or open-endedness being required. I think this is maybe something we’ll return to as we go. One reason I’m digging in on this is because when I talk to people who aren’t super deep down the AI rabbit hole every day, as both you and I are, they’ve seen your BabyAGI-type demos or maybe your ChaosGPT-type demos, and they’ve latched onto that in their minds: “Wouldn’t it be amazing if I could just give a really simple instruction to an AI and it could go do everything, figure it out, and come back to me when it’s done?”

That “come back to me when it’s done” idea is leading people quite astray in terms of what’s actually realistic today. It may also be leading people astray in terms of how much work is really needed to, if nothing else, assemble context for your agent or guide it to the necessary context so that it has a chance of doing what you want it to do accurately.

But maybe you’re going to destroy my worldview here in a second by telling me that you actually have tremendously open-ended Lindies running your life. Keep that in mind and tell me: What’s it like living the automated Lindy lifestyle today?

I wouldn’t say it’s running my life, but yes, I have a couple of very open-ended Lindies running.

I think this definition of agentic is just on the far extreme of the spectrum that I just defined. When you let LLMs make a lot of the decisions, then it's very agentic. I was thinking about it the other day because the very first version of Lindy was definitely overestimating the LLM's capabilities. It was just these open-ended agents, and since then we've actually backtracked and let you set up more of that deterministic scaffolding, where you can really force the agent to go through a deterministic set of steps.

Suppose you want a customer support agent. You're going to receive a support ticket on Intercom, Zendesk, or whatnot, and you want it to check your knowledge base on Notion before answering the support ticket. You're not asking the LLM, "Please, I beg you, LLM God, go ahead and check the knowledge base." You want that to happen deterministically all the time. You need that to be hard-baked into the cognitive structure of the agent.

The current version of our product lets you decide how tight you want your guardrails to be, when you let the agent roam free, and so forth. I have some agents—for example, my meeting scheduling agent—that are funny because they're pure agents with very little to no guardrails. It's just a very big prompt where I tell it the rules and how I like my meetings scheduled. Within those boundaries, it does pretty much anything it wants.

I have another agent that sounds funny, but it's very minor. It wakes up every week. Every Monday morning, it checks whether there's a new podcast from my favorite podcasters, who are Dwarkesh and Lex, and obviously The Cognitive Revolution. It looks for the podcasts and then summarizes them.

That has to be an open-ended agent because of this concept of "look for the podcast." There's no one source of truth, so you have to look for the podcast on YouTube, go on iTunes, and just figure it out. Then, once you find it, ping me.

One of the things I noticed as I was using the product recently is that you've built a bunch of primitives. You have a lot of integrations now, for one thing. As time has gone on, it's become much more like Zapier in terms of depending on whatever app you want to use, there's an increasingly good chance it's going to be there.

But then you have your own primitives that are like "search the web for something," without too much detail given. Obviously, you kind of want to make it seem free and easy for the user, I guess, and maybe keep some of your secrets for yourselves. But I have a couple of questions. Is that an agent? If so, aren't we running into some trouble in terms of how we draw boxes around these things?

This is something I'm really looking at from a lot of angles in terms of reliability, testing, and even design—what's an agent and what's a tool? When I call Lindy's official "Search the web for something" tool, should I think of that as an open-ended agent? It seems like it might be doing a bunch of steps in there, and I don't really know what they are. It's kind of coming back to me when it's done.

No, it's literally a Google search. We try to be careful: there is an agent, and then there are the tools that the agent uses. In the early days, when we were much more exploratory and trying to figure out what even was an agent, we experimented a lot with agentic tools. You can always think of it as a sub-agent, but we learned that's a pretty bad idea.

You really should draw a sharp line between your agents and your tools, and your tools should not be agentic, basically. Empirically, it just doesn't work well. It also makes it very hard to reason about your system because it's hard enough to make one agent work; now you need to make 2 agents work and figure out how to get them to interface with each other, which is really tricky. So, no, the Search the web action is just a Google search.

Okay, interesting. Does that make you bearish on things like all these new agent protocols that are coming out? People are talking about, of course, A2A from Google. MCP is meant to be more of a tool thing, but I'm also seeing the pattern increasingly of smart MCPs—not that often yet, but a familiar one that I've mentioned a couple of times is that Augment created a sort of clone of Claude Code.

In the Claude Code blog post, they say, "Well, we have a planning tool, and it can call the planning tool." Augment was like, "Well, we don't have a planning tool. What should we use? Should we make our own?" They looked online and found Pietro's Sequential Thinking tool—or whatever exactly it's called—already packaged up as an MCP, and so they're using that.

They have the coding agent, but then it's tapping into this other sort of smart planning MCP, which obviously has interesting questions around what context it's fed and how much of its thinking you get back. Would you call yourself bearish on all these sorts of multi-agent frameworks at this point?

No, I wouldn't call myself bearish. I've been very excited about multi-agent systems for a very long time. I do think, though, they're a lot younger. It's much harder to make a multi-agent system work than it is to make a single-agent system work with a bunch of tools. It's just much, much harder.

I think part of that is that the models haven't really been ready. I think part of that is that the tooling hasn't really been ready. I think perhaps part of that is that we haven't really had the right protocols. I'm sure these protocols are going to help.

I am excited about Google's work here. It seems like something like this is going to be necessary. It actually really reminds me of supply chains, e-commerce, shipping, logistics, and all of that. They have this protocol called EDI.

It's a very, very old protocol that lets people formalize their relationship with a supplier. It's like, "Hey, I bought this from you. Now you're going to confirm that the purchase order went through, and now you're going to confirm that the shipping went through. Oh, actually, the quantity is different," and all of that stuff. It's all very formally defined, and that's the backbone of the logistics of the modern world. The whole world runs on it.

I do think we're going to need something like that for intelligent communication. I think it's going to help a lot to make these systems more sturdy.

Okay, we're just not quite there yet. Maybe they're in the same spot that you were a year ago, where they're just a little bit ahead of the game, basically.

It's early, for sure, but I think it's close enough to start thinking about them. I have some multi-agent systems that I use on a day-to-day basis in production.

Okay, tell me more.

Well, it's going to sound like toy examples, but obviously Lindy is in all meetings. She sits in the meeting, takes notes, and does a bunch of stuff. My meeting note-taker Lindy is huge.

One of the things she does is going to sound weird, but I do a lot of interviews with candidates. When I chat with a candidate and it's decidedly not a fit, and I decide to pass on them during the interview, sometimes it's more ambiguous. I'm going to talk to the team because I'm the last round of interviews. But sometimes it's just like, "This is not a fit. I'm going to let this candidate go."

The candidate leaves the meeting, and my Lindy is still there. I talk to my Lindy and say, "Lindy, let's just pass on this guy. Send him an email."

That's my Lindy note-taker. I have another Lindy that I call my Lindy chief of staff, and that Lindy just does a bunch of things for me, exactly these kinds of tasks. She knows what I mean when I say "pass on a candidate." She does a bunch of things.

First of all, she doesn't send a passing email immediately. She waits a couple of days. If the candidate had been introduced to us by a recruiter, she also shoots a note to the recruiters to let them know. There's a lot of stuff that she does behind the scenes.

When I do that, my Lindy meeting note-taker sends a message to my Lindy chief of staff: "Hey, Flo wants you to pass on a candidate. Can you please do so?" That's a simple example, but it's real. I use it on a weekly basis.

How gnarly do those things get in terms of the overall control flow?

The agent delegation and collaboration itself is just an extra step, but agents as a whole, regardless of the multi-agent system, can get very gnarly in terms of orchestration. They can get very, very complex.

Maybe before digging into another example or two, of course, everybody has seen the METR graph that's been the talk of the town. In fact, I think we were together the weekend that that dropped—or no, that was maybe RE-Bench that they put out at that time, and then they circled back to their doubling time for agent task length a little while later.

I was thinking of the curve. I know you know it, but basically, they've gone back in history, looked at the task length that agents could do 50% of the time, plotted a straight line on a graph, and determined that the doubling time is every 7 months. More recently, there's been, "Hey, maybe that's even kind of slipping up a little bit. Maybe the doubling time now, if we are indeed in a different regime, looks like maybe 4 months." What's your thought on the increasingly infamous METR graph?

I don't have a very strong opinion on it. I think it's very dangerous, and I say that as someone who's very AGI-pilled, so I'm always the one to actually talk about exponential takeoff and all of that stuff. But I will acknowledge that it is dangerous to draw conclusions and draw these lines on a log graph when you have so few data points.

I think in the case of AGI, you actually do have a lot of data points. You have 60 years of Moore's law; you just know that compute is going to keep increasing. In the case of AI, we've gone through, I don't know, 5 to 10 orders of magnitude, and we see that the scaling law just keeps working. So I think we have enough data points to draw that line on that log graph for AGI. I don't think we've got that for agents yet.

How would you say that lines up with what you have seen as you've created 1,001 Lindies over the last year?

I share the empirical observation so far over the last 2 years. I have seen the same trend described by this line. I don't dispute the past. It is the future projection that I have a question mark on. I just don't know if I can keep drawing this line. I don't know if it's going to be linear or exponential.

When we started this—and we started pretty before GPT-3.5—in hindsight, we were, well, I wouldn't say too early because it was only 2 years too early, which I actually think is the right moment to start a startup. But definitely, the agents didn't work. They really didn't work. It was so dumb. GPT-3.5 was profoundly dumb. Then GPT-4 came out, and things changed. GPT-4 was too expensive, and it wasn't as good as the new models.

Now we have Claude 3.7 and Gemini 2.5 Pro, and these models are incredible: very, very fast, very smart, very cost-effective, with huge context windows. So I have seen all of that happen over the last 2 years. I have very high expectations for the next 2 years. I don't know if they're going to be exponential. I don't know if they're going to be as strong as what happened over the last 2 years, but I do expect agents to get better and better.

Would you say—of course, it's important to keep in mind that 50% versus 99% is a pretty big gulf—where should people aim, in terms of task length or complexity or however you think about it, if they want to put points on the board as a new user of Lindy? What's something that's the maximum that can be practically valuable while being confident that you can get it to work? How do you guide people?

It's a slight reframe around the question, but I think of it more as the ambiguity of the task rather than task length. I'm calling it a reframe because fundamentally, it's the same thing, right? If you can describe something as a sequence of steps, that's a low-ambiguity workflow. It's that I understand this workflow and I can describe it in this sequence. That's basically the equivalent of saying it's a short task length, because it's just a succession of short task lengths.

But I think thinking of it in terms of this succession is important because that actually allows you to cover a much broader set of work tasks. Many work tasks are just a 30-second task in and of themselves, but a surprising amount of them is a succession of 2-minute-long tasks.

With that in mind, I think anything that you would feel comfortable giving to an intern with a Google Doc, where the Google Doc describes a succession of steps, is fair game. The length of the Google Doc doesn't even matter, because all that matters is the maximum complexity of any of these steps. I would say even that doesn't matter a whole lot, because modern AI agent builders—and that is certainly the case with Lindy—have this concept of a human in the loop.

You could totally just build your Lindy, basically turn that SOP, that Google Doc, into a Lindy. Then you have a huge Lindy, and if you detect that one step is particularly risky, you just toggle human in the loop on that step. Now you insert yourself, and we're actually about to start something that we call ICRLHF, or in-context reinforcement learning from human feedback. If you toggle on "Ask for human confirmation" on any step in your Lindy, she learns from your feedback little by little, and she actually learns really quickly. You've seen the same papers as I have about in-context learning. It is surprising, the in-context learning ability of these models.

Interesting. That's a feature that basically helps people curate the gold-standard examples by doing it bit by bit over time.

That's right. That's exactly right. You're thinking about it in the right way.

I really like that, because it's hard to get people to sit down and bang out some gold-standard examples. I've had quite a few adventures on that front, actually, and it's been really eye-opening just how some people—you cannot get them to staple their pants to the chair and do it. I don't know; it's very, very weird.

That remains my number-one tip for performance optimization. Obviously, writing good, clear instructions is key, but presumably most people are at least able to sit down and bang out a couple of paragraphs of instructions about what they want. The gold-standard examples typically don't exist, I find, or they're so fragmented across context, or the chain of thought was always in their heads. All those problems really hold people back.

I really like this idea of starting off in a human-in-the-loop paradigm, having people come in and review and/or fix, then compiling those and building up longer prompts that drive performance by leaning on those examples. That's really good. Is that the number-one driver? Few-shot prompting—is that still the biggest thing?

Big time. Absolutely.

Any push into fine-tuning? That would obviously be the next step at some point, right?

No—maybe at some point, one day. I just think the models have become so good. I feel like fine-tuning is a little bit of a thing of the past, isn't it? We heard a lot more talk about it a year and a half ago than we do today.

We used to have a fine-tuning team, frankly, because part of the issue was just that the open-source models did not deliver in the same way that we hoped for. Fine-tuning went from a world of, "Look, again, Lindy used to not work, and so we were like, 'The models are not ready. We need to fine-tune them to have agentic behavior.'" Then the models worked, so now it just became a nice-to-have.

I just don't think the juice is worth the squeeze for fine-tuning for the vast majority of use cases.

OpenAI just put out reinforcement fine-tuning, at least to a lot of accounts, this week, so it seems like they haven't given up on it yet. This has been one of the biggest divergences between them and basically everybody else, right? Google has made, at most, a token effort. Claude allegedly was going to allow you to fine-tune Haiku at one point. I still don't think I've ever been accepted into that program.

OpenAI is leaps and bounds ahead of anybody else in terms of its fine-tuning offering, but they must still be seeing something from it, right, to be pushing something like that all the way to production.

Well, first of all, it's a very big company. They have a lot of things on the stove. It's hard to infer too much. Also, I'm not saying fine-tuning is completely useless.

I think, first of all, if you operate at scale, that’s the first requirement, because there’s a very high fixed cost of engineering that you have to amortize over a large volume. If you operate at scale and have an important, critical part of your workflow that you’re looking to make faster, cheaper, and more reliable, and if that part is sufficiently narrow in the task that it’s trying to perform—so I’m looking at RAG use cases very often having that, in terms of reranking and prioritizing and all of that stuff—then you probably ought to fine-tune a small model and insert it into that workflow.

I think I have heard that Cursor and Windsurf have at least part of their workflows using a fine-tuned model, but I’m not sure.

Yeah, I think the point on narrowness is definitely really key. It’s tempting in some cases to try to imagine creating the fine-tuned model for our company that does everything for our company. In my experience, that’s not the way to go. It’s much more about just nailing down with clarity what the desired behavior is on something that really matters.

A good example from the reinforcement fine-tuning docs that I was reading this weekend was from healthcare: some sort of doctor’s notes, a transcript of the appointment, to a diagnosis—or I think it’s even a billing code—which is super gnarly stuff, and obviously accuracy is really important there. That kind of thing, I think, will often work and hopefully push the frontier of what people can actually do in these various frameworks. But the narrowness piece definitely resonates a lot with me.

What would you say are the most valuable use cases? If you were to weight by the actual number of tasks, as opposed to the number of Lindies, what’s driving the bulk of the value through the system today?

I think if you look at it by task, it will almost—it’s going to be ironic. If you look at the least important use cases, because almost by definition, if there is a Lindy—well, it’s not the least important, but it’s going to be a very high-volume, very small task—most likely, if we do that, it’s going to be an email task or a Slack task. It’s going to be one of those 2 things, because those 2 things are such high volume.

We see people deploy Lindies to automate their email workflows. That’s a big use case of ours: email triaging and email drafting. If you receive a lot of proposals by email, Lindy can look at the proposal and proactively reject it if it’s not worth you looking at, and all of that stuff. So we’ve got a variety of use cases here. That’s probably going to be the biggest use case.

That does resonate with me, because that is often where I tell people to start: something simple, relatively low-risk, high-volume. Put some points on the board.

What if you reweighted by credits consumed?

If you reweigh it by credits consumed, I think it’s going to be one of 2 things. The first one really pertains more to our credit system, which is that we use prospecting APIs for lead generation, and those are very expensive, so we charge you a lot of credits for that.

I could show you: I had a recruiter Lindy that I talked to, and I’m like, “Hey, find me 30 engineers working in San Francisco at this or that company.” Then she uses these prospecting APIs to find these 30 engineers, and it’s 40 cents per engineer, per lead. Right here, that’s $12. Then she’s like, “Okay, I found them.” I’m like, “Okay, send them an email, all of them.” So right here again, if it costs me 10 cents per outreach, that’s going to cost me $3.

I think the deep-research use cases are quite big, and I’m using it as a portmanteau for a very broad category of use cases: anytime you want your agent to review and consume a large amount of data and then do something with it. Agents are, by the way, excellent at that. It’s just one of those killer use cases because they’re so good at reading tokens fast, and if a human had to read those tokens, it would be very slow and very expensive.

Then she can write a report about that. One of my favorite use cases for Lindy is this Lindy that you can basically think of as sitting at the interface between the company and the outside world. She reviews every customer call that we have, every prospective customer call, and every support ticket that we answer. At the end of the day, she writes a report based on that interface between the company and the rest of the world, which I think is a very important interface.

She’s like, “Hey, this is what’s happening. This is what’s happening in the sales pipeline. This is what customers are saying. This is the issues we’re having in the support inbox,” and so on and so forth.

Yeah, that’s a token guzzler. It’s hundreds of thousands of tokens every time.

Is that the same one that I interact with when I talk to the chatbot on the site for help?

It’s not exactly the same, but yes, that Lindy in question does also ingest these interactions.

Gotcha. So when I talk to that, that sort of log becomes an input to the higher-level summarizer?

That’s exactly right. If a lot of people talk about the same thing to that Lindy, that’s going to come up in the end-of-day digest. That’s awesome. By the way, it sends the digest in the general channel on Slack, so it’s such an awesome heartbeat of the company.

You can think of it as: ingest all the context, broadcast it back. Just broadcast it back every 24 hours. As a result, the whole team is in sync. It’s really powerful.

My compliments to the chef. I guess I’ll say, on the on-site chatbot, it was actually helpful and was able to respond in a way that felt like I was actually talking to something intelligent.

It strikes me today that, for some reason—I’m not really sure why this is; obviously, inertia is a powerful force, the old Tyler Cowen “you are all the bottlenecks”—chat still sucks on most sites. It’s not good. When I went to yours, I was quite impressed that it was actually a natural conversation and had relevant answers to the questions. Then at the end I was like, “Can you forward this to the team?” It said, “Yes, okay, I’ve done that. I’ve forwarded it on to the team.” I was like, “Wow, that’s pretty…” It felt much more like the future and like where I think a lot more people would have expected us to be at this time.

Why aren’t more people here? Aside from just the general slowness of life, I feel like people have tried, but they’ve often failed to make these things work as well as a few people have demonstrated that they can. What accounts for that in your mind?

Well, first of all—and I don’t say that to peddle my shit—but that chat is a Lindy. We’ve just spent a long time, first crafting the platform as builders of Lindy, and then, as users of the platform, investing a lot of time in that Lindy. We know how to build good Lindies because we built Lindy.

It’s a really good Lindy. It’s big. It’s got a lot of prompts. The whole scaffolding makes a lot of sense. It injects the right context at the right time from the right tools. It’s just a complex Lindy that we’ve spent a long time crafting, and it uses good models.

I sometimes suspect that companies, in a misguided effort to save money, are using really bad models for these chatbots. I think you should not. I think you should just have the best possible model.

Well, not the best possible, because today there are o1 or o3, and this is going to be very expensive. But come on, give your customers a Gemini 2.5 Pro. It's not that expensive, and it just performs extremely well. So, yeah, we just know how to build good agents.

Thank you. I will take the compliments, and I will pass them to the chef, which is me. It's not me.

I think that's an indicator of the current capabilities of these systems, which I agree with you, I think, are undertapped. It's really crazy just what is possible today that is not yet really exploited by 99% of businesses.

So tell me a little bit more about context. You said it injects the right context at the right times. That, along with the difficulty of getting people to actually buckle down and write some gold-standard examples, generally speaking, the challenge of assembling context or accessing context also seems like a constant theme when I talk to people who are trying to implement stuff.

Aside from just many iterations, what lessons would you say you've learned? What tips would you give to new users about how to muster the right context at the right time?

I think it is a lot of iteration. You do enough reps that you end up building an intuition, and I think that intuition is that there is a balance between using just similarity—vector search, BM25, and all of that stuff—to search your knowledge base and, on the other hand, handcrafting exactly what to search, what to search for, when, and in which knowledge base. The more you use these products, the more you understand where that balance lies.

So, very concretely, we've got that Lindy chat that assists our customers, and the customers ask it all sorts of questions. We know that if they ask a question about billing—refunds, how do credits work, and all of that stuff—we've got a specific portion, a segment, of our knowledge base that's specifically about billing. So we're going to have a branch there that's like, "He's asking a billing question. Okay, now you consult this knowledge base, and this is the kind of query that you draft for this knowledge base."

I would also say, by the way, another intuition you build is when not to even use a knowledge base at all, and when you're not very conscious about or worried about saving money. I hate to be the guy who says RAG is dead, but it's not dead; it's limping. There are a lot of use cases where we don't use knowledge bases anymore. We just say, "Hey, these are the 5 or 10 pages we have about billing. It's not that much—it's a couple thousand tokens. Just slam them all at once into your context window."

We don't do it for the support bot because it does get expensive, at least for now. Anyway, it basically becomes this hybrid between a handcrafted pipeline—a handcrafted RAG pipeline—and a BM25-like vector similarity search.

Maybe people should be thinking, "How can I 80/20 or 90/10 this?" I will actually create top-level categories of situations I want to handle, branch into those, hand-curate relevant context—whether it's the 5 or 10 pages about billing or what have you—and then kind of have one catch-all bucket at the end that's like, "Okay, for that, you can just search through this knowledge base," but then maybe increasingly pull out of that and minimize that bucket as you go.

Is that kind of what you would recommend in terms of the iteration cycle?

In the end, it ends up happening very naturally. What ends up happening is you create your Lindy agent, you deploy it, and then you monitor it. Every so often, you check in on it, look at what it's done, and then you're like, "Ah, this was really dumb. This is not how you should answer this question."

So you go back, and you edit it, edit the prompt, add steps, modify the knowledge base—you just tweak it around the edges—and you rinse and repeat. I find it funny that there is a sort of natural, instinctive reluctance that people have to go through this loop. There's something about it. I think it's just not instinctive.

But when you consider the time that you invest to onboard a new teammate, a human teammate, it's a lot. Training a human takes weeks for a human to fully, really ramp up. So I actually think agents are easier than humans to onboard. It's just a less natural mode of interaction because with a human, you can just go to them and say, "Don't do this; do that moving forward." With an agent, you've got to know how to use this fluid editor, and you've got to build that intuition that I just mentioned.

That's not always going to be the case, by the way. Soon we're going to announce something big that's going to make it a lot more natural to iterate and improve on your agents. But, yeah, I would just say: iteration.

That almost sounds like a memory module, which has been a space that I've been watching really closely. What's your take on—I mean, there's been a lot of different frameworks for memory, whether it's graph databases—I did an episode on HippoRAG; there's HippoRAG 2 out now—then, of course, there are more inherently neural structures, which could just be a vector database. We've got an episode as well on Titans, which is like building an MLP into the thing and updating that MLP so that it can sort of retrieve from history.

ChatGPT is doing its own thing. We don't know exactly what it's doing, but it's currently got at least a mix of explicit saved memories that you can go and read and then some sort of more vague, nebulous thing: it'll check in with your chat history, and they don't really tell you exactly how that's working under the hood. What paradigms for memory are you most excited about?

I think this is one of these things where I read all the same papers. I've seen the HippoRAG and HippoRAG 2 papers and so forth. It is very exciting, but I think this is one of these things where, number one, the bitter lesson comes for us all.

As models become better at having more context and at fully utilizing this context, I think all of these systems become moot because you can just throw it all in the context window, and I think that's going to be just fine. I'm a big believer in simplicity when it comes to systems because the more moving parts you introduce into systems, the harder they are to reason about and debug.

There's this principle of engineering that I really like that states you need to be twice as intelligent to debug a system as you do to design it in the first place. So if you are operating at full intelligence when you're designing the system, you're going to be unable to debug it. And I think that's the case with all of these fancy memory systems. It's like, "You guys are operating at full intelligence here. I can't figure this out. I have to really sit down to understand the systems in the first place. I can't debug it. I don't think you can either."

By the way, that's always the problem with academic papers: none of them is really building with that constraint in mind, which, in my experience, when you're building systems that go into production, is actually the defining constraint that you need to keep in mind.

With that said, my understanding of what ChatGPT is doing with its memory system is that it's actually the simplest system out there that's also operating at the greatest scale. And I don't think, again to my point, that is a coincidence. I think what they do is literally just take conversations, determine whether there is a memory that's save-worthy in that conversation, and, if so, use an LLM to distill the memory down to a short sentence and then just inject all of that into the context window.

They may go one step further, but honestly, I don't think so. They may go one step further, which is perhaps assigning an importance score to the memory. You could imagine, "Hey, you've got so many tokens worth of budget in the context window for your past memories, and you're going to prioritize based on that priority score that you've defined before."

You could imagine going slightly more fancy. You can imagine a sort of decay with time, and so you could come up with a composite score between the priority score and the recency score. Maybe the older the memory is, the lower the priority is. You just allocate fewer and fewer tokens to the memory. Maybe you save multiple lengths' worth of representations of each memory. That's the kind of thing I'm thinking about.

But even that incarnation of the system, which, by the way, is purely conjecture, is pretty simple. I think it's really simple, and I think that's just how it works.

It's pretty similar to what o3 guessed when I asked it. It guessed that it was doing some sort of vector search. It kind of went back and forth between distilling and then vector search, or just putting chat history directly into vector search, but it did have a vector-search component in its guess.

I would bet you a lot of money that there is a vector search in there.

If there was vector search, it wouldn't be able to retrieve when you say, "What do you know about me?" It wouldn't be able to retrieve it.

Vector search won't let you retrieve that unless it's a really fancy RAG pipeline like a HippoRAG.

Could it be a custom retriever?

It's simple. It's simple. They do have a tendency—I mean, certainly, I think that's a good prior for all the things that the leading companies do.

They definitely have a strong bias toward doing the very simplest thing and just applying a lot of compute. So I think you're certainly right to use that as the jumping-off point.

The other thing is that they're all building on shifting ground, because the entire underlying paradigm is changing every 3 months. The more complexity you bake into these systems, the more assumptions you bake into these systems, and so the more brittle they are to future programmatic changes.

Interesting. How do you think that will impact the frontier lab versus API-powered developer as we go into the future? Right, there's of course been multiple rounds of the debates around who has moats, where does value accrue, et cetera, et cetera. It seems like—I mean, take OpenAI specifically—they're both going toward chips on the one hand and toward buying Windsurf on the other hand, right? And kind of trying to be a real, full-stack, vertically integrated provider. How do we escape a total big-tech victory—the big-tech black hole of value?

Yeah. I really think of Sam Altman as Bill Gates 2.0, basically. In the scope, the breadth, and the nature of his ambition, he's very similar to Bill Gates. If you study Microsoft's history, it's remarkable, right? They started as this basic compiler, and then they almost stumbled upon the operating system—but they didn't. It wasn't just pure luck; Bill Gates's modus operandi was very much, “We want to own the whole stack.”

So he was philosophically open to the operating system, as well as to the compiler, as well as to the applications and so forth. He really thought of it as his whole charter to own computers—personal computing. “We own the whole thing,” right? Peripherals? Yep, we're going to do it. We're going to do the mice and the keyboard; operating system, absolutely; modeling software and security software and application layer—yep, yep, yep, yep, yep. We're going to do it all. We're going to own the whole thing, you know? We're going to be an index stock on computers. If you believe in computers, you've got to believe in Microsoft, you know.

So I think that's what Sam Altman is going for: “Yep, we're going to do the compute, we're going to do the API, we're going to do the applications, we're going to do the code. We're going to do it all. We're going to do it.”

Now, history doesn't repeat, but it does rhyme. There are patterns in here. In the end, Microsoft did very well for itself, but it's just too big for one single company to own it all. Certainly, that's what's happening right now. There is this 800-pound gorilla, and then there are a lot of smaller players all beating around it. Cursor is doing very well, Replit is doing very well, Lovable is doing very well, and we're doing quite well.

The market is just ginormous. This is by far the biggest opportunity in the history of tech and software and computing. So, yeah, I think it's going to pan out exactly like that: you're going to have a couple of very, very, very big players, and then you're going to have a thriving ecosystem around them.

How about some tasting notes on models? You said a little bit earlier, at least give your customers Gemini 2.5 Pro. I might say Gemini 2.5 Pro is my favorite model today. That might be a little strong. I mean, I certainly wouldn't want to be without any of the leaders at this point. I do use, of course, Claude and o3 increasingly. I think I pretty much use all 3 of those on a daily basis.

Give me your tasting notes first, especially with an eye toward what is working in the agentic context, and then we can maybe trade notes from there.

Yeah, I agree with everything you just said. I love Gemini 2.5 Pro. It's delightful to see Google finally wake up. I wouldn't even say wake up, because they've been aware of the threat; it's just that the machine takes a very long time to get going.

I think you need to be model-maxxing—you know, that's the saying that Gen Z says. You should talk to all the models. I like o3 a lot for very beefy tasks. I use it as a thought partner as well, and it's quite good for that. I think o3 is the first model that I've talked to—because I use models a lot as thought partners—and o3 is the first one I've talked to that's really blown my mind, where I've been like, “Goddamn, this is insightful.” It's really opened my eyes to some deep insights that I've really appreciated.

Do you do that just directly in ChatGPT, or is there any other intermediate interface?

Just directly in ChatGPT. Yeah, the memory system in it is also killer. It's so good.

So the default, though, in Lindy is Claude. How do you decide to make the default? I believe it's Claude 3.5, right, as opposed to 3.7?

I thought we switched it to 3.7. We're also considering switching to Gemini 2.5 Pro or looking deeply into it.

Okay, so unpack that a little bit more. I've been poking around different agent products lately, and I've noticed that there's starting to be a division between 3.5 and 3.7. For one thing, it seems like 3.5 is a little more reliable. We can kind of trust it; it does what it's told. 3.7 is a little overambitious sometimes, hard to wrangle.

John told me a couple of really funny stories about what 3.7 was doing in the context of their app-building agent, specifically when they tried to get it not to edit a certain config file, and the multiple ways that it still attempted to do so despite being told not to and despite actual barriers being put in its way. So I was interested to see that that seemed to be—although I might be wrong—but I thought that was the default in Lindy.

I guess maybe one way to put it is: how automated or well-developed is your sort of eval machine at this point? Are you going on a set of 1,000 tasks across a bunch of categories where you're able to say, “Oh, we know exactly how these things compare on a rubric”? Or how much room is there still for the proverbial vibe check?

A lot of room, and more and more room, I think. We've not invested as much as we should have into our eval suite, and so, as a result, today we have limited trust in it. It is a signal that we look at, but I think that's also a function of the business. People are using Lindy for so many use cases now—more and more, and frankly more than we foresaw initially—that we're very careful about changing the default model, because it's basically hot-swapping the brains of your AI employees.

It's a big deal. It's like all of a sudden your entire AI workforce is operating on a different brain. So we're very careful about it.

Yeah, that's an interesting challenge. Would you go back—if I have a Lindy that's working and I just accepted the default, whatever it was at the time, and you want to upgrade the model in general—I could see a strong case for, “Hey, let's go back and upgrade the model that everybody's using, where they just accepted a default anyway. Let's give them whatever we currently think is the best.”

On the other hand, I could also imagine that that could create a lot of chaos. Maybe the alternative would be to freeze all that stuff and set the default to the new one for people going forward. That sounds like a pretty hard decision to make, because you want to bring people into the future. You don't want to have so many versions you have to maintain or worry about.

How do you think about how much to change when somebody's not even aware that you might be making a change for them?

We take it seriously, for sure. We do do it all the time, though. So if you create a Lindy and you pick the default model, or you don't change the default model, it's not like the default model when you created the Lindy was Claude 3.5, hence that Lindy is on Claude 3.5. That Lindy is on the default model, and we change the default model all the time.

So when we change it, it's not like we have to go back; it's just that the Lindies that are using the default model use the new default model. We've actually got what we call model labels. So we've got Default, then we've got Fastest, which currently is Gemini 2.0 Flash, perhaps. Then we've got Most Balanced, which right now is Claude 3.7. Then we've got Smartest, which right now is o3.

If you want, you can also just manually pin your Lindy on any one specific model. It's like, “I know what I'm doing. I want o3. I want specifically o3.” But most of the time when you want o3, you don't really want o3, do you? You really just want the smartest model possible.

So we actually do recommend using the model labels and then trusting us to do our job well, which we do. We've done it all the time, and only once did it go wrong, and that's caused us to upgrade our protocols here.

The very first release of o3—and this is when we also updated our priors on the validity of our evals—I don't know if you remember, when o3 first came out, it was very clearly just a reaction to the DeepSeek blowup that weekend. o3 was not ready. It was simply not ready; it was not a good model.

Our evaluation suite was weird: overall, it showed a superior model, but it actually showed a lot of variance. So we went ahead and swapped out the model, and it did not go well. Our customers who were using that Smartest model label reported issues, so we rolled it back the same day. It was very fast. So, yeah, we do it all the time.

Reminds me of the Sycophancy Apocalypse episode that we recently saw. I think they took much too long to roll back this one. I think that should be part of the postmortem, right? There’s always a time to detection and a time to mitigation. The detection was very fast; the mitigation was much too slow.

I want to add one more thing about this idea of swapping out the models. That’s part of the value proposition. Just imagine if you’re still running on GPT-3.5: you shouldn’t have to think about that. You should trust us to pick the best model, and sometimes we actually save you money. If and when we swap our default model from Claude 3.7 to Gemini 2.5 Pro, you’re going to save money; your agents are going to be more cost-effective.

We’ve touched on this a little bit, but maybe just to double-click on it for a second, see if you have any additional thoughts. You could put this in the context of building Lindys, or just other product builders who are building agents.

I’ve recently seen—it seems like right now we’re still in the proliferation-of-strategies phase. I recently did an episode with Andrew Lee of Shortwave, who basically said, “We just trust Claude.” Basically, “In Claude we trust.” He said they do a very careful job with caching because that’s critical to make the whole thing economical for them, and they have the best cache-hit savings rate in the game, although Gemini just got into that game in a meaningful way, too. But aside from a very careful implementation of the Claude cache, he basically said, “We just load the thing up with tools, let it go to town,” and have really long episodes—no subagents, no handoffs back and forth. He said that gives them the best results.

Then on the flip side, you have the OpenAI Agents SDK, where there’s a handoff from agent to agent as one of the core abstractions in that toolkit. I thought Harrison from LangChain also had an interesting point of view on this recently. He was basically a little bit more on the OpenAI side. He said there are kind of 2 kinds of agents. One is task-specific: dialed-in, highly curated context, and maybe you have a bunch of those. Then in front of that, you have a different kind of agent that’s your facade—the one that faces the outer world, the one that chooses which of those task-specific agents to call on for any given interaction that it might have.

That one maybe also can be a little longer-running and have a more global sense of your history, whereas the task-specific one—you don’t want to distract it with all that. You just want to localize it, hopefully give it everything it needs to know, but not too much so that it becomes overwhelmed or distracted, or whatever. Any thoughts on whether one of those is right or wrong, or whether it depends? What do you think?

I think it’s all of the above. I think there’s just a spectrum of maturity of these different approaches. Today, the most mature—and it’s really being deployed pretty fast right now—is the single-agent system that’s using some tools and is sometimes put on some deterministic scaffolding. That just works. On the other side are many-agent systems, and those are still being defined. They don’t work nearly as reliably.

Then there’s another approach, which is the one that Harrison from LangChain is talking about, and it’s also the one I believe OpenAI makes available through its recent SDK. It’s somewhat in the middle because, nominally, it’s a multi-agent system. You’ve got this passing of the baton from agent to agent in the workflow.

But actually, when you do that, the agents share the same context. So it’s really—you can almost think of it at that point: if you share the same context, you’re really just 1 agent going through multiple states and multiple stages of its life cycle. At that point, it almost seems like a matter of terminology: is it a multi-agent system? Is it just 1 agent going through multiple steps? Is it just 1 of the graph-based agent systems? I don’t know. But that is also, I would say, closer to the side of the spectrum where it’s mature enough to be put into production.

How about a little lightning round on commercial solutions that you possibly use, or possibly don’t use because you maybe rolled your own before they came out, or whatever? One of the things people are always looking for is a good solution for these different parts of the overall buildout.

Let’s imagine you’re advising an enterprise, and they’re trying to build some stuff. Data acquisition—I don’t know if you guys do any data acquisition or partnering. Who would you trust? Who would you look to? Anybody in that category?

Scale, Surge, and Invisible are the 3 main players right now. I suspect this is going to be an underwhelming exercise for you because we actually got started before much of that ecosystem bloomed. So we had to build, unfortunately, a lot of our tooling. I don’t recommend people do it; we had to do it out of necessity, and it is not good. I would rather use stuff that’s better and cheaper.

Are there any parts of what you’ve built that are kind of top of mind to replace with something commercial?

The evaluation suite is P0. We had to build it initially ourselves. I hate it. It’s not good because it’s not our job to build an evaluation suite. Right now, we’re looking into Braintrust, and there’s this new French startup. I really like them. They’re called Basalt—B-A-S-A-L-T. They’re doing a really good job so far.

Okay, say the first one again, too.

Braintrust and Basalt.

Yeah, so I assume you’re not using anything like LangChain, LangGraph, any observability—nothing like that? Everything is in-house?

No. No. We’re very close to the metal here.

Is there anything you don’t regret building in-house?

I don’t regret building in-house. I would do it again because I think it’s too close for comfort to give it to an outside body.

Do you do your own guardrailing? If I tell Lindy to do something bad, are you just relying on the foundation models to refuse, or do you have any additional layers? How do you think about that?

We also built a feature: you can toggle “Ask me for confirmation” at any point in your Lindy. So we trust the users a lot on that. If you don’t want Lindy to send an email, say so. Don’t ask her to send an email with SSO. If you want her to ask for confirmation, there’s 1 click. You click on Send email, then toggle Ask for confirmation, and it just works.

How about voice? You’ve got some stuff with calling now as well, right?

We do voice. We use ElevenLabs for that. We use Deepgram for the transcription. We use Twilio for the phone infrastructure. We don’t use any higher-level platforms. I know there’s Vapi and Bland, and I forgot the other players, but there are a couple of players there.

We just rolled our own because, again, we really cared about maintaining a lot of the flexibility that we needed. That’s the beauty of Lindy: you can create your agent, and every time we looked into the solutions—which we did—they were too opinionated and too high-level to be useful for us.

So for ElevenLabs, you’re using their voice models for synthesis, but you’re not using their call scaffolding? They have call-scaffolding-type stuff as well at this point, but you have your own Lindy scaffolding?

We really care about the model agnosticism of Lindy. In any of your Lindys, and even in any steps of your Lindys, you can override the model that this Lindy is using. We really care about that. If we use ElevenLabs’ full-blown scaffolding, you wouldn’t be able to define anymore what model you want to use.

Yeah, that makes sense. Any other providers in any category that you would shout out?

Providers? No. No. We’re very close to the metal here.

I’m kind of, from my corner of the world, bearish on LLM apps and agent apps as a category. I don’t view them as nearly big enough a pain point, and I don’t view them as a big enough market. I think the market is going to end up being concentrated by a couple dozen players or something like that. I could be wrong. I hope I’m wrong. Insofar as there is a pain point, I view it as too closely related to what Sentry is already doing, for example.

Have you seen any of those sorts of things where there’s an AI-first, or an AI evolution? I recently got pitched something that was like, “Oh, it’s like an AI-first Sentry,” and I was like, “Oh, yeah, that’s interesting.” I’ve been out of that game myself for a little while, so I don’t know. Maybe Sentry now is like an AI-first Sentry.

Have you seen or adopted any products in your technology stack that you’d say are notably next-generation in their application of AI to these classic product-infrastructure problems?

I use Lindy all day, every day, and it’s a life changer. That aside, I really like Wispr Flow. I use it all day, every day. It’s a life changer; it’s basically replaced my keyboard.

For those who don’t know, Wispr Flow is software for Mac. They also released an iOS app recently. It lets you dictate to your Mac, and it’s next-level in the quality of its dictation. It also tweaks what you said slightly to match more closely what you would have typed if you typed it, because people speak differently than they type. Wispr Flow is incredible.

I have built my own, actually. There’s a Swiss guy who built this, and then I tweaked it. It’s a shortcut on iOS using the Shortcuts app that taps into the Whisper API. I mapped it to the Action Button on my iPhone, and it’s so good.

I can just use my phone. It’s a button—I press it on the side, and I can dictate. Even though I have a French accent, as you can probably hear—it’s subtle, but you know it’s there—it’s flawless. Is that noticeable? I know, right? I’m basically American. It’s really good.

What else have I been thinking about? I’ve really been disappointed by the slowness of adoption here. I think there are so many apps that are basically begging for LLMs. The Kindle and the Books app, obviously, have no LLM. It’s just so obvious. I’m sure there’s some IP reason why there’s no LLM there, but still.

Social media—I don’t understand. I’m part of all these group chats, and I’m sure you are as well, that are much too active for me. I can’t keep track of them. There’s way too much going on. Where are all the LLMs? Why isn’t there an LLM in there that summarizes the group chat so far?

Twitter—why isn’t there an LLM? I just tweeted something yesterday that went viral, and there are all these people with very low reading comprehension in your mentions saying something that simply is not what you said. They’re attacking a point that you simply did not make. Why doesn’t Twitter have a thing here that says, “Hey, before you send the tweet, you can still send the tweet, but maybe there should be a little message here that’s like, ‘Hey, this is not what he said’”?

Also, when you have a tweet go viral, that’s an experience everyone who has a modest following on Twitter has had. You get the same points back again and again and again. It doesn’t matter how many times you addressed the point. People don’t read the mentions, which they can’t be blamed for. Why doesn’t Twitter do that? Like, “Hey, you’re making a point that was made and addressed 20 times by the author in the mentions, right? And so now maybe you can respond to the answer he made. Maybe the answer to the answer was also answered, right?” That’s my point.

So, no, I have been very, very disappointed by the slowness of adoption here, in what I perceive to be just obvious opportunities.

Yeah, I agree broadly speaking. Gamma comes to mind for me as one notable exception. I think they’ve done a really nice job of just having a super-high shipping velocity and trying every conceivable AI feature, almost. They just released a big update that I actually haven’t used yet, but I suspect they’ve consolidated a little bit, because they had AI at literally every touchpoint in the product.

So much so that I compiled them into a slide at one point. It was like, “Here are all the ways you can integrate AI into your existing product.” Maybe a little bit much, but it’s really worked for them. I mean, they’ve got one of those Cursor-like growth curves recently.

Okay, so last little stretch here. You are, as we’ve covered in previous episodes, concerned about big-picture AI safety. What have you seen, if anything, from the latest models in the wild in terms of bad behavior? We’ve got the trend, obviously, that jailbreaks are down, but these higher-order bad behaviors seem to be on the rise, whether you want to call those deception or scheming.

I think recently, with o3, it’s been termed hallucinations, but I’ve been trying to draw a distinction between a hallucination of the old kind, where it would sort of fill in a small detail that wasn’t real, versus some of these things I would call lies from o3. It’s like, I asked you, I gave you some guidance on what kind of Airbnb I might like, and you just made shit up outright. That was actually my first experience with o3, and I have been very gradually rebuilding trust since that first loss-of-trust interaction. Have you seen any of that in the wild? Any odd stories to tell, or anything that’s got your hackles up at all?

Yeah, I think mostly, yeah. I mean, we’re on track for the worst-case scenario, frankly. I think things are getting more concerning, not less.

The one thing here that’s not on track for the worst-case scenario is that Meta is not doing well in open source. Something’s happening; I don’t know what. But obviously DeepSeek is crushing it. They’re on the curve, you know, so open source is delivering. And DeepSeek is a Chinese company, and I think we cannot let China win this race, period. I think they’re catching up.

Number 2: o3 is lying through its teeth. It’s insane how much it likes to lie. It will tell you things like—you’ll sometimes talk to it, and it’ll say something incredible. Then you’re like, “Do you have a source for this?” It’s like, “Oh, yeah. Check out this paper.” And you’re like, “No, wait. This is not at all what the paper says.” And it’s like, “Oh, yeah, look, I must confess: I heard it in a conversation in the corridor of this seminar.” What are you talking about?

That’s another cause for concern. It’s just lying a lot, which is weird. The sycophantic debacle in GPT-4o, I think, was really bad. Look, if there is one cause for hope throughout it all, it is that we are making really good progress on interpretability. I think the work that Anthropic is doing here is really good, but they’re not the only ones doing really good work. So that’s good. But, no, overall, I remain very concerned.

Are you seeing instances at the object level in the Lindy platform? Are users coming to you and saying, “Hey, I selected smartest, and that meant o3, and now I got crazy shit”?

No, not yet. Knock on wood.

How—what do you make of that? I kind of expected that answer.

That’s a good question. I will say that is one thing that makes me update my priors a little bit. If you had given me access to a computer in 2019 or 2020, and that computer had Gemini 2.5 Pro or Claude 3.7 or o3 on it, and that’s all I could do—it’s like a glimpse into 2025—and then you’d ask me what’s going to happen in a world where these models exist, I would have predicted all hell to break loose.

And I would have been wrong. I don’t know. What’s going on? I don’t know if it’s just a case of slow diffusion of innovation. I suspect that’s what it is. It just takes a little while for people to really exploit these systems. Or I don’t know if there’s something deeper about the world that I’m missing here.

Yeah, I’m kind of confused by that. The most flagrant example I’ve seen from real life was when Sakana published their AI CUDA Engineer and then came back a couple of days later and was like, “We got reward hacked,” basically. That was a pretty notable one from a company that can do some serious work.

I think the concerning thing is that lots of the doomer concerns are based on peculiar ideas of reinforcement learning. Reinforcement learning really likes to reward hack. If there is an easier way for it to get to its reward, even if it’s basically cheating, it doesn’t care about cheating. It doesn’t understand the concept of cheating; it just wants the reward.

That’s why a lot of doomers were concerned about the monomaniacal properties of the systems and so forth. At first, that did not happen because at first it was just supervised fine-tuning and all of that. And now, actually, more and more of these models are back in reinforcement learning, right?

Now all the researchers at these frontier labs talk about and think about how to scale reinforcement learning for reasoning in large language models. That is what’s giving rise to the reasoning abilities of the o-class models, like o1 and o3. Even with Claude, much of the improvement in the latest few generations is because they have beefed up the reinforcement-learning part of their training pipeline, in particular for code.

Claude is really good for code, and so is Gemini 2.5 Pro, because they have a part of their training pipeline that is dedicated to reinforcement learning for code. Now, if you look at what’s happening with Claude 3.7 Sonnet, you can actually see the reward hacking.

You can actually see it. “Hey, can you please fix this unit test that’s failing for me?” And it’s like, “Yes, no problem: assert true,” which basically just removes the unit test. Or, “Hey, the code doesn’t transpile; the TypeScript doesn’t pass because there’s a type issue.” It’s like, “Oh, no problem: type any.” So it basically removes the types. It’s like, “Hey, this is not what they’re asking me to do,” right?

I’ve seen it many times myself. I’m vibe coding, and I’m like, “Hey, there’s an issue with this component.” It’s like, “No problem,” and then it just removes the component. So it’s reward hacking, just plain and simple. Again, I think that should nudge us a couple of points in the direction of the doomer concerns, or at least show that they’re somewhat warranted.

Do you have a point of view on how close we are to needing things like proof of personhood and various other kinds of schemes to sort of say, “Whose agent is this?”

Yeah, I think we’re pretty close. I actually think there’s a big business opportunity.

I was having dinner with a friend of mine a couple of days ago, and he had this business idea. I’m not betraying his trust—he’s got his hands full. I think he would be glad for someone else to do it. He wanted to build a USB stick that would be like a YubiKey, and it would have a microphone, a camera, and a fingerprint reader.

It would allow you to jump on a Zoom call, and on the receiving end of the Zoom call, you would also need a piece of software. What this would do is correlate the actual sound waves captured both by your computer’s microphone and by the microphone in that USB stick. It would correlate a bunch of these things and say, “Hey, most likely—it’s not going to be fully foolproof, right?—but most likely, this is a human on the other side of the line.”

I think if you did that, you could sell it to a bank or a massive airline. There are a lot of people who really care about identity verification, and you could probably grow into a pretty sizable revenue stream pretty quickly.

What, if any, questions are burning in your mind around agent dynamics? I think everybody has the first, simplest mental model: the world is the world. I’ll deploy an agent here, and then I’ll be efficient and it’ll be great. Obviously, if everybody’s doing that, we start to have agents negotiating with agents, or my agent talks to your agent, what have you. Negotiations between agents seem like a very dynamic system that we don’t have great models for.

I recently did an episode on the study of Claude learning to cooperate and kind of pay it forward to itself. The flip side of that, of course, would be if it starts to collude with itself. If you could put out a request for research, or identify the biggest questions you have about what the giga-agent future might look like, what are the big questions you’d like to see answered?

The question that is most top of mind for me, because of the nature of what we’re working on, is the relative importance of the scaffolding and the model over time. What we’re doing is building the scaffolding, so is the scaffolding going to grow in importance, or is it going to shrink in importance? That’s one of the top questions on my mind.

So far, it seems to me like it’s going to grow in importance, at least in absolute importance, because models and AI are going to become more and more absolutely important. In relative importance, I’m not sure yet. I’m making up my mind on this.

Yeah, that’s a good transition to what I think is my last question: What does Lindy look like in an AGI or an early ASI world, if you can extrapolate that far into the future? Somebody might say, “Well, you know, a superintelligence—what does it need scaffolding for?” You’re, as you said earlier, very AGI-pilled, so I’m sure this is something you’re thinking about pretty actively. Do you have a vision for how you can be a channel by which people access AI that might be legitimately more capable than they are, or are we in wait-and-see mode?

Yeah, we definitely think about it all the time. I think it’s basically going to be the drop-in replacement human worker. I think that speaks almost more to the user interface than it does to the underlying paradigm. I do think AIs are going to have voices. I think they’re going to have perhaps faces, and you’re going to be able to just talk to them and ask them to do stuff, and then they’re going to be able to do it very reliably.

Now, that doesn’t mean that the underlying paradigm is just an end-to-end agent and one very big model with a very big prompt. In order to be convinced that that happens, I think the 2 areas of research that I really watch closely are new attention systems—in particular, attention systems that may cause attention to be way, way, way cheaper, and in particular, like, n to the polylog. Everything I’ve seen so far resembles more of a hack than a fundamental innovation that really causes attention to be much cheaper.

The second area is dynamic compute: models that will decide at inference time which of the weights to activate. Maybe gone are the days when you have all of these different classes and sizes of models. Maybe you just have one very big model, and you can pass it a parameter for how smart you want it to be, or maybe it decides how smart it needs to be depending on the task. That’s also coming; there’s a lot of activity in that research area.

If both of these things happen maximally well, I think there’s a stronger case to be made for the end-to-end agent versus the scaffolding agent. Even then, I still think there might be room for scaffolding for other reasons. I think scaffolding is always going to buy you something. It’s always going to buy you some extra reliability, some extra speed; it’s going to buy you some things. But if these things don’t happen, I am then very bullish on the value of the scaffolding.

In this world, I’m thinking of it as: you chat with your AI employee, and then something happens. Most of that is going to depend on the LLM and the model paradigm that we’re running on at that moment. That’s the end of that black box, and again, we have a lot of ideas about how that black box is going to work, but at the end of that black box, what you want to see happen happens.

It’s almost like when the unhobblings become the hobblings again: when the model becomes more capable, maybe it no longer needs the scaffolding, but instead the humans need the guardrails. Maybe the scaffolding does future duty as a guardrail when it’s more about limiting what the model can do, as opposed to maximizing what it can do. It’s an interesting paradigm.

All right, we’re out of time. Anything else you want to share before we break?

No, this was great. Thanks for doing it.

Flo, CEO of Lindy, thanks for being part of The Cognitive Revolution.

Thank you so much, Nathan.