The system that outgrew its own name

JarvisOS started with a question that felt small at the time: what would it look like if a founder had a genuinely intelligent operating system for their entire life, not just their calendar? Not a task manager. Not a note-taking app. An actual system that connected finances, creative work, consulting clients, cycle health, scholarly research, and a product fleet, and let all of it inform each other.

Two years later, JarvisOS runs 27 wings, 254 background workers, 405 database tables, and approximately 687 API routes. It processes CEO deal intelligence, cycle-aware scheduling recommendations, cross-brand social publishing, voice synthesis, autonomous article generation, and a personal memoir engine that writes Nandawula's life story from her daily entries. All of it wired together. All of it running on a single Next.js application deployed to Vercel.

The system did not grow this large because of ambition. It grew because every time we solved one problem correctly, it became the foundation for solving the next one. And the architectural decision that made this compounding possible was not the AI. It was the job queue.

The problem with inline everything

In the early versions of JarvisOS, AI calls happened inline with user requests. A user asked the CEO wing to analyse a business scenario; the route handler called Anthropic, waited, formatted the response, and returned it. This worked. Until it did not.

The failure mode was subtle at first. A Notion sync would time out. An article generation job would fail silently when Anthropic returned a 529. A social media post would not publish because the route was still waiting for an image generation API. None of these failures were visible to the user immediately. They accumulated in the background until the system felt unreliable in ways that were hard to diagnose and harder to explain.

The deeper problem was architectural: we were treating every operation as if it needed to complete before the user could proceed. This is fine for a form submission. It is catastrophic for a system where a single user action might trigger an AI call, a Notion sync, a Redis update, an XP award, and a cross-wing signal, all of which interact with external APIs at different speeds and with different failure modes.

The Inngest decision

The turning point was switching every background operation to Inngest, a workflow engine that queues, retries, and executes functions outside the user-facing request lifecycle. The principle is simple enough to state in one sentence: a user action should never wait for anything it does not need to see before continuing. The implementation is more demanding.

Every operation in JarvisOS that touches an external API, runs an AI call, or produces side effects now goes through Inngest. The user-facing route does one thing: accepts the action, validates it, writes the intent to the database, and enqueues the work. The response to the user comes back in milliseconds. The work happens behind the curtain, retried automatically if it fails, observable through Inngest's dashboard, and completely decoupled from the interface.

The engineering impact was immediate. Route response times dropped to under 100ms for operations that had previously taken 8 to 12 seconds. Failures became observable rather than silent. Retry logic stopped being a thing we wrote by hand and became a thing the platform provided. And most importantly: the user experience became stable at a moment when the backend was growing fastest.

What 254 workers actually means

JarvisOS currently has 254 Inngest workers. That number sounds large. In practice, it is a measure of how many distinct operations the system has developed opinions about. There are workers for: generating weekly CEO intelligence briefs, syncing Supabase records to Notion, publishing social media content across 22+ accounts, building monthly magazine covers from brand data, generating article drafts from JarvisOS data, sending email sequences, processing WhatsApp messages, calculating XP awards, and running the autonomous Mirembe Blog writer that published this article.

Each worker is a function with a name, a trigger, and a retry policy. Each one fails independently. Each one retries independently. The system has never lost a job to a transient API failure since this architecture was in place, because Inngest handles the retry instead of us.

The lesson for AI systems specifically

Building AI products taught us something that feels counterintuitive the first time you encounter it: the faster you want AI to feel, the less of it should happen synchronously. A system that calls an AI model inline with every user request is a system that will fail at unpredictable moments, timeout at the worst times, and accumulate technical debt in its error handling until the debt becomes the system.

The correct architecture for AI features is: accept the request immediately, return an optimistic response, do the AI work in the background, and push the result back to the user when it is ready. This is how modern AI products that feel fast actually work. The apparent latency is hidden. The real latency is moved to a place where it cannot damage the user experience.

JarvisOS is the proof of that thesis at scale. 254 workers. 27 wings. One user. Zero visible timeouts.

What this means for your project

You do not need a 27-wing operating system. But if you are building anything that involves AI calls, external APIs, or operations that should not block the user, the architectural question is the same: where does the work actually happen? If the answer is "inline with the request," you are accumulating a debt that will surface when it is most inconvenient. The alternative is not complex. It is just a queue, a retry policy, and the discipline to put background work in the background.