Amaru
A voice-first assistant with specialist agents behind a router.
Amaru is the second version of my personal AI operating layer: an installed app I talk to, a queue of work on a small server, and a written record underneath that both of us read and write. Otto was v1 and proved the idea. Amaru is the rebuild that fixed what v1 got wrong.
v2. In daily use, running unattended.
Otto was v1Otto worked, and I used it every day, which is exactly how I found its limits. It reasoned from a blank page every time. Ask it the same kind of question twice in one week and it could answer both well and still contradict itself, because nothing it produced knew what it had produced before. That is not a prompt you can rewrite your way out of.
So Amaru splits the work in two. Anything that can be counted is counted first, in the database, and handed to the model as a number. Anything that needs a judgement call is left to the model. The agent chooses; it never has to remember, so it cannot forget. Everything else on this page follows from that one split.
Capabilities
Voice in, anywhere
An installed app, voice first, typing as the fallback. What I say lands exactly as I said it and is never edited or deleted. Everything derived from it is written somewhere else.
A router in front of specialists
One way in, several agents behind it. Each specialist knows one domain and carries only the instructions for that domain, and the router decides where a piece of work belongs. No agent carries the whole system in its head.
It writes and ships its own software
It branches, writes the code, runs the checks, and opens the change. Anything that leaves the machine waits behind an approvals gate that I hold, so it can build all night and still not act on my behalf without me.
A browser it looks through
Plenty of systems never shipped an API. The agent drives a real browser against them, reads the rendered page the way a person would, and checks its own work by looking at what it built.
The reviewer is not the author
A separate profile checks the work of the one that wrote it, and has to reproduce the defect before the fix and after it. A clean typecheck is not evidence that anything works.
It deploys itself, and can undo it
A merge triggers its own rebuild and restart. The rollback runs on the host rather than inside the thing it just replaced, which is the difference between a bad deploy that recovers and one that takes the recovery down with it.
Four rules, each one a mistake I made first
A year of using v1 every day is the only reason these exist. None of them is a preference. Each is the shape of a failure, written down so the system cannot repeat it.
- 01
Deterministic things go in SQL. Judgement goes in the model.
Coverage, recency and volume are arithmetic, not opinions. They are computed before anything is asked of a model and handed over as numbers. v1 generated each answer statelessly and the seams showed in the output.
- 02
Raw input and derived records are separate.
What I said is kept untouched. Everything a parser makes of it lives elsewhere. So improving a parser means the old input can be read again, instead of a bad reading being permanent, which is what happened when v1 stored the conclusion and threw away the input.
- 03
Facts and decisions are versioned, never overwritten.
Changing my mind writes a new record that supersedes the old one rather than replacing it. Why we changed our mind is usually the part worth keeping, and it is the first thing an overwrite destroys.
- 04
Silence is not a decision.
An empty day and a day considered and deliberately left empty are different records. If they look identical, nothing downstream can tell a gap from a choice, and it will guess wrong in both directions.
Real jobs it runs
- Take something spoken in passing and file it against the right work without me choosing where.
- Compute the numbers a decision depends on before any model is asked to make it.
- Open, review and merge changes across several repositories, behind an approval I hold.
- Drive a browser against systems that never shipped an API, and read the result.
- Run standing jobs overnight and report what changed while I slept.
- Deploy itself, and put itself back if the new version does not come up.
- Hand the next session the written record, so a settled question is never asked twice.
In motion
Diagrams, not screenshots. This one runs my actual life, so the contents stay private and always will. The architecture is what makes it work, and the architecture is the part worth showing.
the split
counted, in the database
judged, by the model
it chooses, and never has to remember
raw
never edited
derived
rebuilt, not repaired
How it works
- An installed progressive web app is the only surface. Voice first, typing as the fallback, nothing heavy running in the app.
- A queue on a small server, and a worker that pulls jobs off it. Work survives a closed tab and a dead connection.
- A router in front of specialist agents, one per domain, each carrying only its own instructions.
- A Postgres record underneath. Views do the arithmetic and hand agents the numbers, so no agent has to reconstruct history to act.
- Raw input in one place, derived rows in another. Neither can overwrite the other.
- Every session opens by reading the record and closes by writing to it. Nothing important lives only in a conversation.
- A review profile that reproduces a defect before and after the fix, and a self-deploy whose rollback runs on the host.
Otto proved the idea. Amaru is the version that learned from it.
The contents stay private. The architecture is the point. See the rest of what Lucas builds.