Authority, freshness, provenance, drift detection, hooks, and context ceilings.
I don't just roadmap AI.
I build the systems that make AI useful.
I design and build AI-assisted products, developer tools, context systems, governed automation, and the integration layer around them—then make the failure modes visible enough to trust in real work.
Specialist agents, local inference, APIs, workflow routing, bounded execution.
Independent review, CI gates, security controls, confidence, and failure handling.
Selected AI + product work
The proof is in the systems.
I want the work to answer the hiring question. Can I reason about AI architecture, build the thing, govern it, integrate it, test it, and still think like a product owner? These projects are the evidence.
AI engineering · Context systems
Open sourcePersonal Memory Bank
Persistent project context with authority, freshness, provenance, diagnostics, hooks, review workflows, drift detection, and deterministic guardrails.
Read case studyLocal AI · Multi-agent tooling
Open sourceAI Code Review Agent
A local multi-agent review system with specialist isolation, sanitized diffs, confidence-aware findings, security controls, and IDE/CLI integration.
Read case studyAI systems · Research framework
Public researchHarness Engineering
My engineering framework for the layer around the model: context, memory, instructions, tools, orchestration, governance, evaluation, and execution boundaries.
Explore the frameworkProduct engineering · Live telemetry
Open sourcePitLogic
A deployed analytics PWA with device integration, alarms, stall detection, finish-time prediction, offline behavior, and 169 passing tests.
Read case studySee Side Quest Atlas, Tipsy Bunghole, Bowling Tracker, and the full project set →
How I build AI
Models are powerful. Systems make them dependable.
Prompting matters. So do context authority, tool contracts, state, retries, approval gates, verification, privacy, degraded behavior, and whether anyone can tell what happened when the model is wrong.
That surrounding layer is where I spend a lot of my time.
Enter Harness Engineering →Get close to the code.
APIs, Python, orchestration, local models, data boundaries, developer workflows, and the actual implementation constraints.
Bound the machine.
Give automation explicit authority, deterministic controls, and human approval where consequences deserve judgment.
Do not let AI grade itself.
Use independent review, tests, CI, structured evidence, and observable failure instead of quiet confidence theater.
More than AI
I build because I like solving things.
The AI work is central professionally. The rest of the site proves the same operating style shows up everywhere: travel products, live event workflows, bowling analytics, BBQ telemetry, woodworking, and Scouting leadership.