Thesis · Midbar
Your team’s expertise should live in models you own.
Most companies don’t need a tiny clone of a frontier model. They need a small specialist that already knows how this team doesthis job.
The data sitting in plain sight
Public corpora built today’s general models. Fine. That still leaves a hole every team hits in production: the model doesn’t know your tools, your house rules, or the shortcuts people get yelled at for taking.
Experts already generate the missing signal. They open context, call tools, backtrack, fix mistakes, and accept or reject the result. That isn’t a wiki page. It’s how the work actually got done when the ticket was messy.
Docs say what should happen. A session shows what happened when the dependency was down or the last fix didn’t stick. Midbar trains on that difference.
Put the way your team works into weights you control.
Shrinking a general model isn’t the same product
A smaller general model is cheaper. It still doesn’t know local procedure. You keep restating private context. You still don’t own the failure modes.
Our claim is narrower. For work that is bounded, frequent, and annoying to re-teach, train a specialist on private sessions. Evaluate it on held-out jobs of the same kind. Ship it as a model you can run in a VPC, on a laptop, or on a device.
Some of what used to live in prompts can move into the weights. That alone changes the cost of repeating the same internal job. You don’t need “universal intelligence” for that.
Record → clean → train → keep going
Record. Log real sessions: context, tool calls, edits, dead ends, outcomes. Learn from the path, not the polished write-up.
Clean. Turn traces into training examples. Drop noise. Keep the decisions that actually decided the work.
Train. Fit a small model to that job. Score it on held-out work, including whether the tool path looks sane.
Keep going. Deploy it. Capture the misses. Retrain as the team’s habits change. The model stays small; it gets denser where the work is hard.
Evaluate like you would a teammate
Final-answer accuracy alone is a weak test for ops work. The path matters. We look at:
- Outcome: did it finish the job correctly?
- Tool path: did it pick tools and an order a teammate would recognize?
- Human fixes: how often did someone have to step in?
- Held-out tickets: would you trust it on real queue work, not a public quiz?
If it can’t reproduce the workflow, it isn’t useful. Period. Fancy benchmark scores don’t fix that.
Own it, run it close
Session data stays in your environment. You get a portable model, not a permanent bill to someone else’s inference API.
Once the job is narrow, repeated work can usually run on much smaller hardware. That’s not a made-up savings percentage. It’s the boring structural point: known internal work shouldn’t need a frontier call on every turn.
What this isn’t
Midbar isn’t a chatbot skin. It isn’t a generic fine-tune marketplace. It isn’t a frontier model with a new logo and fewer parameters.
It’s a bet that private work sessions are training data, and that the right output is an owned specialist for a real job.
Your team already knows how to do the work. The model should too.