I build AI systems that survive contact with production.

What I built

• Hold-to-send trigger on device, capturing audio and GPS
• Upload path optimised for latency over completeness. Partial signal fast beats complete signal late
• DistilBERT 7-class classifier containerised on Cloud Run, autoscaling from zero
• Live dispatcher console rendering the classification alongside the raw signal, with human override

Decisions worth naming

• The model is a speed advantage, not an authority. Classification never silently determines routing. The dispatcher sees the reasoning and can override.
• An “unclear” class is a feature. Forcing a confident answer on an ambiguous signal is worse than surfacing uncertainty. Most systems are graded on avoiding this. This one is designed around it.
• GPS accuracy gating. Early builds rendered every location fix, producing a marker that wandered when accuracy was poor and destroyed operator trust in the map. Fixed by rejecting low-confidence fixes rather than displaying them. A UI-looking bug that was actually a data-quality decision.
• Serverless because load is spiky. Emergencies don’t arrive on a schedule.

Verified end-to-end on physical devices in release builds, not simulator. 29 automated tests covering the flow. Running live.

I’d already built and shipped it. Before release I ran a deliberate adversarial pass, asking not “does this work?” but “what does this let a hostile party do?”

Three issues, all of which passed functional testing

• Privilege spoofing on the alert path. A client could assert a priority it hadn’t earned, jumping the response queue ahead of real emergencies. Functionally invisible.
• Notification token leak across sign-out. Push tokens weren’t fully torn down, so under specific conditions a device could keep receiving alerts meant for a different account. A confidentiality breach dressed as a lifecycle bug.
• Silent failure on a critical control. A trigger surface that appeared functional but was dead under certain OS states. The worst class of bug in a safety product: the user believes they’ve called for help and has no reason to think otherwise.

Response

• All three fixed, deployed, verified on physical devices in release builds
• Credentials rotated; orphaned cloud resources audited and deleted. Unused infrastructure is attack surface with no owner
• Findings tracked in a single source of truth from discovery through verified

None of these were found by testing whether the feature worked. It worked. They were found by asking what an adversary could do with it.

Directly transferable to agent systems: what can a tool-enabled agent actually reach, what happens when the model is manipulated into calling something it shouldn’t, and what’s logged when it does.

What I built

Composable agent workflows over an LLM with tool access, each scoped to one recurring job, rather than one general-purpose assistant. Pulls live context from email and calendar, acts where it can, surfaces only what genuinely needs a human.

Decisions worth naming

• Narrow agents over one general one. A general assistant is impressive in a demo and unreliable in use. Several narrow agents with explicit triggers are duller and work.
• Hard boundary on autonomous action. Nothing sends, posts or submits without approval. Drafting is automated; the send is not. In practice that’s the difference between a tool you keep using and one you switch off after it does something embarrassing.
• Persistent memory, actively curated. Treated as something to maintain rather than accumulate. Stale context is worse than no context, because it’s confidently wrong. Includes explicit correction entries where a recorded fact turned out to be false.
• Configured to disagree. It pushes back and flags when a proposed direction contradicts a written strategy document. An assistant that only agrees produces confident output and no information.

Recovers roughly two hours a week, but the real gain is that work which used to get skipped now happens consistently.

What I did

Migrated two runtime major versions and one framework major version on a live system with real users. Deployed with no incident, then smoke-tested the critical path specifically.

Decisions worth naming

• Done well ahead of the deadline, not against it. Migrating under time pressure on a safety-critical system is how you ship a regression.
• Verify the critical path, not the deploy. A green deploy tells you the code loaded. It doesn’t tell you the one function that matters still works. Those are different claims.
• Boring is the goal. The correct outcome for infrastructure work is that nobody notices.

Most engineering work isn’t greenfield. It’s someone’s existing system that has to keep running while it changes.