Agentic EV Charger Maintenance

Inspiration

EV charging has been a personal journey for me. For 7 years I architected and built charging backends for Porsche as Technical Lead. Having seen how charging operations look like first-hand and experiencing the large ingress messages indicating drivers charging successfully has been a moment when I knew me and my team were doing something significant. However, in every field operation there are faults and errors - one of the most impactful is charger downtime - especially when a firmware is rolled out and some software error occurs and the charger runs into a death spiral loop, or when the wrong URL gets falsely overridden or when the mTLS certificate is rolled back to factory setting and charger no longer connects. Things like this usually require a field visit and leave the charger offline for days, even weeks.

My mission is to use my software development skills and knowledge to build something of value for the EV charging ecosystem.

What it does

Web3 Energy is an EV charger management platform that offers management, uptime and recovery, 24/7 agentic support, billing, roaming and compliance. The goal of the platform is to be minimalistic and focus on agentic and automation.

For the hackathon we focused on our Remote Link technology and have paired it with the Web3 Energy backend in such a way that a broken charger becomes a closed case without a human. The backend detects the fault, opens a case and wakes the agent team. The Investigator digs through the evidence, figures out what broke and proposes one fix. The backend checks it against policy and signs the exact command. Remote Link runs it on the charger. And a separate deterministic verifier only closes the case when fresh evidence from the charger proves it actually recovered. The whole dance takes 3-5 minutes, including the analysis and validating the fix. No field visit. And judges can break our real charger themselves and watch it happen.

How we built it

Three trust domains that deliberately do not trust each other. The part that thinks never signs. The part that signs never executes.

 CHARGER (Pi)          AWS CONTROL PLANE           GOOGLE CLOUD
 +--------------+      +--------------------+      +--------------------+
 | EVerest      |--1-->| Web3 Energy        |--2-->| Pub/Sub            |
 | OCPP 1.6J    |      | backend            |      | id-only activation |
 |              |      | detect, open case  |      +---------+----------+
 |              |      | PostgreSQL + S3    |              3 |
 |              |      +--------------------+                v
 |              |      +--------------------+      +--------------------+
 |              |      | Evidence + action  |<--4--| ADK Investigator   |
 |              |      | policy + AWS KMS   |--4-->| on Cloud Run       |
 | Remote Link  |<--5--| signs the exact    | LOOP | Gemini 3.7 Flash   |
 | agent        |      | command            |      | on Vertex AI       |
 | executes     |      +--------------------+      +--------------------+
 +------+-------+      +--------------------+
        |              | Recovery Verifier  |
        +------6------>| deterministic      |
                       +--------------------+

The charger reports over two independent connections - EVerest via OCPP and Remote Link via HTTPS - so a healthy Linux process cannot hide a broken charging path. The AWS backend (Java 25, Quarkus) detects the fault and opens exactly one case. It publishes an identifier-only event to Pub/Sub - no charger data travels in the activation. Pub/Sub pushes it to our Google ADK Investigator on Cloud Run, scaling from zero. Then comes the loop: Gemini 3.7 Flash on Vertex AI asks for evidence through scoped tools, AWS answers with only this charger's data, several rounds, one repair proposal. Policy validates it, AWS KMS signs the exact command into a short-lived envelope, and Remote Link - outbound only, zero open ports, no SSH - verifies the signature on the device before running anything. One remediation per run. Budgets live on the server where the model cannot negotiate them. And the verifier that closes the case is deterministic code, not the model. Command success alone never closes a case.

The charger is a Raspberry Pi running EVerest, Remote Link is our open-source Java agent shipped as a self-contained executable, and 900+ tests plus a Python acceptance suite that injects all four faults keep the whole thing honest.

The demo charger can be found here: https://web3-energy.com/app?level=charger&charger=w3e-pi (Any google login will do, the charger is in a demo space visible to all)

The charger can be broken via: https://web3-energy.com/demo/charger (Also contains info about what each fault is and a diagram explaining the flow as well as link where the fault can be seen. Keep in mind it can take up to a minute until fault is detected and reported, we are not overreacting to a systemd recoverable service)

The AWS and GCP deployments are both fully terraformed and can be verified. The video also shows the Cloud Run dashboard running our agentic investigator. Pub/Sub is also used. It is all in the code.

Challenges we ran into

Sizing the idea and what to build correctly: it had to be big enough and doable with quality.
Deciding if we open source Remote Link or not
Building and maintaining the Raspberry Pi Charger - we chose EVerest, because it is open source.
Making Remote Link work on most machines - we decided to use Java and even ship it with the executable.
Regression tests - even with clean code architecture and careful changes, we had regressions. We solved it by having more than 900+ unit and component tests, dedicated quality gates and acceptance tests that use Python and run ALL important cases ensuring AI can recover all of them. Note that this is not deterministic and in the last days had almost 100% success, giving us confidence in our design
Security and agentic boundary was the hardest problem - How do you design the recovery execution so that it is secure and there is clear separation between fixing the problem and validating the fix. Also controlling what is executed on the charger and ensuring we do not break more has led us to design a loop and choose a more controlled approach preventing the agents to spawn many commands on the charger effectively breaking more.
Documentation and presentation was a challenge too.

Accomplishments that we're proud of

Remote Link is open source and can be installed on every Linux charger. It is still evolving.

How the whole dance of detecting a fault, gathering evidence, investigating, acting and verifying is built. Separating the verification from the agent that repairs was crucial design. Also ensuring command bounds, building HSM capabilities, signing with KMS and having short-lived envelopes feels great. Security and controlled intervention was important, especially when the underlying asset being manipulated is an EV charge point. I am sure we can improve a lot, but I am very happy with the current security measures we deployed. Our product is so much more than simple command execution.

The page that allows for easy testing and describes the architecture. With that many submissions, making the result understandable and testable is important. We wanted REAL test, REAL challenge for our agentic repair flow - and we built it. Four distinct faults, where two of the scenarios are very challenging - random config faults preventing startup and wrong energy registry socket, preventing energy reporting, while everything else seems ok.

Also building and investing time in upgrading dependencies, keeping clean code architecture and code complexity low. This required discipline and effort.

Last, but not least, proud to have participated here. It simply is great spending your time building something. I have loved every minute of it.

What we learned

Building a short agentic demo is easy. Building a secured, well-designed agentic team, that can operate and remedy arbitrary faults is complex and in itself beautiful.

Designing how to execute commands and fixes securely on the charger, choosing the right architecture was a huge challenge. Having the final result, is cool, but there is a lot of design and decisions along the way that shape it.

I personally learned a lot about GCP and some of its components. (I come from AWS world)

What's next for Agentic EV Chargepoint Management

Taking a short break - the work done here was substantial and a few days with my wife and son are the best way for me to reset.

On 8th of September I will attend the EV:ent Conference and will present and talk about this exact product and what our software can do. As EV grows, CPOs operate more and more chargers, which comes with new problems and challenges.

Stay curious and stay positive! ; ) See you in the shed.