Aller au contenu principal
Nicolas Cousin Tech SolutionsNicolas Cousin Tech Solutions

A First Hybrid Architecture, Not Yet the Right One

Six articles in, a local/cloud split is starting to take shape on the VPS. This isn't the series' final architecture, just the first version solid enough to be put to the test. Seventh article in the series.

By Nicolas Cousin — Published on October 27, 2026

A First Hybrid Architecture, Not Yet the Right One

TL;DR

After hardening the VPS, assembling Docker/Ollama/Hermes, the CPU benchmark, and the lessons from background mode, a split is emerging between what stays local and what goes to the cloud. I'm writing it down here because it's solid enough to put in black and white, not because it's finished: several questions remain open, particularly around what the local agent can actually execute without supervision.


Table of contents


What the previous articles established

Without repeating the numbers in detail (they're in the articles themselves), these six articles aren't six independent topics: each one follows from the last, and it's that chain that produces the split on this page.

Hardening the VPS (key-only access, Tailscale, a verified safety net) made it safe to install agents capable of running commands on it in the first place. Docker, Ollama, and Hermes assembled on that VPS first revealed that a model "compatible with Ollama" isn't automatically usable by an orchestrator, a configuration lesson before it was a performance one. The CPU benchmark that followed delivered the real verdict: local is too slow for most interactive uses, which is what forced the next question rather than the other way around, namely what to do with that slowness instead of ignoring it. Hermes' background mode answered part of that: it's a genuinely useful pattern for monitoring and batch work, but it also exposed two distinct limits, a result that can vary from one run to the next without always knowing why, and an agent that can lose track of when to stop. It's these limits, more than the slowness alone, that drove the search for a reliable cloud path for anything that stays interactive, and that path (ChatGPT/Codex) is what the previous article established as the simplest one to wire up at no extra cost.

The split that emerges

                  Hermes
                    |
          +---------+---------+
          |                   |
      Local Ollama          Cloud
          |                   |
     simple tasks         complex tasks
     batch                interactive
     transformations      architecture
     repeated generation  research
     low cost             validation

Local: DTOs, boilerplate, simple tests, SQL, YAML, CI/CD, transformations, batch work. Nothing that demands a fast reply, anything that can wait for the CPU to do its job.

Cloud: architecture, complex analysis, large refactors, research, validation, difficult debugging, anything agentic and complex. None of this is specific to a particular provider, only to the observation that these are tasks where waiting several minutes isn't acceptable.

This split isn't original in itself: it's roughly what common sense would produce without having measured anything at all. What has value isn't the split itself, it's having real numbers behind each box instead of a hunch.

What this architecture doesn't prove yet

This split says where to send a task based on its nature. It says nothing about a harder question: once a task is sent to local, can the agent actually execute it without supervision, modify the right files, use its tools correctly, and stop at the right moment? Background mode has already shown signs that the answer isn't automatically yes, and I haven't yet run a local agent on an actual multi-file development task, with a real project, a real environment, and a real result verifiable on disk.

The first attempts in Hermes, as assembled so far, didn't prove anything either way: the project wasn't even mounted in the container.

A starting point, not an endpoint

What I'd change if this split turned out to be wrong probably isn't the "local" or "cloud" box for a given task: it's the implicit trust I place in what happens once a task goes local, without direct supervision. If the articles that follow show that trust isn't warranted, this diagram doesn't change shape: what changes is what has to be verified before applying it.