I build the systems I ship.

Real multi-agent systems fall apart in predictable ways, agents talk over each other, one bad output poisons downstream steps, and retry loops silently rack up cost. I wanted to build the coordination and safety layer that makes many agents actually work together.

A hub-and-spoke communication model where a router mediates every hand-off, wrapped in a shared, typed “content envelope” that carries provenance and QC status between agents. Built a real marketing pipeline (intake → brainstorm → legal check → create → QC ⟲ retry → escalate) and a brainstorming pipeline that sizes and validates tasks.

A registry of agency subgraphs compiled off shared graphs; a single content envelope (type, payload, metadata, provenance, qc_status) as the only inter-agent contract; a deterministic QC rubric with a bounded retry loop (≤3) and an escalation path; a model-role split (heavier reasoning vs. cheaper generation) resolved at one LLM chokepoint.

• One chokepoint for all model calls. Routing did not see the actual LLM calls, they fired inside agency nodes, so the spend guard had to live at the generation function, not the router. A load-bearing detail that only shows up when you build the real thing.
• Governance as data, not vibes. Banned-phrase / doctrine checks are a deterministic rubric, so quality doesn't depend on a model's mood.
• Worst-case pre-flight check. Every call is pre-checked against its maximum possible cost before it fires, a call that would cross the budget is blocked, not made and regretted.

Python · LangGraph · multi-provider LLMs · SQLite · 40+ tests (deterministic offline stub mode)

Content strategy usually runs on gut feel, what to make next, and whether the last batch actually worked, rarely gets evaluated systematically. I wanted a system that treated both halves, what to try and what actually happened, as data problems with a real pipeline behind them, not opinions.

A research stage that takes seed accounts and creators and turns them into an evidence-backed opportunity map, what's working, why, and what's transferable, using a live scraper for ground-truth engagement data where available and search-indexed data as a fast first pass. Paired with a feedback stage that ingests real posting outcomes after the fact and diagnoses where a result actually came from, research, scripting, execution, or platform/audience mismatch, so the next batch inherits the lesson instead of repeating the miss.

A scraping layer rebuilt on a maintained scraping library after an earlier approach proved unreliable, verified via package introspection rather than assumption, since the original method silently couldn't retrieve real view counts; a SQLite log of every scraped data point, ranked by the platform's own strongest engagement signal; two model-agnostic rulebooks, one for research and validation, one for post-hoc feedback, written to generalize across content categories rather than being tied to one account's voice or niche; an explicit hierarchy that treats actual posted outcomes as ground truth over what was planned or intended.

• Verify the tool works before trusting its data. An earlier scraping approach looked functional but was silently returning fabricated or incomplete engagement numbers; the fix was confirming the real data path existed in the library's source before trusting any number it returned.
• Separate fast signal from ground truth. Search-indexed data is treated explicitly as a first-pass triage layer, not the audit itself, a discipline that keeps low-confidence data from driving real decisions.
• The feedback loop is diagnostic, not just a scorecard. Instead of just logging win or loss, the system attributes why, which pipeline stage a miss came from, so fixes target the actual failure point.

Python · a maintained scraping library · SQLite · rubric-driven, LLM-agnostic evaluation rules

Generating a large, consistent, high-quality document package from unstructured input at volume, while keeping cost bounded and catching the tell-tale signs of low-quality machine output, is a genuinely hard orchestration and QA problem. I built the engine that does it end to end.

A pipeline of specialized agents (parsing, scoring, tailoring, generation, quality checking) coordinated over a shared job store, fed by a resilient multi-provider LLM layer, with a deterministic quality gate that runs with zero model calls.

~50 role-specific agents driven by editable rulebooks (behavior is config, not hardcoded logic); a multi-provider router with time-boxed failover (a rate-limited provider is disabled for a bounded window, not permanently); a composite scoring model blending model judgment with rule-based signals; a deterministic stylometry judge scoring tells, cadence, metric density, and rhythm (zero LLM cost) feeding per-item fixes back into the generator; a SQLite tracker as the single source of truth.

• Failover must be time-boxed. An early version permanently disabled a provider after a burst of rate-limits, collapsing the system onto a slow local fallback. Bounding the disable window fixed runs that previously never finished.
• Quality judging should cost nothing. Using a model to judge model output is circular and expensive; a deterministic stylometry pass is cheaper, faster, and more consistent.
• Agents reason against rulebooks. Behavior lives in editable rule files, so the system is tunable without touching code.

Python · multi-provider LLM routing · SQLite · Typst/PDF rendering · deterministic stylometry · extensive test suite

Two-sided marketplaces are deceptively hard, you need role-separated auth, guarded vendor areas, a booking lifecycle, and payment scaffolding, all without leaking one side's capabilities to the other.

Built on the current Next.js App Router with server actions for all auth (no client-side credential writes), server-side route guards for the vendor portal, and a booking draft → review → agreement → closeout flow backed by Supabase with graceful fallbacks when tables aren't present.

Next.js 16 App Router + React 19 + TypeScript; Supabase SSR auth with role-based metadata; server-enforced vendor guards (role + approval state checked server-side); a typed domain model (users, vendors, vehicles with health/maintenance fields, bookings, reviews); payment integration scaffolding; Supabase migration with RLS policies; CI for lint + build.

• Auth writes happen on the server. Credentials and role state are set through server actions, closing a common marketplace security hole.
• Vendor access is enforced server-side, twice. Both the role and the approval state are checked in a server layout, a pending or non-vendor account cannot reach vendor pages even with a crafted request.
• Degrade gracefully. The dashboard reads live data where tables exist and falls back cleanly where they don't, so the app is always demoable.

Next.js 16 · React 19 · TypeScript · Supabase (auth + Postgres + RLS) · payments · Tailwind · Vercel

Delivering credible, personalized guidance over 22 countries' visa, tax, and cost-of-living data means solving three things at once: keeping a large factual dataset accurate and fresh, computing personalized results fast enough to feel instant, and handling sensitive personal data responsibly across jurisdictions.

A FastAPI backend with a large scoring/analysis engine over a structured 22-country dataset, a fast guest flow (résumé in → personalized result in under a minute, no login), and a compliance layer (visible data-freshness disclosures, GDPR export/delete, explicit human-approval gates) designed in from the start.

FastAPI with ~68 endpoints; a structured country dataset on a quarterly fact-check cadence plus automated drift checks; verification of certain claims against official government registries; a multi-provider payment layer (three providers) with webhook signature verification and multi-currency support; magic-link auth; a guest flow that computes results without an account; SQLite with a Postgres migration path; a separate SEO surface of 22 per-country pages.

• Data accuracy is a scheduled process. A documented quarterly audit plus registry-backed verification keeps the dataset defensible, with disclosures on every screen that surfaces a number.
• Compliance is architecture, not a footer. GDPR export/delete endpoints, per-screen disclosure, and a structural human-approval gate were built in, not bolted on.
• One payment endpoint, many providers. A single interface fronts three payment backends with unified webhook verification, so the frontend never knows which provider ran.

Python · FastAPI · SQLite/Postgres · multi-provider payments · government-data integrations · vanilla-JS SPA + static SEO pages · Render

Turning a folder of raw photos into consistently good, platform-ready content usually needs a human editor's eye. I wanted to model that eye, scoring, selection, and assembly, as a repeatable pipeline.

A local vision model scores every image on a multi-axis rubric (composition, color, mood, “save-worthiness”), a planner picks the format and theme against a rotation, and an assembly engine builds the media (Ken Burns motion + word-synced captions for video; layout for carousels). A weekly pass re-weights the rubric from real engagement data.

Local vision scoring (no external API); a weighted rubric persisted and re-tuned weekly; a format planner enforcing a content rotation with starvation fallbacks; a media assembly engine (motion, captioning, grading, layout); a ledger tracking outputs; provider-swappable rendering.

• Scoring runs locally. A local vision model keeps per-image cost at zero and the pipeline runnable at volume.
• The rubric learns. Weekly re-weighting against real performance closes the loop between “what I thought was good” and “what actually landed.”
• Fail safe, not silent. When there aren't enough fresh high-scoring inputs, the planner deliberately falls back and logs why, instead of shipping weak output.

Python · local vision model · FFmpeg-based assembly · SQLite ledger

Generating a consistent character across many images is hard (models drift), and doing it locally on constrained hardware is harder. I wanted a pipeline that held identity stable and stayed runnable on an 8 GB laptop.

Bridged a local image generator with an identity-lock step, wrapped in a job system that logs every run's parameters, status, and lineage so results are reproducible and traceable.

A generation bridge + identity-consistency bridge behind stable internal contracts; a job queue with JSONL run logs (params, status, lineage); a FastAPI service + web UI; a deliberately dependency-light, standard-library-first core so it runs on an M1 Air with 8 GB RAM; provider adapters kept optional behind a stable interface.

• Local-first and resource-conscious. Standard-library HTTP + SQLite core, no heavy dependencies for the first slice, a constraint that forced cleaner boundaries.
• Every run is traceable. Job lineage and JSONL logging make outputs reproducible and debuggable, not one-off.
• Adapters, not lock-in. Rendering providers sit behind a stable contract so the engine isn't tied to any one backend.

Python · FastAPI · SQLite · local generation bridges · Next.js web UI

Voice synthesis is powerful and sensitive. I wanted a working TTS pipeline whose design made a privacy guarantee structural: the audio model and voice profile stay entirely local.

A standard-library-only CLI that chunks text, calls a local voice server, and stitches the results, with an explicit network guard that refuses any non-loopback address.

Zero third-party dependencies (Python standard library only); text chunking + audio stitching; a hard loopback-only guard that rejects any non-local server address, so voice data physically cannot be sent off-box; config-driven with defaults mirroring the local server's own.

• Privacy enforced in code, not policy. The loopback check is a hard refusal, making the “stays local” promise a property of the software rather than a claim.
• No dependencies on purpose. Standard-library-only keeps the trust surface tiny and the tool portable.

Python (standard library only) · local voice server