The Builder's Chair: Lancelot Convert & Clément Poiret on Why Edge AI Needs to Learn While It Runs

The Builder's Chair is Critical Ventures' founder interview series — conversations with the people building the companies in our portfolio. We go deep on the decisions that shaped the business, the hard years that didn't make the press release, and the bets they're making on the future of their industry.

Rhizome Labs is a Paris-based AI startup and part of Hexa's 2025 (HX25) batch, in the Sprint track — Hexa's pre-seed acceleration program — alongside two other companies called Stronghold AI and Sapper Intelligence, in what Hexa describes as a European Defense & Sovereignty cohort led by partner Guillaume Lerouge.

Critical Ventures backed Rhizome Labs on the read that AI's growth doesn't shrink the edge, it overwhelms it: as real-time inference and on-device fine-tuning become more valuable, the harder problem shifts to latency-sensitive, connectivity-poor environments — vehicles, sensors, industrial machines — where "good enough in the cloud" doesn't hold up. Rhizome's on-device continuous learning, built on co-designed hardware and software that's hard to replicate with an API call, sits squarely in Critical Ventures' Automation and Mobility thesis, where they see defensibility moving toward firmware and the edge itself.

According to Rhizome Labs, the goal behind developing AI technology is to build resilient and reliable task-specific AI systems. These systems are expected to be powerful enough to easily deal with real-world situations, run locally, and won't be constantly connected to massive servers. However, they will adapt to changing circumstances, and integrate human-in-the-loop technology for responsible oversight.

Both founders of the company are described by the company as repeat founders: Lancelot Convert (CEO), previously co-founded Fringuant, a Paris apparel-tech startup that applies body-scan technology to reduce online clothing returns; and Clément Poiret (CTO), a PhD in Neurosciences and Deep Learning from CEA/Inserm, who manages research and engineering.

We decided to talk to both about their journey — one that led to creating a company that promotes open, rigorous AI science, publishes technical research, and is building what they describe as a flat, transparency-driven culture. Read our full investment thesis here.

Lancelot, you went from building body-scanning fit-tech for fashion brands at Fringuant to building on-device, continuously learning AI infrastructure at Rhizome Labs. About as different as two startups can be. What's the one instinct or lesson that actually carried over?

They are actually less different than they might look from the outside.

At Fringuant, our models were serving more than 100,000 users a day, running in real time on their smartphones. That meant we were already dealing with many of the problems that come with deploying AI outside a controlled research environment: latency, compute constraints, model compression, pruning, quantization, training our own models, and making sure everything remained reliable once it was in users' hands.

A lot of the technology we are building at Rhizome comes from asking whether the techniques we had developed internally could be generalized. We had built them because we needed them ourselves, but the underlying problems were clearly much broader than fashion or computer vision.

The lesson that carried over is probably that some of the most interesting AI problems begin after you have trained the model. Getting a model into production, keeping it useful there, and improving it efficiently over time is a very different discipline from simply producing a good benchmark result.

Clément, you spent years studying the hippocampus and building deep learning models for neuroscience research before becoming a startup CTO. What's the strangest crossover moment where something you learned about biological brains ended up shaping how you think about artificial ones?

One of the most interesting crossovers is the importance of identity and memory.

A biological system needs to understand that something remains the same object or concept even when the observation changes. Interestingly, identity is also at the core of many modern neural-network training objectives. If you jointly train an image encoder and a language encoder, for example, much of the learning problem consists of teaching the network that an image and its description refer to the same underlying thing.

Memory is another important parallel. Neuroscience distinguishes, among other things, between semantic memory (general knowledge about the world) and episodic memory (information associated with specific experiences). That distinction provides useful intuition when thinking about how artificial systems should learn.

You don't necessarily want a model to absorb every new observation indiscriminately. You want it to retain useful experiences, relate them to what it already knows, and decide what deserves to influence its future behavior. Those questions are surprisingly similar whether you approach them from neuroscience or continual machine learning.

Your site describes you two as repeat founders who bring together product execution and deep technical research. When the two of you disagree on something, who tends to win — the product instinct or the research instinct?

The one with the best arguments.

We actually disagree less often than people might expect, partly because we don't see product and research as opposing forces. A technically elegant result that cannot solve an important customer problem is not particularly useful to us. But pushing something into a product before we understand whether it is scientifically sound creates a different kind of problem.

So the discussion is usually less about "product versus research" and more about asking: What do we know? What are we assuming? What evidence would change our minds? And what is the simplest way to test it?

Our backgrounds make us challenge problems from different directions, which is useful. But neither of us has a permanent veto based on title or domain. If the evidence is stronger on the other side, that side should win.

Rhizome Labs is built around AI that runs directly on-device and keeps adapting to production data without needing constant cloud connectivity. What's the real-world moment or use case that convinced you this was the problem worth building a company around, rather than another cloud-based model?

We experienced the problem directly in our previous company.

Once a model is in production, improving it is an unexpectedly cumbersome loop. You monitor and test it, identify failures, collect new data, label that data, retrain the model, validate the new version, and then deploy it again. Every iteration consumes engineering time, operational time, and money.

What stood out to us was that training itself was often not the expensive part. High-quality data was. Collecting the right examples and getting reliable labels could be far more costly than running another training job.

That led us to a different question: instead of treating every production model as something static that periodically has to be taken back into the lab, what if the system could participate intelligently in its own improvement?

It should be able to recognize what it does not understand, detect novelty or uncertainty, identify the few observations that are actually worth reviewing, and use that evidence to improve safely. The objective isn't uncontrolled self-learning. It is to make the entire learning loop much more selective, local, and efficient, with humans involved where their judgment has the highest value.

That is the problem we wanted Rhizome to solve.

Your site is unusually open about being "passionate advocates for open-source" and publishing rigorous research, while also building a commercial product. How do you decide what to publish openly versus keep as a competitive edge?

We don't think openness and defensibility are contradictory. The important question is where the actual product intelligence lives.

As a general principle, we want the scientific layer around the product to be as open and inspectable as possible: evaluation methods, benchmarks, definitions, interfaces, limitations, reference methods, and results that allow other people to challenge our claims. If we say a system is reliable, there should be a rigorous way for someone else to interrogate what we mean by that.

Where we are much more protective is the decision-making machinery that turns that evidence into a better product: how we select data, diagnose failures, decide what requires human review, determine whether a model is ready to be promoted, respond to incidents, or learn from recurring patterns in deployed systems. Customer-specific data and operational policies obviously remain confidential as well.

A simple way of putting it is that we want the assurance layer to be open while the product intelligence remains proprietary.

There is also a pragmatic reason for this. AI is moving too quickly for companies to recreate every common capability internally. If something is becoming a standard interface, benchmark, or commodity method, we would rather contribute to it and build on it. Our research capacity should be spent on the problems where we believe there is genuinely new science to do and where solving it creates long-term product value.

On-device and edge AI is getting a lot of attention right now as an answer to cloud costs, latency, and data-sovereignty concerns in Europe specifically. Do you think that momentum reflects real demand today, or is it still ahead of what most companies are actually ready to deploy?

It is still early.

A large proportion of the companies we speak with are not yet asking sophisticated questions about maintaining AI at the edge. They are still working out where AI should fit into their workflows and which use cases justify putting a model into production.

There is a smaller group, particularly companies operating cyber-physical systems, that already has models running in real environments. They see the problem much sooner because failures have physical or operational consequences, connectivity cannot always be assumed, and sending everything back to the cloud is often impractical.

Our view is that the broader market will encounter the same issue after its first wave of deployments. Training and deploying version one of a model is only the beginning. Models age, environments change, sensors change, data distributions shift, new failure modes appear, and suddenly the company owns a maintenance problem it did not have before.

So we think the attention around edge AI is real, but the maintenance problem is still ahead of most of the market. Once many more companies have models operating continuously in the real world, it will become much more obvious.

You're a small Paris team competing in a space where large, well-funded foundation-model and edge-AI players are moving fast. What do you think actually determines who wins here — model quality, deployment simplicity, trust, or something else entirely?

AI is an extraordinarily noisy market right now, so we're not convinced that moving fastest is what ultimately determines who wins.

There is enormous pressure to react to every new model, technique, or trend. Companies can move very quickly and still move in the wrong direction. In that environment, the scarce skill may actually be filtering the noise: understanding which developments matter structurally and which ones will be forgotten six months later.

For the kind of systems we are building, we think long-term technical judgment matters enormously. You need very high-quality science because these systems eventually have to operate in environments where mistakes have real consequences. You need a clear product strategy because good research alone does not create a company. And you need a sufficiently strong vision that you can keep making coherent decisions even while the rest of the industry changes around you.

So perhaps somewhat counterintuitively, the ability to think before acting has become more important in the AI era, not less.

We would rather move deliberately in a direction we believe will matter for the next decade than optimize the company around whatever the market happens to be excited about this month. Speed matters once you know where you are going. Direction matters first.