Leader Spotlight: Why every PM should build a personal agent, with Aaron Roy
Aaron Roy is Product Director at Manychat, where he’s building Manychat for Brands. Before Manychat, he was Head of Product at Teachable, leading Product, Growth, and Support across a platform that’s powered $2B+ in creator sales, and he co-founded Wami, a robotics company producing handwritten notes at scale for brands like Gucci, Cartier, and Prada. He was also part of the founding team at 3DPrinterOS, the first cloud operating system for 3D printing. Outside of work, Aaron is an outspoken advocate for personal AI agents, and he writes about his experiments — including the site itself, which he built with Claude Code — at aaronroy.com.
In this conversation, Aaron makes the case for why every PM should build a personal agent, not just a work one. He talks about how doing so has changed the way he uses the internet, what it teaches him about the agent-using customers now showing up to every product, how to pick a first project, what he’s learned from his own agent failures, and what it actually costs to get started. He also makes the case that, underneath all the practical upside, it’s just fun.
Why build a personal agent?
You’ve argued that every PM should build their own personal agent. What changes in the way someone thinks about products after they’ve actually built one for themselves?
I think it will blow their mind. It’s just such a different way of using a product. As a PM, you’re sometimes detached from the outcome. You build the thing, you wait to see users use it, you might watch user tests, you go to learn and you observe. The thing with personal agents is you’re a feedback loop of one — if you build the thing and it breaks, you’re in trouble immediately. In some ways that reminded me of originally playing with Tamagotchis, except the stakes are way higher. So it’s a very different way of building, but it also gives you such a perspective into the things that engineers go through and what your teammates go through.
You now have, not accountability, but you’ve got to take care of everything. The agent is the thing you’re interacting with, but you have to think a lot more about the prompts and the logic and the context. That’s why I use the Tamagotchi analogy — you used to have to water it, play with the thing. Where if you build an agent and give it no context and no tools, it’s like, “Well, it’s just a chatbot.” There is no difference. It’s kind of stupid.
But if you build yourself an agent and go through that exercise — think about what context you can give it, what you can teach it so it could be more useful for you, what tools you can give it so it can enrich itself further — that’s when your mind is blown. It becomes really, really useful, and it’d be hard to go back. I don’t want to do this manual thing over and over anymore.
How has it changed the way that you use the internet?
Obviously, the introduction of LLMs changed people from using search behavior to using chatbots. That was step zero. A lot of folks have already shifted to using ChatGPT and Anthropic to do search queries with a chatbot. The agent way of changing the way I use the internet is going beyond just search.
Here’s such a stupid example, but it’s fun: I was with my wife and we were recently looking at toys from the 1980s, just pulling things out of a pile. Before you might do a Google image search and then try to figure out how much a thing costs, but I already have these agents built. So instead we’re snapping pictures, sending them to the agents and just saying, “Go figure out how much this is. Go find the eBay listings. Go find the conditions,” and we’re sitting there feeding this to the agent — we’re just talking. I’m not even on the internet. I’m just snapping a photo, sending it off to the agent, and using voice to chat. And every few seconds we’d get back a response like, “That toy’s worth five bucks. That toy’s worth three bucks.”
It was so silly, but instead of me having to sit there and Google search and reverse image and then pull all this information together, you can delegate this little minion to go get the information and bring it back. It didn’t interrupt the flow of the conversation, and I think that’s the ideal. The goal is this should supplant and amplify the thing I’m currently doing without being disruptive.
What building an agent teaches you about your users
Many PMs are experimenting with AI through prompts and chatbots. What do they learn by building an agent that they wouldn’t learn just from using AI tools?
I think it’s incredible that PMs are experimenting, period. I think curiosity shouldn’t stop at just the chatbot. The thing they’re interacting with is an end product. There’s a lot to be learned by building an agent because it makes you understand what goes into it. It goes back to giving it context, and being responsible for it staying alive, for lack of a better term. How does an agent fail? And once you understand that it failed, you start to build things differently, because you need something that fails out loud. It can’t fail silently.
A person doesn’t expect to keep learning UIs. We’re seeing that change already. If you only interact with the chatbot, this little box is where the work occurs. The thing with agents is you’re bringing the agent to wherever you’re doing the work, which is very different. A chatbot lives in the chatbot’s window. So if you’re downloading Claude Desktop, you’re working in Claude. When you start to build agents, the agent goes with you where you need it to be. If you’re working in a terminal and you’re looking at financial data privately on your computer, you didn’t have to upload that to Claude and put it in the cloud. You can do that on your machine and your agent can be with you on that journey.
Even in the way I use products — if you have an agent, one of the first things you think about is, well, how do I get my agent to help me explore this product? People are less like, “Go build me a B2B product that I need to learn how to use.” Instead they’re saying, “I want to use your product. Can I bring this to this other thing I’m doing where my agent already exists?” An agent becomes a first-class product need. And if you’ve never built an agent, how the hell do you build for that? You don’t understand the user you’re building for if you’ve never built one. It’s like you’re blind.
Finding your first project
How do you identify the right first project? What makes a problem a good candidate for an agent?
What annoys you? I think that’s always where I start. The project most people recommend is to build a daily morning briefing; even I built tutorials telling people to do that as a starting point. But maybe that doesn’t annoy you, and so maybe you won’t do it. I think it’s great to build an agent for something that you find deeply annoying or deeply repetitive, and you’re like, “I don’t want to do that anymore.” That’ll motivate you to get through the learning to get to building the context so you don’t have to do it again.
How many agents do you have? What’s a good number?
I think one is a great starting point. Building one that is on and persistent and gets to know you is what I advocate for. One held for a really long time.
My Discord channels setup — being able to bifurcate an agent’s access to different channels and loading contacts in different channels — one agent can handle that. We just remind it what memory it should load when it’s in that channel. For instance, if I’m interacting with an agent in the inbox alerts channel, it’s flagged that we’re talking about email. I’ve given it a memory. It’s the same agent, but it’s saying which set of memories apply.
But I do have two agents now, and there was a reason for the second agent. The first agent is on a Raspberry Pi, and the RAM and the storage on that device is much less than a computer. I’m very interested in using more local models, and I’d like to give it more advanced use cases, like analyzing my finances, and I’d like to be able to give a more powerful machine with more storage so I can keep the thing inside my house, versus pushing this information to someplace that I have no control over and no visibility. So the second agent I’ve added — which, again, is just the name of the computer, it’s an M1 MacBook — is called Agent M1.
It has different tools. The first agent has general access, less tools. It can answer questions, it could work across channels, but it can’t cause too much damage. This second agent I built has more tools. M1 can self-administer my GlutenOrNot application. It can access the logs, it can file error reports, it can push code to fix it without me overseeing it. I’ve given that machine more power, piece by piece, as I trust it more and more.
Learning from loud failure
Can you talk about some of your agent failures that have taught you the most?
All the time, nonstop, 24/7. Using OpenClaw when it first came out, I probably spent hundreds of hours tinkering, and it was fail after fail after fail. But the ones I can pull better patterns from — I think letting agents fail silently is a big mistake, and I’ve learned a lot from it.
A great example: if I’m using an agent powered by Claude or Anthropic and the agent gets logged out, or the API key expires, it’s really hard, if you let that fail silently, to understand what went wrong. You could spend a lot of time chasing what’s actually a really basic error, like you’re logged out — that’s the error. But if you build the webhook or a notification to say, “Agent X has been logged out,” you save yourself from wasting a ton of time trying to debug.
A big mental shift for me was making sure agents fail loudly, making sure how they think is visible. So then if I send something to them and there’s an issue happening, we have some sort of log of the thinking and the dialogue and the interaction.
Another pretty big failure point for me: at first, I spent a lot of time trying to approve every single thing. Because I didn’t know what I was doing at all, I thought, “Oh, if I read all the interactions, I’ll figure it out.” I think that was not the best use of time. I learned more from letting an agent try a thing and screw it up than from trying to read the code it was writing.
The better approach was to understand: success for this thing is being able to classify emails, read emails and triage them. I decided I’d do an experiment where I give it 5% of my email for a week. Then, if it stinks, we fix it. If it doesn’t do a good job, we’re just going to work on it. It’s iterative versus, “It’s got to be perfect.” I would’ve gotten much faster learnings earlier on in working with agents if I was just willing to let it fail in a contained environment.
What it costs to get started
What should a PM who wants to build their own agent budget for?
Personally, I currently am using a Claude Max subscription, the $100-a-month one, and that is ample to power the two agents, because I’m using Claude Channels as a setup. Claude Channels is the thing that allows a persistent session to stay alive, and I can access it via Discord. You don’t necessarily need that. I know plenty of folks that are using OpenRouter and using different models and different setups, and they’re spending less than $50 a month. So I would say budget $100 to get started, get up and running, and then pretty quickly, once you figure things out, you could swap out anything you want with different models and setups.
I didn’t mention hardware, though. You can use old computers, that’s worth saying. I’m fortunate I had an M1 MacBook I was not using for this new agent, but originally I did buy a Raspberry Pi. You don’t need the newest one — you can get a Raspberry Pi 4 or 5 for, I think, between $100 and $200. I always recommend Raspberry Pis. They’re super cool personal computers that do all sorts of fun stuff besides building agents. It’s really small, barely consumes power and it can do everything a computer can do. But it’s slow.
Why it’s fun to build agents
If a PM spent a weekend building a personal agent, what would you hope they walk away understanding about the future of software that they didn’t understand on Friday?
I’m hoping by Saturday they get the agent alive, Saturday and Sunday they spend some time figuring out what tasks they’re going to give it, then Monday comes and maybe they’re reflecting. What I would hope for them is they enter Monday understanding that the internet and the way we’re using it is changing. No matter how you feel about it, I don’t think agents are going away. They’re so convenient, and as soon as people get convenience, they’re very unlikely to put it back in the box. So a transformative outcome for a PM would be just feeling that in some capacity.
That’s why I always advocate for finding something that annoys you, because the minute you offload one thing that annoys you to an agent, you’re like, “Oh, what else annoys me?”
Apart from the learning aspect, is it just fun to do something that’s not work-related?
One-hundred percent. That’s why I advocate for personal agents — I am not here to offload building an agent for work. Software tools are going to do that for you. Every freaking company’s building an agent at this point. But building a personal agent — who’s doing that for you? The fun here is you are building something for yourself that can benefit you in your life. It’s a piece of technology, so as excited as I get, it doesn’t replace the human side. I like building things. That’s why I got into product management. I just knew I like to build stuff, and I’m not a real engineer, and building agents scratches that itch of building something.
I am the user of the thing I am building, and I’m continually surprised with the things I can do with an agent. At first, I was having an agent watch my email. Sure, that was cool. Then I was figuring out how to build another agent that can watch Twitter using a Twitter API to give me information I want. You start to stack these things up, and piece by piece you’re like, “Oh wow, each of these little functions in my life that required some form of overhead or mental capacity, I can now offload back onto an agent.” It’s a bit freeing.
So, it’s fun to build, and then it’s fun to get time back, and have more time for the stuff you want to do. I needed to figure out a part for a cabinet in my house that broke, and I did not have the time to fix it. Instead of having to go log into Claude and sending a photo and doing all that stuff, it was just a conversation. I flipped it to my agent, came back, and had three Amazon links with the dimensions, assessed off the photo. That is a thing that would’ve gone on my to-do list and sat there for two weeks. Instead, in conversation, in flight, handed off, got back a result, able to order the part, not a beat missed.
My to-do list that used to be 20 items long, maybe there’s still three items on the list, but they’re really the ones I should do. I’m throwing the rest to the agents — let them get on those things that would’ve just sat there.
What does LogRocket do?
LogRocket’s Galileo AI watches user sessions for you and surfaces the technical and usability issues holding back your web and mobile apps. Understand where your users are struggling by trying it for free at LogRocket.com.