About
I'm Brad O'Haire, currently a Data Collection Lead on a humanoid robotics data program, building toward technical program management and AI research engineering. I run several ventures on the side, and the throughline in all of it is the same: turn messy, multi-threaded work into systems that route, gate, and ship.
Claude Certified Architect (Foundations), issued by Anthropic.
My day job is data. I lead collection on a robotics program, where the work is getting clean, well-labeled, repeatable data out of a messy physical process and keeping the pipeline honest end to end. On that program I have shipped two agents into production with real, measured outcomes, and I treat the agent work the way I treat the data: as pipelines with guardrails. Collect carefully, act inside a known envelope, and never let a read-only job quietly turn into a write.
The repos here are real working systems, genericized for public release. Every one was audited for secrets and personal data before it went up. I care about guardrails as much as capability. The interesting part of an agent isn't what it can do, it's what it's allowed to do and how that's enforced. I also own a car-rental business whose back office runs on a team of agents I built, which keeps the discipline concrete: the agents run the day-to-day operations and reduce my hands-on time and operating costs, while a human stays on the calls that carry liability.
How I build
A breakdown of the thinking and implementation behind the agentic work, written for hiring managers and teams. The methods and the decisions, not the prompt internals.
How I run a build
A coordinator drives the run in waves. Within a wave it fans out to parallel specialist agents, then an auditor gate returns pass, warn, or block. A warn or block routes the work back to build to iterate. A safety floor sits under all of it.
Coordinator and specialists
I design multi-agent systems as a coordinator that routes each request to the right specialist, then composes their output. A mission is decomposed into waves: independent work runs in parallel, dependent work gates on the wave before it. It is the difference between one model doing everything and a team with a conductor.
Control before capability
Every system carries a safety floor it cannot cross: no moving money, no touching secrets, no irreversible action that was not asked for. Autonomy is two dials, how much a human stays in the loop and how far the system can reach, set per run. A run budget guarantees it halts on a known boundary instead of looping forever.
Feasibility before code
Before building, I pressure-test the idea: what is genuinely buildable, where the API and platform constraints sit, and where the legal and compliance surface is. On one product line I cut high-liability ideas and honestly reframed another once I confirmed the integration it implied did not exist. Knowing what not to build is part of the work.
Repeatable, audited, shipped
The same engine that runs a research brief can ship a storefront or an internal tool, because each run is driven by a mission blueprint rather than hard-coded to one job. Every build is scaffolded from a shared template, gated wave by wave by an auditor that returns pass, warn, or block, and checked against an evaluation list before it is called done.
How this site was built, and what that approach saves
This site is the clearest work sample I can point to, because I built it the way I build everything else. It went from a single static page to a deployed, accessible, responsive, multi-page site by orchestrating my own agents end to end, with a human on the decisions.
- Ideation in parallelA think-tank proposes directions at the same time, so the strongest structure surfaces before any build starts.
- Specialists implementBuild agents take the chosen direction and implement it, each scoped to its own slice of the work.
- Auditor gate per waveEvery wave is reviewed and returns pass, warn, or block. Nothing moves forward on an unreviewed change.
- Personas stress it, then it shipsPersona-based testers click through the result and loop findings back to a written definition of done.
The honest read is leverage, not magic. One operator covered design, front-end build, QA, an accessibility pass to WCAG AA, and copy, work that traditionally spans several roles. The build-and-QA loop ran in hours rather than weeks because reviews and tests are part of the loop, not a separate phase bolted on at the end.
EstimateThe time and cost delta, assumptions shown
A hand-built equivalent at this level of polish, interactivity, accessibility, and QA is realistically one to two weeks of focused solo work, or a small multi-person sprint. Orchestrating agents compressed that to about two days of part-time work.
Assumptions: a freelance web rate of roughly $75 to $150 per hour, and a one-to-two-week hand-built baseline for the same scope. On those assumptions the saved effort lands on the order of several thousand dollars of delivery, done by one person. These are ranges with the assumptions stated, not a measured invoice, a billed total, or a stopwatch figure. If the assumptions change, the number changes with them.
How this site is builtFor engineers
This site is its own work sample. A small multi-page static site, vanilla HTML, CSS, and JavaScript, no build step and no framework. Every page is one HTML file that links a single shared stylesheet and a single shared script, and it all degrades gracefully if JavaScript never runs: the content is in the markup, and the motion is progressive enhancement on top.
- One stylesheet, one script, shared. All of the design tokens and components live in
/assets/site.css, and all behavior in/assets/site.js, linked by every page. A token change propagates everywhere. The header and footer are duplicated per page on purpose, since the site is buildless, with one canonical markup block kept in sync. - The script runs safely on every page. Each initializer null-checks its own root element and no-ops when absent, so a subpage that has no hero canvas, no process diagram, and no charts runs the same shared script with zero console errors. One file, doing hero, guardrail, count-up, and chart work only where those nodes exist.
- One animation engine. The hero network and its faint echo in the data section share a single
nodeFieldfactory: onerequestAnimationFrameloop per instance, a capped node count that scales with viewport area, and a safety contract wherestart()is idempotent so at most one frame is ever in flight. The same loop carries the labeled coordinator, specialist, and auditor roles and the request-and-return pulse. - It pauses when it should. The loop stops on a hidden tab through the Page Visibility API and resumes only when the tab is visible again, so a backgrounded page costs nothing. Pointer reactivity is opt-in and only attaches where a fine hover pointer exists, so touch devices carry no pointer cost.
- Reduced motion is honored everywhere. A single
prefers-reduced-motioncheck gates every animated path: the canvases never start, the count-ups and bars jump to their final values, the process diagram renders fully lit, and the guardrail verdicts all show at once. Nothing depends on motion to be readable. - Hand-rolled data-viz. The line chart, the emphasis bars, and the process diagram are inline SVG and CSS with a little path math, no chart library and no images. Each is clearly labeled illustrative where the numbers are illustrative.
- Accessibility baked in.
:focus-visibleoutlines, a skip link, keyboard-operable controls, semantic landmarks, clean URLs, and no horizontal overflow on a narrow phone.
Curious how it holds together? View source on any page, then open /assets/site.css and /assets/site.js; it is all right there.
The applied rules I build agents by
The methods above rest on a small set of engineering principles I hold consistently. The short version is here; the full reasoning, with the trade-offs behind each call, lives on the principles page.
- Loops that advance on intent, not text An agent loop steps on the model's own stop reason, not on parsing its prose or hitting an arbitrary cap. A coordinator routes to specialists, each with isolated context and an explicit handoff, dispatches independent work in parallel, and chooses a fixed task breakdown when the shape is known and a dynamic one when it is not.
- Determinism where compliance must hold Anything that must be guaranteed is enforced in code, with hooks, prerequisite gates, and a hard safety floor the system cannot cross. Prompt guidance is reserved for where probabilistic behavior is genuinely fine. I do not ask a model to promise what a gate can enforce.
- Tools and interfaces designed, not assumed Tools are picked by how clearly their descriptions read to the model, each agent gets only the scoped set it needs, and errors come back structured so the agent knows retryable from terminal. Tool choice is set deliberately, auto, any, or forced, to match the step.
- Structured output that can be verified Output lands as tool use against a JSON schema, with a few examples for consistency and explicit acceptance criteria instead of vague asks. Results are validated and retried on failure, and a separate reviewer checks the work, since independent review beats self-review.
- Context kept honest end to end Transactional facts are preserved outside lossy summaries so nothing critical gets lost in the middle, verbose tool output is trimmed before it crowds the window, and every claim keeps its line back to its source. Confidence is calibrated, and low-confidence calls route to a human.
Data craft
My day job is data, and so is most of what I build on the side. I treat data work the way I treat agents: as pipelines with guardrails. Collect carefully, sample on a schedule, analyze with a hypothesis in hand, and never let a read-only job quietly turn into a write. The two visualizations below are clearly labeled illustrative; they stand in for the shape of the work, not measured results. The real measured outcomes live on the work pages.
Data Collection Lead, robotics
My current role is leading data collection on a robotics program. The job is getting clean, well-labeled, repeatable data out of a messy physical process, and keeping the pipeline honest end to end.
Read-only market samplers
I build scheduled samplers that snapshot Polymarket and Kalshi order books into a time-series. The work is hypothesis-driven, and every task ships with hard no-trade and no-write rails so a sampler stays a sampler.
An agent team that runs my car-rental business
I built a team of agents that runs the back office of a car-rental business I own, handling the day-to-day operations and the work that scales the team. It is the same discipline as the agent work: agents do the legwork, guardrails govern what acts on its own, a human on the calls that carry liability.
Order-book mid-price samplingIllustrative
This stands in for the kind of order-book mid-price series my read-only samplers capture across Polymarket and Kalshi over a session. Sample data drawn to show the pattern, not real measured prices.
Where the data work goesIllustrative
These bars stand in for how my emphasis splits across the data work, from collection through guardrails, in the samplers and collection pipelines I build. Relative emphasis, not a measured metric.
The numbers are relative weights on a 0 to 100 scale, not hours or counts. They are here to show emphasis: collection and clean sampling carry most of the weight, and guardrails are never an afterthought.