Building A Personal Agent That Actually Works and Sounds Like You - w Founding Engineers @Sentience

Let me double check. I think we're live, but I don't know. Oh wait! Hold on, let me refresh the page. Oh, okay, I have to type. I think— okay, I think we're live. Give me one sec. All right. Okay, we can get started. All right. Hello everyone. I'm Angelina Yang. I'm the founder and host of TwoSet AI podcast, and thanks for tuning in today. Quick context if you're new here. TwoSet AI started as TwoSet, 2 people talking about AI. And over the last year, I've interviewed roughly 100 founders and domain experts. A lot of them are O'Reilly authors. So if you do read O'Reilly books, tune in on those sessions and, you know, let me know who you want me to interview. I'm happy to have them on. And every one of those conversations opened the door to a bigger engineer world behind them. And it's actually the engineers solving the messy novel problem the founders were, you know, describing to me. And the technical nuance, I think, deserves its own stage. That's why I started this workshop series to give these frontline engineers the stage to showcase their design thinking of how they solve these real-world challenges, their human creativity in engineering that AI, you know, still cannot replace, and also their deep tech technical differentiator that they built to win their market. And my goal for TwoSet.ai is to help builders, engineers, and anyone experimenting with AI like yourself to find your wedge the same way the founders I interview found theirs and build what you're passionate about and be positioned to sell one day. Today's guest instructor is Armit. Sorry, give me one sec. Today's instructor is Armit. He's the founding engineer at Sentience Company building personal AI. I'll let him introduce himself shortly. Ben was going to join us today too, but unfortunately he's under the weather and couldn't make it today. But a little bit administrative things before we get started. This talk runs about 30 to 40 minutes with time for Q&A, so drop your question in the chat anytime. And one small ask before I hand it over to Armit, if you find the ideas useful today, hit subscribe on the channel. That's the simplest support to help me keep the series going. Thank you so much. Quick question for the chat while we are getting started. Where are you? Tell us where are you joining from and what you're building? Would love to hear from you. And over to Ahmet.

Hi. Hello everyone. I'm Ahmet. I'm a founding engineer at the Sentience Company. where we build digital simulations of human beings. It's a very big claim, but today I will walk you through our current state of the product and I will walk you through the principles that we have learned building, building a personal simulation, right? So I can first start with walking through the product. Let me share my screen.

Yeah, you can share your screen.

Yeah, so this is my home base at Sentience on the Sentience product. I am actually recording this meeting and it will populate as an audio memory. This is about the live threads that I have, and these are the things that my Sentience knows about me. It is proactively surfaced here. So this is the first layer, my home base. Anything that I need, it will be surfaced here. So for example, it knows that I'm going to attend this workshop now, so it prepared a document for me. And then the next layer is the memory layer. We capture, you know, you connect sources, we try to capture as much as we can to simulate you and your way of thinking. We create a personal, basically a personal Wikipedia of you, of the people in your life, of the things that you care about, you know, what you do every day, documents, transcripts that you want to create. And then what we do here is this, we create this personal understanding of you. Your Sentient has its own email, its own phone number, that you can talk to, and then we create this personal understanding on you, the way you think about the world, the way you reason about the world, you know, even your messaging preferences, the principles that you operate under. For example, I do, like, for example, prioritizing the user experience is like one of the most important things that I believe in when building a product. And that is actually what we believe at Sentience Company, where, you know, you start with the user experience and work backwards to find the technology that would best provide that experience. So this is my profile. If you go to Squad, you can talk to— you can see other people's profiles. So for example, Sam is our founder. This is the traits that his sentience have accumulated and understood about him. This is his principles. And the nice thing about it is that this is completely personal. What I mean by that is when I ask a question to Sam's sentience, his answer is going to be specific to him, taking into account his personal preferences, his unique way of looking at the world, what he cares about. even the things that he had during that day, which is incredibly more powerful than asking a question to a one-size-fits-all AI agent. A good thing that I always talk about is when I actually make a judgment call on a product decision, I can't ask every single thing, right? So what I do is I ask Sam's sentience, And then it usually gives me a way better idea on what to consider because this sentience has its own context, its own communication channels. So it has the context. It knows what other engineers are working on. It knows what his company for the vision for a company is. And it answers based on that. For example, a question I like to demonstrate a lot is like, I have 2 options to build a feature. One of them is to do user research and spend spend time, uh, like, let's say, uh, spend time, uh, deliberating, uh, the, the right approach, uh, and the other one is to, is to just ship it and iterate over time. And this is okay. Um, I'm gonna ask the same question to ChatGPT as well, and I want to show you guys the difference that, that Sam's sentience here would make. Uh, so I'll ask Same to ChatGPT as well. Yes, Sam's model has returned. He said, ship the smallest real version, then put in front of 5 users immediately. That's incredibly true. Sam always values shipping super fast. This comes from a lot of his memories that have accumulated over time where his sentience observed that he's incredibly fast. And even in his traits, you can see that his pace is somewhat on the urgent side. Whereas I'm pretty sure that ChatGPT gives you middle-of-the-way answer. You're choosing between reducing uncertainty and learning through shipping. It's like completely useless answer in my opinion. It doesn't help me at all. Whereas Sam's sentences, actually, it's pretty direct. Like, it's like, ship the small real version. Uh, it doesn't like over-explain all that stuff that I don't really need to hear. Um, so that is basically, uh, the core of Sentience, uh, product. Obviously there are like many more things, but, uh, that, that is the core, core, uh, experience. So now I'll talk about, um, I'll talk a bit about how we, um, how we build this personal agent and, uh, the, the lessons that we've learned. Uh, for context, uh, I have joined Sentience in February, so we've been— I've been building this about 6 months now, uh, and the company itself is, is, is very young. Uh, we have launched in private beta, and next week we're gonna launch out of closed beta and it will be available to everyone. If you join now, you'll actually get 3 months for free on our highest usage tier. And during this time, especially after launch and closed beta, we had a lot of iterations and we faced a lot of problems that I am sure that if you're building agents today, that you face as well. And through trial and error, and through some of them, through principles that we had, and some of them through trial and error, the hard way, we've come up with these 4 principles that we believe are like our ground truth. No matter what, we consider these 4 principles in everything that we do. So to talk about these things, I first need to explain the common traps, what people think that they need when they first start and start building a personal agent, right? The most common thing that I see is This idea that you need this very complex system. This graph here is actually from Unreal Engine to build this gameplay loop. But as you might know, there are many systems like this to build agents, right? There's N8N, there's like some others where you need a bunch of nodes connecting to each other and they all like go through different architecture, different paths. A sub-agent calls another sub-agent that calls another sub-agent that does a RAG retrieval and then goes back to results. And like, that goes out of hand. Every new feature you add, it like exponentially gets messier and messier and messier. And after you go through this initial phase, let's say like initial week or 2 of building this agent, you have this like very complex architecture and you think you need this, right? You think you need that architecture, that like that complex system, especially if you're an engineer. It feels nice to draw things out in a whiteboard and come up with nice systems. It's a very satisfying experience. But actually, this is a very big problem that will hinder your success in making a great agent. And that is all this complexity, all this diagrams and nodes, it masks match the actual thing that you need to build, that match the actual problem that you need to solve. For example, you want to store the latest data about a given topic. Let's say the AI workshop that I am now presenting. You can just have agent write it in a Markdown. It's actually very simple. And then you look at it, does it solve the problem? Or you can do an entity graph where each entity connects to another entity in a different way, and you filter by time and date and relevance, and then you do a relevance score and give the result. And oftentimes, all that work, connecting a bunch of entities, bunch of nodes, coming up with a recency algorithm, It hides the fact that you need to store information and you need to be— you need to serve that information at a given time. So make sure that every new, net new thing that you're adding is a mask that filters what actually matters. So you have to be very careful. I mean, there are places where entity systems matter. We did end up having a version of an entity system in Sentience. But the way we got there is that we were really sure that that was solving a problem that we, we needed to be solved, and it couldn't be solved with a simpler solution. We actually implemented the simpler solution, saw that it didn't work, and then went on to the complex one. And a very good example of this is actually, uh, the coding agents, the way coding agents have developed. Uh, if you remember the first version of Cursor, That was a, you know, it was a VS Code fork. It had the tab complete. You hit tab and it completes and it was awesome. And what they tried to do is they tried to index your entire codebase, you know, put it in a vector database and retrieve like a RAG retrieval from there, right? That was the initial idea. They tried that. A lot of, at the time, a lot of calling agents had this idea of building like this entity graphs, and it would traverse through this entity graphs and function relationships, and I would go to the right place and get the right data, right? That turned out to be an incredibly inefficient way of doing things. And what they ended up doing is basically using this good old tool called grep. You know, grep, uh, if you're non-technical, is, is a tool that lets you grab any strings or words in a file, in a file system. So just by looking at words in your codebase, that's all they were doing, looking at words in your codebase, they were able to get to the right place much faster. And they all adopted this. And the first one that, you know, went crazy, Claude Code, was heavily based on grep. Cursor later on just started doing keyword searches. And today, keyword search is one of the biggest parts of coding agents, and it's so simple, right? But it actually solved the problem. So a lot of times a simple solution is enough and it actually solves the problem than a complex solution. The complex solution needs a justification. And actually there is research behind this that shows that grep just keyword search is actually much, much powerful than some other methods that we've tried in the past. So that brings me to my number one principle, is keep it simple, stupid. This picture is from a website called grokbrain.dev. Anyone building anything, this is the website that I think You should read and internalize and know it by heart. It's a funny website. It assumes you're like a dumb person that will forget everything, which will force you to make everything super simple. And you will be thankful that you kept everything super simple. So that's our first principle. So another thing that people think that they need, but in reality that they don't, is this memory layer that is offloaded to someone else, right? That is also a different version of the same principle that you think you need this complex and messy architecture, right? So the idea is that, hey, I want to build a personal agent with good memory. and it needs this messy architecture, right? What is the logical thing that follows? I need this memory layer that is going to do that for me, because if I need that very complex things, I'm better off handing it off to someone that does it better and like using their system rather than my own, right? Well, you don't need a complex system in the first place, but if you do, It's way better that you build it yourself, right? The reason is the type of agent that you're building, if you're building something new, is unique to you, right? It's unique to the way you built it, unique to the way you want to take it. The unique— the product direction is unique to you. So whatever memory system that they have is not going to be able to work with the, with the thing that you're building, or you will, you will do a lot of work plumbing that in. And these like memory systems come up with benchmarks, benchmarks that say, oh, we're, we're better at like, uh, memory retrieval by, by 5%. On what? Like what metric did you— like what, what are you better at retrieving? Are you better at retrieving the specific memories that the Sentience product stores? Are you better at retrieving— like, for example, for Sentience, the question would be, are you better at retrieving the memories that are most relevant to me at the time that I want it? And those 2 questions, most relevant to me at the time that I want it, is very specific questions to the Sentience product. Obviously, the memory system, even if we need a system, The memory system that we build ourselves will be much, much better suited for that, right? So for example, the Sentience product has to do an incredibly, incredibly well job of storing and capturing and surfacing your values, your preferences, your expertise, the people in your life, the projects, and the places. These are like incredibly valuable, right? Um, and these are incredibly specific to the— to our, our product, our customer base, uh, the vision that we have for the product. Obviously, we have to, uh, we have to build it ourselves. Uh, we can't offload to a third party that says like, okay, throw all the memories to my system and it will give you the best, uh, best, uh, uh, best retrieval based on based on this benchmark that doesn't have anything to do with the things that I want to store. So the question that you should keep asking yourself is this. How does my agent do across the success criteria that I've set? Success criteria that we set at Sentience is that it surfaces your values, preferences, expertise perfectly. That is our success criteria. It's not some random benchmark that I don't know what it measures. It surely doesn't measure whether it can surface my values, right? And that brings me to the second point. The second principle that we have is always start from the user experience and work backwards to find the right technology that would enable that user experience. I think it's Steve Jobs that said it the first time. At least I've seen him say it on an old YouTube video. You should research it, it's a great video. And I think it's very true, it's very fundamental to tech. And what that looks like in building personal agents is that I need to surface your values, I need to capture— for example, for us, I need to surface your values, I need to capture them somewhere, and I need to serve them at the right time. Okay, how do I make that possible? What the wrong approach looks like is this. I want to build an agent. It needs to be very complex because it's a hard thing to do. Because it's a complex system, I need a memory layer. And now I have to figure out how to make users want this complex system that I make— I made. It's like completely opposite way, and it's not going to work. So, second principle is always start from the user, work backwards. Figure out the technology. And now that I've talked about what people think that they need, I'll talk about what we found out that is extremely valuable. Am I in the— All right, continuing the show. Sorry, technical, uh, difficulty. Okay, um, what we actually need— we need to look at the monster that we have created at all times. We need to see the monster in full view at all times. And what is the monster? The monster Is the system prompt. The monster is the is the agent's context window. Okay, LLMs the way they work is tokens in tokens out. The tokens that you send in, if you keep adding and keep adding and keep adding, it becomes a monster. So what happens is, and what this definitely happened to us, and it becomes this monstrosity, is. We added a feature. You know, it wasn't getting the times right. You add a section to the system prompt about times. Okay, now it's not searching emails properly. You add a section to the system prompt on okay when you search emails, please make sure do this, do that, do that. Okay, cool. Or or you update the tool description to a a much larger tool description that says. Okay, when you want to reply to an email, make sure you pass in this variable and that variable and this. Okay. And then you keep doing this and you say like, okay, when you talk about sentience, you should talk about, you know, you are that person's digital simulation. You have to talk about this and that. Um, that layer grows and every new instruction that you add, you add makes all the other instructions less valued.

Right?

And then the system prompt becomes this monster. So what we need to do is always see that monster in one place and in full view. John Carmack is a legendary game programmer, game developer. He has this quote that says, if you're going to make a lot of state changes— He says this about actual programming, but it applies to agentic, you know, developing agents as well. If you are going to make a lot of changes, having them all happen inline does have advantages. And he says you should be made constantly aware of the full horror of what you are doing. And what that means in, in, in, uh, in developing an agent, you should have one place to see what goes in, right? If you have, you know, 50 different prompt components that all go to different parts in different times, it's not gonna— you're not gonna be able to see it in one time, and you're not gonna be— you're not gonna know what a monster it is, right? You need to be able to see it in one time, in one place, and you'll have that look in your face that Jimmy Butler is having here, you're a little bit like, what is this? And then you trim it down and you get it into a nice shape so that your agent can perform well. This is incredibly important. So this brings us to our 3rd principle, which is at any given time, make sure that you see the full state of the context window. Of the system prompt, you see the monstrosity that you have created. This the the last point, which also speaks to what people actually need, is is something very boring. We have to suck it up and do it. We have to be like this guy looking at the. Looking at the results, which is doing evals, evaluations, right? The thing with developing with large language models is that they're not deterministic, right? You can't guarantee solutions. If you're an engineer before the LLM era, Before AI, you write some code, it works, it does the thing, and that's it, right? If it does the thing, you can be sure, if you handle all the edge cases, you can be sure that it's going to do the thing. That's a given. What happens with LLMs is you add an instruction, you add an instruction, you add an instruction again, and then it stops following the first instruction you added. And you've played this game of whack-a-mole where you fix something, Okay, now it's like finally listening to me when I told it to not use mdashes. All of a sudden it mixes up all the days. Okay, I fixed the days. I added another, another thing into the system prompt. Um, okay, now all of a sudden it like confuses me with, uh, with some data that was like, uh, confusing what I said with something I said like 3, 3 months ago. So the way to solve this problem is that understand that every change that you make is going to affect every other thing, unlike code where you make one thing and that does one thing. And the way to solve that problem is to run evals first, right? What evals does is— and you don't need to complicate this. Again, keep it simple, stupid. You just need a set of test cases that you run after you make a change to the agent, and you make sure that like the answer doesn't go terrible. That's all. You know, you can use an LLM as a judge. You know, you can have another LLM evaluate the result. You can go through it yourself. You can have some other criteria. To be honest, I don't think it matters much. It matters more that you do it. And you have some way of doing it. The specific method, whether you use LLM as a judge or you judge it yourself, you hire people to judge it for you, it's specific to your situation. It doesn't really matter. You should make that call with the context that you have on your own project. But otherwise, we have this problem that you think you solved the problem, but, you know, a user uses your product and comes back with like, why doesn't it work? And you're like, I thought it fixed. I told the agent it was fixed, but it wasn't fixed, right? So you need to make sure you run cases and you make sure that the agent— that something you do doesn't regress other things. So that's our 4th principle in developing an agent is run evals first. And evals are incredibly important. It catches a lot of things that would regress otherwise. It makes sure, to the agent that you can, to the degree that you can be sure developing with AI, that it's going to work the way you intended to. So those are the 4 principles. And that brings me to the end of my presentation. So I will hand it back to Angelina and— Thank you, I can answer questions.

Hey, Ahmet. Yeah, thank you so much for the presentation. It's so cool. This is like building a personal assistant is a hot topic right now. Everybody is taking a stab of some sort, right? We're using AI and hoping that we can all have this chief of staff that can solve our personal, you know, Daily chaos.

Yeah.

Right. But there are a lot of challenges there as well. Actually, for everyone, Sam, the Sentient CEO, was actually on the podcast and we will release this episode next week so you can tune in to learn about more of the backstory of the company as well. I'm not seeing any questions right now on the through the chat, but I have some questions for you. I'm curious, you as a founding engineer, how does it feel like working for a company like Sentience, a startup building on cutting-edge AI agents? How does that feel?

Yeah, it feels very exciting. It's very, obviously it's very intense. The rate at which, the speed at which we develop is like, Really mind-baffling. At any given time, I'm running like, you know, between 6 to 10 agents in parallel and try to coordinate all of them. But I think the thing that strikes me the most is how fast we make decisions. There's not much of like, you know, let's deliberate this and let's sit on this for a while. It's like, okay, what do we think? Here's what I think, here's what you think, here's what we're gonna do. Done. Now you go and implement and you see how it goes. And it's like, it's incredibly fast. I think a lot of things that would take like months in like larger companies, I do think it takes us like a day or maybe like half a day. We don't really have a lot of— we have this principle of directly responsible individual. So that means, let's say I do the iMessage integration. I make the judgment calls. I am responsible for it being delivered fine. And if there are problems, it's also my responsibility, right? But it's also my responsibility to discuss it with anyone that is impacted or anyone that needs to know about this, right? Obviously, I'm not going to make a huge product call without talking to Sam about it. But it really collapses down this layer of Hierarchy or discussions and meetings, and I just go and do it. And if I need to talk to someone, I talk and come back and do it. Like I have like on average point like point three meetings a day. I have like yeah, I have like on most days I don't have any meetings. I just do it. If I have to talk to someone, I just talk and come back. Or I send them a Slack message. So that's the way we do, which I like to work this way. So it's very fulfilling for me. Obviously, it's long hours and intense, but we have to be. If you're developing at the frontier, you have to be.

We have some questions in the chat. So one question from Fangxie5806, how to ensure privacy in the process, creating personal agents.

Yeah, 100%. This is like one of the most important things that we are— that we have to handle very carefully, especially a company like ours where people— and I should say like very, very influential people that, you know, I can't say, but like they handle a lot of critical data— uses our product and they give, you know, their data. So the way we look at it, A, like obviously we have all the standard security practices. Our database is encrypted. A lot of other AI startups don't do this, but engineers, we do it. Engineers don't get— can't see production database. Like we don't have direct access to the production database. What that means is like sometimes users say like, hey, like my Run failed, or it gave me a weird answer, and can you like look into it? I was like, I can check the logs, I can check the system, I can't see your data. Or some people, so it's like, can you delete this specific memory, right? I was like, dude, I don't have access. I can't like, I can't delete, like go into your account and check these things. So, but we made that call because this is like incredibly important that users trust. Um, the way we see it is that, uh, and, and you can check our website and, and read this, read our terms, but we really believe that you own your data. So, so you have sovereignty over your own Sentience and your Sentience's data. So it's actually legally belongs to you, it doesn't belong to us. Um, so that is the way, the, the way we see it. Um, yeah, obviously other than that, we are I think compared to an average tech firm, way more conscious about security and like, you know, all the security practices, making sure everything is like failproof. There are no like backdoors or any ways in which people can like mess with the system. Everything is like encrypted. So yeah.

If you can't really access any of the data, then how do you solve some of the problems if you don't see some of the examples, right?

Yeah, yeah, yeah.

What's the balance you have to strike there?

Yeah, it's actually a very hard thing because what we do is we have a development database that the engineers have, right? And then the production database that we don't see. So if it's like a technical issue, we have logs like without saying any personal information, but you can see that a chat was created at this time, right? You don't know who, where, how, like whatever. You don't know like personal details. So we can check logs for system issues. But for things like, okay, my agent didn't answer this properly, I'm like, if you're comfortable, can you share me a screenshot? Now I try to recreate that on my account and it doesn't always work perfectly, but that's like a trade-off we accept. We will try to create the recreate the issues that we have on our accounts. We will ask users like if they can like give us more details about how the agent behaved and everything. But besides that, we're not going to look like we're not going to look into. We're not going to be able to do that. So so like that that's a trade-off that we accept. Thankfully, a lot of issues if you happen to you, it probably happens to someone else and it's. I can probably create it on my account as well, recreate it.

Another question. Do you suggest using flexible plugin-based harness like DeepSeek harness for building a personal agent?

I think maybe. I'm not very deeply familiar with DeepSeek's agent harness. My take usually is to— build your own thing to the point that you want to customize it. So that's my take. I think if you want to get a full— I think depends on if you want to do it for yourself personally, you can do it, or you can use like a pre-existing one. If you're doing it as a company, as a startup, Obviously, I believe like you should do it your own, your own harness. Own your harness, I think it's a big thing. If you just want to have a good agent to do it personally, you can try Sentience. Or if you want something more technical, if you're more technically inclined, you can build your own.

And when you said keep the architecture simple, what simple patterns would you suggest?

Okay, so for example, we had a good discussion about this. The way our memory system is largely Markdown-based, right? It's a lot of Markdown files. It's a lot of Markdown documents. You can build a memory system way more complicated. You can do an entity graph. And you can define relationships of those entities. So for example, each person, you would have a role. That would connect it to other people and connect it to other topics, and that would connect, and then your agent would traverse through this entity graph. I think that's a very much complex architecture than having markdown files and agents do keyword search of those markdown files. That's like a much simpler architecture. I think it works way better. Um, so that's like, that would be one example. Um, uh, yes, so things like that.

Yeah. Somebody asked about, you know, if they can try out Sentience Agent for the first 3 months. Actually, I mean, I'm trying it out. I think it's pretty cool. I'm also building my own personal assistant, so I'm comparing, like, is my personal assistant as good as Sentience? So every morning I get a morning briefing.

Oh, cool.

from Sentience, and I create my own, and I'm just comparing it. So far, I haven't been able to beat Sentience for trying to understand my context, which is pretty amazing because I think I provide definitely more context than what I give to you guys.

I see. I would say, yes, I encourage everyone to try it out. It is free for 3 months. What would be incredibly valuable for us is if you give as much feedback as possible. We have a Discord channel. Also, you can just ask your sentience to give feedback. You can just say like, hey, can you like tell this problem that I have to the sentience team? And we actually receive every single one of those messages in our Slack channel directly. So that's like a direct way. If you tell, if you, if you use a product and tell us like, hey, this sucks, I hate it, like, that's awesome. Like, tell us. Like, please do. Uh, please do. Um, if you love it, uh, also please, please tell us. Um, but, uh, actually I would prefer more if you hate it and then you tell us so we can like improve. So if you hate it, if you don't like it, if you're indifferent, if you're, if you're like, hey, I, I, I use a product but it's really not for me, or like I didn't really I used it once and I didn't come back to it. Awesome. Tell us why.

Awesome. One more thing. I think you mentioned earlier about this private data that we own as users. We own our data, we own our context. Does it mean that I can delete all the Markdown files if I use Sentience and decide I don't want to give out my data anymore?

Yeah, yeah, we have the option within the app. If you delete your account, we delete everything. We literally delete every associated thing. So yeah.

And what does that exactly mean, the data sovereign for users? How's that different from OpenAI, how OpenAI is treating the user data?

I think a lot of these large firms, First of all, obviously I'm not like, you know, in OpenAI, so I don't know their specific procedures. But, you know, I know I talk to people in these large firms. If they really need to, they can, they really can go and see the data. Or for some firms, they just like have all access, like people can see it. The other thing is, especially like companies like Facebook and Google that largely make money through advertising, you know, your data is the product, their product is your data, right? And they sell it to advertisers, which are their real customers. We don't operate under that model. We don't do ads. So your data is really your data, and the product is really the product, and you are the customer. So So that's the way we see it.

One more question. Memory, you suggested Markdown. What do you suggest for knowledge base? VectorDB or something else?

I think vector databases are great at storing like specific pieces of information. Like, you know, you wanna index all the messages that you get. I think it's great for things like that. You want to index images, do searches. Markdown is better for, I think, more persistent data. So the state of something's latest value, right? So that's the way I see it. So, I mean, personal knowledge base can mean Many, many things. But yeah, I think those are the way that I would differentiate the two.

Particularly for personal knowledge bases, you know, they're asking, do you handle tabular data, structured data?

Yeah, I mean, if you want to like, in Sentience, if you want to sync your data like a some structured data source, you have like a Postgres table somewhere. Like, we don't do that. We do connect to Google Sheets, so like stuff like that we do. But Sentience at its core is a consumer product, and it's not— we try to be— we try to have it such that it's easy to use, and there aren't that many different things to configure.

Yeah, that makes sense. You don't want to deal with the large data, structured databases. And for personal use, we probably don't have that kind of data.

I think there are like 2 approaches to this. One of them is like you keep the product very modular and it can connect to everything. It can do whatever you want. But then you lose that connection, that control over the experience of the product, right? you can't really achieve the product vision you want. And that works very well for actually developers themselves, right? Because developers want to customize everything to every single detail. For example, I love Vim, NeoVim, because I can do every custom configuration. Whereas I think for most people, they want to have something that is easy to use, and is well-made, right? But it's very hard to make something that's well-made, that's easy to use, that's intuitive, and have like this approach of like being modular and connecting to everything, you know. So that's the— we took the— we take the secondary approach.

Awesome. Yeah. For any more questions, I think, are you open for folks to reach out to you directly? I have your LinkedIn here. So if our audience is wanting to ask you questions directly, can they reach out to you?

Yeah, of course. Feel free to reach out, send a connection request, send an email. On our website, you can talk to my sentience if you want. So yeah, obviously you can. Please do. Please reach out. Actually, I would be very happy.

That's another interesting feature. We can get immediate response from you basically just by talking to your assistant.

Yes, yes, yes.

Right, awesome. Okay, so once again, Ben wasn't able to make it today, but we will definitely invite him to come again and talk about this voice and style side of building a personal agent. And 3 more things before we wrap. One thing is you guys have the referral link, so you guys 3 months for free for Sentience. Try it out. If you're building personal agent, try it out and compare yours with that. This is what I'm doing. This is very interesting and you learn a whole lot through it as well. And if you do have questions, reach out to Armin and ask how he built it. Second, we are back next Friday, 10:00 AM Pacific time with Skanda. He's a founding AI researcher at Yutori. So Yutori, if you know about Yutori, I interviewed their CEO, Devi. Yutori is at the frontier of computer use agents. Those are the AI that can actually operate your browser or desktop for you, book a flight, fill out forms, things like that. They have— they built their own CUA model called Navigator-N2, and they're gonna come in and talk about how they built it and how they, reduce the cost of running a very, very expensive computer use agent. So if you're interested in that, come check it out as well. Lastly, again, my shameless plug. If you are— you find these talks very interesting, remember to subscribe and give me feedback. Reach out to me on LinkedIn and let me know what you want to hear about. I'm here to help you all gain the knowledge to help you build and be positioned to sell one day. Thank you very much. Thank you, Amit.

Really appreciate it. Thank you. Awesome. It was a pleasure. Yeah. Thank you for organizing this.

Thank you. Yeah. See you next week.

See you.