The Workshop — Genius Loci
The Workshop · Builder in public
Where the system gets built — tools out, in the open.
Genius Loci isn't bought off a shelf. It's being built, piece by piece, on a desktop at home: a local system of agents, a library of reusable skills, and three very different builders — Claude, Codex, and a local worker model — routed work according to what each does best. This page is the workshop door: what's on the benches, who does the building, and how a build actually moves from idea to running system. The builds themselves play out daily on The Build.
Where this stands today: the workshop is real and working — the local system runs, tickets are dispatched, and builds ship through review. It is also unfinished, deliberately: some agents are mid-upgrade, some hardware is still on the current card, and The Index is still calibrating. This page describes the building, as it stands — it offers no services and lists no products that haven't been delivered. New here? Begin at Start.
Everything gets built on one of these
Pick a bench to see what's actually on it — what it holds, what it's for, and where its edges are today. A workshop page that hides its clutter isn't a workshop page.
The local system — a desktop that works like an OS
The foundation is a single desktop at home running a local system — call it the home OS — with its own scheduler, a dispatch queue, and local AI models served by Ollama on the machine itself. Work enters as structured tickets through one dispatch door, runs on the scheduler, and reports back. When the system isn't needed for production work, the standing rule is that it should still be doing something productive — drafting, cleaning, testing — rather than idling.
What's on this bench
- The home system: scheduler, dispatch queue, and job reports
- Local models via Ollama — including the picked worker model, qwen3.5:9b
- Hermes, the desktop harness that gives the local model hands: files, shell, and tests
- A read-only gateway and audit trail between the operator's assistant and the desktop
What it's for
- Bulk work at no per-call cost — the capacity the paid builders can't offer
- Keeping the system's data and working files on the home machine
- Running the daily agent work behind the six franchise hubs
- A place where a build can be wired to keep running, not just run once
Honest state: the machine currently runs a single 8 GB graphics card. A dual-card upgrade to 24 GB of VRAM is decided and specced — not yet installed — and until it lands, the local worker is a strong drafter and single-file fixer, not a frontier coder. Hermes is installed; its first proof tasks are still being worked through.
Claude, Codex, and the local worker — routed, not worshipped
No single builder is right for every job, and paid capacity is deliberately scarce: the cloud budget is capped on purpose, so routing is a discipline, not an afterthought. Each ticket goes to the builder whose strengths — and limits — fit it.
Claude
The frontier builder. Claude Code takes the work where quality decides the outcome: architecture, hard debugging, multi-file builds, and the review pass over everyone else's diffs.
- Frontier-quality reasoning and code
- Reviews local and Codex work before anything lands
- Writes the structured tickets the other builders run
Its limit: session-capped. Spent carelessly, it's gone by midday — so it is reserved for the work only it can do.
Codex
The fast, narrow builder. Codex takes small, tightly-scoped tasks — a defined fix, a single-purpose script, a bounded change — fed deliberately, one clear ticket at a time.
- Quick turnaround on well-fenced tasks
- Good second pair of hands on remainder work
- Spreads load so Claude's sessions last
Its limit: it drains fast and wanders on open-ended briefs. Scope is everything — vague ticket, wasted run.
The local worker
The tireless one. A local model on the home desktop — qwen3.5:9b, picked by direct testing — driven through Hermes so it can read files, write code, and run tests like a real coder, at no per-call cost.
- Cleanup passes and test-guarded single-file fixes
- Drafts that Claude then reviews and sharpens
- The always-productive engine between bigger jobs
Its limit: bounded by the loaded model and today's VRAM. Its work is never merged unreviewed — that's the deal that makes it trustworthy.
Ticket, build, review, wiring — in that order
The workshop learned its process the hard way: builds that ran once to prove they worked, then quietly never ran again. The flow below exists so that can't happen silently twice.
The ticket
Every dispatched job is a fully structured ticket: objective, context, constraints, acceptance criteria. Paid dispatches are shown to the founder and need an explicit yes first.
The build
The routed builder does the work — Claude, Codex, or the local worker — inside its lane, against the ticket's criteria, and returns a completion report, not just code.
The review
Diffs are reviewed before they land and public output passes the Review Desk: agents propose, a human disposes. The method behind that gate is on The Loci System.
The wiring
A build isn't done when it runs once. It must declare how it's invoked, show its scheduler registration, and pass a persistence check — or the ticket stays open.
What every ticket carries
Executor-agnostic by rule: the same ticket can be run by Claude, Codex, or the local worker, because it carries everything the builder needs and nothing it has to guess.
- Objective — the one outcome the ticket exists for
- Context — the files, facts, and history that matter
- Constraints — budget, scope, and what not to touch
- Acceptance criteria — how done is proven, not asserted
Why builds stay alive here
The silent-death lesson, written into every ticket since it was learned: a thing built to live on the scheduler must be registered on the scheduler.
- Declare the invocation: scheduler, dispatch, or manual — in writing
- The completion report must show the registration itself
- A persistence check confirms it's still wired days later
- One manual run, however successful, does not close the ticket
The build cool things story, as of today
Builder-in-public means the current state is part of the story — including the parts that are mid-sentence. This is the honest snapshot; the daily version plays out on The Build and the evidence lands on The Proof.
-
In progress
The Index, calibrating
The scoring behind The Index runs in shadow against the real catalog, hand-checked before anything publishes. No entries yet — the workshop's biggest current build is a bar being set carefully, not a list being filled.
-
In progress
The agent roster, upgraded intent-first
All ~60 agent contracts have been assessed intent-first: valid and broken gets upgraded, valid and unwired gets wired, obsolete gets retired, unclear gets asked about — never guessed. The five-agent scout fleet is first in line; its demand-hunting intent is exactly what The Index needs.
-
In progress
Hermes, getting its hands
The desktop harness is installed on the home machine, giving the local worker real hands — files, shell, tests. Proof tasks come first, then small approved changes, before it earns bigger tickets.
-
Decided
The graphics upgrade
Dual 12 GB cards for 24 GB of VRAM, replacing the single 8 GB card — specced, priced, and decided. When it lands, resident models get loaded per purpose (coding and content) instead of hot-swapping, and a larger local coder joins the roster for Claude to review.
-
Standing rule
Always productive
When the system doesn't need its local models, they don't idle: cleanup, drafting, and test work queue up instead. The workshop's cheapest capacity is the capacity it already owns.
A workshop shows work. It doesn't sell the unfinished.
Building cool things in public only works if the line between “built,” “building,” and “imagined” stays bright. So, plainly:
Watching a build is not hiring one. The Build hub is the services door when that door opens — this page sells nothing.
Tools, agents, and workflows shown here are the workshop's own equipment. If something becomes a product, it will appear in the catalog and earn its place through The Index like everything else.
Upgrades are labelled decided, not done. Calibrations are labelled calibrating, not complete. Where a state is unproven, this page says unproven.
Agents never publish directly — not to social, not to the store. Every lane ends at a human decision, as The Loci System documents.
The six hubs are the workshop, running in public
Everything built here surfaces in one of the six franchises. Start at Start, or go straight to the hub that interests you.
This workshop, filmed: real systems built in public, one flagship piece a day.
Its job: the services door
Visit The Build → Hub · The agents Agents at WorkBench 2 in action — the roster doing real work, and the Stack Sheet that documents this bench's tools.
Its job: Stack Sheet capture
Visit Agents at Work → Hub · The judgement The BreakdownProducts and claims taken apart with the same test discipline the workshop builds with.
Its job: Scorecard capture
Visit The Breakdown → Hub · The evidence The ProofThe numbers behind the builds, shown daily — including when a build doesn't hold up.
Its job: Index Drop signup
Visit The Proof → Hub · The comparisons The StackHead-to-heads decided on evidence — the workshop's routing instinct, applied to products.
Its job: Scorecard capture
Visit The Stack → Hub · The winners The SelectCurated picks from the catalog — what the workshop's sourcing work surfaces first.
Its job: the shelf — the Index door
Visit The Select →