What They Don't Tell You About Selling Your AI Startup | Jay Hack, ClickUp Head of AI

People were using it for totally non-code things. They'd ask it to do data analytics, draft documents that made well-reasoned arguments around things that they were trying to argue to their boss. They had it doing customer support. And it sort of dawned on us, this is so much bigger than code. A coding agent is actually a general-purpose knowledge work agent. Code is effectively an explicit encoding of reasoning. Humans vastly over-attribute the amount of work that they will be performing in the future. Pretty much any cognitive task that you can draw a circle around and say, this is something that a human performs, AI will perform. That happened again going to Python, and then it happens again going to LLM. We're basically in that phase where the next level of abstraction is English. I think one thing that goes underappreciated is that you shouldn't pitch your business. It sounds ridiculous, but I think it's actually true.

Welcome to Two-Sided AI. Today I have Jay Haack, head of AI at ClickUp. He was the founder of CodeGen, which is one of the first coding agent companies.

So happy to be here, and thank you for having me on.

I'm curious, when did you start building coding agents?

Wow, interesting question. I mean, I've actually have been working on various versions of code generation for like over a decade. So I, you know, did projects that involved compilers specifically for data science applications going back about a decade, but it really kicked into high gear when the GPT-3 API became public in late 2022. I started doing a lot of experimentation with it on various side products to see basically what its capabilities were and what were the areas that it would end up actually being useful. And very quickly at that point converged on code as a great sort of target area for it for a number of reasons. Your viewers are probably familiar, but it has deterministic verifiability built into it, which is really nice. And so anytime the LLM will output some code, you can run a linter or a type checker or various things on it in order to make sure that it's properly structured. And a poem does not have that property. For example, it's very difficult to basically keep your LLM on the rails and especially from models of that era, it was very important to do so. But you know, besides that, there's there's basically infinite amounts of code out there on the web. Uh, there's very convenient ways in which you can bootstrap additional data in order to teach LLMs to code better. And so at that time, I reasoned that basically we would see an increase in coding capabilities very rapidly from models, and that ended up being true. And here we are today where, you know, software engineering as a job is basically at this point chatting with an agent and having it do the actual changes for you. So I, I started the company CodeGen in early 2023. The idea behind that specifically was let's get an agent to run off and asynchronously make changes to your code and then deliver you a pull request, as opposed to the dominant model at the time, which was something that looked more like Copilot, where it's sort of like as an autocompletion in your IDE, or even, you know, maybe a sidebar that pops out where you can chat with it. Um, so we were sort of skating to where the puck was going. At the time, there were not models that were capable of going off and doing complex modifications to your codebase entirely autonomously and asynchronously. And so it was a little bit ahead of its time, and I, I wouldn't claim that the early versions of that product really got a lot of customer traction or produced a lot of value. But we were thinking about the right set of problems. And then fast forward to 2025, the release of Claude Sonnet 3.7 was really a sort of seminal point in the development of coding models where suddenly it really could do asynchronous tasks that took hundreds of tool usages or something along those lines. And that really kicked our business into higher gear, and we started selling it a lot more rapidly. Um, so yeah, our business, CodeGen, since the very get-go is essentially bringing asynchronous coding agents into interfaces where people are already collaborating with agents or other humans and basically making it very accessible for them to triage tasks and hand it off to an agent and have it come, kind of come back and deliver them the results right in the interface.

What's your point of view on where the market is right now?

My meta view is that the progression that the coding industry has gone through will be the progression that many other industries go through in terms of AI adoption. And coding is just sort of shifted earlier in time by maybe 2 to 3 years. So the way it went was we started out with very primitive autocompletion, basically in your IDE. And in fact, coding as a— IDEs as a category have had autocompletion for a long time, going back decades, right? So this was not something revolutionary, just worked much better. And suddenly everybody in the world was using GitHub Copilot. It was really the first AI product that actually had any usage that wasn't just like something that would draft emails for you. It was a little bit more domain-specific than a fully generalist, you know, ChatGPT. And then over time, people sort of adopted the higher level of automation where it's a chat bar on the side where you can delegate many tasks to it, but you're sort of collaborating on an artifact together. And then ultimately you got to the sort of more asynchronous background agent situation. And as of today, I think the market is in a place where it is clearly the case to me that the vast majority of software engineering tasks certainly benefit from having an asynchronous agent doing large portions of the work, if not can be done almost entirely by the agent, at least the software engineering portion of it, like the actual code writing portion of it. That doesn't mean that the job of software engineering doesn't exist anymore, obviously. Obviously, you know, there are many people who employed in that position, and it's just that their work has shifted to everything that is complementary to the actual composition of the code. And their job has shifted mainly to sort of orchestrating agents, understanding their output, combining their outputs, making sure that the outputs of that actually gets in front of the right customers and gathering feedback on it, et cetera. Um, and so, yeah, sort of going back to my Meta prediction, I think that many other domains are going to see that similar progression where people today are in the, you know, Stone Age where they're sort of using a autocompletion in emails, but soon they will be comfortable essentially handing off management of their inbox and making decisions and producing artifacts and making cases for certain business directions to go into in very non-technical fields. And it will basically see the same transformation that software engineering as a field has. And that's, you know, a great thing for the world because people will be much more productive.

Yeah, it's kind of crazy, isn't it? It's kind of like a sci-fi world that, you know, no, I don't know if I need my computer anymore. Maybe I just need a box I can chat with in the future and then things will get done.

It's an interesting point. I heard somebody make the case the other day that, so chat has been way more successful than a lot of people predicted as the sort of primary interface to AI. And I think what a lot of people would've told you a while ago is that, oh, the AI will be dynamically assembling an interface for you for every single back and forth. And you'll just have like custom buttons. And the counterpoint to that, which this, I think it was like a YC guy put on Twitter the other day, was that the reason that chat has been so successful is because humans agents vastly over-attribute the amount of work that they will be performing in the future. So they won't actually be viewing a dashboard to understand where the data is going and make a decision on that. They'll in fact be delegating the viewing of that dashboard to an agent as well. And the agent will just come back with a recommendation, say, hey, I think you should increase pricing or something along those lines. And so I, I actually do think ChatGPT has an incredible amount of staying power. I do believe in that vision of the future where pretty much any cognitive task that you can draw a circle around and say this is something that a human performs, we will probably get to the point that an AI will perform it, and that implies that the chat interface is going to have a lot of staying power.

If we think about the main approach for humans to communicate, it's really through chat, right? We talk with people or we send messages to people to get things done. So that's delegation in a human world. So we're just repeating that with the digital world, right?

So I largely agree with that. Devil's advocate here is there is like the presentation. Is a format that humans use to communicate, especially when it's going between different sort of power levels in the hierarchy. So if you're a consultant at a company or like a mid-manager, then you're going to have to present your work to Mark Zuckerberg or whatever using a slide deck and say, this is why I think this is a good idea. And sort of the idea there is that you're exposing the underlying reasoning in a way that's easily, quickly consumable by somebody who has more scarce time. I think that the cost of doing that has plummeted also. And so even though it might not be the first thing that you end up doing, I think there will still be a place where essentially, you know, your higher-up says, hey, can you please explain to me why we're doing this thing? And then you can very quickly spin up an agent who will document all of that reasoning. It's sort of like a proof of work in a way to say, this is why this decision was made. That kind of a— in code we have like diagrams. You can ask it to write you an architecture diagram and it will do it. And I think that same idea will apply for general purpose knowledge work in many other domains.

Yeah, if it's just a presentation of the results or presentation of the reasoning process, then the agents should, should still be able to do the same thing, like generate slides to show you.

So maybe some people weren't as surprised by this as I was, but I think that we've seen HTML is HTML, JavaScript, CSS are an incredible output medium for LLMs to communicate with humans. And so for example, in the Claude interface today, if you asked, you know, give me a chart of LeBron versus Michael Jordan and tell me how they're doing. It'll actually make you like an HTML graph inline in an iframe that's in there and you can kind of click around in it. It's very cool. And I think there are many other scenarios where it does make sense to end up doing that. But if you think that we're going to have truly super intelligent LLMs a couple of years from now, maybe they won't even need to show you a chart. They'll just say LeBron's better. Don't worry about it. My full prediction for what the user interface will be is basically chat, you somehow express what it is that you want built, and it's going to go off and do it for you. And humans will effectively not be involved in the actual production of code. And that's a good thing because it means that everybody gets to, you know, participate in the production of software.

Yeah, agreed. And I mean, you built CodeGen pretty successfully, and you built it with real investors. You had real traction in the hottest AI category. There was at the time. What was the moment you decided to sell it?

Yeah, you know, so what we learned in the process of building CodeGen, and this was again something I don't think that was obvious many years before, is that a coding agent is actually a general-purpose knowledge work agent. The same model that powers Claude Code, which is a coding tool or cursor, is actually also the thing you'd use to draft you an email. And the really good reason behind that is that code is effectively like an explicit encoding of reasoning. And there's this phenomenon of positive transfer whereby if you teach something to be really good at code or really good at math or something else that's like a substrate for reasoning, it actually gets better at everything else because something that's strong at reasoning will be good at writing essays and whatnot. You can't exactly draw a straight line between them, but that's the general gist of what's happening in the industry today. And a big part of CodeGen's strategy has always been to meet users where they're at. So instead of building a completely novel interface, we went to Linear where people were already filing tickets. And that was sort of our first partner where we built a really tight interface between the CodeGen product and the linear interface. You could tag CodeGen, it would go off and do stuff for you. But as a user, you didn't really have to have that much additional bandwidth dedicated to grokking a custom UX. Maybe that's why I'm so bullish on chat. This always just worked for us is that it could, you know, just have a textual message. And as we sort of started, you know, integrating with more platforms, so we had a Notion integration, we had a ClickUp integration, obviously we had a Jira integration. We realized that people were using it for totally non-code things, but it was still perfectly capable. Performing the task. So they'd ask it to do data analytics, they would ask it to craft documents that made, you know, well-reasoned arguments around certain things that they were trying to argue to their boss. They had it doing customer support for several of our customers. Origin Financial is one I can think of in particular that really, like, leaned heavily on their, uh, on CodeGen for customer support. You know, it sort of dawned on us, this is so much bigger than code. I mean, I think code is going to expand to take up a much larger portion of, you know, the Things that people do will be, will be backed by code to a greater extent than they were previously. But fundamentally, the cap on a coding agent was not writing code. It could do anything for you. And as we realized this, you know, this really kind of kicked into gear last year as Claude 3.7 and then quickly a parade of other models got released. We, you know, built this very deep relationship with ClickUp. We were seeing, you know, exponential usage on their platform and really saw there's this massive potential behind the model that ClickUp had adopted. ClickUp is a horizontal software platform. I think of it as like 9 different applications all smashed into one and very tightly integrated. And as we were looking at many of these knowledge work, sort of general purpose knowledge work tasks, a lot of the time the actual bottleneck to getting things done properly was not the— it was not the intelligence of the model. It was rather the access to the right context. And so a very concrete example for you. Is Slack had an MCP and an API and they're very restrictive. So they wouldn't allow you to search past like a couple days in the past. They wouldn't allow you to index data. There's no way you could recreate a search through past data. And so if you had asked CodeGen, say, hey CodeGen, why did we make this decision? And please help me, you know, make sure it's reflected in the code or in our future customer service or whatever. It would basically tell you, I can't find the answer. And it, it would seem stupid, but it wasn't stupid. It was just Slack's APIs were very restrictive. Now ClickUp is the antithesis of that, whereas they converged workspace, meaning there's like everything in one place. And the people who use ClickUp, the entire history of their communications are all in one place, all their tasks, all of their chats, all of their, you know, whiteboards, even Zoom meetings. They have a Zoom competitor baked into ClickUp and whatnot. And so this actually, like, actually majorly resolved what I saw as the biggest bottleneck to being productive in a knowledge work context is just pull it all into a single context graph and provide native access to that, to the large language model. So I was extremely bullish basically on where we were going. We built a close relationship with them over the course of building an integration, and eventually we said, you know, this doesn't make sense to continue pursuing it as independent businesses. We think the market cap on bringing the capabilities of Cogent internal to ClickUp, leveraging the existing distribution, the brand, customer base, etc., that they have was going to be, you know, much better outcome for all parties involved. So now we're working on general purpose knowledge work agents at ClickUp, and it's been a hell of a ride.

Yeah, I've talked with actually a lot of founders in this space. For instance, Merge is, you know, they're unifying APIs. And there's also Stack AI building like the agent orchestration. BrowserUse is working at the browser level, taking actions, high touch, moving data across tools, right? It just feels like every, everyone is building towards the same thing, like the, a brain for the whole company that connects all your tools and centralized context. Do you feel that? Are you, are you all landing in the same place by accident?

Yeah, absolutely. I mean, the similarities are deeper than that. I mean, I think it's very clear at this point that, you know, for example, the chat LLM assistant, very valuable. Every company should have a little chat sidebar. That chat sidebar should be able to see the things that you're doing. You should be able to delegate large portions of the work and, you know, humans should spend less time clicking around. And like you mentioned, the natural extensions that are add external integrations into it, excuse me, add external integrations. And so it should be able to view your Salesforce, adding a sandbox to it. So it should be able to write code and execute code so it can do calculator-like operations for you. Should be able to view files, all this type of thing. So I think that this is just like coding agents. It's very clear that there's this shape of a product that people really benefit from, which is, you know, an agent that sits in sandbox and writes code and gives you pull requests or code diffs. I think there is generally an acknowledgement within the knowledge work generalist agent space as well that this is going to be super valuable. I think the thing that it is one thing to say this would be valuable if your agent had access to all the tools, all the context, et cetera. It's another to actually pull it off. And there is a very large difference between essentially just having Merge API or access to many different MCPs and sort of letting the agent stitch together information at runtime versus having the sort of preassembled, all the important insights precomputed, native access for the agent to the right, you know, sort of nodes in that knowledge graph, as well as access to all the relevant UI services. And so there are many things like Manus out there, for example. Manus is an agent who was acquired by Facebook. Yeah, it does exactly what you're describing. There's 50 other clones that are just like it. And, you know, you can tell if you go to Manus website, you can tell it to go do something for you. Maybe you can send a WhatsApp these days. But, you know, the thing about ClickUp is the people who use it spend all day in it and they have 50 different services they're looking at when they're in a task and then they're hopping into a document, they're chatting in a sidebar, you know, or chatting in a thread with somebody else. And the ability to not only provide native access to the context but also to those interaction services makes a real difference basically in your efficiency. Of operating alongside AI teammates. And so that's kind of a key differentiator that we bring to the table is that you don't have to hop between 8 different platforms and install all these MCPs to get value. It's just sort of batteries included agents ready to go.

I'm just thinking like if I'm a company and I'm evaluating different ways about solving the same problem, right? Building a company-level brain and then have access to all the context for, and make that available to all the team members. What if I just make it myself? For instance, I could probably stitch together a ClickUp similar or equivalent with the stuff that I just mentioned, and maybe the Stack AI, get the agent orchestration in and have merge, working with APIs, using browser users, stuff like that, all covered and top it up with maybe RAG or GraphRAG, like, because you mentioned about graph, right? So what do you think of this approach? Do I miss something if I just do that in-house?

This is a widely held opinion by people in the tech industry, I would say, especially with respect to coding agents. And I think that RAMP, actually a former CodeGen customer, fun fact, deserves credit as being sort of a pioneer here where they were the first to say, hey, we're not gonna use Devin or CodeGen or some of these other things. We're actually gonna build our own coding agent in-house. And they have since open sourced the code that they use in order to do that so other companies can go in. And implement their own version of it. I think there probably is a subset of like 10 companies that are capable of pulling this off and they have the engineering resources to pour into it and it allows them to take it from 98 to 100% efficacy on whatever task they're trying to pull off. I don't think that is a good use of time for most companies though, especially if you're non-technical. And, you know, I just want to emphasize that especially at ClickUp, the customers that we're going after are very non-technical customers. So it's like marketing firms, PR firms, construction companies, uh, legal services firms, accounting firms. So the idea that they would vibe code their own central knowledge management and agentic orchestration platform, considering the fact also that if you started building this, whatever we're talking about here, whatever the best version of that is 6 months ago is now completely obsolete. So it's just not a good play for them. And, you know, maybe this will change in 10 years when you could just snap your fingers and it will build you a whole Netflix-scale stack. But that is not the case in 2026, and I think it would be misguided to to go after that.

If leader of company's leader decided to, to, to, is it like, if they're weighing between building versus buying a tool like this, is the, is the biggest barrier engineering resources? Like, is there like any other, you know, considerations that they should factor in before they make such decision?

Yeah, I think that you should approach this just like you approach any other question of acquiring or using software. So, You know, as a bunch of leaders are sitting around a table, they're figuring out, should we vibe code our own payroll solution or should we use something external? The things that go into that are, okay, well, it's taken Rippling, you know, was it 10 years in order to build a good functioning, some would say good functioning payroll platform. Obviously, there's maintenance associated with that. There's anytime something new comes out, you want to update it or else you would end up falling behind. Maybe there's not a lot of new stuff in payroll, but, you know, maybe a good payroll solution has a chat bar that pops out on the side. And if you have not delegated the responsibility to actually do those things to an external company, you have to do it yourself or it's just going to be bad within a short timeline. Right. And so I think all that applies to building some type of an internal brain as well. You have to be ready to actually dedicate a very large amount of engineering resources. You know, at ClickUp, we have, I think it's like 200 engineers or something. And this is our primary focus. Like we're spending every day thinking about these problems. So if you have 200 engineers that you're willing to send on a side quest to go do something that's going to be you know, not even as good as one of the things that are on the market today, you could do that. I do not think it is a savvy business strategy if you're a construction company to be going off and building your own internal AI.

Even if a company decide to buy, right? Doesn't a vertical messaging land harder than a horizontal one? Because I looked at your messaging, right? ClickUp's tagline is literally software to replace all software. That's kind of bold and ambitious.

You know, the vision behind ClickUp has always been to replace all software. Our CEO is a true visionary, has been basically saying that from the tops of buildings since 2017. And I think it's never been more possible than today when the cost of adding additional surface area or additional features to a software platform that's already working has never been lower. So we can continue to basically expand outward. And I would say that our customers are people who realize that there's value in the integration of information between different platforms. So you have your slide decks, but you also have your chats, you also have your tasks and be able to pull that all into a single place and provide like a common context platform, both for humans and agents, that's something that's very valuable to them. And also it's worth calling out, like, if you don't use something like ClickUp, that's a horizontal platform, but you want all the functionality I just mentioned, you have to buy 9 different software contracts. And, you know, it's not really in anybody's best interest to be paying for 9 different things if you could actually just pay for one. And so I think that's really the core of the horizontal software messaging is that we will replace all the other things that you use., and we're going to charge you less and it's going to be a better experience because everything will be integrated at its core. As far as the vertical AI versus horizontal AI thing, it's an interesting point. If you look back at 2022 when the GPT-3 API kind of opened up and that was the dawn of everything we're experiencing today, I think a lot of people thought there was going to be more vertical AI solutions. And at the same time, I think if you look across the industry, it's kind of hard to point to successful vertical AI platforms. And part of the reason for that is that the models themselves are generalists. There's no difference between the model that you would use for a legal tech platform, a coding agent, or a full-scale generalist knowledge agent. It's all going to be, you know, Opus 4.7 today, or GPT-5.5, which just launched this morning. And so really the difference would come in the form of UX. But as we discussed earlier, actually the best UX is chat. And so as long as you have sort of the primitives that allow LLMs to communicate effectively with humans and track their work and do these other things. Like, you can definitely be successful on ClickUp as a legal services firm using Opus 4.7, using our super agents and our so-called ClickUp Brain, which is our sidebar. Ask it the exact same questions you would ask to, you know, Harvey or Crosby or whatever, and it will, it'll give you a very good outcome. And so I think that the benefit of not going after vertical AI is instead of paying for 9 different vertical AI solutions for your slides AI over here and your legal AI over there, just tag @Brain in ClickUp and it will do all this stuff for you. At just as good of quality.

Yeah. So the vertical AI is a selling point because if I'm a legal firm, maybe if you were saying that you handle all the— you give me a legal brain, a brain with legal power, then I feel I would trust you more versus a horizontal, you know, product. So maybe that's the difference. Do you want to talk about that? Yeah.

So let's take that legal example. You know, I'm not a lawyer, but I work with a bunch of people who are in legal tech and our legal team at ClickUp is obviously using ClickUp all the time. And I think that the main difference that a company like Harby brings to the table is not fine-tuned models. If there was any alpha to be had in fine-tuning models on legal text, then Anthropic and OpenAI would have already juiced that, for what it's worth. And there's, like I mentioned earlier, this idea of essentially positive transfer, where if you make it better at legal stuff, it's going to be better at writing novels. And if you make it better at math, it's going to be better at legal stuff. And so there has not been an emergence of domain-specific models that would end up being better at legal stuff. The best model is Opus 4.7. And the main thing that, you know, a company like that brings to the table is effectively an index of legal documents or, you know, some type of like context that the AI can view in order to accomplish a task for you. I think the way that this is going to go is there probably will be really good AI-first services that offer indices like that, that an AI can query. So like a Harvey MCP, or there's a really good example of this for web search, which is EGZA. And then also Parallel, I think is the other one. It's basically like a web search bar for an agent, and we use it and it's great and it makes the product better. But it is not the case that you need to pay for an entirely separate UX that takes you out of context in order to have legal conversations. I'm on the same footing as our legal guys at ClickUp. I could say, hey, what do you think about us doing the somewhat risky move on our AI platform? And it will give me a really good answer and cite all the sources, et cetera. I would say code is somewhat unique. Video— I'm taking out of video models and image models out of this, by the way. I think that's a totally different story, and world models also. But I think if you're looking at text output models or tasks that require that, there are very few examples, at least to date, where a fine-tuned model has been the best play. And maybe that's a function of multiple things. One of them is companies are generally a little bit more open to spending more right now, and over time they'll probably be a little bit more concerned about economics. But yeah, it's hard to think of a fine-tuned model that that people are using right now. Composer 2 by Cursor is the one example I'd point to where it's like they have fine-tuned their own model specifically for code. And now we know they're also going to work with xAI in order to make that basically a frontier model. But yeah, it's, it's not the weights of the model, at least thus far, that have been the thing that drives it forward. I think that'll probably continue for some time.

One more thing I can think of, like specifically for legal use cases, is maybe accountability. I think accountability for vertical AI may be something else that You know, ClickUp, companies like ClickUp, Meta, I don't know. Have you ever thought about that?

Yeah, for sure. You don't want it to hallucinate. You've got basically different parameters governing how risk-seeking you can be in the outputs of the LLM. And I do think that's true. So I think if we, if we continue basically interrogating the position that I'm taking of there will just be one generalist agent that everybody uses, there are exceptions to that. I think if you are a high-powered legal firm, it does make sense that you would have like one vertical platform specifically for legal services. I guess the claim that I would make is more so maybe the legal firm will have a vertical-specific legal AI, but for pretty much everything else, they're going to use a generalist agent because it's going to be 95% as good. And that is basically where we put our chips, is that we are the one-size-fits-all, going to do a really good job on everything. And it comes with the added benefit of the integration of information between these different touchpoints. Because there's an obvious sacrifice you take if you are, let's say you're a legal services firm, you're using some type of vertical specific thing. You spend a long time chatting back and forth with an agent that's looking at a bunch of legal cases, and then somebody pings you on Slack and they say, hey, how's this case going over here? Like, there is definitely work you need to do in order to get that Slack thing to be able to accurately see what's going on in the legal platform. Whereas if it's all contained in a single surface, the level of integration between those things is just gonna be something you can't compete with if it's the data is siloed.

Yeah. Inside ClickUp, was it— what's the part that's actually the hardest to get right when you're building it?

There are many challenges. I would say that the challenges have changed also as consumer behaviors have changed. So, you know, for example, a while ago, nobody expected the agent to have memory. Nobody expected that it would be able to remember things over time. And now that's actually an assumption that a lot of people who are ChatGPT or Claude or Gemini users have, is that this is going to remember stuff over time. And so I would say the meta challenge is keeping up with all the cool stuff that's coming out and knowing where to place our chips and what bets are worth making. A related problem to that is the problem of telemetry. So basically being able to observe which approaches we're taking end up providing some net benefit to customers. So if you're doing something like, you know, Copilot, for example, where it's just autocompleting lines of text, there's a pretty obvious thing you can look at, which is how often do people accept your suggestions? However, if you're making a general purpose knowledge work agent and you ask a question, what should I focus on today? And it comes back and it gives you a bunch of answers of what you should do. There's nothing obvious you can point to that you're gonna be able to collect like a lot of data on for how well that's performing, especially if you're doing it in an online evaluation, meaning you've actually rolled this out to your production traffic and you're seeing customers use approach A versus approach B. And a very obvious example of this is like new model comes on town. G5.5 launches this morning, seems like it's pretty good. How do you know if it's actually better? And how do you know this is providing more value to your customers? And ideally you can do this in a very short amount of time, and so you're able to maximally juice that model as opposed to waiting a month to figure out what's happening. So I would say that at a very high level is a super important problem to us, is figuring out what's working better and setting ourselves up in this process where we really can just be like a software factory churning out the latest features, you know, things that make people's lives better, etc. In terms of specific features that have been difficult to implement, like I mentioned a second ago, I think memory is a fascinating topic, especially when you scale it to an organization. So a big difference between ClickUp and many of the other agents that people would consider buying out there on the market is ClickUp is natively multiplayer. So you have your entire organization inside of this thing. People use it for collaboration. It's not the type of thing where you just use it for personal project management. And so if you talk about memory, then there's all these very complex permissions problems that come up around memory. So if I talk with you, but also my agent in a shared channel, and then I'm talking with somebody else who, you know, maybe is not at the same level of, you know, they don't have access to the same information that you do, should that agent leak information from our conversation to this other person over here? And I think a lot of these questions, like, there is no, like, there's no converged upon correct answer in industry today. Claude, OpenAI, ChatGPT, Gemini, they haven't had to solve this because their AI is purely multiplayer. It's something you chat with one-on-one and then it will, you know, basically remember like little tidbits from your conversation. And so our challenge is more so one of like scaling this concept of intelligence to an entire organization and making it work in such a way that people can buy it and they're not afraid that it's going to leak sensitive HR or payroll information or something along these lines. So that's something we think about pretty constantly. And, you know, the last one I would throw out is just the challenge of scale of data. So we have constructed what we consider, you know, basically the most fleshed out context graph for any work management solution out there. We have your tasks, we have your chats, we have your whiteboards, we have your meeting notes, we have your emails. All this stuff is pouring into a single place and The question is, how can you efficiently assemble a data asset or a context graph, as it's known, that the agent can query and find the right information quickly? And the properties of a good one would be it pre-computes the things that matter. And so you don't need to continually recompute summaries of the things that are already summarized. It can find the right information, it can do so efficiently. And so you're able to not charge your customers too much for this stuff. You can make it very efficient and sort of a no-brainer for them to end up using it. And I think there are, You know, there's decades of science on how you go about doing that. A lot of that stuff just got thrown out the window because of the emergence of large language models. And so in a way, we actually are kind of pioneering a lot of the new approaches that people use in order to tie together complex and very heterogeneous data assets into a single unified view that an LLM can operate on efficiently.

I noticed that you guys have your— build your own memory model, right? So, so even though you support Claude and GPT and all those kinds of things, Why, why build your own?

I just want to clarify. So we, we do not have like trained parameters that represent the way in which we store memory. We do have a proprietary algorithm that we use in order to store context over time that can be reused by other models. And that, you know, you could just sort of call that memory, I guess. But, you know, there's, there's a way in which the thing will remember things as you're talking with it. There's a way in which that information is gated or shown to other people if it would be useful for them and if they should have access to it. And that is something that is proprietary. And the reason that we're not using, you know, the native Claude or OpenAI memory is twofold. One, they actually don't expose that through the API. So we probably would have run an experiment with it if they made it very easy for you to do it. Even if they did expose that through the API though, it would be natively single player, which is the only thing that those models support right now. So it only stores information about your interactions with the model. And if you think about all the stuff that happens in a large organization, you know, ClickUp sweet spot is maybe company is between like 20 and 2,000 people, which is, you know, two orders of magnitude. But if you look at organizations like that, most of the useful stuff that you'd want an AI to remember happens between people, and it's not the type of thing that happens in a separate siloed chat. And so even if we did use the OpenAI solution off the shelf that they don't offer currently, then it wouldn't solve for the vast majority of things that we, we do care about, um, which is scaling intelligence to the entire organization. And I think this is going to be a very rapidly evolving area for us. Like, we're going to invest more time and energy in this because this sits at the very base of our AI system is how do we assemble the right information for the AI to take action as well as humans. So the way we think about it is an organization is emitting vast amounts of information every day. You and I have a chat, we make a channel, and there's a bunch of interesting things that get said there. And some of those things get written down in documents. There's tasks that get created, some tasks get finished. Maybe you have external integrations that are posting messages in the channels, and a lot of that context ends up getting discarded. But there's some information that is in each of those things that's valuable, should be summarized and carried forward. And so we essentially have implemented something that looks like a hierarchical summarization inside of Workspaces where at any given point in time, based on any action that somebody takes, we will distill the relevant insights from that and then store it in such a way that it's permissioned just like any other object in ClickUp, where it's only available to those people who had access to the original information. And there are a bunch of elegant ideas in computer science that allow you to do this efficiently. We actually take a lot of inspiration from the thing that sits at the basis of Bitcoin, the Merkle tree, which is a way to efficiently basically compute whether a bunch of hashes combine into another hash. You can do the same thing for basically understanding, do I need to recompute a summary for a given portion of a workspace based upon the updates that have been made in it recently? And so that basically, you know, is a very vague way of me gesturing at this idea that we are computing compressions, summaries, and sort of a secondary graph on top of the existing graph of human communications. And then this secondary graph is the thing that the LM will primarily communicate with or use in order to distill what's going on in your workspace. I think it's very important to note that this is all constructed on the same primitive set of data models that we already have inside of ClickUp. And so just as an agent should be able to search through chat messages, it should be able to search through summaries of chat messages. And this shouldn't require some type of large-scale re-architecting for us. It's just constructing, fleshing out the existing set. Of primitives and data models that we have.

Are these concepts different? Memory, knowledge, and context.

So, this is a semantics debate. I sort of have a policy personally that I do not partake in AI semantics debates because I feel like they always devolve into navel-gazing. But I will entertain this question just for the purpose of the podcast. So, yes, I do think that all of them are different. Knowledge is, some people say, justified true belief. That's what certain philosophers around, whatever, the 1600s, would have you believe. I don't think that in the LLM context it's the same thing as memory because it is basically memory from pre-training, but it is not something that is picked up since they froze the model and they started offering it up in the API. It's just something that's baked into the nates, the weights of the model. I think memory is something that pops up when you essentially enable an agent or some type of an LLM-enabled entity to run around inside of an environment and it has certain interactions with things and then it's able to basically store that or refer to that later. Um, but in the context that I'm describing it, that would be something external to the API that you're using. I do think there is a version of this in the future where the LLM providers do provide some type of like a native memory where you can essentially have it perform certain actions and then you get like a key that corresponds to like a certain set of experiences and they just handle it on their side. You don't have to really think very hard about it. I'm sure we would use something like that in the future for certain applications. But, um, yeah, this is something that happens on top of the LLM itself. It's like an additional set of experiences. Memory, knowledge, and what was the third one?

Context.

Context is, you know, you could have anything. Context is basically just tokens that get fed into an LLM. And so there are things that are, you know, like I would say an example where knowledge and context are different is you can repeat the same thing 50 times and put it in context to an LLM that really only contains one piece of knowledge or one piece of new information. However, the context is 50x. So context is sort of more of a like brutish way of thinking about the input to an LLM.

Yeah. Can we think of context as more like a working memory?

Certainly. Yeah. It's also, it's basically just a, for an agent, it's a log of everything it has seen and all the actions it has taken. So it is like a short-term memory of sorts. I think that, you know, if we talk about, so one of the hot topics right now in AI is continual learning. And this is the idea that actually you wouldn't need to implement memory separate from the LLM itself. It would just learn over time and get really good. And one very compelling vision of how we end up achieving this is that actually you just get to 100 million tokens context and you just never stop accumulating in the context. You just keep jamming it in there. And presumably in the layers of the transformer or whatever comes next, it somehow figures out how to compress the entire history of its experience into things that are consumable at the time it's generating the next token. And I think that is plausible. It's actually a Dario Amodei thing from Anthropic. He's the one who sort of is the biggest advocate of this idea. And if you do that, then context is memory, but it's not necessarily always the same thing.

Do you think that's the right way of doing it?

It is definitely not efficient today. One of the ways I could see us getting towards that is there are different implementations of the attention algorithm. And so, you know, right now attention is quadratic, at least in terms of the amount of compute that you're doing as you scale the number of tokens. But there are various models that make that linear. So RWKV and Mamba-style models, there's like a whole category basically that change the types of computations that you're doing on top of context. Actually, NVIDIA just released a model, NeMoTron, that has that baked in. These models aren't very good, and so there's some fundamental research that needs to be done there. But I don't think that fundamentally it's something that's insurmountable. I think it's really just a question of what do the research gods end up shedding favor upon. And I could see a version of this where they do come up with an efficient implementation.

But even if this becomes possible to do, would you choose approach or choose this approach, or would you, would you try to be more efficient? Because, because as humans, we don't remember everything. Like, a lot of things already happened today for you and for me, right? You don't remember everything. I don't remember everything.

Yeah, I mean, just to clarify, like, let's say you did have 100 million tokens and you showed an agent, you know, its entire 100-year history of interacting with humans on ClickUp. That doesn't necessarily, even though it has a log of every action it's doing, it doesn't necessarily mean it's going to attend to every token. When it ends up generating the next thing. I'm just basically suggesting that the mechanism by which it would choose what to attend to is something that's baked into the weights of the model itself, as opposed to like some type of external tool use. Um, and so I think you could do that efficiently. You could have like a really efficient way of doing attention over previous tokens where you just cut out the many years of stuff where it was completely irrelevant. Um, and I think in a way that is kind of what humans are doing is, you know, we're sort of— we have access to all of our memories, we're just efficiently able to pull up the ones that are relevant to us at any given point in Do I think that we would use that if it came out? I mean, I would love to experiment with it. Yeah, I guess the only other point I would make there is that I think that part of being in the application layer game, which ClickUp and I am very much a part of, is, you know, I certainly have certain theses around what's going to happen in the future, but I think you have to be absolutely ferocious in terms of taking whatever is working and then applying that. And you have to be ready to burn down your entire tech stack like every 4 months at this point. Because something new comes out, it's better, you want to deliver that value to your customers. And it's never been more possible to rewrite code than in the era of Opus 4.7 and whatnot. And so, that's the perspective we take, is we're kind of agnostic, and we just put together a really good experimentation— excuse me, experimentation framework to be able to determine what's the right approach.

That seems to be a good reason for continuously hiring more engineers instead of saying that the software engineer job is is doomed because we don't need more engineers. Actually, because if you're rebuilding every 4 months, then we need more engineers, right?

Yeah, that's maybe a hot take. I mean, I could see it going the other way where you say, actually, there's a ton of friction that comes from more engineers. And in fact, some of our fastest moving products inside of ClickUp have very few engineers who are very high agency, very high ownership, you know, basically cutting it down to a team of 10 people. Actually introduces a lot of efficiencies that you would not be able to realize previously because code was the bottleneck. So, I don't think it's necessarily the case that we're going to see an increase in software engineering hiring in the future. I think, in fact, we're going to see a lot of organizations slim down.

Do you have any advice for software engineers?

I personally think we're going through something that's going to look like, you know, Industrial Revolution Round 3. In a way, we have been going through this since, you know, the invention of the personal computer, and this is just the latest continuation of the trend. But I think We've definitely accelerated with, you know, with GPT-4, GPT-5, et cetera. You know, we're entering totally new territory here where like LLMs are going to be pushing the frontier of hard science and math and whatnot. And it's really difficult to see what's going to happen. I do think that the job of software engineering as we knew it previously, where you're sitting down, you're writing code all day, that's going away. And I would recommend people who are going into software to instead frame it to themselves as understand what you can about the code. But also it's more so about building things. It's more so about being productive and orchestrating multiple agents to extend yourself to have greater output. And I am not convinced that we're going to have the same level of employment of people solving very specific problems. And, you know, like what's the most performant way to do XYZ in a web application, which is what most engineers are employed to do today. And my evidence of that is I would point at compiler optimization or something like that. There probably are more people employed in compiler optimization today than there were a couple of years ago. But sorry, let me rephrase that as people working on the optimization of low-level languages like assembly. There probably are a lot of people who are doing that, but it's nowhere near the percentage of the industry that it was when that was the state of the art, because we've invented higher-level languages and most people operate in those languages. And so, I think that's what we're going through again today is the software engineers of the future will primarily interact with LLMs through English, and they should adjust their training accordingly to basically, you know, make themselves good at collaborating with agents. I think software engineering is the profession that has basically made, uh, throughout its entire history has been inventing itself out of a job. You start with assembly, then we invent C. And initially, apparently, I was just chatting with ChatGPT about this the other day, apparently when C was invented, people really did go in and investigate the assembly code. That it would create, the C compiler would create, they'd say, "Hmm, is this right? Is there a way I can do this better?" Because it was faulty. And there were potentially, you know, things that would output that wouldn't be the most performant. That's still true today, right? But no C engineer in the world today, certainly not C++, goes in and is, like, viewing the individual assembly things. It's just not worth their time. They're probably delegating it to Claude, and maybe Claude can do a better job at optimizing it. And that happened again going to Python, and then it happens again going to LLMs. And so, I think we're basically in that phase where the next level of abstraction is English.

So, if the next level of abstraction is English, then doesn't that make the software engineer role equivalent to the product role?

I think they're convergent. I think that, you know, we will think of people in the future as people who build software. There may be people who are more concerned with uptime of a system or making sure it's performant or making sure that there's some objectively verifiable properties about it that are going well, and other people who spend more time thinking about the user and What, what goal is this product trying to solve and how are people receiving the stuff that we've put out? But I don't think that they will be using as different of a toolset as we see people using today. Like right now, your developer's in an IDE, your product manager is in Figma or something along those lines. And I think those two get collapsed into a chat interface, essentially.

Do you think that changes the roles you're hiring on your team?

Totally. We've had to rethink our hiring process and, you know, this far predates even ClickUp. Like I had to think about this a lot. Building CodeGen because, you know, this is in the midst of new language models coming out. I think that the old way of interviewing software engineers especially is you give them a coding puzzle like a LeetCode-style interview and you see how well they do on that. And then, you know, maybe you give them another like take-home programming project. Our policy at CodeGen, which we've carried through to ClickUp to a limited extent at this point, is AI maximalism. And so the idea is we're not measuring your ability to solve a LeetCode-style programming question, we instead give you a very ambitious task and we give you a powerful AI and we say, accomplish this and talk me through how you're thinking about it. And we watch how they interact with the AI, how they build with it, what the scope of challenges they can take on are, how well they understand how to collaborate, all this type of thing. And then besides that, also we'll do sort of interrogation on figuring out how well they think about AI systems. So it's like a whiteboarding interview. LLM would not be very helpful there because you still have to draw stuff on a, on a whiteboard and whatnot. But if they, in the middle of the interview, they said, hey, I'd love to ask ChatGPT about how this stuff works, we certainly would be open to that.

Likewise.

Yeah, I think the set of capabilities you look for in finding a senior, you know, high output contributor has absolutely changed.

Is that— I mean that, you know, I don't have to be the best in class programmer. I need some other skills to nail that interview with you. With your team and what that still feels.

Just one. Yeah, I wanna clarify, we still want the best-in-class programmers. It's just that what is best-in-class has changed. Best-in-class now means you actually are very efficient at working with AI and somebody who's without AI going up against me with Claude 4.7, like I'm gonna absolutely destroy them. There's just no question. And so yes, basically the, the evaluation has shifted as a result.

Yeah. Do you think the current education of software engineers are not equipped with What companies are rethinking how they're hiring, like what you just told me? Like for students, what should they do if they're in software, like CS programs, what should they do?

Yeah, education is— this is a very deep topic. I think it, you know, there's many questions outside of even just computer science to all of STEM and humanities. I have not been extremely dialed in to, you know, what like the computer science curriculum at top schools looks like these days. I'd be very curious, but, you know, I know a lot of it has shifted online. I mean, going back, so I graduated college in 2015. Even then, for the last 2 years of being in college, I basically didn't go to lectures because all of it was online and all of our projects would be submitted online. And so this is definitely a continuation of that trend. I think that we saw a huge influx of people into tech in the like late 2010s and especially during COVID I think it kind of got this reputation as being, you can get an easy job at Google, you just like get boba tea and go rock climbing and like push a couple lines of code per day. It'll be easy. And so a lot of people who didn't actually love building software, but they were there because it was basically a good gig, came in. And it gives me great pleasure to see those people, you know, kind of filtering out of the ecosystem now that they realize it's a little bit more competitive to get a job. I think the people who are left are people who love computation. They love building stuff. You know, they really get a dopamine hit from shipping code. And for those people, this is the best time ever to be in the industry, is you just get to feel like a god. You know, the AI is coursing through your veins and you're able to build anything. In 1/20th of the time it would have taken you previously. I think that there's probably going to be a lot of interesting innovations that come down the line though, in computer science education. I know Andrej Karpathy is building a new company sort of in that realm of educating people, maybe not just computer science, but that's certainly what he specializes in. But yeah, I don't have a ton of interesting insights to offer on what's working currently.

What about for non-technical people? I feel for them, it's also the best time to build as well.

Yeah, absolutely. I mean, it was impossible to build before. I, you know, my wife, for example, is trained as a product manager. That's what she's done throughout her entire career. And she's able to vibe code stuff that is incredible and she has good taste. And so she'll be able to make something that, you know, actually works and feels good to work with. And that would have just been completely out of scope previously. So in a way, she's the biggest winner of, or, you know, that her type of profile is the biggest winner coming out of this whole AI wave, as people have just unlocked a whole new set of capabilities.

Would you hire someone like her who's tried and experimented with AI even though not trained as a software engineer?

I mean, I would actually go so far as to say I would not hire somebody who's not like her insofar as any type of a person who's going to be doing product management in the scope of ClickUp, what we're doing today, or even at Cogen, like if they are not thoroughly immersing themselves in AI, then they are probably not the type of person who has the level of curiosity and drive ambition to be successful at a company like this. We're always trying to push the frontier. As a result, basically need to always be knowing what's working and, you know, have everybody fully dialed in to what the latest things are that are coming down the line. Would I hire my wife to be a staff software engineer on building our agents product? Probably not. There's still a gap there. And you need, you know, you need to know all the best practices of software engineering and no amount of chatting with a language model is going to get you to be as efficient as somebody who has spent 20 years doing this.

Right. What would you hire someone like her as on your team?

Oh, I mean, I think that sort of product generalist is a role that is flourishing today. So, you know, I think internally at ClickUp, we have a practice now where engineers, they used to, sorry, product managers used to go through this lengthy process where they'd have a designer rig it up in Figma, and maybe they'd make some change themselves. And then, you know, they would, once that sort of got approved, they would make a prototype, then we would test it out.. And that whole process has been compressed down to literally sending a chat message at this point to a coding agent. I think it's Cursor usually that will make a full prototype based upon a design system and a repository that we've set up that is interactive. And you can send a link to people and they get a Vercel preview link that shows them the entire product. And so a lot of the things that previously were bottlenecks for product have been completely eliminated, which means it is their time to shine. And so they can go out, you know, really the bottleneck in, in an organization like ours is get good user feedback, understand where the priorities lie, make sure the right people are aware of those priorities, their work is progressing properly, making sure all the trains arrive at the same time. And so they're, you know, your work is constructively interfering and not destructively interfering. And that's exactly what you'd hire somebody like this for, basically to help prioritize and find the high-value things to look at.

And what are those roles called? Are they called still product manager, or you mentioned the word product generalist? That's a really—

Yeah, I like the trend where people now just say member of technical staff on LinkedIn. I think it conveniently unasks this very question because I think a lot of the boundaries have blurred. Personally, I don't think about hiring as like slots that you put people into. I think you meet talented people who are high agency, high motivation. You find out what their capabilities are, and then you plug them into the fully connected graph that is your team of everybody communicating to them, and you hope that they pull the sled, and they do so in such a way that accumulates value, so other people become more productive. So I think that describes what does a product generalist come in, what do they do when they come in? They communicate with the engineers, they communicate with the customer, they end up help shaping your product marketing, especially if you're a consumer product. They, you know, help understand where the actual issues are, the gaps in the current implementation. They probably do a little bit of prototyping here and there, work with designers, but it's less so about like churning out code that hits production.

I hear you. The audience are thinking of, you know, about their career and either for transitioning or graduating, how do they prove to you that they have the mindset that you're looking for? What are— how are you going to test them?

I think that there are some things where when I talk to a candidate, it's clear to me they're passionate about AI, like they're excited about it. And that excitement comes through in them having done personal projects. They build really cool stuff. You know, they're not just doing a 9 to 5. They actually just are independently curious about what the capabilities of this technology are, and they'll dive into it. You know, it's a little bit trite to say I like to see good side projects, but like, that actually is what differentiates the tourists from the people who love building stuff. Is people who love building stuff, they go to hackathons, they build stuff there, you know, they spend their weekends just talking with Claude because they think it's incredible that we now have this god machine that can tell you, you know, an answer to anything. And so usually a big part of how I get to know people is I understand what are their perspectives on AI, where do they think it's going in the future. So do they have like an actively developing mental model of the space and how it's changing, um, and how they use it themselves and how they've been able to rig to have a personal workflow that is high efficiency. Probably the main thing that I would key on, obviously you have to be very good at using it in order to produce outputs. And so I'd want to see them be good at a coding interview using Cursor or something along those lines.

What AI do you use on a daily basis and what do you use AI for? Can you share with us?

Yeah, I mean, I, my entire job is in ClickUp, and that is true for a lot of the people on our platform. And so it makes a ton of sense for me to just be using our own product. And I, you know, as a result can dogfood it and You know, especially with the latest generation of models, it is true that our product, especially for the use cases that our customers want to use it for, is like by far and away better, almost trivially better than the alternate because it's already hooked up to all of your contacts. And so otherwise it would just take a really long time to get the same. So that, that's like my daily driver and that's, I pretty much conduct my entire job at this point through chatting with a sidebar or tagging an agent to go, you know, figure something out for me. Um, and it's transformed the way that I work just the way that Cursor transformed the way that I write code where, you know, my interface to it was largely through natural language. But I do think that, you know, especially for somebody in my role, like, I am entrusted with guiding a lot of the AI development at this company. And so I need to know what's working in the world and what the patterns are that people are kind of latching onto. And so I have basically taken it upon myself to daily drive like 6 other AI clients. So, you know, right now, let's see, I can pull it up on my screen. I have Claude, Codex, obviously ClickUp. I have ChatGPT, um, and then Gemini all going. So, you know, on any given day, I'll, I'll take the same query too, and I'll fire it off against two different models pretty frequently to compare their responses. I also have an open source GitHub repo that's called Galaxy Brain. Happy to share, uh, which is basically a set of evals that I use personally, and they're problems that I'm very familiar with, and I will dish them out to multiple agents. Usually it's a coding problem or it's like create an animation or a video game that does something. I have a pretty good sense of what a good output looks like there. That's the first thing I'll reach for when GPT-5.5 comes out. I'll say, "Hey, how does this perform on—" One of them is create a simulation of an island with a bunch of different creatures running around, simulate evolutionary dynamics, plot their populations over time, have them have wars with each other. You can really see the progression of models over time if you have a problem like this. That you can anchor on.

Other than ClickUp, if you were to choose one to retain, which one would, would you keep?

I think there is vanishingly little product differentiation between all of the single-player AI clients right now. You've got Codex, Claude, the desktop application. Gemini also has a desktop application. It's not very good. It's not very feature complete. I would probably go with Claude. I prefer the Claude models and the way they phrase things. GPT-5.4 and 5.5 though are really good and it's I'll go to one model versus the other based on what the problem is. So, I would say probably both of those are great. Oh, also I should say Cursor. I'm a daily driver of Cursor. For anything that's like specifically code related, I still reach first for Cursor.

Do you mind teaching me one thing about being a better founder? This is my last question, cuz you were a, a founder and a very successful founder, so I'm curious if you can teach me one thing to be better.

Yeah, I think one thing that goes underappreciated is that you shouldn't pitch your business. And that, it sounds ridiculous, but I think it's actually true. It's like paradoxical that in the process of trying to convince people that what you're doing is a good idea, you end up actually in many ways showing that you're desperate. And this applies to raising venture capital, it applies to hiring people, it even applies to getting customers. And what a lot of people will do is they'll, you know, get out there on social media and they'll say, our thing is the best, like, here's why you should use our thing. And they really are like kind of laying on the sauce heavy.. And I think what works so much better than that is basically constructing a narrative where the user themselves ends up arriving at the conclusion that your product is better, or your team is better, or your approach ends up being better, or, you know, this is the right place to work, or this is the place I want to park my money. Um, but you basically let the person who's listening to your narrative feel smart by arriving at that conclusion. And what you do is instead of laying out, you know, a 5-part essay that explains this is this is what the customer should do. You instead basically say interesting things that demonstrate a mastery of the topic at hand that are by themselves interesting to hear about. And you kind of cut out a hole in the narrative that you're telling where the natural conclusion or the thing that's missing is your product ends up resolving whatever tension they're feeling. I think there's a bunch of companies out there that do this masterfully in their public communications. Instead of talking about This is why you should use Figma. I think Figma talks about like exalting the designer. The designer is the winner and the thing that enables the designer to deliver on their role is this futuristic product that allows you to collaboratively put together whiteboards and designs and stuff like that. And I think that basically, yeah, if you do that, you carry yourself with quiet confidence. It feels a lot less salesy and you'll end up attracting more flies to, you know, come feed on your honey. It's very rarely people want to be sold to, and if somebody wants to be sold to, then it's kind of a red flag that maybe they're not the right person you should be talking to, especially as you think about employees, venture capitalists, potential customers who could be high value for you. I think it's, you know, much more so you want to bring value to them by explaining interesting insights, and then their conclusion on top of that should be, this is a winning approach.

How do you practice this yourself?

You know, I try to, when I publish something, when I'll like do online writing or when I talk to somebody, about what we're doing at ClickUp, I try to, instead of emphasizing like, this is why our approach is great, and instead emphasize the underlying theses that I have that have led me to the conclusion that this is the winning strategy. And so maybe in this specific podcast, I've spent a lot of time referring to what we do specifically at ClickUp, but I hope also the takeaway from guests has been like, you know, there is a huge benefit from having integrated information that allows the agent to be more effective in carrying out whatever task you have. There's a huge benefit in having an integrated UI. And so you don't need to hop between different places in order to achieve some outcome. There is a tax associated with fragmentation of information. And if you're on Slack, you're not going to be able to have your agents view all the same stuff. And then basically once I have presented that set of conclusions that I've arrived at, then I talk about what ClickUp is doing, sort of set it up and then knock it down. I think people can spot a shameless salesman a mile away and sort of people, especially on social media, if you're just talking about this is why our thing is so sick, then people realize that it's phony. And I think it is the best way to go about getting people to be excited about what you're doing is to lean into authenticity. And for me, the authenticity that drives what I'm doing is I legitimately believe everything I've just told you. And so that becomes primary in the narrative. I can feel it.

Yeah. Thank you so much, Jay. It's really, really fun talking with you. And I feel like you gave me a lot of ideas on how I can live better and use AI, you know, in my daily life, you know, maybe even using the tools that you are, you know, the company you're working at, right? ClickUp, even though, you know, you told us the story about moving, selling your product and believing in a bigger vision. And I feel I'm convinced. And thanks for sharing all your technical insights as well, like very deeply in terms of how these things, the brain, how you build the brain, how you build the context memory and all those kinds of things that makes the company and the product valuable. But in the meantime, this is how good things are built, right? Absolutely.

Well, hey, thank you so much for having me on the show. You asked some great questions and made me think deeply about, you know, some of the things I do just from muscle memory on a day-to-day basis. But hopefully this is helpful to your, your listener base as well. Thank you.