Work

Four projects from the Project Nexus Code lab, plus decision-support data work from prior engagements. Each piece is framed by what changed for the business, not just what got built.

From the lab

• Project Nexus

  Distributed AI architecture across a mesh of heterogeneous compute.

  The problem

  Modern AI workloads don't fit one machine, and they shouldn't pay for one machine when they don't fit. A research desk, a workstation, and a handful of consumer GPUs are different shapes of compute with different lifetimes, and a serious AI lab has to use all of them.

  What we built

  A distributed runtime that treats heterogeneous nodes (different GPUs, different operating systems, different network reliabilities) as one fabric. Workloads pick the right node by capability, not by hostname. Reliability is in the scheduler, not in a wiki page nobody reads.

  Why it matters

  The lab can run real work without rewriting it every time the hardware shifts. The architecture is the bet that you don't need a hyperscaler to do serious AI engineering, and the bet is paying off.

• Vector

  An edge robotics perception platform.

  The problem

  Robotics perception code is brittle in production and brittle in the loop: it works on the bench, then a new sensor variant or a new operating environment quietly degrades it, and nobody knows until something falls over.

  What we built

  A perception platform aimed at the edge, where you don't get to ship a model the size of a car. Sensor abstraction, model packaging, eval harness on real captured data, and the kind of instrumentation that makes a regression visible the day it happens instead of the quarter it happens.

  Why it matters

  The interesting part of robotics perception isn't getting the model to work once. It's keeping it working as the world it sees changes. Vector is built for the second part.

• Agent-driven sprint platform

  Autonomous-agent runner and contract-first work-planning system.

  The problem

  AI coding agents are useful and they are also chaos generators if you let them work without contracts. "Write the feature" is too big. "Make this test pass" is the right unit. The trick is the middle ground: a board of small, contract-shaped work that agents can pick up in parallel, with humans on the merge button.

  What we built

  A kanban-style board purpose-built for agent-driven work. Cards are contracts (inputs, outputs, definition of done). The runner is the loop that picks them up. Re-entrant by design, so the system can resume after a crash without losing place.

  Why it matters

  It's the production version of the workflow we use for our own projects, which is the most honest possible recommendation. We've shipped real features through it, including the features of itself.

• Career Ops

  A ToS-safe job-hunt pipeline.

  The problem

  Looking for the right senior ML/AI role is a data problem and a ranking problem before it's a pitch problem. The job boards have different APIs, different terms of service, and different definitions of what a "remote" job actually is.

  What we built

  A pipeline that ingests postings from sources that allow it (with required source attribution), fit-scores them against a profile, tracks applications through their lifecycle, and runs locally on the machine that owns the data. PII never leaves the operator's control.

  Why it matters

  Job-hunt tooling that respects the boards it reads from and the person using it is rarer than it should be. Career Ops is also our own pipeline; we eat the food we cook.

Prior client work

Delivered during prior employment. Named engagements are kept anonymous here; the discipline and the outcomes are not.

• Decision-support data systems for a manufacturing leader

  Reporting UX on .NET, during prior employment.

  The problem

  Leadership at a Fortune-500 manufacturing company was being held up by reporting interfaces that hadn't been touched in a long time: slow, hard to read, hard to trust. The data was there. The path from data to decision was the slowdown.

  What we built

  Refreshed executive reporting interfaces on .NET. New layouts that matched the questions an executive actually asks. Charts that answered the headline question on first glance, with the supporting numbers one click away. Quiet performance work underneath so reports loaded in time to be useful.

  Why it matters

  The discipline -- get the right number on the screen first, know where it came from, know how stale it is -- carries directly into the AI/ML systems work we do now. Models that decide things deserve the same data hygiene as humans that decide things.

• Reporting surfaces for a healthcare technology platform

  Reporting and dashboard surfaces on .NET, during prior employment.

  The problem

  Same shape of problem, different setting. A healthcare technology platform's decision-makers were spending more time wrangling reports than reading them.

  What we built

  Reporting and dashboard surfaces on .NET tuned to the actual reading rhythm of the people using them, not the data team that generated them. Clearer hierarchy, sharper defaults, less noise.

  Why it matters

  Decision-support UX is the under-named discipline of putting the right number on the screen first. The work earns its keep again now as the data-input layer for ML decision systems: a model that gets a clean number gets a chance to be right.

Want one of these tailored to your environment? The lab work and the client work share a method; what changes is the data and the constraints. Tell us what you're trying to do.