I build production AI, and the team that runs it.

A platform where a plain-English job becomes a governed, running agent

Most AI agents are one-off scripts with no limits and no record of what they did. On this platform, a recurring job described in plain English becomes a scheduled agent with spending limits, access control and a full run history from its first run. Any bounded job that can be described in a sentence can be run, watched and audited.

What runs on it

One platform runs many kinds of recurring work, across engineering, models and data.

Started from

Slack, inside the product, the fleet console, or a schedule.

Runs in

The client's own isolated network for sensitive data, or the central hub for internal-only work.

Govern centrally. Run where the data lives.

Raw client data stays in the client's network. The hub keeps pointers, counts and anonymized traces. Only the model call crosses, and it goes through the one gateway.

Safe by construction

• An agent's key is its whole accessEach agent gets one key, scoped to the tools it was granted. It holds no URL and no credential, so there is nothing else for it to reach. In testing, a model allowlist held against four bypass routes.
• Every run traced end to endInputs, tool calls and outputs are recorded for audit and for debugging, and every model call and tool call is tied to the agent that made it.
• Traces without personal dataA PII reducer sits in front of tracing, so the central view shows every step and none of the personal data.
• One door for models and toolsEvery model call goes through one self-hosted gateway for keys, rate limits and spend budgets. Every tool call goes through one governed MCP door. Swapping a provider is a config change.

How a sentence becomes a run

1. Plain EnglishSomeone describes the job.
2. SpecA flow of a few fixed step types. Data, not code, and no field for a URL or a credential.
3. Shape checkChecked without running anything: is it a valid flow, using only the allowed step types?
4. Access checkEvery tool and model it names is checked against what's allowed.
5. PublishSaved as a fixed version that can't be edited. Rolling back means pointing at an earlier version.
6. Durable runFailed steps retry and resume, and every step is recorded. Every model call goes through one gateway and every tool call through one door.

Because an agent is data, not code, it can be checked before it ever runs.

Design choices

1. An agent is a spec, not generated code.A machine can check an agent built from a fixed set of step types, and it can't check arbitrary code. The spec has no field for an address or a key, so an agent has no way to reach an endpoint it wasn't given.Instead ofletting a model write Python
2. Code computes, the model narrates.The model writes only about numbers that code already computed, so checking it is mechanical: pull every figure from two reports and compare. That is what makes a cheaper model safe to swap in.Instead ofletting the model do the math
3. Rules set the verdict, the model explains it.Where a decision has to be stable enough to act on, rules set it. Where a model's judgment helps, its opinion sits beside the computed verdict with a disagreement flag, never in place of it.Instead ofa model deciding severity
4. The advantage is the domain knowledge.A generic vendor can't quickly copy a growing library of physics-based rules for rotating equipment, extended with every case the platform handles.Instead ofbetting on orchestration

What's being built next

Review agents already read an agent's past runs and recommend what to improve, so agents get better with use. A knowledge base is being built beside them. It grows from what the platform solved and what it didn't, draws on many processes, and opens as a clickable graph that people can browse and correct by hand.

My part: co-led across two squads, with the largest share of the commits. Owned the vision and the security review.

A platform that trains, checks and watches its own models

Industrial ML fails quietly. A machine-learning model trained on a compressor's startup noise will pass its metrics and still be wrong about the machine. So we built the whole loop, from raw sensor data to retraining. Nothing ships until it clears the data checks and a vision model has read its plots.

1. CleanStrip startup and shutdown transients, so machine-learning models only learn real operation.
2. SelectStatistics plus an LLM playing domain expert pick the sensors that matter.
3. TrainAutoML tunes several model families in parallel on a cluster.
4. GuardData checks fail a run loudly before any compute is spent.
5. ReviewA vision model reads the plots and says deploy, retrain or investigate.
6. ServeThe verdict lives on the model's own record, then it ships.
7. WatchAccuracy checks and four drift tests against the training baseline.
8. RouteRetrain, rerun AutoML, or flag a process problem. A human signs off.

My part: the design of the whole loop, from the drift framework in 2021 to the review and routing stages, and a large share of the code. It runs on Ray clusters and is cheap to run by design: a small head node stays up, and workers start when a machine-learning model is requested and shut down when the job ends. Training data comes straight from the data lakehouse. The team I lead builds and runs it; one of its data scientists wrote the feature-selection pipeline.

An agent that investigates an alert the same way every time, then judges

When a diagnostic rule fires on a machine, an engineer needs the same questions answered before deciding to act: what the rule checks, which sensors tripped, what they read, and what happened last time. A free-roaming agent skips steps and varies run to run. This one gathers the evidence in a fixed order that code derives, then makes a single model call to judge from that evidence alone.

What it does with one alert

1. Find the alertResolve which alert is meant.
2. Load its detailsThe machine, the rule and when it fired.
3. Explain the ruleWhat the diagnostic rule actually checks, in plain terms.
4. Pick the sensorsWhich sensors fired, and how the machine is set up to watch them.
5. Read the historyWhat happened the last time this rule fired, and what was done.
6. Assess the contextThe operating conditions around the alert.
7. Read each sensorWhat the flagged sensors actually measured.
8. Check related sensorsWhat moved alongside the ones that fired.
9. Build the timelineHow those sensors performed over the period.

Nine steps gather the evidence. One model call then judges from it, and does nothing else.

Design choices

1. Order comes from dependencies, not from a prompt.Each step declares what it needs and what it provides. A prompt never names a step, so a wording change can't reorder the chain, and a step with a missing input fails before any model call is paid for.
2. A number is converted once, and a test enforces it.The platform already converts units at its boundary. A second conversion gives a number that looks plausible and is wrong, so a scan of the code fails the build if any conversion or conversion constant appears.
3. One function can write the data-quality marker.Whether a report rests on live or partial data is computed from the run's own counts. Construction raises if a claimed marker disagrees with the counts, so a report can't call partial data complete.
4. The core knows nothing about the framework running it.An import check keeps web, model and agent libraries out of the triage logic. That let the execution engine be swapped under a test requiring identical steps, outputs and serialized results, instead of a rewrite.

My part: I directed most of the triage agent's design, and made architecture calls on the assistant around it over a few sprints. Product engineering built the assistant and runs it.

Telemetry in open tables, so any model can be retrained on the data it first saw

Data scientists need one row per machine per timestamp, with thousands of sensor columns. The source stores one row per sensor reading, in the same database that serves live data, so analysis was slow and competed with the live system. The lakehouse copies changes into open Iceberg tables and serves the reshaped view on request.

How it works

1. CaptureChanges from the operational database are copied into Iceberg tables, with full history.
2. ServeEach timestamp's sensor values are stored compactly and expanded into named columns only when requested.
3. PublishA refresh is written to a branch and checked there, then published, so readers never see a half-written snapshot.

Readers only ever see a complete, checked snapshot.

Design choices

1. Reshape on request, not in storage.A pre-built wide table ran out of memory at 10,000 columns and slowed about 7× at 7,500. Storing each timestamp compactly and expanding it on request made a yearly backfill 5.4× faster.
2. A small API, not table sharing.Table sharing returned the full two-year history for a two-day query on an unpartitioned table. A call that takes equipment, a start and an end returns exactly that window.
3. Retrain on the exact snapshot.Every job logs a snapshot ID, and a training run can query the table as of that snapshot, even after later backfills or deletes change the source.
4. Open formats over a vendor warehouse.Iceberg was chosen over Hudi and Delta for wider engine support, transactions, schema changes and time travel.

My part: built the first Iceberg version, which reached production as the raw-data layer before a rewrite replaced it with change capture. For the serving layer I shaped the architecture, scoped it, worked out the usage patterns and held the latency and cost targets. A data engineer built it.