A self-hosted AI platform — ingestion pipelines, a four-store knowledge model, governed memory, per-domain voices, and model routing — running as one Docker stack on hardware you control.
You've used Copilot, ChatGPT, Claude. World-class models — Otto uses those same models. What those products don't give you is everything underneath: where knowledge lives, how it gets there, what happens after the conversation ends, and who controls all of it.
| Hosted assistants | Otto | |
|---|---|---|
| Where your data lives | Their cloud, their terms | Your hardware, four stores you can open |
| After the chat ends | A transcript, maybe opaque memory | Session becomes governed, searchable knowledge |
| Ingest your scanner, vault, podcasts, RSS | No — paste and pray | Ten intake channels, one enforced pipeline |
| Route tasks to different models | One vendor's picker | ~34 task routes across three providers + local models |
| Add a module (meals, chores, contacts…) | Wait for the vendor | Schema + panel on the same substrate |
Those products end at the conversation. Otto begins there — self-contained and expandable because the storage and pipeline substrate exists.
Five layers, one Docker Compose stack. One ingress. Four stores at the center. Every external dependency is swappable configuration, not code.
Different questions need different representations of the same source. These are not redundant copies — the design decision reads, verbatim: "distinct representations, not redundant copies."
The immutable original + a plain-text sidecar. Re-index everything without re-uploading anything. S3-compatible — swap to R2 or Azure Blob by editing .env.
Semantic vectors — 140K+ and counting. "Find things like this" across text and images. pgvector was considered for this role and rejected.
Entities and relationships extracted from the text. A theology paper yields chunks in Qdrant and graph edges between the people it discusses.
The index of indexes: cross-store pointers, pipeline state, application data. Chosen over Postgres for personal data whose shape keeps evolving.
A vector store alone can't answer "who influenced whom." A graph alone can't do fuzzy matching. Blobs alone can't search at all. The registry ties the other three together so a single document ID resolves to its original, its meaning, and its structure.
Redis sits beside them as the operational cache tier: session state, streaming coordination, API quotas.
owner field —
global, household, or personal. The ownership filter is
applied at query construction in every retrieval path. There is no code path where a query
runs unfiltered.Anything the household touches can become knowledge. Every channel converges on the same nine-step sequence — the code comment reads "the 9-step order is non-negotiable."
Fail at any step and the pipeline rolls back what it wrote — vectors deleted, graph nodes detached, the document marked failed, never half-ingested. The registry entry is written only after everything upstream has succeeded.
n8n was considered twice in the decision log and rejected twice — the recorded verdict: an external automation sidecar "adds operational complexity without unique capability." Orchestration here is code-first and git-trackable: flows are Python in the repo, reviewed like everything else, with retries and observable runs. A visual workflow tool would put pipeline logic outside version control in a second UI.
The honest nuance: Prefect is not used for everything. Hot, short jobs — chore auto-generation, the session-memory embedder, cost alerts — run on APScheduler inside the API process, because a worker round-trip adds ~30 seconds of latency that interactive-adjacent jobs shouldn't pay. Right tool per job class, not dogma.
Hallucination control is an architecture property here, not a prompt suggestion. Every answer about your data passes through a three-tier gate.
Semantic search across the owner's collections plus graph traversal. Proceeds only when the top match clears a 0.75 confidence gate.
Below the gate, Otto pulls the full text of the few most-plausible source documents from MinIO and answers from the originals — bounded, never a full-corpus dump.
Still nothing? Otto says it doesn't know, and shows near-miss candidates you can open or pin. No confident invention.
And when you want a document fully in context, /focus pins up to two documents
as complete session context — no retrieval roulette for the conversation that matters.
Hosted assistants give you memory as a black box. Otto's memory is governed: you can see it, decay it, correct it, and opt out of it.
/update records the new fact and
flags contradicted memories as superseded — hidden by default, never destroyed.A single system prompt gives everyone the same assistant. Otto maintains a lens per person per domain — how you think about study, home, research, and AI — and injects the right one into the answering call.
Why this matters to the whole: it's the difference between an assistant you configure and a platform that learns each person under governance. It is also the enterprise story in miniature — per-department voices with human-approved evolution is the same mechanism at a different scale.
No agent in Otto calls a vendor SDK directly. Everything flows through one config-driven router — which is why models are swappable, costs are attributable, and outages degrade gracefully.
Otto adopted LangGraph early for agent orchestration — and then outgrew it. When the tool-calling runtime was built, the wrapper layer cost more code than it saved, and the one behavior Otto needed most — switching providers mid-loop and replaying the conversation — wasn't expressible. So in mid-2026 the dependency was deleted and replaced with a 158-line hand-rolled loop with a provider-neutral turn format. We adopt frameworks when they pay rent, and remove them when they stop.
The same reasoning applies to routing gateways like LiteLLM — considered, and rejected in the decision log for one recorded reason: less control. Routing is a product capability here — cost, quality, and resilience per task — not plumbing to outsource.
Generic chat frontends exist, and they're fine — for chat. Otto's interface is a household application in which chat is one panel among many.
Meals, chores, tasks, lists, contacts, notes, a lifelog, and a full settings surface — including a cost dashboard and per-user lens editing. A chat skin would have capped the product at chat.
An owner switcher on every scoped panel, per-user themes (four of them, token-driven), per-user navigation visibility, per-user model selection. The UI understands the household the same way the data layer does.
Svelte 5 + Vite 8, compiled to plain JS, built in Docker. The recorded decision chose Svelte over React and Vue for exactly this: reactive components with no runtime framework weight.
Server-sent events are handled in one store, not scattered across components — the kind of discipline that makes a small codebase stay small.
Most assistants make web search the product. Otto inverts that: your accumulated knowledge is the primary context, and external tools serve it.
Meal planning and chore scheduling aren't bolted-on features. They're proof that the substrate composes.
Each module reuses the same machinery: the four stores, the owner model, the ModelRouter, and the UI's registry system. Meals get per-person plans, pantry awareness, and AI-estimated nutrition; chores get recurrence rules and AI-generated weekly schedules under household time-zone logic. Neither required new infrastructure — a module is a data schema plus a panel, not a new stack.
That's the enterprise extrapolation: household → team, family member → employee, domain lens → department voice, ownership tiers → org permissions. The mechanisms chain because they were built once, at the core, instead of per-feature. (What that path still requires is stated honestly below — the tenancy model today is single-household.)
Nightly backups of all five stateful systems, weekly encrypted offsite sync, a scripted restore with a written recovery runbook and stated recovery-point objectives. Every service image keeps a rollback tag — reverting a bad deploy takes about ten seconds.
A monthly spend ceiling ($50 default) that pauses AI calls when hit; per-job ($2) and per-user daily ($10) research caps; a pricing engine that prices every call, flags any unpriced model within a day, and reconciles measured spend against provider bills.
Separate dev and prod stacks, family-hours maintenance windows, and a required multi-agent review gate before anything touches core code. Main is always shippable.
Every feature carries a public/private disposition in a reviewed ledger with a running audit log. That process once caught a stale-base commit that had silently broken an integration for five weeks — the audit found it, root-caused it, and turned it into a hard rule. Process that catches its own mistakes is the point.
Otto is a production system for one household, built by one owner and AI agents. Taking it to enterprise means closing real gaps. Here they are, with the work each one requires.
| Gap today | What it would take |
|---|---|
| Single host, no horizontal scaling | The API is stateless-ready and storage is portable by design (.env-swappable, S3-compatible blobs) — scale-out means managed stores + a container platform, not a rewrite. |
| Dev and prod share the data layer | Separate volumes and databases per environment; the compose split already exists, so this is provisioning work, not architecture work. |
| Secrets live in .env, not a vault | Vault/KMS integration at the compose layer; a no-downtime rotation runbook already exists for every credential. |
| Auth trusts proxy headers | Safe as deployed — the API is never exposed except through the authenticating proxy. The planned hardening adds a proxy-to-API shared secret so the guarantee no longer depends on network topology. |
| No CI/CD; images built on-host | GitHub Actions + registry-published images are already designed for the public release track. |
| Tests thin but growing (256 passing) | Coverage targets and CI enforcement; the suite grew 25% in the last release cycle alone. |
| Observability = health panel + chat-ops alerts | Metrics and tracing (e.g. Prometheus/Grafana) alongside the existing per-service health checks and alert webhooks. |
| Single-household tenancy — the biggest true gap | The ownership-tier model generalizes to orgs conceptually, but org-grade multi-tenancy (isolation, admin, billing) is real engineering and is stated as such, not hand-waved. |
| GPU shared with the family gaming rig | Charming at household scale — a scheduler literally waits for the game to end before the nightly audio pipeline runs. Enterprise means a dedicated inference box. The scheduling discipline transfers. |
The best way to evaluate Otto is thirty minutes of the real system — the pipeline ingesting a document while you watch, retrieval citing its sources, the cost dashboard showing where every fraction of a cent went.
Trey Bayne · trey.bayne@gmail.com