What This Is
Start Here
I did not want a chatbot. I wanted something that already knew my household and acted on it.
The problem
Section titled “The problem”My household’s load is constant and forgettable. A school notice that needs a parent to decide something. A form with a date on it. An appointment that needs moving. A delivery I will miss. The weekly shop. A subscription worth checking. A trip that needs planning.
Each item takes minutes. The volume is the problem, and the failure mode is always the same: nothing gets missed loudly, it just quietly does not happen.
The first attempt, and why it failed
Section titled “The first attempt, and why it failed”I built something that could answer questions. It was impressive for a week and unused by the second.
The reason: it did not know anything I had not just told it. Every conversation started from zero. An assistant that has to be briefed every morning is a search engine with extra steps.
The second failure was the documentation
Section titled “The second failure was the documentation”This matters because it is the mistake I made twice.
Attempt one: I produced a thorough inventory of the system — components, schedules, capabilities. It was accurate and nobody read it. It described what the agent was, not what it did for me. It was also wrong within a month.
Attempt two: I automated the wrong half. A nightly job produced a fresh, dated copy of the agent’s entire state every morning. It ran perfectly for months. It produced hundreds of folders and answered no questions.
Both failed for the same reason: they documented the machine instead of the household. An inventory rots in weeks. “It reads the school notices and puts the dates on the calendar” does not.
There is a third failure worth naming, because you will hit it: I built it in one burst and never revisited it. Documentation with no maintenance loop is a photograph.
What finally worked
Section titled “What finally worked”Four changes, in order of how much they mattered.
Give it an identity before anything else. Its own name, its own mailbox, its own account on the machine. Everything else in this blueprint depends on that separation, and retrofitting it later means undoing work.
Write the hard limits before you give it power. Deciding what the agent may never do is much easier before it can do anything.
Describe outcomes, not inventory. This whole blueprint is written that way on purpose.
Give the documentation a heartbeat. Something has to notice when it goes stale. Mine is a monthly review that flags any page not verified in 60 days, plus a changelog I write by hand when something structural changes. That is the part I skipped twice.
How this blueprint is organised
Section titled “How this blueprint is organised”As onboarding, because that is what it is.
| If you think of the agent as | The setup reads as |
|---|---|
| A piece of software | Install, configure, deploy |
| A new hire | Identity, workspace, tools, permissions, responsibilities |
The second framing is not a metaphor for me any more. It forced questions that software thinking does not ask. Who is this? What may it decide alone? What must it never do without asking? Who does it answer to?
Every one of those became a real design decision.
The most useful sentence in this blueprint: an agent you would not trust with a credit card is not an assistant, it is a demo.
What I am not claiming
Section titled “What I am not claiming”- This is not finished. The Gaps I Have Not Solved is a real list, and it is the part I would want to read first if I were you.
- This is not the only way. It is one way that works and keeps working.
- This is a snapshot. It was true the day I wrote it.