Selected work
My Latest Work.
PaperCusp
Agent platform
2026 — present
A local-first platform where fleets of AI agents plan, coordinate, implement, test,
and release complex software with limited human oversight. TypeScript/Hono operator
API and a React/Tauri desktop app over embedded PostgreSQL.
- Orchestration model for agent fleets, project harnesses, plans, and work queues — collision-safe file claims, dependency-aware scheduling, event-driven wakes, and restart-safe session recovery.
- Blueprint-driven harness system for reusable agent roles and workflows spanning software development, research, review, migration, and general knowledge work.
- Multi-account inference gateway with rate-aware routing and failover, so concurrent agents share model capacity without hard-coding a single provider credential.
- Self-improvement pipelines built on rubrics, scorecards, and feedback loops that turn production observations into prioritized, traceable improvements.
- Release infrastructure spanning unit and integration tests, real Tauri desktop verification, guarded promotion, deploy health checks, and rollback — dogfooded with 50+ concurrent agents on its own codebase.
Oddsmith
Prediction markets
2026 — present
An automated bidder for prediction markets — Polymarket and Kalshi — built
as a Tauri desktop app with an embedded Postgres and a live trading engine. It is
strategy-agnostic by design: the same path a backtest replays is the path that trades.
- A real pipeline, not a script. Prospector ingests markets from the venues, an analyst produces a calibrated probability, the engine sizes the position past the risk gate, and the order manager places it — every stage inspectable, every decision auditable.
- Analyst and trader are separated on purpose. The research side emits a calibrated probability and a rationale, and never sizes a position. The money side trades on
edge = p_model − p_market, only past a threshold beyond fees and spread.
- Risk is structural. Fractional Kelly sizing, hard exposure caps, idempotent orders, and an armed kill-switch on the top bar of every screen.
- Paper-first, with a pre-registered gate. Real money is not armed until forward-validated evidence clears targets fixed in advance — closing-line value, Brier score, and per-stream scorecards accrued on live market data. The bars do not move to meet the results.
Built on PaperCusp
Oddsmith runs on the same agent infrastructure I built. Its research desk
lives in PaperCusp as the oddsmith-ops pot: agents ingest markets
from the venues, queue each liquid one as a bet-analysis task, and hand it to an
analyst to price into a signal. The trading system’s own development and its
daily research loop run on the same coordination, queueing, and audit layer.
Store Wolf
Commerce at scale
2013 — 2025
The company I founded and ran for twelve years: a fully automated commerce
platform that generated over $1M per month in revenue while needing only three
warehouse staff to operate. Almost none of the difficulty was in the selling
— it was in keeping millions of records correct across systems that were
never designed to agree with each other.
- Distributed synchronization of inventory, pricing, orders, and listings across millions of SKUs and multiple marketplaces, with serial-level tracking and high-performance caching.
- A fulfillment optimizer that modeled 100K+ SKUs as a weighted graph; bitmap indexing evaluated millions of configuration paths and recomputed lowest-cost fulfillment in roughly sixty seconds.
- An LLM-assisted product matcher that combined model confidence with human-calibrated thresholds, so high-confidence marketplace matches could be automated safely and the rest escalated to a person.
- Microservices for distributed execution and cross-machine communication, plus automated listing, advertising, price-history, and availability engines.
$1M+ / mo
Revenue, running on automation rather than headcount.
3
Warehouse staff needed to operate the whole business.
Millions
Of SKUs kept in sync across multiple marketplaces.
~60s
To recompute lowest-cost fulfillment across the catalogue.
SideStage
Live commerce
2026
Live-selling infrastructure — a seller studio and a buyer room joined by
sub-second video, running on the same sample catalogue as Restart. The seller talks;
the room watches, bids, and buys without the stream ever leaving the page.
- WebRTC in both directions, no SDK. The browser publishes over WHIP and viewers subscribe over WHEP against MediaMTX — plain HTTP negotiation, sub-second glass-to-glass, with an authenticated TURN relay on 443 for networks that block UDP outright.
- The transcript is a control surface, not a caption track. Speech streams to Deepgram over a live socket (Web Speech as the fallback engine); finalized segments are matched against the seller’s own catalogue, and naming a product offers to put it on stage — a suggestion the seller accepts by click or by saying “confirm”, never an automatic swap.
- A grounded seller copilot. Buyer questions are answered from live event facts and the catalogue, and every proposed answer or price action lands in a review queue the seller clears — the model drafts, the human ships.
- Guardrails computed twice, on purpose. Price floors and markdown caps are evaluated in the browser so a seller is never shown a control that composes an offer the server will refuse, then enforced again server-side as the only authority — the client mirror is imported from the server’s own guard and tested against it, so a divergence fails a test instead of reaching a seller.
- Everything in the room is live state. Postgres is the record; presence, chat, transcript, auction and inventory replicate to every open room over websockets, so a bid, a sale, or a markdown lands on all of them without a refresh.
seller camera
↓ whip · turn 443 fallback
media server
↓ whep
every buyer in the room
seller audio
↓ live transcript
↓ match the catalogue
“put that on stage?”
Restart
Demo build
2026
A demonstration build, not a business — a multi-marketplace listing platform
and B2B storefront I put together to show the architecture end to end. The catalogue
and the figures on it are sample data; there are no real customers or orders behind it.
- One description in, six marketplaces out. A universal product schema is the pivot; per-marketplace adapters map it to Amazon, eBay, Walmart, Backmarket, Newegg, and Google Shopping.
- The model sits inside the typed path, not around it. An LLM classifies the product type, then extracts properties under the matching Zod schema — validated and rejected on a miss, never quietly defaulted.
- Vision-verified imagery. Candidate product images are checked by a multimodal model — no watermark, single product, actually matches the description — and the listing is rejected if none pass.
- NestJS microservices over a Redis transport with Postgres and Drizzle, each marketplace subscribing to its own listing topic, plus a description cache keyed by content hash so repeat inputs skip the model entirely.
description
↓ classify · extract · validate
universal product
↓ verify imagery
↓ map per marketplace
amazon · ebay · walmart
backmarket · newegg · google