Part 3 of Kotlin: Behind the Scenes at Leap

How Leap Automated Grid Operator Emails Using Kotlin and LLMs

It was 02:37 when the email came in.
No webhook, no API call, just a plain message from a grid operator:

“URGENT: reduce power consumption in region west.”

Until recently, someone read that manually.
Now Kotlin does it.

From Inbox to Impact

When the electricity grid goes out of balance, Leap steps in.
The company operates a virtual power plant that instructs thousands of distributed devices, batteries, chargers, air conditioners and heat pumps to temporarily reduce consumption or feed power back.

“When the grid peaks, we make sure devices respond. And it all happens in real time, at massive scale.”
/ Bart Kummel, Principal Engineer at Leap

“Some emails contain not one instruction, but several. Each instruction requires multiple checks and calls. Synchronous processing was simply too slow.”
/ Paul Noorland, Software Engineer bij Leap

The challenge: not every grid operator communicates in a modern way.
Some send neat API calls.
Others send email.

Sometimes with structured data.
Sometimes with an attachment.
Sometimes just: “can you reduce by 5MW?”

For years, a support desk read these messages manually and triggered the correct dispatches in the system.

“It worked, but it was not scalable. We wanted to remove people from the loop without losing control.”

From Manual Work to Machine Intelligence

The first attempt: regex and template parsing.
Fine for one sender. Disastrous for five.
As soon as someone changed “Start Time” into “Dispatch Initiation”, everything broke.

“We needed a parser that was as flexible as the people we were trying to replace.”

Leap built a lightweight Kotlin service that automatically processes incoming emails.
Depending on the sender, the service selects a prompt describing what must be extracted, such as fields like start_time, end_time and dispatch_target.

The service uses a Large Language Model (LLM) to read the email and return a strict JSON result.
No hallucinations allowed.

“We use LangChain4j. It is minimalistic, but exactly what we need.”

Kotlin provides type safety.
LangChain4j provides AI abstraction.
Together they turn emails back into data.

Prompts in YAML, Not in Code

Each type of email has its own YAML prompt.
This allows operations and market teams to add new formats without involving a developer.

email_parser:

  sender: "operator@example.com"

  prompt: |

    Extract dispatch instructions from the following email:

    Subject: {email_subject}

    Body: {email_body}

    Return JSON with fields:

   - start_time

   - end_time

   - dispatch_target

“Some grid operators change their format without telling anyone.
Because prompts live outside the code, we can adjust immediately without shipping a new release.”

Learning, Refining, Iterating

The service learned quickly.
With temperature set to 0.0, the output stayed predictable.
A few well-chosen examples in the prompt significantly improved consistency.

Not everything was perfect.
Poor email formatting could still confuse the model.
But Kotlin’s validation layers kept reliability high.

“We do not use AI to make decisions, but to extract data.
The human decides. The AI calculates.”

The Results

The LLM service is now running in production.
What used to be a 24/7 manual task is now automated and extremely fast.

• Instant response times, no queues
• New dispatch programs added in minutes
• Full traceability from email to JSON output

“We do not call it an AI transformation.
It is simply automation that works.”

Accelerating with Non-Blocking Calls

As the number of energy programs supported by the service increased, the volume of emails grew as well. Some emails did not contain a single instruction for one resource, but several. For each resource, a separate call had to be made to check whether meters were available. Meters then had to be grouped per resource, and another call had to be made to send the correct instructions.

This resulted in multiple synchronous calls forming a long chain.
Leap decided to move these calls to coroutines, a powerful Kotlin feature that lets external calls run non-blocking. The service no longer waits for responses, but continues processing other tasks. Once all responses arrive, the service proceeds to the next step.

Practical advantages:

• The service no longer blocks during wait times
• Multiple calls run in parallel
• Structured concurrency keeps the flow manageable despite parallelism

By using this approach, long chains of sequential calls disappeared and the application became significantly faster.

Kotlin at the Core

The entire service runs on Kotlin, intentionally.

“If it compiles, you know it is correct.
And that is exactly what you want when AI output influences energy distribution.”

Kotlin’s type safety, expressiveness and stability made it possible to combine experimentation and production with confidence.
A reminder that modern JVM technology can be both reliable and elegant.

About This Series

With Kotlin: Inside the Kitchen, we highlight how Dutch JVM organizations use Kotlin to create real impact.
In the lead-up to Kotlin Dev Days 2025, we speak with CTOs, engineering managers and developers who practice the craft of software engineering every day.

They build. We listen.

Want to join Kotlin Dev Days 2025?
Follow our LinkedIn page for ticket raffles, community stories and new editions of Kotlin: behind the scene's