AI Needs Better Batteries. Better Batteries Need AI

From iron-air batteries to CO₂ storage, the next energy breakthrough may be coordinating electricity and computation—not just inventing a better battery

---

Training a model is a computing problem.

Keeping its infrastructure powered through a windless night, a demand spike, or several days of weak renewable generation is an energy problem.

Increasingly, those two problems belong in the same architecture.

AI can help improve how energy storage is designed and operated. Energy storage can help supply the electricity that AI infrastructure needs. Between them sits a third opportunity: software that coordinates when electricity is stored, when it is released, and when flexible computation runs.

The most interesting connection is not an LLM attached to a battery dashboard.

It is coordination.

Two directions of innovation—and a missing middle

The relationship between AI and energy storage runs in two directions:

AI → Energy storage
Better models, experiments, forecasts, and operating decisions

Energy storage → AI
Electricity available beyond the moment it is generated

Both directions already have concrete examples.

Researchers at Pacific Northwest National Laboratory have combined neural networks with physical models to study redox flow battery performance. Google, meanwhile, has announced a collaboration with Energy Dome to support long-duration storage deployment. pnnl

But the missing middle is where things become especially interesting for developers:

Forecast renewable generation
            ↓
Estimate available storage
            ↓
Understand computing deadlines
            ↓
Optimize energy and workload schedules together
            ↓
Execute within explicit operating constraints

Instead of treating a data center as an inflexible electricity consumer and a battery as an isolated asset, we can investigate them as parts of a coordinated system.

First, stop treating every battery as the same product

“How long can it supply power?” is a different question from “How efficiently does it return stored electricity?”

And neither question tells us everything about lifetime, operating cost, deployment constraints, or maintenance.

The technologies entering this discussion are also more diverse than the word battery suggests:

Technology	Example company	Storage mechanism
Iron–air	Form Energy	Electrochemical storage
Vanadium flow	Invinity	Electrochemical storage using circulating electrolytes
Aqueous zinc	Eos	Zinc-based electrochemical storage
CO₂ storage	Energy Dome	A thermomechanical cycle
Advanced compressed air	Hydrostor	Compressed-air energy storage
Liquid air	Highview Power	Air liquefaction and subsequent energy recovery

These are different engineering systems, not interchangeable versions of one device. formenergy

Their intended time horizons differ, too. Energy Dome describes an 8–24-hour operating envelope, while Form Energy targets approximately 100 hours of discharge. blog

That creates a software problem: how should resources with different capabilities work together?

1. AI can improve the models behind storage

A storage controller needs some representation of the equipment it operates.

How much usable energy remains? How will performance change with temperature? What happens if operating conditions shift?

One promising approach combines physical modeling with machine learning rather than asking a neural network to learn everything from scratch.

A PNNL study coupled a deep neural network with a multiscale redox flow battery model. It investigated variable electrolyte inlet velocity to reduce pumping power, with a small reduction in discharge power. This was a modeling result—not proof of performance in a particular commercial product. pnnl

The distinction matters.

“AI improved a simulated operating strategy” is a useful research result.

“AI has solved commercial battery efficiency” is a different claim.

Where this could go next

The following are project directions, not claims about what the named companies currently deploy:

• For flow batteries: estimate internal conditions and investigate pump scheduling.
• For iron–air systems: model usable energy and plan reserves across several days.
• For zinc batteries: investigate charging strategies and detect abnormal behavior.
• For CO₂, compressed-air, and liquid-air systems: develop fast surrogate models for operating-point optimization.

Each proposal needs equipment-specific data, physical constraints, and validation.

A model that works for one storage chemistry does not automatically transfer to another.

2. AI can help decide which experiment to run next

Improving storage also means improving materials and manufacturing processes.

Here, the useful question is not simply:

Can a model predict a material property?

It is:

Which experiment should we run next to learn something valuable?

That creates a feedback loop:

Propose conditions
        ↓
Run experiment
        ↓
Measure outcome
        ↓
Update model and uncertainty
        ↓
Select the next experiment

Researchers at PNNL and the University of Washington demonstrated an autonomous experimental workflow for optimizing the synthesis of fluorenone derivatives relevant to redox flow batteries. Using Bayesian optimization over factors including concentration, reaction time, and temperature, the workflow identified 11 conditions with synthesis yields above 90%. pnnl

That percentage describes chemical synthesis yield.

It does not describe battery efficiency.

This is exactly the kind of distinction good technical communication must preserve: AI may improve one step in a development pipeline without solving the entire energy-storage problem.

3. The larger opportunity is deciding when to use what

Imagine a hypothetical system with:

• Wind and solar generation.
• A storage resource intended for shorter-duration cycling.
• Another intended for multiday energy delivery.
• A data center with both urgent and deferrable workloads.

A simplistic strategy might discharge whichever storage asset currently looks cheapest.

A better research question asks what that decision does to the next several days.

Should the system preserve long-duration reserves because low renewable production is likely tomorrow?

Should it run a flexible computing job now, while electricity is abundant?

Should it keep additional reserves because the forecast is unusually uncertain?

These are connected decisions.

A proposed architecture could separate them into distinct layers:

Telemetry and external data
            ↓
Probabilistic forecasting
            ↓
Equipment state estimation
            ↓
Constrained optimization
            ↓
Validated operating schedule
            ↓
Execution and monitoring

Not every layer needs AI.

For an initial implementation, I would use machine learning for forecasting and state estimation, then pass those outputs to an optimizer with explicit constraints.

The optimizer should account for limits such as:

• Available energy.
• Charging and discharging power.
• Equipment operating boundaries.
• Required reserves.
• Computing deadlines.
• Restrictions on grid import and export.

The LLM, if included, belongs in an interface or analysis layer—not as an unrestricted actuator.

4. Storage is also becoming infrastructure for AI

The connection is not only theoretical.

Google’s Energy Dome announcement describes using storage to shift clean electricity across 8–24 hours, bridging the gap between when renewable power is generated and when it is needed. blog

Separately, reporting on Google’s Minnesota data-center arrangement describes planned Form Energy storage of 300 MW and 30 GWh. These are announced project specifications, not evidence that the full installation is already operating. trellis

Power and energy are different quantities:

• MW describes the rate at which electricity can be delivered.
• MWh or GWh describes how much energy can be delivered over time.

For the announced figures, 30 GWh divided by 300 MW corresponds to 100 hours at rated power.

That is a different planning horizon from shifting electricity across an evening.

It also suggests a compelling software research direction: coordinate storage dispatch with computing schedules.

5. Build an experiment, not an “AI-powered” label

A useful first project does not need a physical battery or access to a hyperscale data center.

Start with a simulation.

Define the system

Use time series for:

• Renewable generation.
• Electricity prices.
• Inflexible demand.
• Flexible computing jobs and their deadlines.

Add two storage models with different durations, efficiencies, and operating constraints.

Keep the assumptions explicit. A generic storage model should not be presented as an accurate digital twin of a proprietary product.

Compare meaningful baselines

Test at least three strategies:

1. A rule-based controller.
2. A forecast-based optimizer.
3. Joint energy-and-compute scheduling with uncertainty-aware forecasts.

This prevents a weak evaluation in which an elaborate AI system only competes against an obviously poor baseline.

Measure the whole outcome

Track:

• Electricity cost.
• Unserved demand.
• Missed computing deadlines.
• Storage losses.
• Constraint violations.
• Sensitivity to forecast errors.

Do not celebrate a lower electricity bill if the system achieves it by missing critical workloads or exhausting reserves.

For developers interested in flow-battery modeling, PNNL’s open-source EZBattery provides a physics-based starting point for simulating concentrations, potentials, and cycling performance. It is not itself an AI controller or a complete microgrid simulator. github

The breakthrough may be between the components

Better materials matter.

Better storage hardware matters.

But a system can also improve because its components stop making decisions in isolation.

A storage controller should understand the consequences of using energy now rather than later. A workload scheduler can be designed to account for electricity availability—not just processor availability.

That is the opportunity worth investigating: not a battery that “thinks,” but an architecture that coordinates energy and computation under real constraints.

The strongest result will not be an impressive dashboard or a persuasive chatbot.

It will be a reproducible experiment showing that the same resources can deliver more reliable service, meet computing deadlines, or reduce cost—without hiding the trade-offs.

created by: https://almodarresieh.github.io/