Can you use an LLM to build a BESS optimization engine in-house?

Using an LLM to build an in-house battery optimization infrastructure

With today’s large language models (LLMs), building sophisticated software has never looked easier. AI agents can analyze data, write code, review software, and independently work through complex tasks. So, if you understand battery markets, why not use them to build your own optimization engine? The short answer: you can try. But writing the code is only a fraction of the challenge.

For battery optimization, the real complexity lies in everything surrounding the algorithm: data, system architecture, testing, security, validation, market rules, contractual requirements, operational constraints, and the countless edge cases accumulated through years of operating assets in real markets.

A typical customer question we get is: Why did my battery behave this way yesterday evening? A typical context for this is a charge occurring during out-of-norm late-night price peaks. You can use standard LLMs to answer this question. Battery optimization is one connected system, and every link must be transparent. There are prequalification rules, grid constraints (FCAs), outages, hands-off requirements, and many more factors to consider when building a fully automated trading model. It’s not only about building a piece of software with an LLM; it’s about integrating the entire framework around it. For energy trading, this involves critical infrastructure, exchanges, and market surveillance on order activities to prevent market manipulation. You must integrate all of this before you can even start coding. As an optimizer, offering transparency extends not only to the asset owner but also to the regulator, the power exchange, and the grid operator.

What do most people picture when they hear AI?

The approach to solving problems with LLMs is simple. People open their LLM of choice, enter a prompt, and get an answer that, at least on the surface, sounds intelligent and correct. However, classic software engineering has deterministic outcomes, meaning data input is linked to an expected output, and if that output diverges from the expectation, the ensuing exception must be accounted for accordingly.

An LLM, on the other hand, isn’t deterministic; the answer to the same question might be different every time you ask. If you try to create a battery optimization engine with an LLM, you should keep in mind that your identical data input (asset specifications from the EMS, price forecasts, weather forecasts, etc.) will produce different results with every optimization run. The question now is whether LLMs have a place in BESS optimization at all.

Keeping these characteristics in mind, a human component in quality control becomes vital when programming a reliable optimization strategy. Below are two lists of crucial basics needed to lay the groundwork for a functioning, market-proof optimization. An LLM provides none of these.

• Input data used by the optimizer
• Asset telemetry and trading results
• Optimization source code
• Asset-specific parameter files
• Underlying contracts
• Market rules
• Access to the code repository
• Access to the time series database
• Integration with own monitoring
• Integration with third-party tools

Data challenges

The monitoring of an existing optimization algorithm already requires an enormous amount of information. Asset parameters, forecasts, historical dispatch, market prices, grid-access conditions, performance warranties, and potentially hundreds of thousands of time series all need to be available, accessible, and interpreted correctly. Simply feeding an LLM more information doesn’t solve the issue.

In one early monitoring setup, the prompt for a single battery reached roughly 500,000 tokens, and the model can only reason from the information it receives. If an operational restriction is missing or poorly documented, perfectly logical analysis can still come to the wrong conclusion.

That becomes particularly challenging in energy markets, where contracts, regulations, and operational requirements frequently contain grey areas. Turning decades of accumulated domain knowledge into clean, machine-readable information is a colossal task in itself.

Agents don't always listen

The autonomy inherent to AI tools is part of their appeal, but it can also be a risk. During development, agents can be instructed not to access certain configuration files, but they often still find ways to read restricted files and disregard previous instructions. In other cases, agents presented with large datasets decided to sample data rather than process the entire time series, estimating exchange rates for unavailable FX time series. That kind of creativity can help with brainstorming, but it’s a hindrance to validating performance warranties or controlling valuable physical infrastructure.

Another misconception about quickly building an optimization engine with AI is that coding represents the bulk of the work. In reality, building an LLM-based system for monitoring batteries took over six months, and while the coding itself was accelerated at an acceptable token cost, the reduction of overall effort and work amounted to only 10%. Design, testing, validation, cybersecurity, software architecture, quality assurance, and other aspects of the technology require reliable software engineering LLMs are unable to develop.

Our internal analysis estimates that rebuilding an existing optimization platform from scratch, with the help of the same people who developed it manually in the first place, would still take approximately three years. The existing technology represents seven years and around €48 million of work, but an estimated 98% of its complexity is invisible to clients.

If you ask an LLM whether it can build such an infrastructure for you, it’ll probably say yes and make the process appear simpler than it is. And when you ask again, it might voice some concerns but maintain its positive outlook. The question is, would you trust such an engine with a multi-million-euro battery?

[This section was provided by Nichola Plower, Partner at Baringa]

The external perspective

Business management consultancy Baringa addressed the question of build vs. buy vs. partner at get enspired! 2026. With batteries entering a new growth phase and enormous capacity coming online—Baringa estimates an increase from 20 GW to 145 GW by 2030—the commercial strategy for these assets should consider more than the mere stacking of revenue pools. The models behind the monetization of batteries must adapt quickly and take into account factors like degradation economics, market locality, contractual limits, regulations, co-optimization, asset health, and a portfolio-specific bidding logic. These parameters are precisely why a plug-and-play solution for optimization is questionable at best. Simply put, poor data going in equals bad results coming out. Therefore, it’s not just the amount of ingested data that matters but also the quality.

Market-proof optimization relies on continuous learning – learning from the market, from assets, from grid behavior, from governance, from itself. The market and the regulations around it are evolving non-stop, and the optimization has to stay on top of that if you want to maximize revenues.

[This section was provided by Nichola Plower, Partner at Baringa]

Buy, build, partner

So, what’s the best approach if you want to successfully monetize your battery in dynamic markets and modern energy landscapes: buy, build, or partner? Buying software as a service for these kinds of requirements was typical in the past, but BESS made trading move beyond that. Data is much more critical now for positive trading outcomes. The role of human capital is no longer execution but has shifted from using the bought software to calibration and curation of logic.

Baringa looked into client examples of buy vs. build vs. partner.

• Building in-house: A client spent nine months technically finetuning its optimization platform, although an agile approach that would have prioritized data from the start could have enabled market entry much earlier and focused on market and geographical nuances.
• Expanding through acquisitions: An IPP considered acquiring optimization technology and commercializing it externally but ultimately decided to focus on its own portfolio.
• Acquiring an optimizer: An energy company found acquiring an established trading-as-a-service provider more economical than self-building, gaining expertise, technology, and organizational agility.
• Buying technology: A company acquired a battery optimization platform but struggled with integration due to competing internal priorities.

The key learning is that optimization isn’t a one-size-fits-all type of business. Even companies with enough resources face challenges around strategy, investments, time-to-market, and internal prioritization. These experiences highlight the importance of careful consideration when rationalizing whether building in-house or buying existing software brings more value than partnering with a professional optimizer.