Staff Applied AI & Platform Engineer / Portland, OR / Open to work

I'm Dan Richardson. I ship whole products. I want to build the next one with your team.

I build and operate applied-AI and platform systems. Over the past year, I have shipped native iOS and Android apps, edge backends, and .NET services. I stay hands-on: I architect, code, debug, review, and operate production systems. I am seeking a Staff role, Portland hybrid or US remote.

20 years
shipping production software
3 clients
native iOS, native Android, and web. One wire contract.
10 seconds
to install a fresh iPhone build
Roughly 10x
directional agent-workflow comparison
Seeking Staff applied-AI and platform engineering roles. Open to Portland hybrid or US remote.
Dan Richardson
Why teams hire me

How I work

My advantage in applied AI is three decades of shipping in unfamiliar, regulated domains.

01

Reduce ambiguity before implementation

I turn stakeholder discovery into specs and documented decisions, then hold the work to automated checks, vacuity proving, review, and scope control.

Evidence: The Shape of Done →

02

Route work by evidence

I measure complexity, quality, and cost, then route deterministic work to code, bounded work to lower-cost models, and hard judgment to higher-capability models.

Evidence: Latticeflow →

03

Become useful fast

I learn the domain from the people doing the work, find the constraints that matter, and turn unfamiliar subject matter into working systems.

Evidence: Johnny Solarseed →

04

Make tradeoffs visible

I collaborate across boundaries, review code, mentor engineers, communicate tradeoffs, and leave documented decisions the next person can use.

Evidence: TradeTrack2 →

Track record

Experience

Senior software roles across manufacturing, aerospace, logistics, and clinical diagnostics. Much of it regulated: HIPAA, FDA, FAA, ITAR. I am not a compliance specialist. I know the rigor those environments demand and the patience they teach. Full resume →

2026 - Now
Founder & Principal Engineer, Throughline Technical Services
Designed and shipped the product suite here by directing agents.
2025 - 2026
Technical Lead, Systems Modernization, ZRT Laboratory HIPAA
Cut researcher post-processing from weeks to days with custom extraction tooling. Unified reporting across accounting, shipping, receiving, and research, groups that did not share data with each other.
2023 - 2024
Senior Software Engineer, Technical Lead, LiquidWire
Core C#/.NET for Bluetooth cloud-connected smart clothing at a startup under 20 people. Set the strategy for a high-risk VR push and directed two contractors. It shipped on time with the stretch goals intact.
2021 - 2023
Senior Software Engineer, OIA Global
Modernized legacy .NET logistics for a $1.3B freight forwarder, 60+ offices across 30+ countries, on an IT team of seven. Hands on the company-wide Workday cutover.
2019 - 2021
Senior Software Engineer, Datto
Bare-metal restore and ransomware-protection backup on a 12-engineer team inside BCDR. Disaster recovery is jenga at scale: nothing ships without meticulous review.
2016 - 2019
Senior Software Engineer, Team Lead, Revelar FDA
First software engineer on a breath-analysis diagnostic instrument. Built the software function from nothing and led a team of four across fluidics control, instrument OS, and web.
2014 - 2016
Senior Software Engineer, Jeppesen / Boeing FAA / ITAR
C#/.NET flight-routing software. Paired with the product owner on Route Snippets: assemble a flight from reusable partial routes instead of building every one by hand.
1995 - 2014
Earlier
4-Tell (ecommerce recommendations for retailers including Columbia Sportswear), HydroLogics (decision support for the reservoir system serving over nine million people across New York City and four upstate counties), Hewlett-Packard (DeskJet manufacturing, plus ergonomics and EHS programs across four international sites).
Toolkit

Skills

I use agents as implementation tools. I still own the architecture, review, debugging, and what ships. The bands reflect how directly and recently I have used each skill.

Core hands-on

Languages & platforms - C# / .NET 10 (preview) through Latticeflow; Python through Johnny Solarseed; TypeScript; SQL; macOS / Linux / Windows.
Generative AI - LLM orchestration, agent pipelines, prompt design and evaluation, cost-aware model selection, and RAG.
Applied ML - Clustering, association rules, and random forests.
Architecture & delivery - System and data-model design, APIs, specs, stakeholder discovery, technical leadership, and documented decisions.
Testing practice - Test strategy, unit, integration, contract, and end-to-end tests; automated gates and vacuity proving.
Security & privacy practice - Privacy by design, encryption, HIPAA-compliant AI deployment, threat-aware review, and structural privacy boundaries.

Recent production use

Native mobile - Swift, SwiftData, and Kotlin through Rejog Stash; on-device vision and iOS 27 (preview) Foundation Models.
Cloudflare - Workers, D1, KV, R2, Pages, Tunnel, and Access through Rejog Stash and Loomwork.
Developer tooling - Native CLIs, CI/CD, worktree automation, macOS app deployment, and Astro publishing systems.
Applied ML - On-device segmentation, embeddings, semantic search, and image classification.

Familiar

Cloud & data - Azure, Postgres, SQL Server, and Redis.
Infrastructure - Proxmox, Tailscale, and self-hosted services.
Interface systems - Responsive Astro interfaces, CSS custom-property themes, and hand-authored SVG diagrams.

M.Eng., Civil Engineering - Portland State University  ·  B.S., Mechanical Engineering - Rochester Institute of Technology  ·  Graduate study, Industrial Engineering - Penn State
Production Deployments

Recent projects

Everything here was built with an agentic development pipeline I designed. Filter by what you care about, or see everything.

Johnny Solarseed screenshot
Energy / AI

Johnny Solarseed

Community-solar customers cannot tell whether their utility bill is even correct.

Built: Time-of-use rate modeling split into volumetric and fixed costs, validated against real utility bills, plus two Home Assistant plugins shipped through HACS.

PythonHome AssistantTOU modeling
Role
Owner and sole engineer
Team
Solo
Timeline
2026 - present
Outcome
Two HACS integrations shipped.
Production · Used in real community solar work Live ↗ Case study →
Rejog Stash screenshot
Mobile / Cloud / AI

Rejog Stash

Neighbors want to lend and borrow without spinning up accounts or trusting a middleman.

Built: Native iOS and Android clients plus a Cloudflare Worker, sharing one versioned wire contract rather than a codebase. Offline-first cataloging, photo, voice, and text search that matches on meaning, and a clean one-way opt-in to the web.

Swift / SwiftDataKotlinWorkersD1R2
Role
Owner and principal engineer
Team
Solo
Timeline
2026 - present
Outcome
Native iOS, Android, and web clients are in pre-launch testing.
Private Beta · In pre-launch testing Live ↗ Case study →
Latticeflow screenshot
AI Process / Dev Tools

Latticeflow

Agentic coding is nondeterministic and the bills are unpredictable.

Built: A deterministic .NET runner that drives AI agents through plan, build, test, review, rework, and commit against Plane, gated by an automated review before anything ships. Sizes each agent to the task, tracks cost per ticket, and runs any CLI agent I point it at.

.NET native AOTClaude CodePlanemac / linux / win
Role
Owner and principal engineer
Team
Solo
Timeline
2026 - present
Outcome
A deterministic ticket lifecycle now runs the work behind this site.
Production · The pipeline behind this site Case study →

Six months ago I wanted to know what I could build with agents. Now I know. Next I want to build it with people.

Latticeflow

Latticeflow

AI coding agents are powerful and completely non-deterministic. Latticeflow wraps them in one: a single native binary that drives a ticket through a deterministic plan, implement, review, ship lifecycle - and only pays for an agent on the steps that actually need one. I use it to build almost everything else on this site.

The Problem

My earlier approach drove everything through a persistent chat session that re-read its whole prompt corpus on every action. One observed 7-ticket chain on TradeTrack2 took four hours and used about 190 million cache-read tokens. Roughly 76% of that was the chat re-reading the same 26k-token prompt corpus on every transition. I was using a chat loop as a state machine and paying the full corpus cost on every step.

That run happened on a subscription, not a metered API bill. I do not publish a dollar conversion because I do not have a sourced pricing assumption for it. The observed baseline is still useful: repeated orchestration context, not implementation, dominated the run.

What I Built

Latticeflow, a single-binary command-line tool called build that owns the full lifecycle of a development ticket. Point it at a Plane project, give it a ticket, and it drives that ticket through a deterministic state machine: plan the work, cut a git worktree, implement the changes, run a gate of automated checks, dispatch a review, and ship the result back to the target branch. The ticket only advances in Plane once it clears that gate, so the review step is enforcement, not a courtesy. Every phase either succeeds, fails with a classified exit code, or triggers a bounded rework loop. No daemon, no server, no shared state across invocations - the binary exits at the end of each verb.

Latticeflow replaced Claude-Config, an earlier corpus of markdown slash-commands that drove ticket lifecycles through a live Claude Code chat acting as runtime, state machine, and tool gateway all at once. That corpus shipped real tickets on real projects, TradeTrack2 among them, and it’s the reference implementation behind The Shape of Done. Latticeflow is the public name, build the binary, throughline-build the repo.

Benchmark Method

The baseline is an observed predecessor run: seven TradeTrack2 tickets, four hours, about 190 million cache-read tokens, with roughly 76% attributable to repeatedly loading the same 26k-token prompt corpus.

The redesign removes that repeated prompt and state-machine work from the chat loop. State transitions, gates, and Plane writes run as deterministic code. Agent sessions are reserved for plan, implement, and review. I define comparable task quality by the same standard on both sides: a ticket is not complete until it passes its configured gates and review.

The roughly 10x result is a directional comparison from field operation, not a paired experiment. I did not replay the same seven tickets against both systems under controlled provider, model, cache, and pricing conditions, and I do not have a publishable redesigned token total for that run. The evidence supports the architecture and the direction of the reduction, not a more precise claim.

Tech Stack

Languages
  • C#
Runtime & frameworks
  • .NET 10
  • native AOT (single self-contained binary)
  • System.Text.Json
Data & storage
  • TOML config
  • Plane backend (git worktrees for isolation)
Infra & deploy
  • cross-platform AOT builds (Windows / macOS / Linux)
  • GitHub Actions three-platform CI matrix
AI / ML
  • multi-vendor worker orchestration - Claude Code
  • Codex
  • Gemini
  • Copilot CLIs
  • ConPTY / Unix PTY interactive transport
Testing
  • xUnit

How It Works

C# on .NET 10, compiled to a native-AOT single executable that needs no .NET runtime on the target. Every interaction falls into one of three tiers: state transitions, gates, and Plane writes are plain deterministic code; small scoped decisions are single API calls; plan, implement, and review spawn a worker CLI in an isolated git worktree.

The worker layer is multi-vendor. Claude Code, Codex, Gemini, and Copilot each sit behind an IWorkerAgent implementation, selectable globally or per phase.

A check that always passes provides false confidence. Before Latticeflow trusts a gate, it confirms that each configured check can actually fail. The GateVacuityProver owns that proof. A separate GateControlProber re-runs failed checks against the untouched base ref so a broken environment is never blamed on the ticket.

Latticeflow ticket state machine Latticeflow drives one ticket left to right through six states: plan, cut worktree, implement, gate, review, and ship. Review can send the ticket back to implement, capped at two rework rounds. The gate runs two provers of its own: GateVacuityProver proves every gating check can actually fail, and GateControlProber re-runs failed checks against the untouched base ref. Three tiers of work sit under the spine: deterministic code with no LLM covers state transitions, gates and ticket writes; single API calls cover small scoped decisions; and a worker CLI in a git worktree runs only in plan, implement and review. Any phase can end the run with one of twelve exit codes, 0 through 11, mapped by ChainExitCodeMapper. Latticeflow one ticket, plan to ship the gate proves itself GateVacuityProver proves every gating check can actually fail GateControlProber re-runs failed checks on the untouched base ref plan cut worktree implement gate review ship rework, max 2 rounds deterministic code, no LLM state transitions, gates, ticket writes single API call small scoped decisions worker CLI in a git worktree - only plan, implement, review exit codes 0..11, mapped by ChainExitCodeMapper every phase either succeeds, fails with a classified code, or reworks clean | gate vacuity | ReviewUnavailable (quota / rate-limit) | gate env failure | ticketing outage
One ticket through Latticeflow: a deterministic spine, a gate that proves itself, and only three phases that ever spawn an agent.

The chain orchestrator drives multi-ticket trees through a post-order traversal with accumulated integration branches - children ship into a parent’s local chain branch, nested parents merge up, and only the outermost chain lands and pushes. Multi-ticket dispatch builds a graph from blocked_by relations and runs level-synchronously with bounded concurrency.

Vendor Compatibility

All four adapters are wired behind the same worker interface. The validation evidence is not identical, so the matrix keeps “wired” separate from “validated on every platform.”

AdapterWired transport and auth posturePublished platform evidence
Claude CodeCLI worker; interactive subscription transport through ConPTY on Windows and a Unix PTY on macOS and LinuxInteractive transport validated on Windows 11, macOS 26.4 arm64, and Ubuntu 24.04 x86_64 against Claude 2.1.177
CodexCLI worker; API keys removed from the child environment so the CLI uses its own subscription authAdapter is wired; individual platform validation is not documented
GeminiCLI worker; API keys removed from the child environment with ADC fallbackAdapter is wired; individual platform validation is not documented
CopilotCLI worker; inherits the GitHub CLI keyring credentialAdapter is wired; individual platform validation is not documented

Enterprise Operation and Governance

Latticeflow is operator-run today. Each worker CLI owns its authentication. The orchestrator removes provider API keys from child environments where required, while Plane credentials can be referenced through environment-variable indirection in local TOML configuration. Configuration validation fails early when a selected worker has no matching config block.

The production governance path is local configuration, per-phase provider selection, isolated worktrees, deterministic gates, bounded rework, classified exit codes, and Plane as the ticket system of record. A centralized enterprise provider account and consolidated provider audit trail are not the production path today. The vendor-neutral IModelClient with SSE streaming is built and tested, but it is not wired into production, so I do not present centralized API-account control as shipped.

What Made It Hard

Making a non-deterministic tool behave deterministically at the boundaries. Attributing cost per action across four different vendor CLIs. Proving a passing gate actually tested something. And building an interactive transport for Claude Code after Anthropic moved --print usage onto a separate credit allowance: launching Claude under a platform PTY (ConPTY on Windows, a Unix PTY elsewhere), feeding the brief as a file reference, and detecting completion by tailing the persisted transcript once the per-turn Stop hook stopped firing in interactive sessions. Validated green on Windows 11, macOS 26.4 arm64, and Ubuntu 24.04.

The Throughline

This is the tooling underneath everything: I built the system that builds the products. It’s the productized version of the method in The Shape of Done, writing to my self-hosted Plane fork, and it’s the difference between using AI and engineering with it.

Status

Active development, and dogfooded - every ticket in Latticeflow ships through Latticeflow. The four worker agents, the full plan-through-ship pipeline, the chain orchestrator with gate and batch implement, the bootstrap verbs, and the interactive Claude Code transport are all functional and in daily use, with the AOT binary built and tested across all three platforms. A vendor-neutral model client with SSE streaming is built and tested but not yet wired onto a production path. Plane is the sole ticketing backend today; GitHub and Linear remain aspirational.

Let's talk

Get in touch

Seeking Staff applied-AI and platform engineering roles. Open to Portland hybrid or US remote. Email is the fastest way to reach me.