Adam Rosler

I build things that run.

Not demos. Not mockups. Systems that do the job every day without me watching. Each one says what it does, a decision I'd defend, and the proof.

01

Next.js · Firebase · Stripe

Live product

Civil Surgeon: a live product used by real practices

One engineer, me. It runs the whole immigration medical exam for a practice: patient intake in two languages, a case dashboard, exam workflows, billing, and the finished USCIS I-693 form.

Decision
Every record is checked against who owns it before anything happens, so one practice can never see another's patients.
Proof
Live and used by real practices. Patients fill in one link; staff finish the exam and print the final form from one dashboard.
Visit civilsurgeon.app ↗

02

TypeScript · agent workflows

Public workflow available

My production system: one person, a whole media operation

Research, recording, transcription, editing, rendering, publishing and analytics, run by AI agents. It's how one person with a full-time job runs a whole channel.

Decision
Every step checks the one before it. The original recording is never touched, and nothing moves forward until its checks pass.
Proof
108 projects through it so far. Interrupted or out-of-date work never ships.
See the public workflow ↗

03

macOS · local-first

Open source

Local Flow: free dictation for your Mac

You talk, it types wherever your cursor is. Transcription and cleanup run on your machine with whisper.cpp and a local Ollama model. Free and open source.

Decision
No cloud service. Your voice and your words never leave your Mac.
Proof
The full app is on GitHub under the MIT license, with an end-to-end audio test.
Get it on GitHub ↗

04

Three.js · Web Audio

Playable game

DUST — After Hours

A browser game about one little cleaning robot and a very messy studio. I built it for fun. Three shifts, a fleet race, and 64 robots in free play.

Decision
Everything is drawn in code, with no 3D model files. Saved clips record only the game, never your screen, camera or microphone.
Proof
Played through to the end, every shift, on keyboard and touch.
Play it →

Nine rules for building with agents

I learned these the hard way, so you don't have to. Want help applying them? Email me.

  1. 01Don't build your own agent framework

    Let the lab maintain the loop, tool execution, and context management. Your leverage is teaching the agent your systems, not rebuilding the harness.

  2. 02Skills beat custom tools

    A markdown skill that composes existing tools is shorter, more reliable, and editable without a deploy. Only hand-code a tool when you need execution the model can't be trusted to do.

  3. 03Clean file structure is the real interface

    Repo layout and docs are how an agent understands your system. Architecture and naming are prompt engineering now.

  4. 04Codify your workflows into skills

    Anything you do twice should be written down once, so the agent runs it the same way every time.

  5. 05Check agents' work with agents

    Build verification loops instead of eyeballing output. Make the check a step in the system, not a thing you remember to do.

  6. 06Orchestrate, don't build one mega-agent

    An orchestrator dispatching focused subagents beats one agent trying to hold every job in context.

  7. 07Most SaaS is a UI over an API

    An agent can drive the API itself. Teach agents your systems instead of renting an interface.

  8. 08Build for agents, not just humans

    If you ship software, expose an API or MCP an agent can call, not just a UI a human clicks.

  9. 09The standards are still being written

    Pick opinionated conventions for building agent systems and set them before someone else does.