The demo is impressive. What would make it investable?
A demo is one point. What matters is how far you can move from it, what moving costs, and whether the point sits inside the region the system was built for.
A demo is one point. Somebody chose it, and they chose it from a space of possible settings, inputs and conditions that you are not being shown. Nothing about that is dishonest — you would choose the good point too. The question that decides whether the demo means anything is what the space looks like around it, and that is a question the demo is structurally incapable of answering.
The three things I want to know are how far you can move from that point before the behaviour changes, what it costs to move, and whether the point sits inside the region the system was actually built for.
Control is not free, and the honest form of it is a curve
On a system I led, we built agents that perform a fixed task while taking an instruction at runtime about how to perform it — do this job, but in this manner. One policy, many behaviours, no retraining between them.
That capability demos beautifully. You ask for a behaviour and it appears. What the demo does not show is the trade. We measured it: as you push harder for the requested behaviour, adherence to the request goes up and success at the underlying task goes down. At zero pressure the agent does the job well and ignores your preference entirely. The interesting object is not either endpoint but the curve between them, and the user is really choosing a point on it.
Any system offering behavioural control is likely to have some trade-off surface, whether or not anyone has drawn it. Tone control in a language model, aggressiveness in a trading policy, caution in a driving stack: the control is being bought with something — task performance, latency, compute, stability, or operating margin. A team that has plotted the surface can tell you the exchange rate. A team that has only ever demonstrated one point has shown you that the control exists, which is a weaker claim than it appears.
So the first question is: show me the frontier, not the point. And if the frontier hasn’t been measured, that is itself informative — it means the trade has never been priced, including by them.
The demo point is almost always inside the trained region
The second thing the demo cannot tell you is whether you are looking at generalisation or at recall.
In the work above, control is reliable within the region of settings the system was trained across, and we said so in the paper. Outside it, the behaviour is not guaranteed to hold — an agent can learn one setting well and transfer poorly to a neighbouring one. This is not a defect of that system; conditioning on a parameter does not by itself guarantee useful behaviour outside the range the system was trained across. Which is why we deliberately trained across a wider range of settings than we intended to use, so that the useful range sat comfortably inside the trained one rather than at its edge.
For an assessment this converts into a question with a factual answer: was the demo configuration inside the range the system was trained across, and how close to the edge? A demo at the centre of the trained region tells you the system works. A demo at the centre presented as evidence that the system generalises tells you something about the team.
The related question is what happens when you leave the region on purpose. In the same work we tested five out-of-distribution situations, including opponents the agent had never encountered. It largely held up, and it degraded in the hardest case — a configuration that does not even occur in the deployed setting. I would much rather see that pair of results than a clean sheet. A team that reports where their system fell over has been looking; a set of results with no failure anywhere raises the question of what was tested.
Composition is where the interesting evidence lives
There is a third question, and it is the one that separates a controllable system from a system with a set of switches.
If a system supports several behavioural controls, can it do two of them at once — including a pair it has essentially never seen combined? In our case the agent executed combinations it had encountered less than once in a million training scenarios. We also saw it doing something more interesting than obedience: asked for a behaviour that required a weak instrument, it used the weak instrument to set up the situation and then switched to a stronger one to exploit it. It was not following the instruction literally; it was pursuing what the instruction rewarded, in context.
That distinction matters commercially. A system that composes controls it wasn’t explicitly trained on has learned something about the structure of the problem. A system that only handles combinations it was shown may have learned a narrower mapping than the demo suggests, and adding the next customer’s requirement is then a training run rather than a configuration change. Those two systems imply very different marginal costs for serving the next customer, and from the outside, on a demo, they look the same.
What I ask after a demo
What is the frontier, and where on it are we standing? Every control is bought with something. If nobody can name the currency, the trade hasn’t been measured.
Was this configuration inside the trained region? And how much of the space around it has been evaluated, rather than assumed.
Show me a combination you didn’t train for. Composition is one of the cheapest tests of whether the system learned reusable structure rather than only the cases it was shown.
What did you try that didn’t work? Not to catch anyone out. A team that can answer this has explored its own space; a team that can’t has explored the path to the demo.
What does the next customer’s requirement cost you? A configuration change, a fine-tune, or a training run. The answer determines whether this is a product or a series of projects, and it is usually more legible than any technical claim on the slide.
The part that generalises
None of this is specific to agents, or to games, or to reinforcement learning. It applies to any system whose behaviour is conditioned on something — a prompt, a parameter, a customer configuration.
A demo shows that a system can reach a good point. An investment case needs the shape of the space around that point: how far you can move, what it costs, and where the edge is. Teams that have measured it tend to show you willingly, because it is the most interesting thing they know about their own system. If the only answer to those questions is another demo, I still do not know the shape of the system.
This is the kind of thing I work through in technical due diligence — what the evidence establishes, what it doesn’t, and which experiment would settle the difference.
Evidence
- arXiv 2026 first author, project lead