EngineeringLive2026

Agent Orchestration and Self-Hosted AI Stack

A two-machine agentic dev setup: local inference, n8n orchestration and parallel agents in isolated worktrees.

Live as my daily working setup; it runs Loop end to end.

Role: Architect and operator
Timeline: Sep - Oct 2026
Team: Solo
Platform: Web, macOS

Ollama
n8n
Tailscale
Factory CLI
Orca
Docker
AI
Infrastructure
Self-hosted
Automation

Two Mac Studios stacked on a shelf under a light bar, the top one with its audio cable plugged in and the lower one with a braided cable running to a CalDigit dock on the right, a webcam in front

TL;DR

01 / What it is

The two-machine setup behind Loop: one Mac Studio I work on, one headless Mac Studio that runs the models and the agents, connected through GitHub.

02 / Why it existed

I wanted unlimited local inference and orchestration running all day without cloud bills, and without a fragile shared folder between machines.

03 / What I achieved

My daily working setup, and the engine under Loop: local models draft, cloud models review.

M3 Studio Ultra machines (96GB each): 2
cloud spend by default (local-first): 0

Overview

This is the infrastructure Loop runs on. Two M3 Studio Ultras with 96GB each, split by job. Frontline is the one with a screen, where I work. Backbone is headless and always on: it runs the local models, the orchestration, the agents' working copies and the vault. They never share a folder; everything meets in GitHub. n8n orchestrates, Ollama serves the models, and Tailscale links the two machines and my phone. Cloud models are used for review, not drafting, by default.

The n8n workflow for Linear agent-ready dispatch: a chain of nodes from a Linear webhook through signature check, a should-dispatch decision, an alignment gate and verdict routing, to writing a brief with a local model, choosing a model, marking the ticket aligned and creating a checkpoint, with an hourly safety net and a failure branch that frees the ticket for retry — The automation with Linear: a ticket labelled agent-ready fires a webhook, passes the alignment gate, gets a brief drafted by a local model, is routed to a model and checkpointed. An hourly safety net catches anything the webhook missed, and a failure path frees the ticket for retry

Why it existed

Running Loop properly needed its own infrastructure. Cloud inference is expensive for drafting, and I did not want every agent run to depend on a provider. I wanted local models with no per-token cost, orchestration that runs around the clock without my laptop open, and two machines that could not step on each other. The split was the answer: one machine for the work I see, one for the work that runs in the background.

My role

I designed and documented the architecture: setup guides for both machines, the conventions every agent inherits, and the verification checklists. I built and secured the orchestration, inference and networking layers.

Approach

Engineering

Frontline is the machine with a screen: the editor, the design tools, the browser and the notes. Backbone is headless: it runs the local models, the orchestration, the agents' working copies and the vault, and it never sleeps.

Orchestration runs in n8n, self-hosted in a container and reachable only over Tailscale, the private network that links the two machines and my phone. When a ticket is ready, n8n dispatches it to an agent that builds in its own copy of the repository, opens a pull request and reports back. The two machines never share a folder; everything meets in GitHub.

Models are routed by job. Local models draft, because drafting is the expensive part and they cost nothing per token. Cloud models review, because review is where quality matters most. The default is the cheapest tier that can do the job, and escalation is a deliberate choice.

Key decisions

Decision

Local-first drafting vs cloud-first

Cloud-first (all inference in the cloud)
Local-first (local drafts, cloud reviews)· chosen

Why: Cloud drafting is expensive and depends on a provider. Local drafting is unlimited and private. The cheap-quality pattern is: local models draft, cloud models review. This protects spend and keeps the drafting layer independent.
What it cost: Local models are weaker than cloud; the review layer must compensate.

Decision

Two separate GitHub clones vs a shared folder

Shared folder (both machines read/write the same files)
Two separate GitHub clones (machines sync through the repo)· chosen

Why: A shared folder is fragile - sync conflicts, locked files, no history. Two clones meeting through GitHub means every change is a commit, every state is recoverable, and the two machines never step on each other.
What it cost: Two clones to maintain; the repo is the source of truth, not the filesystem.

Outcome

M3 Studio Ultra machines: 2
cloud spend by default: 0

It is my daily setup and it powers Loop end to end. Local models draft, cloud models review, n8n dispatches, and the two machines meet through GitHub. Nothing is exposed outside the private network.

Learnings and what's next

Infrastructure for AI-assisted work is a design problem, not an ops chore. The machine split, the model routing and the private network were each a decision about what to optimise: cost, quality or independence. Architect the infrastructure the way you would architect the product.

Next: a security review of the write path and more connectors beyond Linear.