I want to be honest about how this was made. The honest version is more useful than the myth.

I didn’t sit down and architect a system. I had a problem. I was drowning in newsletters and articles I meant to read.

So I thought I’d learn about AI by building something that would actually help me. Something that runs on my local machine, uses local models, and spends no money, or close to none, while doing something useful.

So I started solving it in small steps, with an AI as my pair. On a dedicated machine with its own account. Nothing pretends to be me. It’s my assistant. I asked for a thing, Claude built it, I used it, I said what was wrong, and we fixed it. Then the next thing.

Do that for months and you don’t get a design. You get a stack. A few hundred small decisions stacked into something that runs.

The thing is called Argus. It runs on a Mac Mini in my house that never sleeps. It reads my feeds at 1am and 2am, transcribes my podcasts and voice memos, keeps a searchable index of everything I’ve read, drafts in my voice, and reminds me of what I said I’d do. It’s been in production for months.

What the finished thing actually looks like

I measured it rather than guessed. Here are some numbers.

Argus is about 12,850 lines of my own code. Roughly 81 percent of that is deterministic. Fetching, deduplicating, indexing my reading into a vector store, routing, cron, health checks, and a dashboard that’s almost entirely plain web and database code.

The part that actually touches a model is around 2,400 lines. And even that’s generous, because most of those lines are HTTP calls, retries, and JSON parsing wrapped around a much smaller core of prompts.

The models themselves are invoked from 32 places in the whole system. Twenty of those calls go to a local model, Qwen, running on a second machine over a private network. Twelve go to a frontier model, Claude. That’s the entire “AI” surface. 32 call sites in 13,000 lines.

I didn’t plan that ratio. It’s just what fell out of solving each problem with the cheapest thing that worked. But looking at it now, I think the ratio is the whole lesson.

What the system actually does

• Reads my newsletters and article feed overnight, throws out the noise, and writes a short case file on what’s left
• Audits its own picks. A separate step checks whether an article really fills a gap before it earns my attention
• Keeps a searchable index of everything I’ve read, about 5,700 vectors, so I can question my own reading
• Drafts in my voice, off my own back catalogue
• Transcribes my podcasts and voice memos locally. No subscription, no cloud
• Remembers our conversations across sessions and reminds me of what I said I’d do
• Runs itself on a schedule, self-heals when a piece falls over, and reaches me over iMessage
• Handles the admin: finance categorisation, reading tracking, the odd hockey score
• Syncs my Goodreads shelf and classifies fiction and nonfiction as a learning signal

All of this lives on my locally run dashboard, which replaced Obsidian.

The pattern I only saw afterward

Here’s what the iteration taught me without my noticing: almost nothing in a useful AI system wants to be a model.

The high-volume judgement, the first pass over every incoming article asking “is this even relevant to me,” runs hundreds of times a night on the local Qwen model. It needs to be consistent. Nothing fancy.

The frontier model is held back for the rare, expensive calls. Drafting, editing, and one job I really like.

When the local synthesiser flags an article as strong, it usually justifies that by claiming the piece fills a gap in what I already know. I didn’t trust that. So at some point I added a separate step, on Claude, whose only job is to try to prove the first step wrong. It checks whether the gap is real, and if it isn’t, the article gets quietly downgraded.

The expensive model doesn’t do the work. It audits it.

I didn’t design that inversion on day one. I added the gap-verifier because the synthesiser kept over-claiming and it annoyed me. But that’s the point about iteration. The good structure arrived as a fix to a real irritation, not as a diagram. And once it was there, I could finally see the principle it was an instance of. The frontier model belongs where a cheaper step needs auditing, and almost nowhere else.

What was actually mine

If Claude wrote a lot of the code, and it did, a fair question is what I contributed. Having gone back through it, the honest answer is the steering. And it turns out that’s most of the job.

I made the constraint. My data does not leave my machines unless I decide it does. My journal goes back to 2015 and it lives in my Obsidian vault. So local-first is the rule that forced most of the choices.

I made hundreds of small calls about what was good enough, what to throw away, what to push further, and when a thing was actually right. I chose to route the cheap work to hardware I own and hold the expensive model back. And I’m the one who went and measured the result and recognised the pattern in it.

None of that is writing the HTTP client. All of it is judgement.

And I’ll be honest about the parts that aren’t mine at all. Qwen and Whisper are off-the-shelf models I route to, not things I trained. The skill on display isn’t invention. It’s knowing where each piece belongs.

Why this is the more useful story

The fashionable way to build this in 2026 is the opposite of what I ended up with. Reach for a frontier model, wrap it in an agent, hand it tools, let it figure things out. It demos beautifully, and a lot of production systems are being built that way right now.

Mine drifted the other direction. One pragmatic fix at a time, until the models were the small, audited, expensive part and plain code carried the weight.

I don’t think that’s just my accident. I think it’s where these systems settle when you optimise for actually running every day instead of demoing well. The deterministic core is fast and doesn’t hallucinate a step. The cheap local model eats the volume for free. The frontier model earns its cost precisely because it’s rare and its job is to disagree with something cheaper.

That’s a system that survives its author walking away. And mine has, through shipped bugs and a crashed dashboard and drafts I lost to a page refresh. Each one fixed into something steadier. Production isn’t about avoiding failure. It’s about recovering from it.

The point

“AI solutions architect” gets used as if it means picking the best model. In my experience it means the opposite. Knowing how little of the system should be a model at all. Routing each decision to the cheapest place that gets it right. Having the judgement to recognise a good structure when iteration hands it to you.

I didn’t design Argus top-down and I’m not going to pretend I did. I grew it, argued with an AI the whole way, and paid attention to what the result was trying to teach me. One person, two machines, 32 model calls in 13,000 lines, and a stack of small correct decisions.

The judgement is the part that was mine. The architecture is just the shape it left behind.