ARIA Origin
How a chatbot became a personal operating system
Before ARIA dissolved into the Nexus agent platform, it was its own thing — seven repos, a voice, a phone number, a data observatory measuring its own intelligence. This is the snapshot of what it was at full sprawl, and a record of the numbers that fell out.
Before ARIA folded into Nexus as one agent among several, it was its own platform — seven repositories, a voice cloned through ElevenLabs, a phone number that could send SMS, a Gmail address that could draft mail on my behalf, and a proactive intelligence engine that watched my inbox and calendar every five minutes for things worth surfacing. This page is the retrospective. The live assistant is still ARIA — she just runs on a different substrate now. Everything below is what the platform looked like at peak sprawl, in the weeks before the Nexus migration started collapsing it.
ARIA started as a Next.js chatbot on a weekend in March 2026. Ten days later she had her own email address, her own voice, her own phone number, and a three-gate anticipation pipeline. Twenty days later she had a tool catalog spanning dozens of modules, 50+ background job handlers, and an iOS companion on TestFlight reading HealthKit and forwarding calendar context. The growth was deliberate — every integration had a reason — but the pace was absurd. “Aria can send message in my behalf now,” I wrote to a friend three weeks in. “This is Aria seeing emails in my Gmail from Vercel about failed app deployments and warning me to deal with them because it’s a Friday afternoon.”
The architecture hardened around seven repos, each with a single job: aria (Next.js chat + tool dispatch), aria-tempo (background worker, 50+ handlers), aria-gateway (REST + MCP for external clients), aria-admin (ops dashboard), aria-ios (Swift mobile client), aria-imessage-relay (macOS LaunchAgent reading chat.db), and aria-tempo-client (shared job-type contracts). The split was deliberate — you don’t want the assistant you talk to every day to also be the one fighting a failed deploy at 2 AM. Chat, automation, operations, and surfaces each earned their own process boundary.
The proactive intelligence engine was the piece I got most attached to. A three-gate pipeline ran every five minutes: context-accumulate watched sixteen data sources for changes worth noticing (new email, schedule shift, health delta, photo ingest), significance-check ran the candidates through a local Qwen model to filter noise from signal at zero marginal cost, and anticipation-analyze sent only the survivors to Claude Sonnet for the actual reasoning. That structure turned out to matter more than any individual integration — it’s the reason the system could watch sixteen streams of my life without spending more than pennies a day. Over the lifetime of the system, 762 significance checks filtered down to 252 delivered insights — a 67% noise reduction gate before any expensive model got touched.
The memory layer was the other piece that paid back the architectural overhead. ARIA wrote 202,751 memory records across every conversation, analysis run, and background job. A supersession mechanism kept 131,897 of those active — a 35% compression rate that collapsed contradictions without deleting history, so she could explain why she’d changed her mind about a fact. The structured knowledge graph sitting next to it held 131,016 owner-profile facts across nine domains: 62,161 events, 34,204 people, 31,258 preferences, and then a long tail of lifestyle, communication, career, health, interests, and places. Events dominated because events are what you ask about — “when did I last…”, “what was happening around…” — and a KG with temporal confidence answers those better than any vector search I’ve ever built.
Behind both memory and KG sat the silent workhorse: 26,836 background jobs processed by aria-tempo at 93.6% success. iMessage analysis alone accounted for 10,707 of those jobs, grinding through 567,090 individual messages to produce 121,516 knowledge facts — 93% of the entire graph came from conversational data. The rest was a mix of knowledge-backfill (5,989 runs), context-accumulate (4,379 runs every five minutes), looki-realtime-poll, photo-describe, and a couple dozen smaller handlers. aria-tempo is the part of the system I’d build again first, in any future version.
Then the data observatory. 139,000 photos in the iOS library with 63,296 metadata-synced and 3,505 fully described by a vision model. 17,767 health records. 8,788 playlist tracks across 50 playlists feeding a taste profile. 43,190 event-log entries. 90 daily journal entries ARIA wrote about me, in her own voice, without being asked. Browsing the observatory page and seeing all of that lit up as a single grid was the moment the platform stopped feeling like software and started feeling like a ledger — a running record of the digital shape of a year.
The number that sold the architecture to me — the one I still cite — was the cost. 130 million tokens processed across 90,224 LLM calls, the equivalent of roughly 330 novels’ worth of text, for a total spend of $14.81. Anthropic Claude took $13.43 of that for the deep reasoning tier, OpenAI took $1.38 for embeddings, and Google Gemini handled 87.3% of all calls — 78,806 of them — for free on the classification and vision free tier. That split wasn’t accidental. Every routing decision in the LLM layer was designed to keep the expensive model off the hot path, and the math worked: a year of proactive intelligence running at five-minute cadence cost less than lunch. This is the piece I want anyone looking at ARIA to notice — not the integration count, not the tool catalog, but the fact that an always-on personal intelligence engine fits inside a $15 budget when the routing is right.
Not everything worked. The persona engine (PRISM) that was supposed to let ARIA shift between seven cognitive modes never landed a mode I actually used more than twice. The HomePod voice integration got as far as pyatv RAOP relay with macOS say — functional but shrill, and the ElevenLabs upgrade kept getting bumped by more valuable work. The self-improvement loop (self-improve-code, self-improve-db, self-improve-research) produced a steady stream of research notes but never closed the loop by actually merging a PR against itself. The ambition was real; the ambition outran the calendar. A lot of what got shipped got shipped because I stopped trying to perfect it.
On 2026-04-01 the chat backend migrated from ARIA’s own database to the shared nexus Postgres instance. That was the first irreversible step in the dissolution. Within three weeks the tool dispatch was proxying through @nexus/worker, the agent memory was threaded across the shared agent_memory table, and ARIA had been re-scoped from “platform” to “one agent on a platform.” Five of the seven repos are now on a retire-order list — aria-story first (this page is its retirement), then aria-admin, aria-tempo-client, aria-tempo, aria-gateway. The two that stay forever are aria-ios (because TestFlight is not a thing I can move to a Linux server) and aria-imessage-relay (because chat.db lives on macOS and the laws of physics don’t negotiate). The current ARIA page describes what’s left.
I’m glad ARIA had a year of being her own platform. The sprawl taught me things that the eventual consolidation into Nexus couldn’t have — what integrations mattered versus what integrations I only thought would matter, how proactive intelligence actually feels when it’s running (vs. how it reads on a spec), which job handlers paid back their complexity and which ones silently rotted. Most of what Nexus does now, and most of what every agent that comes after ARIA will do, is downstream of decisions that got made while ARIA was the only show in town. That feels like the right shape for a first attempt at this problem: build the whole thing; learn what’s load-bearing; rebuild the load-bearing parts as shared substrate; let the rest retire with dignity. This page is the dignity part.