Almost everyone building a personal assistant starts the same way. The agent needs to know about your calendar, so you give it calendar access. Then it needs your email, so you give it email access. Then a second agent shows up, and it needs the same two things, so it gets its own connections.
Six months later you have four agents and six sources, and somewhere in there you have twenty-four separate opinions about what your week looks like. Every one of them is a credential to rotate, a rate limit to respect, a sync to debug at eleven at night. And none of them remembers anything, so every conversation starts from zero and every new agent starts from nothing.
The problem is not the agents. It is that each of them owns its own copy of the world.
01 / The inversion
So we built the other thing. One append-only log. Everything that happens lands in it once, through a single writer, and everything downstream reads from there.
Five mailboxes, messages, calendar, weather, phone, a wearable. Seventeen small services, around twenty-six thousand lines. None of them interesting alone. What is interesting is that there is exactly one writer, so the log can never disagree with itself, and the shape of every event is validated by its kind at the edge, where rejecting a bad one is still cheap.
And then the part that changes everything: every reader keeps its own cursor.
That single decision buys three things that are otherwise expensive. A consumer that was broken for three days catches up by itself, because its position is a number and the history is still there. A consumer that did not exist last year can read data from last year, which means you can ask a question tomorrow with code that had not been written when the answer arrived. And no reader can slow another one down, because nobody is waiting for anybody.
Plugging a new agent into a life stops being an integration project. It is a cursor.
02 / History is the asset
There is a second thing that falls out of append-only, and it took me a while to see it.
Nothing is updated and nothing is deleted, so the log is a history rather than a snapshot. Derived state is not stored anywhere sacred: it is computed from the log. Which means the day you change your mind about what a signal means, you do not migrate anything. You throw the derived layer away and recompute it.
The layers that draw conclusions write those conclusions back into the same log, as events. So the record contains not only what arrived, but what the system made of it and when it decided that. When something goes wrong two weeks later, the question "why did it think that" has an answer with a timestamp.
Integrations are commodity. Anyone can get calendar access. The history is the thing that cannot be re-bought, because if you did not record it, it is gone.
03 / The test we did not schedule
Theory is comfortable. Here is what happened.
The observation layer was written as the architecture of a product that was winding down, and it was running on that product's infrastructure. Its data lived on a server that belonged to the project. Its tokens were served by the project's domain. The code was fine. The dependency was fatal: the day that infrastructure went away, the eyes would go dark, no matter how good the code was.
So it moved home, to a machine in the corner of a room. Service by service, with the old system still running the whole time. The data came across and was verified by checksum on both ends: around ninety-seven thousand events, seven hundred megabytes, identical hashes.
One decision defined the migration. The old setup used push, which was fast and depended on a hostname that was about to stop existing. We moved to polling, which cost about ten minutes of latency and bought total independence. That trade looks bad on a benchmark and correct on a calendar.
When the old server was finally destroyed, nothing happened. Twelve services up, a clean polling round immediately after. The log did not notice that the world it was born in had ended.
04 / What it is for
The reason to own this layer is not architectural elegance. It is that the thing which sees your life should not live on infrastructure you do not control, and should not be scattered across whichever vendors your agents happened to be built on.
Build the log first. Let the agents be replaceable. They will be: the model you are using today will be embarrassing in a year, and the agent you wrote last month is already a draft.
The log is not. An integration is a connection. A log is a memory. Only one of them is worth keeping.