The message arrived on a Thursday evening. Forwarded twice already. The text looked official: a government energy rebate notification, a pending payment of £400, a link to "verify your bank details before the payment window closes Friday." The sender was her son's colleague. Nobody had checked where it came from first.

She forwarded it to her son before clicking. He was about to say it looked fine. Then he noticed the URL: gov-rebate-energy.co.uk. Not gov.uk. Not energy.gov.uk. A registered domain, clean design, HTTPS padlock, professional enough to pass a quick read. He told her not to click. She'd been one browser tab away from entering her sort code and account number into a credential-harvesting form.

This near-miss required one thing: a second person who knew what to look for. Most people don't have that. That's what I'm trying to build.

She sent 47 applications in June. Got three responses — two automated rejections and one screening call for a "graduate entry" role that turned out to require three years of commercial Python experience. She kept a spreadsheet. Most rows stayed blank.

This isn't a personal story of bad luck. It's what the ONS is measuring when it reports that employment concern among UK adults rose from 31% in June 2024 to 54% in June 2026 — the highest level since the survey began. The headline is anxiety; the substrate is a market where 14% of entry-level postings disappeared year-on-year, ATS systems silently discard CVs against narrow keyword thresholds, and job aggregators cheerfully surface the same role six times from six different scrapers.

The current generation of AI job tools makes this worse. They optimise CVs to game ATS keyword matching. They automate bulk applications, violating employer terms of service. They give candidates the dopamine hit of "sent" with no honest signal of fit.

I built the UK Graduate Career Navigator this week as a direct counter to that. It has Claude on the inside. It is not trying to do more than a candidate should trust an AI to do.

Ten weeks, nine posts, and four working systems.

The practical question behind all of it: how do you build useful AI systems where cost, connectivity, data privacy, and human accountability are hard constraints?

The industry narrative is dominated by cloud-first, fully autonomous agents operating with unlimited budgets. JigsawFlux took a different direction: local inference, offline-first architectures, Kubernetes home labs, and strict state-machine controls.

The path is visible in retrospect: direct local LLM wrappers gave way to stateful agent workflows, which gave way to bounded edge systems for clinical consultation, travel risk assessment, and NHS appointment recovery.

This is what those nine posts covered, what connects them, and the five engineering rules that emerged from the work.

The letter arrived on a Tuesday. Oncology outpatient appointment, 9:15am, Thursday fortnight. It was in English. The patient spoke Somali.

She didn't attend. The clinic marked her DNA — Did Not Attend — and returned the slot to the general pool. Three weeks later, a re-booking letter arrived, also in English. By the time a care navigator reached her by phone, her chemotherapy cycle had shifted. The treatment window had narrowed.

This happens eight million times a year across the NHS. The aggregate cost is approximately £1.2 billion annually, but in oncology the cost isn't primarily financial — it's clinical. Missed chemotherapy cycles and delayed radiotherapy planning disrupt treatment pathways engineered around strict timing for efficacy. The slot that goes unfilled at 9:15am on Thursday is time that cannot be recovered by anyone on the waiting list behind her.

I built Appointment Guardian this week to close a specific gap: not sending the reminder, but handling what comes after it. The system imports appointments from FHIR, generates personalised reminders in the patient's language using a local LLM, manages patient replies, classifies barriers, routes tasks to the right care team, and escalates non-response automatically — without any human initiating each step.

It went live on a home-lab MicroK8s cluster on 2026-07-18. This post documents what I built, the four architectural decisions that shaped it, and five things that went wrong.

It is 11:40pm local time in Crimea. A field researcher — call her T-002 — is in her hotel room when she hears shots outside. She picks up her phone, opens the company travel app, and types what she can see. The app is offline. There is no satellite signal. The ops centre in London cannot be reached.

What happens in the next sixty seconds matters. Not for a sprint retrospective. For her.

This post is about building a system that makes those sixty seconds count — an offline-first agentic travel risk assessment application that runs entirely on a local LLM, asks one clarifying question if it needs to, and produces a structured risk verdict before the connection returns. No cloud dependency. No API key in the critical path. The database, the model, and the application all run on the same MicroK8s node — the one I set up in my previous post on my home lab Intel NUC.

But before the architecture: the context. This system exists because employers have a legal and moral duty to protect people they send into harm's way. That duty does not pause when the internet does.

The code is at JigsawFlux/airgapped-agentic-trm.

A 999 call comes in: a 3-storey building is on fire, casualties are reported, and High Holborn is gridlocked. The Incident Commander has roughly 90 seconds to answer four questions. Which hospital can take burns patients — and is it under pressure? How many pumping appliances does the NFCC minimum require for a multi-storey structural fire? Which traffic corridor can the ambulances actually reach? And does this cross the threshold for a formal Major Incident declaration?

Which agentic pattern you use to support that decision changes everything — not just how fast the answer arrives, but whether the answer is auditable, protocol-compliant, and safe to act on without a human double-checking it.

This is Part 2 of the JigsawFlux series on open-source agentic frameworks. Part 1 compared LangGraph, CrewAI, and AutoGen at the framework level. Part 2 puts eight specific reasoning patterns — ReAct, ReWOO, Plan-and-Execute, Reflexion, Hierarchical, DAG, Network/P2P, and Consensus — through the same incident and measures what each one actually does. The full source is at github.com/JigsawFlux/agentic-patterns.

The first decision in any agentic project isn't which model to use. It's which framework will orchestrate it. Get that wrong and you inherit a stack you can't run locally, can't afford to scale, and can't escape when the vendor changes the API.

This is a JigsawFlux project. JigsawFlux builds open-source tools for health tech, humanitarian response, and crisis management — in places where "cloud-native" is not an option and IT budgets are measured in grants, not headcount. That context imposes hard constraints on every architecture decision: portability, cost, and freedom from vendor lock-in.

The frameworks here — LangGraph, CrewAI, and AutoGen — were chosen because they meet those constraints. They are open source, actively maintained, and run entirely on hardware you own. Alternatives like Microsoft Semantic Kernel or Amazon Bedrock Agents are capable, but they introduce hard dependencies on specific cloud ecosystems. That trade-off doesn't fit the JigsawFlux model.

The name cuts two ways. It's a clinic — for patients. And the clinic runs on agents.

The problem this POC targets is specific: small and charity hospitals where doctor time is genuinely scarce and IT budgets are measured in hundreds of dollars, not thousands. A consultation isn't just a diagnosis — it's intake, medical history retrieval, triage sorting, prescription recording, pharmacy stock checking. The typical workflow hands all of that to a doctor anyway, because there's no other option. The result: a clinician spending 40% of their time on work that doesn't require clinical judgment.

The premise here is simple. AI handles everything that doesn't require a clinician. The doctor steps in exactly once — to read the AI-produced intake summary and give a diagnosis. That's it. The prescription agent takes over from there.

This is a JigsawFlux project. JigsawFlux builds open-source tools for health tech, things that matters — tools that have to work in the real world, not the well-funded one. That means two hard constraints shaped every architecture decision here: cost and deployability. Viable on a shoestring budget. Runnable in places where "cloud-native" isn't an option — a clinic with a single server, unreliable internet, and an IT team of one.

Built on AWS Bedrock (Claude Haiku 4.5), LangGraph for orchestration, LangChain @tool wrappers for data access, and Streamlit for the UI. Total cost: < $0.01 per consultation. Deployable on a £25/month VPS or a clinic's own hardware, with the option to go fully on-premises as models improve.

Four months into 2026, Uber's AI budget for the year was already gone — thousands of engineers with un-gated access to Claude Code, bills reportedly running $500–$2,000 per person per month, and leadership asking very loud questions about what exactly all those tokens were buying. Around the same time, an unnamed "mystery company" reportedly burned $500 million on Claude credits in a single month — not from a runaway model or a billing bug, but because nobody had thought to put a usage cap on employee licences.

Neither story is about bad engineering. Both are about one broken default: when developers get unrestricted access to frontier models, they use frontier models for everything.

I've been working through a framework to fix this — not by restricting access, but by routing the right task to the right model. The goal is frictionless development that doesn't quietly drain your budget. Here's how it works.

In Part 1 I ran Ollama directly on a Linux machine and wired it up through an MCP layer to a small web app. It worked. But bare-metal has friction — if the process crashes, it stays down. Adding Open-WebUI means managing another process. Resource limits are manual. There's no clean internal networking between services.

This post moves the whole thing into Kubernetes. The goal isn't enterprise-grade infrastructure — it's a home lab setup that's reliable, easy to extend, and honest about its limitations.

Manifests are in the ollama-mcp-starter repo under backend/k8s-deployment/.