Building JARVIS: The System I Run Six Companies On
I built an AI operating system to run a six-company portfolio because no existing tool could hold the context. Here's what it is, what it runs on, and why I built instead of bought.
Building JARVIS: The System I Run Six Companies On
I run six companies plus two W-2 consulting engagements, and at some point the overhead of holding all of it stopped being a scheduling problem and became a wall. Not a capability wall — I could do any individual piece. An overhead wall: the compounding cost of holding every company's state in my own head simultaneously. I was the integration layer. My brain was the system. So I built a different one.
That system is JARVIS, and what it does — persistent memory, cross-company context, real execution — I described from the user's side in what an AI chief of staff actually does. This is the builder's side: what it is, what it runs on, and why I built instead of bought.
Why nothing off the shelf worked
I tried the existing tools first. They all had the same fatal flaw: no persistent memory across sessions. Every conversation started from zero, which for a multi-company operator is worse than useless — re-briefing a tool on six companies every time costs more than just doing the work myself. The thing I needed most was the thing none of them did: carry context from one session to the next, across all the companies, permanently.
So the core of JARVIS is a real data layer — not a chat history, an actual queryable store of companies, clients, tasks, knowledge, decisions, and memory. That's what lets the next conversation start where the last one ended.
What it runs on
JARVIS runs on infrastructure I control end to end. Cloudflare Workers handle every API call, cron job, and automation as domain-specific services. A real database holds the persistent state. AI models handle routing and reasoning. I deliberately own the integrations directly rather than routing through intermediaries — the same reason I replaced workflow tools with code I control: I don't want a dependency I don't own sitting between the system and execution. If a vendor changes its terms or pricing, the workflow continues uninterrupted because I hold the relationships.
That ownership is a core design principle, not an incidental detail. An operating system you don't control isn't an operating system; it's a rental.
Why build instead of buy
The honest answer is that the thing I needed didn't exist, and the things that claimed to be it weren't. But there's a deeper reason I kept building rather than waiting for someone to ship it: building it myself meant it fit my actual operation exactly, and it meant I understood every part well enough to extend it. JARVIS keeps growing — business intelligence, content and publishing pipelines, eventually evaluating acquisition opportunities — because I own the whole thing and can build the next layer whenever I need it.
That's the thesis behind Noevant too: what I built for myself can be architected for other operators with the same problem. Built by someone who's actually run one in production, not theorized about it.
I'm Jesse Myers — Marine veteran, 32 years in enterprise IT, and I run 2057 Holdings, a six-company portfolio I operate on the system described here.
Featured image: Photo by Austin Distel on Unsplash.