Eleven months ago, building an agent meant spending a lot of time telling a model how to work.
You wrote a prompt, connected a few tools, and watched it attempt a task. After a failure, you added an instruction. After another, you added a retry, a routing rule, or another agent to check the first one's work. Developers built substantial systems around models to get dependable results.
Since then, developers have started removing some of that scaffolding. More capable models can handle work that once required explicit orchestration. In its research on long-running agents, Anthropic describes removing parts of its harness as newer models made them unnecessary.
We expect that simplification to continue. We also think developers will want more control over how models perform on the work specific to their business.
You can give two companies the same foundation model. They will have different workflows, different standards, and different definitions of a successful result. A support team needs decisions that follow its policies. An engineering team needs changes that pass its tests and fit its codebase.
Through repeated use, those teams produce examples of what works. They correct answers, review decisions, and test results. At Mubit, we're building a way to use that work to improve the models and agents they run.
We call this runtime calibration for agents.
You connect Mubit to your existing agent workflow. Through Mubit, you capture execution traces and associate them with verified outcomes. You can use that evidence to evaluate changes to your runtime and develop task-specific models alongside the frontier models you use. Explore Mubit
Consider an agent that classifies incoming support requests. You begin with a general-purpose model and instructions describing your categories. As your team reviews its decisions, you collect accepted answers and corrections, including examples where the original instructions left room for interpretation.
Those examples give you material for fine-tuning. You can train a model for that task, compare it against your current setup, and decide whether it meets your requirements. You need to measure the cost and latency alongside the quality of its decisions.
Our goal is to make this a continuous part of running agents. As your agents do more work and your team reviews the results, you should be able to use that evidence to improve the model for the task.
Getting the first fine-tuned adapter is one step. You then have to collect fresh examples, train its replacement, check for regressions, and deploy the new version. You need to track which adapter serves which task and keep a working version available if an update makes things worse. Repeating that process across dozens of tasks creates a substantial operational burden.
We're building Mubit to manage that cycle: train and evaluate new candidates as evidence accumulates, promote versions that meet your requirements, and support rollback when needed. Developers should be able to define their quality thresholds and review the results without having to coordinate each adapter replacement by hand.
Fine-tuning requires care. A model's answer gives you a record of its behavior; you need additional evidence to decide whether that behavior deserves reinforcement. A successful tool call can produce an incorrect result. A reviewer can approve an answer for reasons the trace doesn't capture.
We're interested in the engineering and research needed to close that gap. Developers should be able to inspect the examples behind a model update and understand the evaluation used to approve it.
That work also shapes Banyan, our family of models.
We've released Banyan Sapling, an open-weight research preview focused on semantic verification. Given a policy, evidence, and a claim, developers can use Sapling to check for support, violations, missing information, and inconsistent context, with explicit uncertainty. [Explore Banyan Sapling](https://mubit.ai/).
For a developer, that provides a component to evaluate at a specific point in a workflow. Before accepting an agent's proposed decision, you can check whether it follows from the evidence and the rules you supplied. You also need a way to handle cases where the available information does not support a confident judgment.
We're preparing Banyan Trunk, our forthcoming 120B-parameter generative model. With Sapling and Trunk, we're pursuing research across verification and generation. We'll share Trunk's design and evaluation results as we approach release.
Our research agenda follows the practical questions developers face when adapting models.
We want to understand which examples make useful training data. That includes how to interpret feedback, identify conflicting judgments, and avoid reinforcing errors from an existing model.
We're studying specialization: the conditions under which fine-tuning helps a recurring task, how much data it requires, and how to evaluate performance as the task changes. A model that performs well on familiar examples needs testing on cases outside its training distribution.
Continuous adaptation adds another set of questions. We need to establish when enough evidence exists to justify an update and how to improve performance on new cases while retaining capabilities the team depends on. We're interested in evaluation methods that help developers distinguish a useful update from a regression before deployment.
We're also researching calibration and uncertainty. Developers need to understand when they can use a model's judgment and when they should gather more evidence or request review. For verification models, we need to measure both the correctness of accepted answers and the proportion of cases the model can resolve.
We'll write about these areas through our experiments and releases, sharing evaluation methods alongside results. We want developers to have enough detail to test our conclusions against their own workloads.
The future we're working toward is one where you can start with a capable general-purpose model, put it to work, and use verified results to develop models suited to your tasks. As your requirements change, you can keep improving those models through a process you can inspect and control.
You decide what counts as success and the conditions for adopting an update. Through Mubit, we want to make the ongoing work of training, evaluating, and replacing those models manageable for your team.
We're excited to build this with developers running agents in production and researchers working on model adaptation and evaluation. If you're interested in that work, join us at Mubit. Bring a task you want your agents to get better at.