Selected Work

Five engineering problems, each with a different shape. What they have in common is not a technology — it is that none of them arrived with a finished specification.

Pencil illustration of a small, fragile laboratory prototype on a workbench on the left, connected by a plank bridge to a sturdy, fully enclosed production unit on the right, with an engineer walking across carrying a tool. — From prototype to production

A Platform Where Humans and AI Agents Build Structured Knowledge Together

FIG. 01 — MULTI-AGENT AI PLATFORM

The Situation

A team needed a way to turn open-ended conversation between people and AI into structured, auditable documents — reports, plans, code, experiment results — without someone manually reassembling a chat transcript into a deliverable afterward.

The Uncertainty

There was no existing pattern to copy. The obvious shapes — a chatbot, a Notion-style AI editor, an orchestration framework — were each explicitly the wrong model, so the real architecture had to be worked out from requirements up before any agent logic was written.

What We Did

We designed a decoupled "agent bus" architecture: roughly two dozen independent agent services — writer, editor, planner, coder, image generation, research/retrieval, UI control, and more — coordinate purely by publishing and matching messages on a shared bus, with no agent aware of any other. A dedicated audit agent listens to every message and builds a traceable log per work thread, while a multi-format document service (text, Markdown, DOCX, XLSX, HTML, JSON, PDF) acts as the system of record.

The Result

The system has gone through more than fifty iterative development phases, including two full architectural pivots discovered through real use — replacing regex-based intent matching with LLM-based classification, and replacing hardcoded per-agent logic with a hot-reloadable skills system — and now runs with several hundred passing automated tests.

Python / FastAPI
Message-bus orchestration
Multi-provider LLM integration
Custom RAG / embedding store
Multi-format document engine
Audit logging
Docker

The Shared AI Backbone Behind a Family of Products

FIG. 02 — AI CONTENT & COMMUNICATION BACKEND

The Situation

A growing family of products — educational games, an online learning platform, branded chat bots, and marketing sites — each needed language generation, image generation, translation, speech, and eventually generated video, without every product team rebuilding that integration layer from scratch.

The Uncertainty

No single AI vendor reliably covers all of that. A design locked to one provider would break every time a model was deprecated, rate-limited, or simply had a bad day.

What We Did

We grew a JSON-RPC command layer on top of infrastructure already in place — a self-contained, multi-threaded server handling static hosting, reverse proxying, and firewalling — exposing over a hundred AI commands, each backed by a provider-abstracted fallback chain across multiple language models, text-to-speech engines, and image models. We also built a from-scratch face-animation pipeline that matches audio features to pre-recorded video segments, rather than depending on a third-party lip-sync model.

The Result

The backend has run continuously since 2020 and is now the shared AI backbone behind several branded products and around twenty chat bots, with automatic provider fallback keeping products online through individual vendor outages.

Python HTTP/HTTPS server
Reverse proxy & rate limiting
JSON-RPC command dispatch
Multi-provider LLM / TTS / STT / image
Custom audio-driven video pipeline

Bringing Order to Archives Scattered Across Hundreds of Drives

FIG. 03 — CONNECTED STORAGE PLATFORM

The Situation

A client needed to catalog, archive, and safely share large volumes of files spread across many external drives and projects — work that had been happening ad hoc, drive by drive, with no formal system behind it.

The Uncertainty

There was no fixed specification to build against. The data model, the sync strategy, the access-control levels, even the way user identity worked, all evolved through real use, and the system had accumulated real technical debt along the way.

What We Did

We built a native desktop admin application with a full drive-scanning and archiving pipeline — scan, package, encrypt, upload — a remote sync backend, expiring password-protected shared links, and role-based access control scoped by company, project, and drive. When the user-management scheme showed its age, we redesigned it from first principles instead of patching around it.

The Result

A production tool in active daily use, now on its second major architectural iteration of its access-control layer, with a documented, deliberate path for the next one.

Native desktop application
Custom sync protocol
Encryption
Drive / media cataloging
Role-based access control

Making an AI Web Platform Behave Like a Trustworthy Native App

FIG. 04 — MOBILE AI COMPANION

The Situation

An AI web platform needed to reach users as an installable app with persistent voice access and a reliable background presence — not a full rewrite, but genuinely trustworthy native behavior wrapped around it.

The Uncertainty

Wrapping a website in a native shell is easy. Making it behave like an app a user trusts — surviving being backgrounded, correctly handing microphone permission from the OS to the page, recovering gracefully from a dropped connection — is where most such wrappers quietly fail.

What We Did

We built a native Android shell with a persistent foreground service, automatic permission bridging so the web page can use the microphone through the OS's own prompt, and a bundled offline screen with automatic reconnection, shipped through a signed release build.

The Result

A stable, installable companion app that keeps a session alive through backgrounding and network loss instead of silently dropping it.

Native Android
Foreground services
WebView permission bridging
Offline-first UX
Release signing

A Scheduler Small Enough for Hardware That Can't Afford an RTOS

FIG. 05 — EMBEDDED SCHEDULING LIBRARY

The Situation

A client project needed cooperative multitasking and event handling on a microcontroller too resource-constrained for the overhead of a general-purpose RTOS.

The Uncertainty

Off-the-shelf RTOS options assumed more RAM and flash than the target hardware could spare, and hand-rolling something bespoke risked producing a fragile scheduler nobody could maintain.

What We Did

We designed and built a small, dependency-free C library from first principles: an event queue, a tick-based cooperative scheduler, macro-generated state-machine tasks, and supporting primitives — ring buffers, memory pools, timers, a small file system — sized to run in dozens of bytes of overhead.

The Result

A reusable, openly licensed embedded foundation, now available for future low-resource hardware work.

C, bare-metal / MCU
Event-driven scheduling
Cooperative multitasking
Memory-constrained data structures

Have a Problem That Doesn't Fit a Clean Category?

That is usually where the interesting work is.

Bring Your Own Problem