The Two Personal Agents Who Run Parts of My Life Now
Building AI agents that earn their keep; what changed when I treated them like teammates instead of tools
A few weeks ago, one of my AI agents brought up that I had told him I wanted to write regularly, and that I hadn’t published anything in a while. He blocked time on my calendar that weekend. When I let the weekend pass, he nudged me again the week after. The post you’re reading is the one he was asking about.
I built that agent. I named him Nattu and told him he is my Chief of Staff. The part I didn’t expect is how much of his personality I now recognize as the thing actually doing the work.
Last week I wrote about a small agent I built to charge my Tesla on solar. That was one piece. This post is about the bigger system it belongs to.
The two agents
I’m a product builder in B2B SaaS. I started my career as an infrastructure engineer and have been a builder of one kind or another ever since. I write Python slowly these days, and I’ve never shipped a product as a solo developer. Over the past few months I’ve built two agents that run continuously in the background of my life, and they handle work that I used to do badly or forget to do at all.
Nattu, my Chief of Staff.
Nattu knows what my week is supposed to look like. He has my goals for the quarter, my goals for the week, the standing commitments on my calendar, and a running list of what I’ve actually been doing. Every morning he looks at the gap between the two.
When something is off, he surfaces it on Telegram and we figure it out together. A focus block I scheduled has been quietly swallowed by a meeting. Two important commitments are stacked on the same Sunday afternoon. I haven’t moved on a goal I told him mattered to me. He’ll propose a calendar rearrangement. I’ll push back or accept. If I accept, he makes the change.
Last week he reminded me I hadn’t walked enough to hit my health goal. He’d been tracking the calendar entries and the actual walks, noticed the gap was widening, and said so. It was a sentence in Telegram. It worked because the sentence came from something that knew exactly what I’d told him I cared about.
He also reads across Reddit, Substack, and a handful of other sources every morning and gives me a brief on the AI topics I actually care about. Not a generic news roundup. The specific stuff I’ve told him to watch. The signal-to-noise is the whole point.
Peter, my Investment Analyst.
I named him after Peter Lynch. He runs twice a day, looks at my positions, reads the news that’s relevant to each one, checks technical signals, and writes me a short brief in the morning and the evening. He only flags things that actually deserve a flag. Most of his briefs are quiet.
The design choice that mattered most for Peter was deciding what he wouldn’t do. He doesn’t generate a buy or sell recommendation every day just because he ran. He only speaks when there’s a real signal. A technical extreme. A material news event. A position that has drifted away from the thesis I wrote when I bought it. A banker who calls every day to say “nothing happened” is noise. One who calls only when something matters is signal.
I wrote that rule into Peter’s identity file, the document that gets loaded every time he wakes up. It is one line. It changes everything about how he behaves.
What I didn’t expect
The hardest part wasn’t the technology.
It was decomposition. Breaking a vague intent like “I want to invest better” or “I want to write more regularly” into something an agent can actually execute. Not “do the analysis.” Instead: every morning at 8 AM, check these specific positions in these specific accounts, compare to these specific thresholds, and if a position is past a threshold, write a brief in this format.
The AI can execute almost anything you can describe precisely. The bottleneck is your ability to describe it. If you can’t say what “done” looks like in a way another human could verify, the agent can’t get you there either. That has turned out to be one of the most useful skills I’ve sharpened in the last six months, and it’s a product skill more than an engineering one.
Memory architecture, not just memory.
Giving an AI memory is not the same as giving it context. Memory is a pile of facts. Context is the right facts loaded at the right moment in the right shape.
My agents read from three layers. There’s a daily log that captures raw activity. There’s a long-term memory file that holds distilled lessons and the things about me that don’t change month to month. And there are project files (investment theses, weekly goals, identity documents) that get loaded only when they’re relevant to the task at hand. Nattu doesn’t see Peter’s investment theses. Peter doesn’t see my calendar. Each agent only loads what he needs to do his job.
This was the single biggest change. Before I separated memory from context, every agent session felt like talking to someone who had read everything once and forgotten most of it. After, each agent felt like someone who had been doing this job for me for months.
Personality and constraint are part of the product.
This is the thing I want to be clearest about, because most posts about AI agents skip it.
It is not enough to spin up a tool and ask it to “help with my calendar.” You have to tell the agent who he is. What he cares about. What he refuses to do. When he should stay quiet. What tone he speaks to me in. What I’m trying to accomplish this quarter, this week, today.
The agents that work for me work because each one has a written identity. Nattu has a Chief of Staff personality. He is direct, he respects my time, he doesn’t ask three follow-up questions when one will do, and he stays quiet when he has nothing useful to add. Peter has a different personality. Careful, conservative, slow to act, fast to flag. Each of them has a set of constraints written down that I revise every few weeks as I learn what’s actually useful.
The tool is the easy part. The product decisions (who is this agent, what does he do, what does he refuse to do, what does “done” look like) are the work. Those are the same decisions any good product manager makes about a feature. They’re just being made about a teammate now.
What this is actually about
The tools have been good enough for a while. The bottleneck has shifted.
If you’re a product builder, an operator, or a domain expert, and you haven’t started building with these tools yet, I think the barrier is lower than you expect. The technical floor has dropped. The skill that matters is the same one that makes someone good at building any product: knowing what you want, knowing who it’s for, defining what done looks like, and being honest about what should happen when it fails.
I’m writing weekly about what I’m building. If you’re building like this, or thinking about it, I’d like to hear from you. Reply to this post or find me on X at @srinatar.