"Train an agent" is one of those phrases that sounds precise and means almost nothing. Ask three people what it involves and you will get fine-tuning, reinforcement learning, prompt iteration, and adding documents to a vector store — four operations with completely different costs, risks and reversibility, wearing one word.
We picked a different word on purpose. We qualify agents. Nothing in our product updates weights, for anyone, ever.
What actually changes
Four things, and they are all inspectable:
- What it reads. Which sources are connected, which are assigned to this agent, and what version of each was in force.
- What context it is handed. The retrieval strategy, the case history, the gold standard it grounds against.
- Which model it routes to. Chosen per capability, changeable, and named in the ledger entry.
- What bounds it. The certificate it has earned, the guardrails in force, the ceiling you set.
Every one of those is a configuration you can read, diff and revert. None of them is a set of numbers inside a model that changed for reasons nobody can reconstruct.
Why we think this is the better lever
Weight updates buy you real things. They can make a small model beat a large one on a narrow task at a fraction of the cost, and for the right team that is a genuine advantage. But they cost you three properties that matter enormously to the people who have to authorise an agent to touch a payment rail.
They cost you reproducibility: you cannot cleanly explain why a fine-tuned model behaved differently this quarter. They cost you separability: once behaviour is baked into weights, you cannot isolate which change caused which effect. And in most architectures they cost you data locality, because the training data has to go somewhere.
An operations director does not need the agent to be marginally better. They need to be able to say what it is allowed to do, and to be right.
What we hear in almost every conversationThe honest limitation
This approach has a ceiling, and we should name it. If the underlying model genuinely cannot perform the reasoning a role requires, no amount of context engineering, routing or bounding will fix that. Qualification measures and constrains capability. It does not manufacture it.
When that is the wall you are hitting — you need a model that is materially better at your specific task, and no configuration reaches it — you want a post-training platform, not us. That is a real and growing category, and it is a different layer of the stack. What we would say is that a model trained to be excellent at your task still arrives with the original problem unsolved: nobody can yet state what it is permitted to do, or prove what it did.
Those are complementary problems. We are only claiming to have solved the second one.
