Energy taught me that knowing a fact and knowing what to do with it are different problems. That distinction is at the heart of my work on decision systems.

My understanding of artificial intelligence is strongly shaped by my experience in the energy sector. Energy efficiency, self-consumption and project finance led me to work on problems that required linking installations, commercial terms, costs and business needs. None of those pieces made much sense on its own.
An offer could look good until we reviewed the contract. An investment could seem attractive until financing was included. A measure could reduce consumption and still make the company’s operations more difficult.
So when I think about applying artificial intelligence to an activity, I start with a question: what does the system need to know for its proposal to make sense? That may sound less ambitious than building an intelligence capable of doing everything. Once you try to answer it in sufficient depth, it no longer seems like a small question.
Imagine a facility that wants to reduce its energy costs. To study the options, we need to relate consumption to equipment, schedules, production, the contract and operating constraints. Gathering the bills is only the start.
We also need to distinguish what we know from what we are assuming. A contract price may be documented. Next month’s consumption requires a forecast. The possibility of shifting an operation depends on conditions we may not have checked yet. Even when we bring this information together in a conversation, we still need to know what has been verified and what rests on an assumption.
This is the problem I want to address with sector-specific world models: building a useful representation of an activity and connecting it to the calculations and models needed to study what could happen if we intervene.
The decision defines the scope: represent enough to solve the problem while preserving the relationships that could change the conclusion. An inventory identifies assets; a behavioral model studies how they respond. A graph can show connections; attributing a cause requires other evidence. A simulation lets us explore scenarios under assumptions that must later be checked against the actual facility.
This way of working connects with several research areas. World Models, by Ha and Schmidhuber, and Dreamer study how to learn representations of an environment and use them to anticipate scenarios and improve an agent’s behavior.
Brick, in turn, makes it possible to describe a building’s assets and their relationships through a shared vocabulary. It addresses a different need: enabling different tools to interpret what each element of a facility represents.
My view is that these capabilities complement one another. Identifying a piece of equipment, predicting its behavior and deciding how to operate it are related tasks, each with its own role. This leads to a design principle I consider essential: choose the tool according to the problem.
If a formula is known and there is enough data, I prefer to calculate. If the result depends on future demand, I need to estimate it and express uncertainty. A language model can help interpret a document or a request. Choosing among alternatives requires explicit objectives and constraints.
I want to retain the precision of a verifiable calculation while making use of a good prediction even when it is uncertain. The value lies in connecting them while understanding what each can contribute.
I use the term “vertical AGI” to explore a capability broader than automating one isolated task: a system able to tackle different problems within a sector, connect knowledge, propose alternatives and review its actions when conditions change.
The generality I want to study is bounded by that domain. The term describes a research direction whose scope must be supported by evidence.
The distinction between performance, generality and autonomy described in Levels of AGI is useful here. Solving one task very well, adapting to different tasks and acting with greater independence are distinct properties. Each needs an evaluation that helps us understand what has been achieved.
In a company, I would add another distinction: the ability to find a solution and permission to execute it. The boundaries of action reflect the responsibility granted by the organization; intelligence is assessed by the problems the system can solve.
My work at TheryOS starts by connecting these needs around an organization’s activity. The idea is to build a foundation on which calculations, predictive models, tools and people can work together while preserving the context of decisions.
My starting point is that the company’s activity should organize the system. Language models can help interpret and communicate; calculations, rules and specialized models should handle the parts that belong to them.
What I want to test is whether this integration helps solve sector problems better: with less information lost between tools, more useful alternatives and results that can be reviewed. That is the direction of the work. The name matters much less than the evidence that supports it.
Founder of TheryOS, business owner and entrepreneur in the energy and financial sectors.