Sprocket

Project Overview

Sprocket is a personal productivity app built on VoltAgent and React Router 7, bootstrapped from Iridium, my starter kit, and grown into its own product. The chat is the primary surface, and the assistant inside it is named Spur. Spur is a Claude Sonnet 5 supervisor holding roughly seventy tools directly, delegating only three narrow jobs to Haiku sub-agents: journaling, weekly reviews, and email drafting. Every domain (contacts, interactions, journal entries, tasks, events and their checklists, habits, shareable pages, generated images) is exposed both as a normal CRUD UI and as an agent tool, so the chat surface and the manual surface stay in lockstep. On top of that sit a full scheduling engine with booking links, weekly hours, date overrides and email confirmations; a Trigger.dev task fleet for background work like image generation and booking reminders; and read/write YNAB access so budget questions get real numbers. Working memory persists across conversations and across agents in its own Postgres database, kept separate from the Prisma application schema. Hooks inject temporal context into every request, and guardrails enforce input length limits and redact PII from streamed output. Auth is Better Auth with HTTP-only sessions, and the whole thing deploys to Railway from Docker.

Knowledge Gained

The most useful lesson was architectural, and it came from being wrong first. Sprocket originally shipped with twelve specialized sub-agents, one per domain. In practice the supervisor routed better when it simply held the tools itself, so I collapsed twelve specialists down to three and kept delegation only where a genuinely different voice or a long synthesis step was needed. Model capability moved, and the right topology moved with it. The same instinct applied to features: I cut four whole domains, including a RAG-backed notes system I had built and liked, because they were not earning their place next to a real budget integration. Beyond that, I got real reps on separating VoltAgent's memory schema from the application schema by giving each its own database, forwarding tool-call and text-delta streams cleanly so the UI can make agent work legible, and treating guardrails, hooks, and middleware as first-class abstractions rather than afterthoughts. I also replaced a hand-rolled cron setup with Trigger.dev once background work outgrew it, and I learned that a scheduling engine is deceptively hard: availability rules, timezones, date overrides, buffers, minimum notice, and slot generation all have to agree before a single booking link works.

The Impact

Sprocket is the project I point to when someone wants to see how I think about agent-native software. It is not a wrapper around a single LLM call. It is a supervisor holding roughly seventy tools, memory that survives across conversations, guardrails on input and output, and a UI that makes every tool call legible to the user. It is also the project where I can show judgment rather than just capability, because the most important commits were the ones that deleted agents and features I had already built. For anyone evaluating me for AI engineering, agent design, or full-stack roles where the assistant is the product, this is the clearest end-to-end example. It exercises the rest of the stack I work in daily: React Router 7 with type-safe loaders and actions, Base UI components on Tailwind v4, Prisma, Better Auth, Trigger.dev, Cloudinary, Bun in development, Docker in production, and Railway for deploys. Sprocket and Iridium are intentionally paired in my portfolio. Iridium is the foundation, and Sprocket is the proof that the foundation holds up under a real, opinionated product.