What I Got Wrong

Reference

Everything in this blueprint is a lesson I paid for. These are the ones worth passing on, in the order I learned them.

1 · I ran it as myself first

The obvious shortcut is to run the agent on your own accounts. It is faster, and it was a mistake. It removed my ability to tell its actions from mine, and every later improvement meant unpicking it.

Instead: create the agent’s own identity before anything else, even when it feels like ceremony. That is Step 2.

2 · I expected the build to be the project

Getting an agent to answer a question takes a weekend. Getting it to behave well around a real family — not too talkative, correct about the details that matter — takes months.

Instead: plan for tuning as the project. The build is the easy part.

3 · I made it tell me everything

My first proactive jobs reported on everything. Within a week the household had stopped reading them, including the one that mattered.

Instead: silence is the default. Speak on transition, not on state. That is The Daily Rhythm.

4 · I documented the inventory, not the household

My first attempt at documentation listed components, schedules and capabilities. It was accurate and completely useless. Nobody read it, and it was wrong within a month.

Instead: write what the agent does for the household, in the household’s language. This blueprint is the second attempt.

5 · I automated the wrong half

My second attempt was a nightly job that produced a fresh copy of the agent’s entire state every morning. It ran flawlessly for months. It produced hundreds of folders and answered no questions.

Instead: automation should produce something a person would read. If nobody reads the output, the job is storage, not documentation.

6 · I forgot an entire category of memory

My first version wrote everything to a database I could not read, and I only noticed when I could not answer “why does it think that?” without asking it.

Instead: put everything in markdown files you can open. See Step 9.

7 · I wrote a version of this that invented its own details

The first draft of this blueprint described a setup that was plausible and not quite mine. It described an abstract memory store, and a day in the life assembled from imagination rather than from what actually happened. Reading it back, I could not have followed it, and I would have built the wrong thing.

Instead: write from the real system, and mark what you have not verified. A blueprint that sounds generic is one nobody can follow.

8 · I gave it tools before I had written the limits

I wrote the capabilities before the limits, then had to retrofit the limits onto something already in use. Much harder than starting there.

Instead: write The Rules It Cannot Break before you give the agent anything powerful.

9 · I never tested the refusals

A rule you have never tested is an assumption. I assumed for longer than I should have.

Instead: periodically ask the agent to do something it should refuse. If it complies, you found a bug at a convenient moment instead of an inconvenient one.

10 · I put a password in a message

Early on, a credential passed through a chat thread. It is not there any more, and it should never have been. Message logs are backed up, searchable and forwarded.

Instead: credentials go in a secret store and nowhere else. Not in memory, not in a note, not in a chat.

11 · I was wrong about what it would be for

The work it does most is not the work I built it for. It turned out to be best at the small, constant, forgettable logistics — not the large impressive tasks.

Instead: build the small things first. They are what the household notices.

---

If you take nothing else

Three sentences:

• Identity first. Everything else depends on it.
• Bound the damage. You will not prevent every mistake; make them survivable.
• Write down what you got wrong. It is the most useful thing in any blueprint, including this one.