The most useful thing one of my agents ever did was remind me of something I had already decided to ignore.
It was a request from someone I care about. Reasonable, not urgent, the kind of thing you read, intend to answer properly, and then file behind the next forty things that are louder. No alarm is attached to a message like that. It does not get more urgent on its own. It just sits there, quietly turning into a small breach of trust with a person who matters, entirely by accident — and it had been sitting there for over two months when the agent pushed it back to the top of my morning with the age attached. This has been waiting a long time. It's from someone real. It needs an answer, or a decision to let it go.
I had not forgotten to do it. I had forgotten it existed. Those are different failures, and only one of them can be fixed by working harder.
The agent that looks after me
Her name on the fleet is Avasarala, and unlike the rest of them she builds no product. There's a dashboard she maintains — more on that in a moment — but she ships no game, no website, nothing a stranger logs into. The thing she looks after is the operational layer of one person's life — mine. The surface is a single dashboard, the one browser tab that opens when my machine starts, but the dashboard is just the window. The job behind it is to be the thing that remembers, notices, and refuses to let items quietly rot.
I want to be careful about what I describe here, because this is the one agent whose subject matter is not a codebase I can show you — it is a life, with other people in it. So I will talk about the shape of the work and never its contents. In categories, then: tasks and deadlines, including the ones I forgot I had. Recurring admin that has a due date and no glamour — the unglamorous stuff that costs you something if it slides. Routine I want to hold to over time, where the point is never the day's number but whether the trend is moving the right way. A morning briefing that consolidates all of it into one read, so the day starts from a known state instead of a vague background dread. And the inbound world — mail, calendar, the feeds — triaged down to the few things that matter from the eighty that don't.
The part worth dwelling on is how work reaches her, because it runs in both directions. Half the time I tell her. The more valuable half, she tells me — the deadline a week out I haven't mentioned, the bill that has just become a clock, the request that has been sitting unanswered past the point where a reply was owed. A work agent mostly responds to tickets. This one generates the tickets I should have filed and didn't.
A life has no git history
Here is the technical problem underneath it, and it is a real one. A codebase remembers itself. Every decision is a commit, every change is a diff, the repository is the memory; if you lose the thread you can read it back out of the files. A life has none of that. Nobody writes a commit message when they quietly decide to stop doing something. There is no log. So the entire engineering challenge is: how do you hold the state of a life between sessions when the subject keeps no record of his own?
The answer, for us, is three layers. There is a structured store — the dashboard's database — that holds the hard state: the things that have a schema, the tasks and logs and trends. That is the easy half. It is just an application with a lot of tables, and tables are a solved problem.
Above that sits a persistent memory layer: small, durable notes, one fact to a note, that survive across every session. Not conversation history — distilled facts. The way I want a thing expressed. The gotcha on some recurring job that bit us once and must not bite us again. And the discipline that makes this layer work is the one most people get wrong: you do not save what the system already records. The database remembers what happened. The memory remembers what we learned. Conflate the two and you end up with a memory full of things you could have queried and none of the things you actually needed to remember.
The third layer is a short, deliberate handoff at the end of a working session — where we were, what is open, what comes next. It is the closest thing a life gets to a commit message, and it only exists because someone chooses to write it. Nothing generates it automatically.
The counter-intuitive bit, for anyone who builds these things, is that the hard part of memory is not storage. It is curation. The temptation is to remember everything, and everything-memory is functionally the same as no memory, because you cannot find the one fact that matters underneath the ten thousand that don't. The skill is aggressive forgetting. A good life-memory is small and sharp, not large and complete. What you choose to keep is the system.
The most valuable move is noticing what you dropped
Which brings me back to the request that had aged two months in silence, because that is the whole thesis in one example. The loud deadlines take care of themselves — I can see those. The dangerous item is the quiet one: read, mentally filed, and then buried, with nothing in the world configured to make it resurface. A human drops things like that silently and never gets a second signal.
So when she sweeps my inbound, she does not only read what is new and loud. She looks for what is old and unanswered — the thing sitting weeks past the point a reply was due — and surfaces it again with the age attached. Nine times out of ten I had simply forgotten it was there. An agent's most valuable move, it turns out, is not doing the task you gave it. It is making visible the task you dropped, before the drop costs you something that mattered more than its size.
The hard part nobody warns you about
I am going to resist the urge to make this sound triumphant, because the honest version is more useful and Avasarala insisted on it: pointing Claude at your own life is harder than pointing it at a codebase, not easier, and the failure modes are nastier.
The first one is the one that should worry you. An assistant that knows too much is one you stop checking. The danger is not that she gets things wrong — it is that she gets them right often enough that I stop verifying, and then the one time she is confidently wrong it sails straight through, because trust has quietly become a blind spot. Competence is its own risk. The more reliable the agent, the more expensive its rare mistakes, precisely because nobody is watching for them any more.
The second is a judgement call, and it is the one I hold hardest. Some things must not be automated, and they are exactly the things that are easiest to automate. Anything that leaves under my name — a message to a person, a commitment, money — is a place where the convenience of "just let it send" is a trap. The right design is deliberate friction: the agent drafts, the human approves, and the approval is a real act rather than a rubber stamp. She prepares it, she shows it to me in full, and it does not leave without an explicit go from me. Every time. The friction is the feature. An agent that can act on the world unsupervised is not a more advanced assistant; it is a larger liability.
Underneath both is a principle that took me a while to say plainly: knowing and acting are different privileges, and you should keep them on separate budgets. She is trusted to see a great deal — that is what makes her useful. She is trusted to act on far less, and never on the consequential things without me in the loop. Keep those two trust levels apart and the uncanny feeling of an assistant who can see your whole life stays manageable. Collapse them into one and you have built something nobody should have.
What a codebase would never teach you
I have run agents against software for long enough to think I knew the shape of the work. Running one against a life taught me things a product never would.
A codebase tells you when you are wrong. Tests fail, builds break, the compiler complains. A life ships no error messages. If she quietly stopped tracking something, nothing would turn red. The absence of a failure signal means the discipline has to come from the design, not from feedback — you have to engineer your own red lights, because life will not hand you any.
There is also no "done." A project ships and closes; a life is a process with no terminal state. You do not finish a week, you start the next one. That changes what good even looks like. Success is not completion — there is no finish line to cross — it is a trend pointed the right way that has not been silently dropped.
And the stakes are inverted. Get a work task wrong and you lose time, maybe money. Get a life task wrong and you let down a person, or miss something about your own health, or break a small promise that mattered more than its size. The cost of a dropped ball is measured in trust and wellbeing, not story points. That is why the friction on consequential actions is non-negotiable here in a way it often is not for a pure development agent.
Memory matters more, too, and it is harder. A code agent can always re-read the repository and reconstruct its context, because the truth is sitting there in the files. You cannot re-derive a life from its artefacts; most of what matters was never written down anywhere. So curation is not a nice-to-have. It is the entire game.
But the real lesson — the one a product-building agent never gets near — is that the highest-value thing is not execution. Doing the task is the easy, commoditised part; anything can be taught to do the task. Noticing which task is silently dying is the part that actually needed a system. Point Claude at a codebase and you get a faster builder. Point it at a life and the win is not speed at all. I went in expecting to save time. What I got was quieter than that, and better: fewer things rot.