Rebuilding Jarvis: Two Engines, Less Fragility

The art of being wise is the art of knowing what to overlook.

— William James

I started building my own agent on top of Claude Max long before Anthropic stopped people running their subscription through Openclaw. I took that path because although Openclaw was real progress, I knew eventually I’d be stuck with API-only usage (lots of $$$$) or maybe I wouldn’t be able to use my preferred LLM at all. I was right, and the day Openclaw broke for most people, my version kept going.

Openclaw had shown me the vision. An assistant that remembers context between sessions, builds skills, manages automations, connects to your services, stores ideas. All of it running on Claude’s reasoning. That part I wanted to keep. What I didn’t want was the fragility. I also wanted something I could evolve. When Hermes came along I wanted to use what it did well, not have to switch wholesale. I was ready to build on a foundation, rather than keep switching.

So I rebuilt from scratch within Claude’s Terms of Service.

The Split

The new ToS doesn’t touch the reasoning part. Claude Code is still fully available for that. What it prohibits is running Claude Code in automated, non-human pipelines. That’s what Openclaw relied on for background tasks, and that’s what broke for most people in March.

Splitting those two things was the fix.

The interactive layer is Claude Code, same as before. I’m in the loop for anything that needs real judgment: building, planning, debugging, thinking through something complex. Human-initiated, fully within ToS. This is where most of the value is anyway.

The automation layer is n8n, a workflow tool running on a small Google Cloud VM (about $6/month). Morning briefings, health checks, scheduled tasks. 26 workflows running all day without touching Claude Code. They don’t need reasoning. They need coordination and connectivity, which n8n handles fine.

Two engines, one set of services. The split is the point.

Shared Services Through MCP

Both layers talk to the same services through MCP (Model Context Protocol). Open standard connectors for Gmail, Calendar, Obsidian, GitHub, and others. Free, configure once, works in both. The diagram shows how it fits together.

For persistent memory (the thing Openclaw users miss most) Supabase runs on my local machine in a Docker container. Free. It handles structured data (project state, preferences, task history) and fuzzy search across past sessions. Everything stays on my machine, not in someone else’s cloud.

Cost of Setup vs Cost of Fragility

Is this more setup than Openclaw? Yes. Budget two or three weekends if you’re starting from scratch, more if this is new territory. Stability is comparable, and Openclaw honestly wasn’t a high bar there. The pieces I’m using are boring, well-maintained open source tools that have been running in production elsewhere for years. That’s actually an advantage over something more clever.

A lot of people looked at the ToS change and went searching for a different all-in-one replacement. I’d push back on that framing. The split between interactive reasoning and background automation isn’t a workaround. It’s a better design, and I can evolve it myself. I don’t have to jump to another agent that provides an incremental improvement and break my setup again the next time the rules change.

YMMV, but for me it’s been worth the setup time.

What Jarvis Does for Me Today

26 n8n workflows on the automation side. Morning briefings that pull from Calendar, Gmail, GitHub activity, and a few internal status checks. Health checks across the services Jarvis depends on. Scheduled jobs that don’t need reasoning, just coordination.

Claude Code on the interactive side, with the same MCP services available. When I’m working on a project I can ask it to pull context from Obsidian, check what’s on the calendar, read recent Gmail threads, all without leaving the session. The local Supabase keeps the memory persistent across sessions.

The whole thing runs for less than $10/month in infrastructure. The expensive part is my own time setting it up, but the marginal cost of evolving it is low because each piece is independent.

Why This Matters Beyond My Setup

The pattern is generalizable. If you’re building anything that combines AI reasoning with automation, you’ll eventually face the same question: do you want one thing that does both, or two things connected by shared services? The all-in-one option is faster to set up and easier to break. The two-engine split is slower to set up and harder to break.

For tools you depend on every day, slower-to-set-up and harder-to-break is the right tradeoff.