I build these because I like building. Outside of work, on my own time — mostly to learn something I haven't used yet. I like picking a new tool or method and seeing what it's actually good for, not just what the docs promise.


Four single-purpose agents (seasonality, logistics, budget, itinerary) with typed Pydantic handoffs, no orchestration framework, and three distinct memory types (episodic, procedural, session).
Two stages over one closet: three agents (cataloguing, weather, stylist) that turn a cataloged closet and a forecast into ranked outfit suggestions, and a compatibility graph plus purchase optimizer that ranks candidate buys by how much new outfit variety each one actually unlocks.
run(input) → output, and one schema, ClosetItem, that
forbids extra fields so a compatibility score can never get written back onto an item
record. The weather agent is split three ways: a deterministic API fetch, a rules-based
warmth window, and an LLM call reserved for ambiguous days only — a dry 26°C
day gets no API call, a day with scattered showers and an 11°C swing does.
Stage 2 runs the same closet through pairwise compatibility scoring
(color, formality, pattern, gated by hard rules like a formality gap ≥3), enumerates
every valid outfit as a clique in that graph, then ranks purchase candidates by outfits
gained — discounted to distinct style signatures, not raw combinations, so a
duplicate doesn’t read as variety.recommended vs. redundant, even
though the duplicate alone still produces real combinations. The live paths —
recommend and suggest-buy against a real closet and a live
API — haven’t produced a run report yet.A typed adapter contract for any agent exposing run(input) → output, pluggable scorers — deterministic and LLM-as-judge side by side — and a paired bootstrap regression test on score deltas instead of a raw before/after diff.
run() — so the framework never learns how an
agent works, only that it can call it and get typed output back. Scorers ship as
factories, not hardcoded checks: seven deterministic factories (schema
validation, numeric bounds, set coverage, sequence integrity, duplicate detection) plus
an LLM-as-judge scorer, both behind the same interface, running concurrently under an
async runner that holds a semaphore around judge calls so a large suite doesn’t
open hundreds of connections at once. Regression detection runs a paired
bootstrap on score deltas rather than a raw before/after diff, because eval
scores are bounded, skewed, and small-n — exactly where a t-test’s
assumptions fail.NO_SIGNIFICANT_CHANGE at n=8 and REGRESSION at n=400. The
self-contained toy-agent example runs end-to-end and writes real, diffable run reports.
Not yet validated against a live agent — wiring it into the parks planner above,
in place of that project’s one-off eval_suite.py, is next.A tiered naive → Holt-Winters → global LightGBM production stack wrapped in split-conformal prediction intervals, plus a second Prophet / LightGBM / SARIMAX / Ridge-ensemble bake-off at monthly granularity — both validated on a synthetic fixture with known ground truth before being applied to 73,482 real weekly transactions across Iowa’s top 25 liquor retailers.
Multi-touch attribution — Markov removal-effect and a data-driven LightGBM + SHAP model, benchmarked against classic heuristics — validated on 8,000 synthetic journeys with known ground truth before being applied to 267,084 real journeys from the public GA4 e-commerce dataset.