TJHG / about

ABOUT / TYLER J.H.G.

I build systems, then try to break the explanation.

Tyler Harbin-Giuntoli

I’m Tyler James Harbin-Giuntoli, a software engineer at Microsoft and an independent machine-learning researcher. I care about systems that keep working when the clean example stops being clean.

That means production schedulers, agents that recover from broken tools, experiments designed to attack the reason I think something worked, and small models pushed until the hardware tells me no.

Tens of billionsmonthly value flowing through work coordinated by a production scheduler I wrote
1 hourthe end-to-end SLA target we are driving that scheduling system toward
Thousandsof evaluations run through Micro Suite; about 850 were the focused prompt-stabilization pass

THE PIVOT

My daughter changed the accounting.

I had a safe trajectory. I had also become a parent, which made the fact that time is finite substantially less abstract. I stopped being willing to spend most of that time simply staying on the safest path because it was already working.

I wanted the work to matter to me. That pushed me harder toward agents, machine learning, robotics, and research: places where I could use the production-engineering habits I already had, but aim them at questions I actually wanted answered.

The independent work on this site is not a separate academic persona. It is what happened when I started applying the same standard outside production: define the claim, build the comparison, look for the failure case, and keep attacking the explanation until the weak version stops surviving.

PRODUCTION / CONSEQUENCES

I learned engineering where being wrong is expensive.

I joined Microsoft full-time in 2019 after three internships, initially working on commerce data pipelines, reconciliation, and automation. A late job, a bad join, or a plausible-looking number could have real downstream consequences.

I cut one clearing workflow from roughly 35 hours to just over 3 and built reporting around a reconciliation process covering about $360 million a month. The work later moved into shared cloud services, durable dependency-aware scheduling, observability, privileged operations, and auditability. Today, a scheduler I wrote coordinates workflows handling value measured in tens of billions of dollars per month, and we are working to drive its end-to-end SLA toward one hour.

That scale is useful training. “It usually works” stops sounding like an engineering argument very quickly.

AGENTS / EVALUATION

The agent has to survive the part after the demo.

My recent work is increasingly agent-shaped. Micro Suite is used across my team and has been through thousands of evaluations. About 850 of those were a focused stabilization pass to determine which prompt changes each model family and version actually required; that is one slice of the evaluation history, not the total.

I added same-session recovery so a failed tool call can be repaired instead of ending the job. Auto Research starts from a repository, an objective, and a measurable notion of improvement, then works through papers, experiment proposals, tests, and proofs of concept. I’m also building multi-agent livesite triage where the interesting problem is not merely automatic classification, but a reliable warm handoff between agents operating under different teams’ policies.

Completion is the easy screenshot. I care more about whether the system notices that reality diverged from the plan, repairs the state, and leaves evidence explaining what happened.

RESEARCH / METHOD

I try to break my own idea first.

A result gets more interesting when the explanation becomes harder to defend. If an endpoint looks dramatic, I want the trajectory. If a representation looks expressive, I want to know whether the consumer can use it. If a mechanism sounds plausible, I want the control that would make it fail.

I use small examples when they expose the whole mechanism, then vary the task, data, architecture, or hardware and see what survives. Proofs are useful when they can kill an empirical branch before another training run; experiments are useful when the theorem’s assumptions stop matching the thing we actually built.

The articles are the readable argument. The notebooks preserve the sequence and saved computational record. Compiled Experiments bind code, artifacts, environment, and run identity. Theorem Library makes formal assumptions inspectable. I want disagreement to have somewhere concrete to land.

CONSTRAINTS / MACHINES

The hardware gets a vote.

I’m interested in models and agents that operate under real constraints, which is why so much of the surrounding work ends up touching heterogeneous local inference, old GPUs, small shared-memory devices, and reproducible experiment packaging.

Away from the screen, I work on my 1987 Toyota MR2 or go birdwatching. Designing an active-aero component, tracing a model failure, and repairing an old machine scratch a similar itch: understand the mechanism well enough that a change has a reason to work.

Machine learning, robotics, and philosophy keep pulling me toward the same questions: what information is actually present, what a system can do with it, what the constraints remove, and how much confidence the evidence has earned.

CONTINUE

Take the work apart.

The research map and articles follow the current investigation. Compiled Experiments are the reproduction surface.