Problem we walked into
We kept rebuilding the same five primitives every time we shipped an agent: a memory layer, a scheduler, a dashboard to see what was running, a way to pipe state between scheduled cloud runs and local processes, and a human-in-the-loop bridge. Every client project had its own variant. The variants were drifting.
What we built
Nexus is VRA's internal multi-agent runtime — one place where agents register, hold memory, get scheduled, push status to a dashboard, and surface decisions to humans (Telegram bridge, for now). Agents we ship for clients run on top of Nexus instead of reinventing the floor.
Tech under the hood
TypeScript runtime, persistent memory layer, cron-style scheduling, web dashboard, Telegram bridge for in-the-loop human approval / interrupts. Designed so a single agent can move between scheduled cloud execution and local execution without rewriting state handling.
Why we built it (and what it signals)
Two reasons. One: every serious agent shop will need this internally — better to own the abstractions than rent them. Two: it's the kind of architecture work that doesn't show up in a screenshot, but it's the only thing that lets a small team ship reliably across many clients. Every client project gets compounding leverage instead of starting from zero.