NOMINAL
--:--:--
 
One person · one stack · documented in public

Built for the
systems running
in my home lab.

AI Concepts is where RizOS is built: a self-hosted control plane for running coding agents and a Linux dictation app that works entirely offline. Nearly twenty years keeping other people's systems running — now building my own, and writing down what actually worked.

▸ See the work Read the build log

● Available for freelance & contract work · 2 tools running daily · nothing here is a mockup

rizos://stack — what's actually running
dictation:stt:faster-whisper, no network ✓local
ollama:inference:qwen3:4b · vulkanrx 570
guardy:security:local-only, fails closed ✓local
firstmate:dispatch:3 worktree slotspi 4
api:spend:capped hourly · daily · monthlyrented
me:building: 
Tools running daily
2
Working in IT since
2007
Self-hosted on
Pi 4 · RX 570
Mocked screenshots
None
/ Work

Software, not promises.

Two projects, both running every day on hardware sitting in my flat. One of them never touches the network at all.

Both in active development
Development documented in public

A self-hosted control plane and a fully local desktop app — developed on real hardware and documented as they take shape.

RizOS Mission Control — v0.2, running daily on a Raspberry Pi 4.

Not a chat window: a self-hosted cockpit for dispatching scoped work to commercial coding agents in isolated worktrees.

Watch workers and terminals, review evidence, run metric-driven overnight loops, and keep API spending and service health visible from one status bar. The infrastructure is mine; the models are rented, with hard spending caps.

Every screen answers a question I ask during the loop. The repository is private for now; the source will follow when it's fit to read.

RizOS Dictation — v2.5 in development. Press a hotkey, speak, get clean text — nothing leaves the machine. STT via faster-whisper, optional local refine via Qwen2.5-1.5B. Tauri shell, Python sidecar, ships as a .deb. Linux only · clipboard-mode injection.

Get in touch How it's built

Every screenshot is the real thing running on my own hardware — nothing mocked.

The harness

No agent grades its own work.

Both products are developed through the same multi-agent harness and skill library. One rule holds the whole thing together: whoever writes the code is never the one who signs it off. Everything else is plumbing to make that rule enforceable — and to keep the orchestration, the evidence and the spend limits on my side of the wire.

01

Dispatch

smallest mode that fits
02

Isolate

one git worktree per worker
03

Implement

coding agent, sandboxed
04

Review

different model, fresh context
05

Verify

read-only auditor, no tools
06

Promote

only if the SHA hasn't moved

Separation of powers

Four roles, deliberately held by different models, so a mistake has to survive someone who didn't make it.

Implementer
Writes the code in its own worktree. Never reviews, never merges.
Adversarial reviewer
A different model in a fresh session, briefed to attack the change rather than approve it.
Integration supervisor
Sees only the merged candidate. No filesystem, no runtime, no edit rights — it returns evidence and a verdict, nothing else.
Completion verifier
Read-only final audit, bound to the exact commit it examined. Stale or missing evidence is a fail, not a warning.

The rules it enforces

Most of the engineering here is refusal — the interesting part is what the system won't let me do.

  • Dry-run before dispatch. The launch button stays disabled until a plan has actually rendered.
  • No metric, no overnight run. If success can't be expressed as one number a command prints, the loop won't start.
  • Fail closed. A missing reviewer stops the pipeline. It never degrades into shipping unreviewed.
  • Caps are hard. Iteration limit, time limit, error threshold, spend ceiling — all set before anything runs.
  • Reports are append-only. The cockpit records what I decided; it doesn't rewrite history and it doesn't perform the merge.
  • Everything binds to localhost. Worker terminals included.

The cockpit

The dashboard used to be organised around categories of data — anomalies, memory, performance, analytics. It looked busy and told me nothing. v2 is organised around the loop I actually run, and every screen answers one question I genuinely ask.

Dispatch
What am I sending out?
Fleet
What's running right now — and which worktrees are in debt?
Review
What am I accepting, and on what evidence?
Nightwatch
What happened overnight?
Compass
Which tool should the agents be using?
Health
What's running locally, and what has it cost?

It shows state, it doesn't invent it

The constraint that shaped the build more than any other.

  • The harness schema is the single source of truth. The UI adds no fields of its own — if a control isn't backed by something the harness actually accepts, it doesn't exist.
  • Where a status genuinely isn't written to disk yet, the screen reads "not run" and I go fix the gap. It never renders a plausible-looking value to fill the space.
  • A worktree with unmerged commits and no live worker gets flagged as debt, rather than quietly disappearing from the board.
  • Failures stay on screen. A gate that didn't pass is shown as a failed gate, with a link to the terminal that produced it.

Eight composable skills · installed per project · config stays local

Field notes

Things that actually happened.

Running AI on your own hardware teaches you things a benchmark won't. These are the ones that cost me the most time — written down so they cost someone else less.

NOTE 01

An RX 570 is not an AI GPU

gfx803 was dropped from ROCm years ago, so the obvious path is closed. Ollama still reaches the card through Vulkan — but a 64K context floor pushes almost every model back onto the CPU regardless. The fix wasn't a smaller model. It was a smaller prompt.

NOTE 02

Read the prompt before you benchmark the model

An agent was answering slowly and rambling. I nearly spent a day comparing models. The problem was its identity file: one instruction about matching effort to the message took a simple greeting from about two minutes to ten seconds.

NOTE 03

The LLM lost to a shell script

For security triage, a tuned bash collector cut the noise from 119 alerts to 6 — better than putting a model on the job, at a fraction of the cost. The model earns its place on judgement calls, not on filtering.

NOTE 04

Design it to fail closed

The security agent runs local-only with no cloud fallback configured. If the local model is unavailable it stops rather than quietly escalating to somebody else's API. For that job, unavailable is a safer failure than remote.

NOTE 05

Know which of your agents can read what

Host and network scan output was landing in a notes vault that a cloud-backed agent could read. Now it lives outside the vault with tight permissions. Multi-agent setups need a data boundary drawn on purpose, not by accident.

NOTE 06

Half my agent roster didn't exist

Names accumulate faster than software does. An audit found most of the "clan" were shell scripts, message prefixes, or plain fiction — seven were real. The scheduler is the source of truth now. If it isn't in cron, it isn't an agent.

Longer write-ups as I get to them.

How it's built

Self-hosted where it counts.

Three layers. The control plane, the data and the terminals are mine; the models are a mix of local and rented, picked per job. Constraints are the interesting part — this stack has real ones.

LAYER 01

Models

Local where they fit — Ollama over Vulkan on an ageing consumer GPU, faster-whisper for speech, small models picked to fit the box rather than the benchmark. Commercial APIs for the heavy coding work, behind hard hourly, daily and monthly spend caps.

LAYER 02

Agents

Two surfaces, deliberately kept apart: the development harness above, and a set of scheduled local agents for briefings, security triage and housekeeping — each with an explicit role, its own model policy, and its own data boundary.

LAYER 03

Surfaces

A Tauri desktop app with a Python sidecar for dictation, and a dashboard on the Pi for everything else — reading from a plain Markdown vault, so the data outlives the tooling.

/ About

Ricardo

London. Nearly twenty years keeping other people's systems running: POS estates, networks, field break-fix under SLA. Now building my own tooling, and shipping it.

I started fixing PCs and small-business networks in 2007 and never quite stopped — that work still runs alongside everything else.

The formal side came next: an extended engineering year at London South Bank, then a BEng (Hons) in Computer Systems and Networks, finished with a 2:1.

Most of my career since has been field engineering — years of IT support across care facilities, then EPOS terminals, servers and switches in high-volume retail, where I also trained new engineers. More recently, field service across retail and hospitality estates: installing and configuring POS and network hardware on client sites, diagnosing faults under SLA, and handing systems over working.

The common thread is systems that aren't allowed to go down, diagnosed under time pressure, usually on someone else's site with a client watching. You learn quickly that a status light which lies is worse than no status light at all.

These days I spend my own time building software: a dictation app that runs entirely offline, and a self-hosted control plane for running coding agents. Both are on this site. Both run daily. Every screenshot is the real thing.

Infrastructure & field engineering

Networking (TCP/IP, routing, switching), Cisco routers and switches, POS/EPOS estates, hardware installation and configuration, break-fix and fault diagnosis, root cause analysis, first and second line support, SLA delivery. Windows and Linux.

Systems & self-hosting

Linux services, Raspberry Pi deployments, process supervision, local networking, and static hosting on Cloudflare Workers — including this site.

Building software

Python, Tauri desktop applications, local speech-to-text and LLM inference, and multi-agent orchestration across commercial coding models — with spend caps and an audit trail in front of them.

How I work

Not slogans — these are rules I've written into the systems on this site, and they hold whether or not anyone is watching.

  • Smallest thing that fits the job.
  • Dry-run before anything launches.
  • If success can't be expressed as one number, it doesn't run overnight.
  • Fail closed. A missing reviewer stops the pipeline; it never degrades into shipping unreviewed.
  • Never display a state you can't verify. If it isn't known, it says "not run".
  • Nobody grades their own work — including the models.

English (fluent) · Portuguese (native) · based in London, on site or remote

Say hello

Working on something self-hosted?

I'm open to freelance and contract work — AI tooling, infrastructure, or the field engineering I've done since 2007. Happy to talk about the stack either way.