Kinect, Glass, Arduino
The same protocol, years earlier: one server so a motion sensor, a wearable, an Arduino and a browser could all drive each other over a network, whatever kind of connection each one spoke.
For twenty years, whenever a tool didn't do what people needed, I built the missing layer and wrote it down so it could be used again. Those layers fall into four kinds. They turn out to be most of what agentic AI is made of. Here's the same move on both sides of the line.
A shared way for separate systems to pass messages, without either end having to know the other's internals. Today this is what MCP does. I kept building it by hand for years before it had a name.
An open-source message server built on one idea: wrap every message in an envelope the server never needs to understand, so clients can talk in new ways without redeploying it. That's roughly the bet MCP makes. I got there early by accident, not foresight.
Read the case studyThe same protocol, years earlier: one server so a motion sensor, a wearable, an Arduino and a browser could all drive each other over a network, whatever kind of connection each one spoke.
On a client platform I build and run MCP servers that let a chat agent reach real tools and data. One of them, a run-any-model server, is published and installable on its own.
Read the case studyLet a non-programmer work in the tool they already understand, then compile what they made into something a machine runs. A skill file is exactly this: write the method in plain language, the model follows it.
Read an animator's timeline in the tool they already used, and emitted production CSS or JavaScript from it. A compiler with swappable outputs, so the designer never had to hand-translate their work into code.
Read the case studyNine steps of UX work, from audience research to visual identity, written as skills a model follows and installable in one command. They're design deliverables, compiled into a form a machine can run.
Browse the skillsBuilt with that skill set, top to bottom. The research, the personas, the architecture, and the copy all came through the pipeline. It's the clearest proof the method works, because you're reading it.
Don't trust the measurement you were handed. Build your own, make it checkable, and put it in the pipeline so the standard holds without anyone remembering to check. This is the hardest part of building with AI, and the oldest habit I have.
A way for a team to agree what "done" meant before starting, so nobody shipped something plausible but wrong. A spec is a fidelity contract, and it's the best defence against an AI that hands you something that looks right.
Read the case study thenWhen human review was the bottleneck, I automated the loop: upload, inline, send, check. The same shape as evaluating an agent's output today.
Read the case studyOn a client build, accessibility and performance checks run against a committed budget in CI, so the standard holds because the build fails. I'm also building a harness that scores how well a model's sources actually support what it claims. That one is early, and honestly still an open question.
Take a noisy, continuous input and reduce it to a small set of things a system can act on. In AI work this is structured output and safe tool use. I'd been doing it with gestures, scroll, and sensors for a decade.
Mapping one continuous input, scroll position, onto a designed sequence moving through 3D space. GreenSock featured it in their documentation. It's also, more or less, the thing you're scrolling through right now.
Read the case study thenA live installation that turned a stream of social posts into a single shared object on screen, and closed the loop into physical lights when it filled. Messy input in, one clear signal out.
Read the case studyOn the client platform, anything the model didn't write itself, scraped pages, error logs, uploaded data, gets wrapped and escaped so it can't be mistaken for an instruction. Typed tool schemas keep the model's output to a shape the system can act on.
The four moves sit on top of two decades of straightforward user experience work, for enterprises and nonprofits alike. Same discipline, whether the reader is a person or a model: work out what good looks like, then make it legible.
32 interviews turned into the thing the organisation didn't know it needed. Research as the constraint on the build.
enterpriseTwo user groups with opposed incentives, one interface. The kind of problem AI can't do for you.
nonprofitStudents and donors, one site, measured outcome: more completed applications, lower bounce.
dataWhen the dataset outgrew the tool, I built the pipeline, then turned the volume into a picture someone could act on.
I'll tell you what's underneath it: what's solid, what will bite you, and what to fix first. Fixed price, clear start and end, no obligation after.