Record
Log real sessions: context opened, tools called, edits made, dead ends abandoned, and the outcome that stuck.
Capture the sessions your experts already run. Train a small model on that work. Keep the weights. Run it on your own machines.
The bet
Frontier models are good at a lot of things. They still don’t know how your team closes a ticket, which internal tools matter, or which shortcuts get rejected.
So people paste the same context into prompts. Again and again. Midbar starts from the sessions themselves: what an expert looked at, which tools they called, what they fixed when it went wrong.
From that, we train a small model for one kind of work. Not a thinner generalist. A specialist whose weights carry local procedure.
The model should know how your team does the job, not just how the internet talks about jobs like it.
How it works
Same loop every time. Capture work, train on it, measure against real jobs, then feed misses back in.
01
Log real sessions: context opened, tools called, edits made, dead ends abandoned, and the outcome that stuck.
02
Turn messy traces into training examples. Drop noise. Keep the decisions that actually decided the work.
03
Fit a small model to that workload. Score it on held-out jobs of the same kind, including the tool path, not just the final answer.
04
Ship it. Collect the cases it mishandles. Retrain. The model should get better as the team’s work drifts.
Compared to what you already have
We’re not chasing a smaller GPT. Click a Midbar cell for a short note.
Deployment
Some jobs can’t leave the building. Some can’t wait on a remote API. Midbar is for those: train on private sessions, then run the specialist in your VPC, on a laptop, or on a device.
Session logs don’t leave your environment for someone else’s training cluster.
Not a forever API bill to Midbar. Train, take the weights, run them where you need them.
Once the job is narrow, you can usually run it on far less hardware than a frontier call.
Evaluation
A lucky correct output can hide a bad process. We grade specialists on held-out jobs from your own work, including the tool sequence.
Right answer, right artifact, accepted outcome.
Right tools, in an order a teammate would recognize.
Corrections are signal. High rates mean the model isn’t ready.
Held-out work from your queue beats a public quiz every time.
Animation of one held-out ticket. Expert and Midbar complete the same tool steps. A generic model picks wrong tools and needs human corrections marked with X.
Good fits
Engineering
Operations
Judgment-heavy queues
Notes
Start with the thesis if you want the full argument. These are shorter cuts into data, eval, and deploy.
Data
A wiki says what should happen. A session shows what someone did when the ticket was incomplete.
Read note →Evaluation
Correct finals can hide bad process. For operational work, the path is part of the product.
Read note →Systems
Capture, clean, train, measure, deploy. The artifact is weights, not a forever API hop.
Read note →Let’s put that into a model you actually own.