World model labs won't say what they're building. The interview question that makes a candidate say it.
On September 18, 2026, TechCrunch published an account of a world models panel its writer had moderated at the All In conference. The piece describes a field with plenty of buzz and funding, and very few stated product plans. When the writer pressed Michael Rabbat, a co-founder of AMI Labs and the company’s VP of World Models, on what the company was working on, the answer was, “We’ll talk about it when we’re ready to talk about it.” Over email, Rabbat clarified: “We’re still in a research and building phase, so we’re not talking publicly about any product plans or timeline.” TechCrunch was careful to add that AMI is less than a year old, and that keeping quiet is fair enough. It also described World Labs’ Marble as probably the most fully developed product in the space, while observing that the whole platform “seems more designed to demonstrate capabilities.”
The article's most useful detail comes from a supplier. Alex de Vigan, CEO of Physicl, which supplies data to these companies, told TechCrunch: “I wish they would tell us more. We could build more useful data if we knew what they were working on.” That is what it looks like to work with a capability when nobody will name the product. TechCrunch argues the labs have a reason for the silence, which is that a clear path to market invites funded rivals. A candidate in an interview has no such reason, and yet most answers about AI work behave the same way. They demonstrate capability and never say what was built. The interviewer is left where de Vigan is, unable to do anything useful with what they have heard.
Why they ask it
The question is Tell me about a time you built a product involving AI inference. The important words are product and inference. Most managers with a model in their stack can describe the model. Fewer can describe what happened when that model had to answer a real request from a real user, within a time limit, at a cost someone had to approve.
Inference is where an AI feature becomes an operational commitment. Latency now sits in the user's path. Every call has a cost, and that cost scales with success. The output is not deterministic, so ordinary notions of testing and correctness stop being sufficient. An interviewer asking this wants evidence that the candidate has carried those constraints as a product owner and made decisions under them, not merely sat near a team that did.
The trap
The weak answer is a capability demo. It names the model family, the architecture, the retrieval layer and the vendor. It sounds current. But it describes a platform designed to demonstrate capabilities, and it could be delivered by someone who attended the design review and nothing else.
A second weak answer is a quieter version of the first. The candidate stays vague on purpose because the work felt proprietary or the results were mixed. Secrecy may be rational for a lab delaying competition, but it costs a candidate the interview, because the interviewer can only score what is said.
A strong answer reverses the order. It opens with the user and the job the product did for them. It treats the model as one component with a budget. It spends most of its time on the decisions that inference forced: what ran where, what happened when the model was slow or wrong, and how anyone knew whether it was working.
Applying STAR-T
Situation. Name the product and the user in one breath. For example: Our support agents wrote every reply by hand, and queue times were growing faster than headcount. We proposed drafting replies with a model and letting agents edit and send. This sets out the user, the job and the stakes before any model appears.
Task. State what was owned, and state the constraints as numbers the candidate can defend. A manager might say they owned shipping the drafting feature inside a response-time budget agents would tolerate, and under a per-ticket cost ceiling agreed with finance. Once the constraints have been stated, the decisions that follow make sense to the listener.
Action. This is the body of the answer, and it should be a sequence of inference decisions. We routed classification to a small, fast model and reserved the larger one for drafting. We cached answers for the most common intents. We set a timeout, and when the model missed it the agent got a template instead of a spinner. We built an evaluation set from past tickets, scored by our best agents, and no prompt change shipped without passing it. Each sentence is a choice with a reason behind it. None of them depends on the listener being impressed by the model.
Result. Report the product outcome first, and the system outcome second. The product outcome covers handle time, the share of drafts sent with light edits, and agent adoption. The system outcome is cost per ticket against the ceiling. Bring the real figures. If one metric disappointed, say which one. An answer made up only of wins sounds like a demo.
Trade-off. This question rewards a candidate who names a cost. The smaller routing model misfiled long, multi-issue tickets more often, so we sent those straight to humans and accepted that the feature would not touch our hardest cases. A candidate who can say what the product deliberately did not do shows that they understood what it was for.
The follow-up that breaks weak answers
What happened when the model was wrong?
A candidate who gave a capability demo has nothing to say here, because a demo never has to be wrong in front of a customer. The answer is usually general reassurance about human review or guardrails.
A prepared candidate has a specific incident. They can say what a bad draft looked like, how it was caught, who it reached, what changed afterward, and how the evaluation set grew so that the same failure could not ship twice. They can also say how the error rate was measured in production rather than assumed from testing. De Vigan's complaint applies here as well. The interviewer can only build on an answer if the candidate has said what they were actually working on.
Score your answer against the director’s bar
Q: Tell me about a time you built a product involving AI inference.
Bank the one AI product story where the constraints, the fallback and the failure can all be named, and rehearse it until the follow-up holds. Try it free →