Mikita Daroshkin

About

I build AI agents that large enterprises actually run in production — inside regulated workflows, under audit, in domains like pharma, healthcare, aviation, and lending. Most of the engineering in that work lives in the gap between a system that demos well and one that holds up against real users, adversarial inputs, and a compliance review. That gap is easy to underestimate until you’ve shipped a few things across it, and closing it is most of what I do.

I work forward-deployed, which in practice means one person holding roles that are usually split across three: the engineer writing the code, the architect deciding what to build, and the delivery lead accountable to the client’s executives. I think those roles are worth more held together than apart — the architecture decisions that matter are the ones made by someone who then has to implement and defend them — but that’s where I’ve ended up, not where I started.

How I got here

My first real systems work was in banking: computation engines in C#/.NET grinding through large financial files, star-schema warehouses feeding reporting across dozens of branches, a nightly batch I profiled and rewrote from six hours to forty minutes. None of it was glamorous, but banking software is unforgiving in a particular way — a reconciliation that silently drops a row is worse than one that crashes, because the crash is the one you notice. That’s where I started paying attention to the failure modes that don’t announce themselves, and to whether a system could be run by someone who wasn’t me.

Then a few years in games, which is where I learned distributed systems under real latency pressure. I built matchmaking and telemetry for a title with over a million daily players — lock-free concurrency, Redis-backed state, tail-latency budgets tight enough that a garbage-collection pause registered as a user-visible defect. The anti-cheat was more interesting than it sounds: isolation forests over sliding-window behavioral features fused with a rules engine, tuned deliberately toward false negatives, because the asymmetry mattered — wrongly banning a paying player did more damage than letting the occasional cheat through. Calibrating that threshold, rather than chasing raw accuracy, was the actual job. On another title I owned the ML end to end: lifetime-value forecasting with a zero-inflated loss, churn, the experimentation loop.

Around then I co-founded three companies as the technical half. The one I learned the most from was a writing tool where we fine-tuned GPT-2 on each customer’s brand voice. It beat GPT-3 few-shot on the metric that mattered — voice fidelity — at roughly one-eighteenth of the inference cost. That result has stuck with me, because it cuts against the reflex to reach for the biggest model available: a small model that has actually seen your distribution will routinely beat a much larger one prompted cold, and the cost difference isn’t close. This was early 2021, before that trade-off was a fashionable thing to say. I also did the unglamorous founder half — customer interviews, fundraising, pricing — and trained on preemptible GPUs that got reclaimed mid-run often enough that checkpointing stopped being optional. Two of the three companies didn’t survive.

After that came a few years of ML research at a medical-device company, under FDA regulation, where every model shipped with a physician’s sign-off and a traceable paper trail. I trained a computer-vision model on ten million 3D scans to catch manufacturing defects — a multi-view architecture, sharded training in mixed precision to make it fit, the long fight with a heavy tail of rare defect classes. I also built an air-gapped assistant so researchers could query internal knowledge without a byte leaving the building: QLoRA on a 7B model, hybrid dense-sparse retrieval, reranking, and grounded citations — because in that setting an ungrounded answer isn’t a UX rough edge, it’s a regulatory problem. Working where “wrong” has consequences past a bad review is what taught me to distrust a good benchmark number on its own. A benchmark is a hypothesis about production, and the two disagree more often than anyone likes.

What I do now

I lead agentic AI delivery for Fortune 500 companies. Client names stay off this site, so in general terms, the shape of the work:

How I actually work

The thread through all of it is evaluation-driven development, and I mean something specific by it. Before an agent goes near a user I want a golden dataset that encodes what “correct” means for the task, an offline harness that runs against it on every change, an LLM-as-judge gate wired into CI, and tracing on every tool call so a production failure is a span I can open instead of a mystery.

The part most teams underestimate is that the judge is itself a model, with its own failure modes, so you have to evaluate the evaluator — spot-check it against human labels, watch for the biases it inherits (length, position, sycophancy), and never let an unvalidated judge block a merge. You also have to be honest about the axes you’re measuring on: task success and groundedness are not the same dimension as latency and cost, and a system optimized on one while blind to the others will sail through review and fall over in production. None of this is exotic. It’s the ordinary discipline of finding out where a system breaks before a user does — most teams skip it because it’s slower up front, and it’s usually the difference I get hired to supply.

I also build for the handoff. A forward-deployed engagement that leaves behind a system only I can operate has failed on a dimension that never shows up in a demo, so a large share of my effort goes into the parts that let someone else’s team run it: the CI, the per-agent scorecards, the promotion gates, the runbooks. That work is far less visible than the agents, and it’s usually the reason the system is still running a year after I’ve left.

The foundation

Before any of the above there was a computer science degree at BSU, and then a master’s in applied mathematics at the same place, in the big-data processing department. The master’s is where I first had to make things run at a size that punished naivety: a tiled 2D algorithm parallelised across GPUs with MPI, a distributed URL shortener behind Nginx on Cassandra, a hierarchical search engine built up from PageRank and BM25 to BERT. None of it was production, all of it was the first time the constant factors mattered more than the asymptotics.

Alongside the degrees I spent two years at the Yandex School of Data Analysis, which is the part of my education I’d keep if I could only keep one. It is unusually theoretical for an industry-facing program, and the work was derivations rather than notebooks: proving results in statistics, optimization and decision theory before touching an implementation. I built a Bayesian hyperparameter-tuning framework there, spent a term on where VAEs beat GANs and where they do not, and worked NLP forward from TF-IDF to transformers by reimplementing each step rather than importing it. Being made to derive the thing before using it is why I am suspicious of a benchmark number now, and why the statistics in what I write tend to hold up.

The undergraduate degree gave me two habits that outlasted the syllabus. One is competitive programming, which sounds like a party trick and is really a decomposition reflex: you learn to find the shape of a problem before you write anything, because there is no time to write the wrong thing twice. The other is a thesis on encoder-decoder segmentation of 3D MRI volumes, which was my first encounter with a model whose errors mattered to a person, and with the gap between a validation score and a clinician’s confidence in it. I have been circling that gap professionally ever since.

Underneath all of that is nine years of watching systems fail in production and working out exactly why.

The stack, if you’re looking for it

The part of a project I still like most is the first week after launch, when real usage starts contradicting assumptions you didn’t know you were making. I write code every day, and I read other people’s postmortems the way some people read the news.

If any of this is close to what you’re building, email me: mikitadaroshkin@gmail.com.