Selected work

We don't publish client names or program details. We can describe what was hard, what we did, and what shipped. Some of this work was done embedded inside the client's team, alongside their engineers. Some we owned outright, from takeover or first commit through release.

Offline provisioning for secure wireless field devices

Federal security program · Desktop, hardware, offline

The problem. Operators configure wireless field devices over a custom serial protocol, on machines that cannot count on a network. The inherited tool failed in the field. Dongle detection broke when more than one USB device was attached, map imports failed silently, and offline maps were unreliable.

What we did.

• Took ownership of the inherited prototype and stabilized the boundary between the UI and the device protocol: a versioned command contract, contract tests, and categorized errors with retry rules.
• Built virtual serial ports and simulated devices, so the full discover → connect → program → verify workflow runs on any developer machine without the hardware.
• Found field-reported hardware bugs at their root cause, including port probing at the wrong baud rate and a startup race that left offline maps blank.
• Packaged a self-contained installer with no runtime installs on target machines. Built a disk-backed map library, and designed a pack format to move maps between machines on removable media.

Outcome. 44 tagged releases over about 13 months of our work and roughly 380 automated tests. Recent work is traced from ticket to commit, with written design and decision records.

Making an AI assistant safe to act inside a construction finance platform

Construction-tech SaaS · Production AI, integrations, security

The problem. The platform runs bids, budgets, draws, and invoices for contractors. Its AI assistant takes real actions over chat and text message. As usage grew, so did the risk of an agent misreading a message and changing the wrong record, and so did unpredictable model spend.

What we did, inside the client's team.

• Moved the application's model calls behind a single LLM gateway with named routes, failover, and per-tenant cost attribution. We migrated the calls in stages by risk.
• Took the asynchronous document-review service to production: deployment, jobs that survive restarts, per-tenant concurrency limits, capacity reserved for interactive users, and queue metrics.
• Ran security audits that found and closed a privilege-escalation path and a cross-tenant data-access path.
• Contributed to a platform where every agent action is assigned a risk tier: it runs automatically with an audit record, it is suggested, or it requires human approval.

Outcome. The AI features are in production on a platform carrying about 3,300 automated tests and integrations with payments, accounting, SMS, and email. The application's model traffic is routed, metered, and attributed to each tenant.

Reliability for a broker-connected automated trading workflow

Fintech · Scheduled automation, AI cost control

The problem. The platform runs every minute during market hours. It analyzes news and market data with AI and manages orders through a brokerage API. It has to survive duplicate scheduled runs and drift in the broker's state without acting twice, and keep AI spend predictable.

What we did.

• Added tracing on every AI call, detection of exhausted quotas and token limits with alerts, and daily caps on AI-generated output.
• Inferred market session state when the broker API didn't report it, so automation stops running outside market hours.
• Hardened notifications with phone-number normalization, sensitive data removed from logs, and an audit trail of what was sent.
• Delivered architecture documentation and a production deploy pipeline that tags every release.

Outcome. Every AI call is traced. Quota exhaustion raises an alert instead of failing silently. AI generation is capped per day, and every SMS and email is logged. All of this sits alongside the platform's own distributed locks and retrying event queue. (We make no claims about trading performance.)

Our own tooling: AI agents in the delivery pipeline, with humans owning the gates

Internal product · Developer tooling, AI workflow

We use AI coding agents in our own delivery. We built the control plane that keeps them in bounds.

• tkt is a ticketing CLI written in dependency-free Python. One fixed set of commands works across Jira, GitHub, Linear, or a plain-file board on local disk, and the same workflow runs in about a dozen AI coding tools.
• QA is a hard stop for a human, and an agent can't deploy to production unless a human grants it. Every agent run has a stop switch, an iteration cap, and a three-attempt limit before the ticket is marked blocked. Each run leaves an audit trail on the ticket that survives a crash.
• tktban is a terminal console for operators to supervise agents and dispatch work to them. Dispatch always asks first, and it can't remove worktrees or close agent panes.
• The suites total over 1,150 automated tests, including adversarial suites, and the tests run offline by design.

With the plain-file board, the whole control plane runs without a network, and the AI tool it drives is a single configurable command. That is the shape disconnected environments need.

What these have in common

Each system acts on something outside its own process: a radio, a ledger, a brokerage account, a production deploy. In each one, our work made that action more bounded, observable, and recoverable. We put in contracts at the boundary, human approval where the stakes call for it, tests that run without the real hardware or service, and audit trails that outlast a crash.

That is the same discipline our Type 1 background demands. It applies whether the boundary is a crypto module or an AI agent with write access.